Why open banking APIs are so different

Open banking comes with a lot of expectations and promises, such as democratisation of Access to Account (X2A), increased competition between banks and fintechs, and provision of better control to end-customers over their financial data and payments. To facilitate the adoption of open banking, several API standards incentives were created including Open Banking UK, Berlin Group, STET in France, Polish API, CDR in Australia, and so on. Also, a process of collaboration between API groups has been initiated. However, in the real world of open banking, APIs’ consumers, including fintechs and banks themselves, have faced a lot of challenges while integrating those APIs into unified product propositions. Why? Because APIs are so different.

And the difference lies not only between various API specifications, which is quite obvious. The difference is dictated by laws, historical background, local market development, individual decisions of financial institutions, premium APIs monetisation strategies, technical capacities, etc., and lies at multiple levels. Let’s analyse the roots of such differences and how they can be handled, the insights being gathered based on Salt Edge’s own experience working from both sides of the table - from one side helping businesses integrate with thousands of open banking APIs, and from another side, building APIs for institutions to be compliant with regulatory requirements.

Service-level agreement (SLA)

The API has been used in software development for decades and the general assumption is that a working API is almost 100% reliable, the assumption being based on the SLA of widely used services such as Google, Amazon, Facebook, or Apple. However, there is more than just one vendor in the open banking world, and there is no SLA available from API providers (i.e. banks). Banks may temporarily disable a part or entire sets of APIs due to scheduled or unscheduled maintenance work, quite often even without advance notification. Furthermore, banks can have an issue/error with some specific API endpoint or use case that stays unresolved for many months. Banks can release new API versions and deprecate the old ones based on their roadmaps, with quite limited support for the deprecated versions (i.e. 3 months).

Authentication journey

In most cases, open banking API specifications are referencing several authentication methods, i.e. redirect model (web and mobile), decoupled, and embedded. However, every bank is unique and has implemented different customer authentication elements, like login/passwords, mobile apps, token devices, SMS, digital signature, or other options available for Strong Customer Authentication (SCA). Banks are also free to choose what authentication methods they prefer to support, i.e. it can be only redirect, only decoupled, or several of them, even if the API specifications are the same. This means businesses cannot build a unified user journey as easily as with card payments, because the user authentication journey varies from bank to bank and even depends on the type of bank customer (retail vs. business vs. corporate).

Local adoptions within the UK/EU

The general assumption is that the UK applies only Open Banking UK standards, France - only STET standards, and Germany/Italy/etc. -  only the Berlin Group standards. Unfortunately, this assumption is completely wrong. Take the UK, for example: only CMA9 (the 9 largest banks) is mandated to support Open Banking UK API specification to the maximum extent, while the rest of the banks can support any desired open banking API specification, including Berlin Group/STET or even their own API standard. Some of the banks (e.g. Metro) have chosen to support only the modified customer interface (MCI) without consideringAPI at all. In Europe, banking groups (e.g. Starling, BUNQ, PayPal, QNB, Abanca) quite often adopt unique API specifications, sometimes not relying on any API standard.

Data sets

The UK/EU open banking regulation mandates banks to grant third party providers (TPPs) access to payment accounts, i.e. current accounts, some types of savings accounts, and credit card accounts. However, in practice, we have faced several interpretations and approaches for such access. For example, although the API specifications mention access to credit card accounts, quite often this is not provided via banks’ APIs. There are cases where not all the information about payment transactions is available via the API, for example, a full description of payment. Additionally, according to the applicable regulation, banks should provide account holder names (natural person or legal entity name) via the API, however, this is mandated only if the bank’s existing end-customer interface displays the account holder information. The exact time attribute in regards to posted/pending transactions might also be missing, while only the date attribute is available to be fetched from the bank. In other countries or some specific banks, there can be dozens of different types of account balances (i.e. Interim Available, Closing Booked, Interim Booked, Authorised, Expected, Booked, Clav, Clbd, Xpcf, Othr), and let’s not forget of different types of payments (i.e. ATM, card, tax, internal transfers, bills/utilities, etc.), and so on.

Geographical

In most cases, when we talk about open banking, one might imply that it’s referred to as the PSD2 regulation in Europe or Open Banking in the UK, however there are several countries outside of Europe that have already adopted the open banking regulation. Some of them chose to adopt a framework similar to the European one, while other regions choose quite different approaches. For example, Australia's open banking does not cover the payment initiation capability, and yet, they went for a more holistic approach toward customer data - by covering access to all types of accounts including non-payments, too. Moreover, every country has its specific data points, which are unique and are historically used by the banking sector. In the Czech Republic, there are notations of transaction code (i.e. Constant, Specific, Variable).

Other

There are several other differences that are mostly applicable to specific business cases, e.g. differences in handling the limitation to access historical data for only 90 days back (especially important for lending use case), differences in availability of remittance information in open banking API implementations (especially important for reconciliation and accounting), difference in issues resolution reported to banks (i.e. from several days to months or even infinity, difference in access to private or corporate accounts (i.e. custom paperwork for end-customers), differences in the handling of 4 accesses per day to an account (i.e. some banks allow only 4 API calls per day per account per TPP), some banks do support only one active AISP consent per TPP at any given time (i.e. AmEx, Spanish banks), etc.

Open banking in practice means the interconnection of thousands of banks with thousands of TPPs which, as a result, creates the conditions for millions of potential issues to be raised - issues that should be handled and solved. Unfortunately, as the legislation should be technically agnostic, it cannot dictate specific implementations in order to predict such issues. However, the legislation has the jurisdiction to mandate the creation of an open banking API certification body, similar to PCI DSS, that would handle certification of open banking implementations in a unified way, regardless of the API specification, country-specific approach, authentication methods, etc. and would work across markets. Otherwise, all the enormous resources invested by banks and fintechs in open banking will result in participants leveraging only a part of open banking benefits, eventually slowing down the adoption by the market and increasing the costs for everyone. 

The next post on “How to handle differences in Open Banking APIs” will describe how business cases should be built and risks should be handled to benefit the most from current open banking API reality and future developments.