1. Introduction

"Open" has recently become a new buzzword in the financial services industry, i.e. open data, open APIs, open banking…​, but what does this new buzzword really mean?
"Open" refers to the capability of companies to expose their services to the outside world, so that external partners or even competitors can use these services to bring added value to their customers. This trend is made possible by the technological evolution of open APIs (Application Programming Interfaces), which are the digital ports making this communication possible.

Together companies, interconnected through open APIs, form a true API ecosystem, offering best-of-breed customer experience, by combining the digital services offered by multiple companies.

In the technology sector this evolution has been ongoing for multiple years (think about the travelling sector, allowing you to book online any hotel). An excellent example is the success story of Uber. In just a few years this company has acquired a market capitalisation which is larger than that of BMW. This while Uber mainly combines multiple API services offered by other companies, i.e.

• Positioning is done by the operating system (iOS, Android)

• Route calculation and maps are provided by MapKit and Google Maps

• Twilio sends real time text messages to the customers

• Payment is handled by Braintree

• The receipt is sent via Mandrill

• The services are hosted in the cloud on Amazon Web Services (AWS)

Combining these best-of-breed API services allows start-ups like Uber to deliver an excellent and innovative user experience in a very short time frame, thus facilitating rapid growth.

Afterwards these start-ups will typically deliver their own APIs, which in their turn are integrated in the offering of other companies. E.g. the API of Uber is also integrated in the application of United Airlines.

These examples show the mutual benefits of such an open API ecosystem, i.e. the customer-facing company can deliver additional services to its customers, while the service-providing company can profit of an increased usage of its APIs. This leads for both companies to increased revenues.

The example of Uber is certainly not an isolated case, e.g. UPS has successfully increased its market share by integrating its APIs in online webshops or eBay generates already 60 percent of its revenues via its APIs (e.g. API to submit item for listing on eBay).

The banking industry, traditionally quite slow in integrating new technologies, will also be more and more impacted. Open Banking is becoming an emerging trend, pushed by increased and changing customer needs, Fintech competition (there is a Fintech company for every service offered by the banks) and regulators pushing banks to open up their data and architecture (e.g. PSD2), while still obeying increasing customer protection rules (e.g. GDPR). In the 2017 Digital Banking Report, Open Banking was mentioned by bank executives to be the fourth most important trend for 2017. In the 2016 version of this report, this trend was not even in the top ten.

This article describes the impacts of this trend on the financial services industry.

2. Drivers

The rapid adoption of open banking is driven by multiple evolutions in the banking industry:

• Customer needs are increasing and changing: customers are demanding a multi- and cross-channel experience, which is real-time and 24/7 available. Furthermore, the experience should be customer-centric, rather than the product-oriented approach that most banks currently offer.
  E.g. customers are demanding banks to offer services like 360° holistic personal finance management (i.e. including assets & liabilities held at other financial institutions). This 360° view gives customers not only the ability to manage their budgets, but also to launch immediately internal and external services from the analyses happening in this module. An example of an internal service would be the investing of excess money in securities, while an example of an external service would be the automatic proposing and managing of a switch from utilities company, when comparison with peers shows that the customer is paying too much for his utilities.

• Regulatory pressure: regulators (especially in Europe) are pushing banks more and more to open-up their architecture, with PSD2 (Payment Service Directive 2) in the European Union and the Open Banking Initiative of the CMA (Competition and Market Authority) in the UK.
  Both regulations aim to increase the competition in the financial services industry (aiming to provide consumers better services at lower costs) by imposing banks to allow third-parties to retrieve directly account and other information from banks. E.g. the Open Banking Initiative imposes banks to share product and service information (like prices, charges, terms and conditions) and customer information (like account information and the possibility to execute payments directly).

