Ecosystems - The key to success for all future financial services companies

While the word "Ecosystem" was almost unused in the financial services world a few years ago, today it is on the top of the agenda of every bank and insurance company. As always, with such a loaded term, it is important to take first a step back and oversee the bigger picture.

Ecosystems in the financial services industry are a logical evolution of a number of trends:

• The trend towards more customer-centricity, i.e. it is important to service customers as part of their customer journey, meaning at the moment (time) and place (location) where it is most relevant for them and this with ultimate convenience, i.e. in the most frictionless, proactive, (hyper-)personalized and invisible way possible. This results in concepts like embedded finance and (banking) apps transforming into super-apps.

• The trend to be more open with regards to data. With GDPR forcing companies to move ownership of data from the company collecting the data to the user to which the data relates. As a result, data should be much more accessible, in order to meet the legal requirements of a user’s right to inspect/access (view) and correct/rectify (modify) his data, to transfer his data (i.e. data portability) and his right to be forgotten. The PSD2, Open Banking and Open Insurance initiatives fit perfectly in this trend.

• The increasing need to be agile and fast (first) to market. With incumbent financial services companies often lacking this flexibility and having a culture of risk-aversity (i.e. no "culture-of-innovation"), they need to partner with smaller companies (e.g. Fintechs), which can bring innovations much faster and can better deal with the risks associated with new products and services.

• The increasing cost of customer acquisition, as it becomes more and more difficult to get the attention of users, who are bombarded with offers and information 24/7. As a result, a smaller firm (start-up) is unlikely to position its product on its own, unless it can spend millions of VC money in marketing. The companies with less deep pockets are therefore forced to partner with existing institutions with large customer bases (like the incumbent banks and insurers).

• Technological evolutions like cloud and APIs (supported by tools like API Gateways, Sandboxes, Developer Portals…​), which make partnerships and ecosystems much easier to setup, as it becomes easier to expose internal services in a secure and controlled way to the outside world. Furthermore technologies like cloud, micro-services and containers allow for a start-up to be much more scalable and meet other non-functional requirements (like security, availability, performance…​) imposed by an incumbent bank. Before such requirements were often too costly to be met by a start-up, but today thanks to different open source tools and cloud offers, even a small start-up can meet the highest non-functional requirements imposed by a financial institution.

• Increased transparency and facilitation in finding the right offer, i.e. customers tend to compare more and more the offers of different financial institutions, with marketplaces and online (price) comparators facilitating this research. As a result financial services companies are forced more and more to be present on these digital platforms, where demand and supply is matched (i.e. matching a user with the best possible offer).

• Innovation becoming more and more costly, due to increased complexity, which makes it difficult for each financial services company to build every innovative service/product on its own. Often it is better to partner with a third party, which can offer these services (usually in a white-labelled solution) to different financial companies. This allows a financial services company to invest in (and try out) multiple innovative products and services, without having to do enormous investments and undergo first a big bang digital transformation.

All these trends (Open Banking, Open Insurance, Open Data, PSD2, Marketplaces, Super-Apps, API Economy, Embedded Finance, Experience Banking…​) enforce each other for the financial industry to be (even) more open and outward looking.

Overall we can classify partnerships (and their resulting integrations) from the position of the bank or insurance company in 5 categories:

• Banks or insurance companies giving access to their data, e.g. PSD2 forcing banks to give access to third parties to retrieve the balance and transaction history information of cash accounts. Currently this is still very premature as only basic information (on cash accounts) can be accessed, but in coming years other data like credit card information, securities account information, insurance information…​ will all become accessible via well-defined and user-friendly APIs.
  Already today these data consultation services are resulting in interesting use cases, like account aggregation, PFM/BFM services, robo advise, deals cash-backs, risk scoring (for insurance, credit and counterparty risk), automatic loading of accounting systems, expense management, (gift) vouchers handled via cash-backs…​

• Banks or insurance companies integrating their products (for sales, but also for servicing) in customer journeys (i.e. embedded in non-bank networks and delivered in context, where consumers want them) on other platforms (like travel agencies, eCommerce platforms, car dealers, accounting platforms…​), but also in market places, comparators or even competitors. Today these integrations are still limited to only simple, standardized products and services, like payment initiation (via payment buttons), origination of consumer credits, bike and car leasing, car insurance…​, but these integrations will likely evolve towards more complex products and services, which are more personalized and even more frictionless.

