Equivalence: Treat Others as You Wish to be Treated – An Open Banking Imperative
Open banking is based on the principle that a client must not be discriminated against, whether he banks directly with his bank or with a third-party provider (TPP). The main idea behind open banking and PSD2 is to fuel competition among financial institutions for payment services. Payment competition only works if a client can choose his payment channel without any service disadvantages regardless of whether the payment initiator also manages the client’s accounts. In practice, this means that a payment on my account initiated through other players (such as TPPs) should be as quick as the payment through my home bank’s online banking. For this reason, the entire regulation centers around non-discrimination and equivalency.
What does equivalence mean?
How is equivalence mandated and how should it work in practice? Article 32 of the PSD2 RTS regulation sets out obligations for a dedicated interface in fairly straightforward terms: «ASPSPs [i.e. the banks] shall ensure that dedicated interfaces do not create any obstacles to the provision of payment initiation and account information services.» Both national regulators and most banks conclude that open banking must rely on state-of-the-art REST APIs. Most web-based communication and the interfaces of our everyday apps and websites rely on this technology without you noticing it. In addition, online banking payments have become a more or less frictionless commodity. As a result, any new payment channel must meet these client expectations. ASPSPs must therefore prove to the regulator and the public that, regardless of the banking channel, clients do not face any obstacles − especially when relying on open banking APIs.
Get «Open Banking» articles in your inbox.
Demonstrating the availability and reliability of online banking versus open banking components
Open banking works on the basis of a number of new components interacting with the existing systems of a bank’s architecture. Proving equivalence involves matching the technical KPIs of the systems compared. Such technical KPIs must be provided by a state-of-the-art monitoring system. In Synpulse’s open banking projects, such a system has been specifically built for open banking components, triggering all the relevant APIs to monitor their functionality and response metrics.
ASPSPs (banks) need to provide information on the uptime and downtime of each open banking API and compare it with such times for existing systems (in most cases online banking). Let us illustrate why this is a challenge: A client who submits a payment through a TPP calls a certain API (apart from others) specifically designed for consent. He will of course be unaware of this fact, as he will consent to the payment by proceeding through an online form. The response time of this consent API call can easily be measured. Compare this to a client who submits a payment through the same bank’s online banking. Consent is also required for this payment, typically by confirming the payment online with a single user action. Apart from the API call, these actions are very similar. In open banking, however, the ASPSP must also check and compare the TPP’s identity in a common but protected registry. It needs to register consent and make it transferable, which is usually achieved with a cryptographically signed token. Finally, it must make sure that its client authenticates at the time of the payment (regardless of the previous authentication when logging into online banking). The regulation requires both actions to be measured and to be compared and matched end-to-end. It cannot come as a surprise that this presents a huge challenge for most banks, and this comparison match is one of the main reasons why regulators only recently announced an additional grace period for some of the PSD2 deadlines.
APIs themselves are easy to monitor, since a monitoring system can call APIs at specific, predefined time intervals and analyze their responses. Setting up a similar monitoring system for online banking is not straightforward, which is why comparing API calls and online banking actions often feels like comparing apples and oranges. Figure 1 shows examples of online banking and the equivalent open banking services.
As Figure 1 shows, from an outsider’s point of view each item can be linked with another for comparison purposes. Take as an example the link between open banking consent and online banking login. The same link looks different from an architectural perspective, given the different systems providing the services.
Here is an example of such systems: Online banking and core banking systems usually rely on different platforms with separate databases. In addition, REST APIs usually rely on a middleware layer that docks right into the heart of the bank’s core system and offers connectivity to other internal and external modules, such as online banking. Imagine a release upgrade of the core system that affects API availability but technically not the online banking system. Do you need now to switch off online banking, nonetheless, to guarantee equivalence? If online banking were not to be switched off in this case, an online banking set-up that ran on its own database would have a higher availability than open banking APIs. While reducing the availability of online banking is certainly not the regulator’s intention, it is obvious that a well-defined open banking architecture is an absolute necessity, even though this might bring about substantial change to the existing architecture.
Though the regulation specifies in detail what monitoring reports must look like, it remains unclear as to how the APIs in the report should be measured. Two different system architectures relying on different databases and security layers are unlikely to both return the same technical performance. How does the number of milliseconds for an API call relate to the account information and payment service and the client’s user experience in online banking?
To sum up, from a regulatory perspective, discrimination must be avoided. From an implementation perspective, however, providing the required data and user experience is tricky. Currently it is not clear what sort of gap (if any) is acceptable between the systems. The intention cannot be to require one system to be slowed down to reach the same (slower) performance as the other. The industry has still to prove that it can provide a new data and payment service that is as secure and as fast as a system (online banking) that has been developed and improved over the past 30 years.
How to ensure the data is accurate
At this point, many banks have done substantial testing to ensure the equivalence of the new open banking solution with existing banking channels. Nevertheless, it might only be possible to reach definitive conclusions once a real TPP has been onboarded and is in live, productive operation. It will then be up to the regulator and to the client to confirm that both systems work to a satisfactory degree.
How can a bank test the account, payment, consent and online banking applications in a market where demand for TPPs for testing purposes currently exceeds the supply of TPPs that are ready? Stay tuned for the next article if you would like to know how we tackle this challenge.
Interested in our «Open Banking» mini-series?
Would you like to talk to someone who can share hands-on experience in open banking? You can reach us directly using the contact details below.