• Fintech competition: banks face more and more competition from Fintech companies (e.g. robo-advisors, peer-to-peer lending, crowdfunding…​), which can deliver innovative customer services faster and cheaper. Currently banks are competing head-on with these Fintech companies, but this approach appears not to be very successful. Instead banks should better partner up with a few well-chosen Fintech companies to deliver attractive services to their customers. This approach enforces banks to setup an open API architecture, facilitating the rapid integration (plug-and-play) of the bank’s and Fintech’s service offerings, ultimately creating banking app stores.

• New technologies: the rapid technological evolutions in the industry (IoT, big data analysis, real-time customer analytics, AI, block chain…​) make it almost impossible for a bank to invest (and be at the top) in any new technology. Partnering with specialist companies is therefore almost a necessity to stay ahead of all those technological evolutions. Also, these partnerships should be facilitated by an open API architecture.

• New architectural design principles: historically the application architecture in the banking industry is composed of several large, very closed, monolithic legacy systems. This traditional architecture is reaching its limits in the current digital and fast-moving world of banking. Banks are therefore taking their first steps in the migration to a microservices based architecture. Since microservices communicate with each other through well-defined APIs, this architecture can be exposed to the outside world much cheaper and quicker than a traditional architecture.

3. Impacts on the Banking industry

The banking landscape is undergoing its most fundamental transformation in decades, driven by the fast digitalisation in the sector. Just like the entertainment, media and retail industry, the internet has changed the way of doing business completely. Banks should not only open their services, but also build their own digital ecosystems and participate in external ecosystems. Banks will therefore have to transform themselves to an "Open Bank", offering "Banking as a Service (BaaS)".

According to a report by McKinsey, globally over 12,000 Fintech startups are competing with banks for up to $1 trillion in profits of which up to 60% are at risk, in the following five retail businesses: consumer finance, mortgages, small-business lending, retail payments and wealth management.

This will have a radical impact on the banking industry, which traditionally has been very protective of its data and processes. Banks should redefine their business strategy, resulting in 2 edge scenarios:

• Banks can opt to deliver only banking services (focus on risk management and providing financial infrastructure) and let the distribution and customer contact be managed by other parties (e.g. Fintech companies or other banks). This model can be interesting for certain large banks (profiting of large economies of scale), which have difficulties to transform their organisation into a fast, moving, flexible organisation (i.e. having difficulties to deliver the new compelling customer facing interactions). Since non-facing banking services tend to change less quickly, it allows the organisation to focus on typical banking non-functional requirements like stability, reliability, security, availability…​

• On the other hand, banks can opt to focus only on distribution and customer management and use other players (e.g. other banks or Fintechs) for the banking services. This model might for example be well suited for smaller niche players, which have strong customer relations. Only focusing on distribution, allows these banks to profit from the economies of scale of the larger players of which they use services.

Note: In most articles, Fintechs are positioned as distributors and banks as underlying service providers. This because Fintechs typically provide better user experience and are more agile to adapt to fast changes, while banks have already all banking services in place. This split in responsibilities can however perfectly be inversed. Banks are also well positioned to oversee distribution and the direct customer relation, thanks to their existing customer base, strong trust-relations with their customer and extensive distribution channels (including call centres and branches). In this model Fintechs would deliver some or all underlying products and services (like e.g. crowdfunding, peer-to-peer lending…​).

Of course, all scenarios between these 2 extremes are possible as well. We believe however that the scenario in which the bank does not open up is not a scenario which guarantees a successful future for the bank.

Ultimately banks should shift from building full end-to-end financial solutions to assembling best-of-breed financial services tailored to meet the innovative customer needs. This means that the traditional product-centric distribution should be transformed to services providing deep financial insights and integrating services of other sectors. This can only be achieved by creating an open API ecosystem, which is beneficial to all involved parties.

In practice, this API ecosystem digital platform would resemble an "App store" with services offered by the different parties involved in the ecosystem. The customer would be in the driving seat to choose the functionality/service and user interface that suits him best. Once having made this choice, the customer would give a consent to the party to use specific data present in the ecosystem. Since customer can easily switch from one service to another (without any impact for his financial data), this will boost innovation considerably and result in new service offerings which are superior in terms of cost, performance and convenience.