• Banks or insurance companies expanding their app or web portal with third-party services and in extreme examples positioning their app as a super-app. Not every bank aspires this positioning, but if a bank or insurance company wants to keep selling its products and services via its own channels, it needs to increase the attractiveness for its users to come to its channels.
  As explained in my blog on super-apps (https://bankloch.blogspot.com/2020/08/from-app-to-super-app-to-personal.html), next to the international super-apps (most likely taken by Big Tech), there is room for 1 or 2 local super-apps (per region). Financial services companies are well-positioned to take this spot, which can give large rewards if done well.
  In this category of banking/insurance apps opening up to other services, we can identify 2 sub-categories:

  • Getting access to third-party information, like account aggregation (with accounts at other competing banks), showing balance and transaction history of social vouchers (like Monizze), integrating accounting information in BFM part of app, getting health information from health sensors or car telemetry information from car sensors…​ (cfr. also my blog on IoT sensors: https://bankloch.blogspot.com/2020/02/iot-revolution-or-evolution-in.html)

  • Initiating daily transactions from the app, like buying third-party products and services (like car park entry and exit, tickets on public transport, the use of shared bikes, cinema and entertainment parc tickets…​) in a fully integrated way.

• Banks or insurance companies acting as a lead generator for other products and services, like cost improvements (e.g. facilitating switch of utilities company to reduce recurring costs), deals like coupons and cash-backs (to facilitate customer acquisition to retail merchants), optimizing salaries of employees of a business (e.g. via social voucher issuing or solutions for bike leasing), increasing efficiency for SMEs (through offers of social secretariats, HR platforms, recruitment platforms…​)

• Internal partnerships (invisible to the end-customer), i.e. SaaS-based white-labelled offers, where the branding of the company offering the service is hidden away. Typical examples are: robo-advisors (like Gambit, TradingFront, WealthKernel…​), subscription management (like Minna Technologies), banking-as-a-service (like Mambu, Fidor, solarisBank…​)

All those partnerships, if done well, can result in a win-win-win situation, i.e. for the bank/insurance company, for the partner and for the customer. The trick is in the "if done well", as managing a partnership consists of much more than just selecting the right partner.

Based on my experience with partnerships, the following aspects should be carefully considered when setting up a partnership:

• Make sure there is a cultural fit: even if 2 partners are perfectly complementary from a product/service point of view, a partnership is still managed by people and the partnership also needs to be convincing (feel authentic) to the end-customer. As such a cultural fit and fit in values is essential. A typical example of a misfit is a financial services company partnering with a "Green" company, trying to boost its "Sustainability" reputation.

• Define clear roles and responsibilities: often this is well defined during the implementation (project) phase, but much less clear once the necessary integrations are delivered. As such it is important to agree upfront how aspects like marketing, sales lead management, contract management, customer support, change management…​ will be organized throughout the partnership.

• Ensure good communication flows between the 2 partners, but also towards customers: this consists of agreeing on communication plans (agreeing on planning, but also validating each other’s communication and relationship with the press), defining communication and escalation lines (like defining SPOCs), but also try to boost personal connections between the people (at both sides) actively executing on the partnership (e.g. via joint team building events). Often there is a mismatch in communication style in a partnership between a larger and smaller player, i.e. a larger player will take a long time to take decisions and execute upon, but typically quality of deliverables is high. A smaller player is often much more agile, but quality standards are not always that high (e.g. in communication on social media). Important is to be aware that any communication sent out by 1 party, will indirectly impact the reputation/credibility of the other party, making it crucial to have good agreements on the point of communication about the partnership.
  Furthermore good communication implies also transparency (avoid any suprises). Often due to strict SLAs partners try to hide internal issues from each other, which ultimately leads to bad relationships. As such it is important to be open about any issues and about the future product roadmap.

• Foresee a plan to keep partnership alive: many partnerships start with a bang, i.e. with a big press releases and marketing campaigns, but after a few months nobody is looking anymore to the partnership (sleeping partnerships), resulting in a slow dead. To avoid this it is important to have a plan of repeating certain marketing campaigns (after a number of months), having quarterly partnership meetings to discuss results, potential improvements and next steps and putting partnership objectives also in the KPIs of employees (at both sides), potentially even as part of their bonus plan.

• User support is one of the most complex elements in a partnership. Ideally the customer should call to the party where the user journey is occurring (providing also a single support system), but often the support desk of this party will not be aware of the specifics of the partner’s functionality. At that moment it is important to avoid having to transfer too much calls to each other and avoid blaming the other party (customer has no message that there is a partner behind). This can best be solved by sharing good FAQs between partners (so that each party can also reply standard questions of other party), by assigning a unique owner to each request/call, who does the end-to-end follow-up with the customer (hiding away the discussions with partners), by good SLA management on response times (to questions and incidents) and by sharing easy dashboards where the end-to-end status of any customer’s request can easily be tracked.

• Standardize on integrations: if you work with multiple partners try to standardize as much as possible the integration, as managing different integration types will become costly and difficult to manage in the future. In order to enforce a standard, it is best to come with a very user-friendly integration, supported by a Developer Portal (with self-service onboarding, API documentation, a sandbox…​).
  Obviously if an API is used by multiple parties backwards compatibility is important, but some banks and insurance companies refuse an API-reply (for security reasons) even when it contains unknown tags (even if it backwards compatible). This is important to consider, as a (backwards compatible) change in a standard API, might result in regressions to certain partners.

• Agree on SLAs, with regards to availability, API response times, incident fixing, response times…​ The most important here is to ensure that all targets can be monitored (easily and automatically) and that there is regular reporting. Too much SLAs are just defined on paper but are not measurable or are measured but never discussed with or reported to partners.
  Furthermore these partnership discussions should not lead to blame discussions when SLAs are not met, but instead in defining together a plan of action to improve the situation. This way trust and transparency can be fostered, and a culture of continuous improvement can be put in place.

• Make sure the business model which is a win for all parties: too often the larger (dominant) party tries to impose its will on the smaller party, resulting in the smaller party getting a bad deal. While in the short-term this might increase revenues, in the long-term this is not a good way to build a strategic partnership, as the smaller party is likely to give less priority to the partnership or even worse might go bankrupt as its business is not sustainable. This ultimately leads to a loss of revenue for the larger party in the long-term.
  In the business model it is furthermore not only important to discuss about the commissions, but also of how these commissions will be calculated and invoiced, how potential joint costs (e.g. on marketing material) will be split and how changes requested by one party to be implemented by the other party will be funded. Often it can be interesting to make an important partner also shareholders, even though this can of course also have an impact on positioning towards other partners.

• Although everyone wants a successful partnership, the more successful a partnership the higher its dependency (and counterparty risk). As such these future dependencies should be carefully managed and precautions should be built in up-front. Typical dependencies impacting the partnership are a party going bankrupt, a party being acquired (potentially by a competitor of the other party), a party shifting its strategic focus, a party wanting to increase/decrease prices, a party becoming also a competitor of the other party (even on other product than the partnership), a party also setting up partnership with competitor of the other party or a party struggling with quality (due to an unsuccessful IT project or departure of key resources).
  Obviously all these risks can be contractually mitigated, but if you need to start going legal, it’s probably already too late for your partnership to successfully continue. As such a close and transparent follow-up and ensuring a win-win relationship are the best recipes to find a solution before it becomes a real issue.
  Nonetheless it might be good to include some mitigations in the contract like sharing application source code (often at a third-party Escrow service), foresee possibility to acquire the company (or specific product/service) at a pre-defined price in case of certain events (like bankruptcy or acquisition), threshold for pricing increases, penalties in case of failures, definition of pricing committees, termination conditions…​

• Security vs. usability: as partners often make direct connections to each other’s systems, security becomes vital, as one party can become an access point for hackers to the other party. Obviously each party can protect itself by securing those entry points, but even then the partnership can be a weakness (e.g. for social engineering). As such parties should have sufficient trust in each other when it comes to protecting their systems and data. Ideally this should be done by supporting each other in improving each other’s systems from a security perspective, but it can also be enforced more formally, by (external) security audits and certifications.

• Data sharing: one of the main advantages of an ecosystem is in its data gathering and sharing. This allows a much more frictionless user experience (e.g. single-sign-on and avoiding to reinput data) and a more personalized experience. Obviously with multiple parties involved, data protection regulation (GDPR) becomes an important concern. The necessary user consents to share data should therefore be collected and DPA (Data Protection Agreements) agreements need to be signed and documented between all involved parties (exchanging data).

Clearly with partnerships becoming more and more important, setting up and managing partnerships becomes a key task for many organizations. As such it should be embedded in the organization and the specific skill sets need to be built up.
More and more financial services companies start creating specific teams managing partnerships and ecosystems. This will become even more important in the future. The trick will be that these teams don’t become too isolated from the rest of the organization and continue to focus on creating value for the organization and not on bureaucratic reporting about the different partnerships.

Check out all my blogs on https://bankloch.blogspot.com/
In the topic of eco-systems you can also read:

• Transforming the bank to an Open API Ecosystem(https://bankloch.blogspot.com/2020/02/transforming-bank-to-open-api-ecosystem.html)

• Transforming the insurance sector to an Open API Ecosystem(https://bankloch.blogspot.com/2020/02/transforming-insurance-sector-to-open.html)

• Eco-systems - Welcome to a new cooperating world(https://bankloch.blogspot.com/2020/02/eco-systems-welcome-to-new-cooperating.html)

• From app to super-app to personal assistant(https://bankloch.blogspot.com/2020/08/from-app-to-super-app-to-personal.html)

• Marketplaces in the financial industry - Here to stay?(https://bankloch.blogspot.com/2020/06/marketplaces-in-financial-industry-here.html)

• Monetization of a marketplace in the financial industry - Make your idea profitable!(https://bankloch.blogspot.com/2020/07/monetization-of-marketplace-in.html)

• Marketplace analytics - Stop running your business blindly(https://bankloch.blogspot.com/2020/08/marketplace-analytics-stop-running-your.html)

• The war for direct customer contact - Banks should fight along!(https://bankloch.blogspot.com/2020/02/the-war-for-direct-customer-contact.html)