Open Banking will also have a substantial impact on the bank’s organisation where bridges between business and IT departments will be alleviated, as decisions will need to be made much quicker due to the faster evolving technologies and customer expectations. Thanks to Open Banking, business and technology needs will become further aligned urging business analysis and software assembly and implementation to run in coexistence.

4. Opportunities and Threats for the Banking industry

The creation of open API ecosystems offers several opportunities, but also significant threats, to the banking industry.

Banks not opening their architecture and not participating in these API ecosystems are expected to lose the most. Interesting to quote BBVA here: "a company without an API is like a computer without internet".
At the same time the benefits that banks participating in such ecosystems will profit from, will also depend strongly on the role the bank will play in the ecosystem.

In the most optimistic scenario, the bank would be the central player in the ecosystem managing the customer affiliation. The Fintechs would compete against each other to get access to the bank’s customer base. As a result, the bank would be able to choose between different Fintech players, selecting the one with the best service offering for the bank’s customers and the one providing the best conditions for the bank. In this scenario, innovation comes at very low expense to the bank, i.e. new players can experiment with new approaches, without the bank having to invest any money in these trials.

At the other side of the spectrum, it could be that Fintech companies (or probably one of the Gafa tech giants, i.e. Google, Apple, Facebook or Amazon) would be in the lead of the ecosystem. In this scenario, the Fintech company would take most of the profits and manage the customer relationships, while banks would have to compete between each other to offer the underlying (invisible to the customer) banking services and products. In this scenario banks would be reduced to the role of invisible commodity service providers.

The party managing the customer relation will not only take most of the profits, but will also gain access to the customer data, which can be used to fine-tune and personalize the customer experience and increase cross-selling opportunities.

It is difficult to predict which "role" banks will play in these future ecosystems, but the coming years will be crucial for banks to take a dominant position. The banks have certainly a lot to gain, like a more extensive service offering, additional and improved distribution and enhanced risk mitigation.

When comparing banks with Fintechs today, both have competitive advantages. The party which will be able to best leverage on its advantages and improve its disadvantages, will win this "race" for becoming the dominant actor in the ecosystems:

• Bank advantages:

  • Trusted brands: even though banks took a serious hit on their trustworthiness during the Financial Crisis, customers still trust their banks more than Fintechs for keeping their money safe.

  • Large customer base: banks have a large existing customer base and high potential for new customers (e.g. children of existing customers).

  • Diverse product & service offering: most large banks offer a full spectrum of financial offering to their customers, avoiding the customer having to shop for each individual financial product/service.

  • Unique expertise in banking: banks have ages of experience in risk management, compliance, and security regulations (i.e. proven experience in handling regulation requirements). Furthermore, strict regulations (often different country by country) and banking license restrictions make it hard for Fintechs to quickly open up new markets.

  • Banks have a unique knowledge about the customer, due to the mandatory KYC process, but also because of their ability to access all financial transactions about a customer (allowing to create a very detailed personal profile of the customer). Even though banks are not (or insufficiently) using this data today, this could quickly change.

  • Access to large amount of capital: allowing banks to make large investments in new technologies. This allows banks also to acquire Fintech companies, which provide services, on which the bank has a competitive disadvantage.

  • Multi-channel experience: banks offer a variety of channels to their customers (branches, contact center, self-banking via ATMs, phone banking internet banking, mobile banking…​). Even though Fintechs typically provide better internet and mobile banking solutions, customers still appreciate having the option to use more traditional channels (e.g. to discuss more sensitive or complex subjects like e.g. succession planning). Especially the branches, which are anchored locally, provide a strong factor of customer binding.

  • Banks have all the infrastructure in place for processing, clearing and settlement of payments, securities, …​

• Bank disadvantages and challenges:

  • Long & Costly Change cycles: the biggest hurdle for banks to compete with Fintechs is probably their inability to evolve their IT applications quickly and cost efficiently. This is mainly due to 2 reasons:

    • Legacy systems: most banking services have been built on top of legacy systems, which were built decades ago and are not adapted to the current digital requirements. The transformation to an open bank, delivering compelling and innovative API services, will pose a huge transformation challenge, which will require significant time and money.

    • Banking culture: due to their long history of IT, their complex application architecture and their inherent risk aversity, banks have a culture of slow, but steady change. This is reflected in large and complex releases once or twice a year, the wide-spread use of traditional development methodologies and the fact that IT is often still considered as a non-core cost centre, with little decision power (i.e. banks have not made the switch to becoming a "Technology Company").

  • Poor customer experience: due to their inability to quickly adjust their applications to new evolutions (both technological as social), the banks are starting to lag behind on their digital channels. With many customers doing their banking activities almost exclusively via digital channels, this starts to impact the customer engagement.

  • Strict and changing regulatory environment: a very large part of the IT investment budget of banks is consumed by complying with the new regulations. This makes that little budget remains to improve the customer experience of their digital channels and to create the "Open Banking" services to effectively participate in the ecosystems.

  • Banks have a lot to lose: the advantages of trusted brands (reputation) and a large customer base, pose also a significant risk for banks. More than the Fintechs, the banks have a lot to lose and have a zero tolerance for mistakes, when participating in these API ecosystems. A correct management of all associated risks is therefore essential, e.g. security, management of third-party partners (e.g. fraudulent third-parties or third-parties delivering bad service quality might reflect on the bank), customer privacy concerns (e.g. compliance with GDPR, which is stricter for large companies than small companies).

Independent of which role the bank will take in the ecosystem, the customer will certainly benefit the most of this evolution:

• Increased competition, leading to lower prices and better service levels

• More transparency, i.e. it will be easier to compare different financial products and services. This will be facilitated by websites, which allow direct comparison of prices (cfr. Booking.com for hotel prices).

• New forms of distribution, i.e. a customer will be able to initiate financial services and products from websites of other companies in other sectors (e.g. retailers). A customer will also be able to launch non-financial services from the bank’s website.

5. Successful API Strategy

Critical to a successful API strategy, is the understanding that an open API is also a commercial business product and not just a technical interface. Therefore, converting the bank’s services to open APIs should not just be a technical IT project, but instead be driven by the business. This means banks should hire API product managers on the business side.

A successful open API should allow to:

• Create new revenue streams, i.e. monetization of APIs. Different monetization models are possible:

  • End-users paying transaction fees to use the solution

  • Partners and/or developers paying for service/data usage

  • Partners and banks entering into a revenue-sharing agreement, such as pay-per-click advertising (i.e. step out of the traditional product/service license fee agreements)

• Improve customer service and satisfaction, i.e. APIs should be designed for customers, i.e. exposing a service valuable to a customer, not just exposing products and raw data (e.g. transaction history from an account).
  This can be achieved by enriching the raw data (e.g. adding a categorization to the transaction history of an account) or by adding value-added services on the raw data (e.g. provide a saving or investment offer based on the raw data of the transaction history).

• Gain more data: capturing more customer data, allowing to obtain better customer insights, which in their turn can be used to improve revenues (e.g. through cross-selling and up-selling) and customer service and satisfaction.

At the same time, such an API should:

• Be carefully monitored, so that usage can be monitored continuously, and rapid action can be taken upon these metrics.

• Be quickly changed upon need. Important however is that even if an API evolves, the API format (i.e. the request and reply interface used by the external parties) should be changed as little as possible or in any case support previous versions of the format. This to avoid that all partners should adapt their software, when a new API version is delivered.

• Be well marketed, not to traditional end-customers, but to innovative companies, who could partner in the ecosystem. In this context, it is important to create a real developer community, which is typically done through events, like innovation days, hackathons, online marketplace…​, where ideas for new banking services are matched with developers.

• Be well supported by development portals, allowing to make the developer experience as seamless as possible. Such a portal should provide

  • Easy and quick onboarding (i.e. ideally through a self-service access) without much support of the bank

  • Detailed documentation of the APIs (e.g. through Swagger), i.e. API should be self-explanatory

  • A sandbox to try out APIs, including a good description of the test data available in the sandbox

  • Cross-platform SDKs and other tools (e.g. sample applications, sample source code…​) to reduce time and effort of third-party developers to consume the APIs.

A successful API strategy should furthermore not only focus on the outbound APIs, i.e. the APIs exposed by the financial service company. Financial service companies should also have a strategy of using APIs from other companiesa(like Fintech companies). This allows rapid creation of new services, by building further on functionality exposed by partner companies.

6. Success Stories

A few financial institutions have already taken their first steps in the evolution towards an open banking API ecosystem, with most prominent examples being BBVA, Crédit Agricole, Capital One, Citi, VISA, MasterCard, SWIFT and Fidor.
In case of banks this consists of providing APIs for services like payments, getting account information, placing a securities order…​
In case of card companies like VISA and MasterCard this consists services like digital wallet, finding an ATM, doing fraud detection…​

BBVA is often considered as the flagship of this evolution. Already several years ago, BBVA declared itself no longer as a bank, but as a financial services software provider.

Other successful initiatives are banks positioning themselves as providing the banking services (i.e. the licensed bank infrastructure) to Fintechs to build on top off (i.e. Banking as a Service). Examples here are CBW (Kansas), Solaris Bank, Wirecard Bank, Railsbank…​

At the same time, several Fintechs are also creating their ecosystems. E.g. WealthFront (online trading) and Venmo (online remittances), Fidor Bank and Sum-Up (mobile point-of-sale), Metro Bank and Zopa (online lending), Moven (online bank) and CommonBond (online lending) or Number26 (mobile bank) and TransferWise (online remittances).

7. Standardisation

A major issue for Fintechs and companies from other sectors wanting to use the APIs of the financial service industry is the lack of standardisation in the APIs. Developers do not want to integrate a completely different API for each bank they want to connect with.

Unfortunately, like any standardisation process, creating this "lingua franca" is very challenging. Many initiatives try to define a standard and group banks together, which proclaim to comply with this standard, but an agreement on a global (or even national) standard is not expected for the very near future.

Some example standardisation initiatives:

• Open Banking Working Group (OBWG) UK (http://theodi.org/open-bankingstandard)

• CAPS (https://www.caps-services.com/)

• Open Bank Project (https://openbankproject.com)

• Open API initiative (https://openapis.org)

• IXARIS Open Payment Ecosystem (https://www.ixaris.com)

• Open Financial Exchange (OFX) (http://www.ofx.net)

• Financial Transaction Services (FinTS) (https://www.hbcizka.de/english/)

• Banking Industry Architecture Network (BIAN) (https://bian.org)

• Berlin Group (http://www.berlingroup.org)

• W3C Web Payments Interest Group (https://www.w3.org/Payments/IG)

Again, the key here is a fast go-to-market strategy, allowing big banks to impose their standards to many early adopters creating a widely accepted Open Banking standard. A good test for such standardisation will be PSD2 (going live in 2018), where standardisation and acceptance could for example be obtained through aggregated PSD2 Payment Hubs used by multiple TPPs (third party payment providers) and Banks with well documented API calls.

8. Implementing APIs

As mentioned before, APIs are standardised sets of requirements that govern how one software application can talk to another (e.g. Google Maps API, which allows to integrate map information in any application). An API can be seen as a user-interface, with different users in mind, i.e. computer applications and their programmers.

To facilitate using this interface, the service provider publishes a precise API specification, which typically provides following details:

• What functionality is available

• A description of the flow (like e.g. next possible/best action)

• The details of the communication, i.e.

  • Data Transmission: the way the data is transmitted. This is almost always HTTP/HTTPS.

  • Data Exchange: the format of the exchanged data. Most common formats are XML and JSON.

• The API design, i.e. the way the API is designed. Most common standardized design principles are REST (Representational State Transfer) and SOAP (Simple Object Access Protocol).

• Conditions for using the service, i.e. the data access determining who gets access to which data and how this is achieved. Most common standards here are SAML (Security Assertion Markup Language) and OAuth 2.0 (Open Authorisation).

An API can be open or closed/private. An open API can be accessed (under specific conditions) by third-parties, while a closed API can only be accessed within the boundaries of the organisation.

A good API should additionally meet several non-functional requirements:

• Secure: given that open APIs are exposed publicly, a good security design is essential, so that confidential data is not exposed to the wrong party and that DoS attacks (on the APIs) don’t affect other (critical) systems of the company.

• Flexible to adapt: APIs should be flexible to modify. E.g. bugs in an API should be fixed very quickly, since such bugs will not only have internal impacts, but also give impacts for external partner companies.

• Easy deployable: given that an API should be flexible to adapt, it should also be easy to deploy. This deployment should happen without downtime and running multiple versions of the same API concurrently should be supported.

• Highly available: given that the usage of APIs is hard to predict and can be very flexible, windows of unavailability become very hard to manage. Therefore, APIs should be 24/7 available and guarantee also high availability in case of unforeseen incidents.

• Elastic Scalability: since APIs will be used by other companies, which are often start-ups, the usage can grow very rapidly. APIs should therefore support elastic scalability, i.e. automatically adjust (without down-time) the available resources based on the load.

Both at design and run-time APIs are typically supported by an API Gateway, which provides following functionalities:

• API routing: route requests based on message content, headers, identity and other factors. The API routing should also support prioritisation of requests, based on SLAs agreed with the API callers.

• Data Transformation & Validation: the request should be validated against a schema and transformation of the data should be supported.

• Tool comes with several standard connectors, allowing the API to connect directly to mail servers, databases, document management systems…​

• Security Management: this is probably the most important functionality of an API gateway. The tool should

  • Manage the API visibility and restrict access. Typically, this consists of supporting authorisation standards like SAML and OAuth 2.0. It also includes the management of authorisation keys (e.g. creation and validation of keys) for external parties to access the APIs.

  • Authenticate and encrypt all messages sent over the network

  • Secure tagging to easily manage sensitive and non-sensitive data in the API calls

  • Enforce rate limiting and throttling dynamically based on usage quotas and bandwidth quotas

  • Detect and prevent SQL, JavaScript or XPath/XQuery injection attacks

  • …​

• API Repository/Registry: repository to manage and store all available APIs. This repository allows to search APIs, view API details, manage APIs (like activate/deactivate, deployment, access management), send notifications when new API (version) is published…​

• API Portal: provide a secure online portal to onboard partner third-parties and create a community. This portal should contain:

  • Self-registration to subscribe to APIs (sandbox / production)

  • API documentation (i.e. functionality, API format, request/reply examples, code examples of how to use API…​)

  • Forum discussions

  • Description of the sandbox (i.e. connection details, test data description…​)

• Tools to easily design, build, document, test and deploy APIs (new APIs or changes to existing APIs)

• API Monitoring and Analytics: different types of monitoring on the APIs:

  • Technical monitoring: track API usage, successes versus errors, latency, …​

  • Define SLA rules and monitor if APIs meet these SLAs

  • Business Activity Monitoring

  • API Analytics: identify key trends and behaviors in usage of APIs, deeper understanding in API traffic…​

  • Alerting: receive notifications when SLAs are not met, when change is published on tracked API…​

• API Monetization: configure payment schemes to monetize API usage and integrate with billing systems for automatic billing.

9. Conclusion

Banks should move now in adapting their internal architecture, to expose well-defined and well-documented services to the outside world. Instead of only doing the bare minimum (i.e. payments and account information) required by regulators (i.e. PSD2), banks should already start opening also their other products and services (i.e. securities, credits, insurances…​). This strategy of exposing products and services as APIs, will not only allow the business of a bank to explore new opportunities, but will also push IT organisations to restructure, allowing them to evolve to a more agile, customer-centric organisation.