What Regulatory Equivalence in Open Banking Means for Your Bank’s Organization and Architecture
The new European regulatory initiative on open banking is set to change the banking landscape as we know it. This mini-series deals with the challenges around regulatory implementation related to proof of equivalence, testing, and operating model.
Open banking is the umbrella term for an industry phenomenon where financial data flow upon customer consent, and services are shared through so-called open APIs. It’s now gone global. In the EU and UK, open banking is even a regulatorily mandated activity planned for going live on 14th of September 2019. However, due to insights in various countries we believe there is a likely shift of the deadline mid-September including possible changes to the scope. Under open banking, banks will introduce new services (such as offering other businesses a customer journey for their own clients) obligated to provide the same 24/7 availability as for the bank’s own services (for example its e-banking platform). The first part of open banking comes in the form of what is, for most banks, a completely new product: payments and account information services via APIs. Figure 1 provides a simple overview of the newly introduced services under open banking.
The open banking regulations pose various technical and organizational challenges. We’d like to share some lessons learned with dealing with these challenges on the basis of our experience with implementing a project for an international private bank over the last year.
One of the main challenges is applying for so-called exemption from the contingency measures. This means banks have to prove to the respective regulator that their APIs are working as defined by the regulation. Receiving an exemption allows a bank to avoid having to implement an enhanced screen scraping mechanism as a backup.
This is the opening article preceding a series of three deep-dives, each of which focuses on a specific topic relating to the exemption application. In the opening article we have given now a short introduction to open banking and briefly elaborated the requirements it entails in terms of banks (ASPSPs), their clients, third-party providers (TPPs such as AISPs) and the operating model. Let’s do a quick outlook of what we else have in store for this article series:
1. Equivalence
Open banking is based on the principle that a client must not be discriminated against, regardless of whether they bank directly with the bank or with a TPP. From a technological point of view, this means that open banking APIs must be as readily available as currently existing channels (e.g. e-banking) to avoid discrimination. This availability must be proven to the regulator and the public. The challenge is now how to comply with a regulation that compares apples with oranges – or in banking terms, e-banking with open banking APIs. The first article will shed some light on the challenges around this “equivalence to be reported” from a regulatory perspective and the resulting impact that we faced during technological implementation.
2. Market testing before entering the market
The second article centers around testing. This is a topic of great importance from both the bank perspective and the regulatory viewpoint. Testing for open banking differs from standard banking testing with internal employees or pilot users. As required by the regulation, banks must engage in B2B testing with market participants ahead of the launch of open banking services. This is to ensure the stability of the infrastructure and its intended functionalities. But more important at this stage is to prove that the system works equivalently to the existing e-banking platform and therefore to the satisfaction of the regulator. This article looks at the challenges that arise when testing is demanded but there is a lack of market participants and readiness. It also deals with the challenge faced by small banks given that the regulations require the entire European banking sector to conduct extensive testing before market launch in mid-September.
3. How to support a new business model
Last but not least, the third article focuses on the future target operating model for open banking. New services raise the question as to how to set up support within existing organizational structures. Open banking services make this especially tricky. With the advent of open banking, a bank has to change from offering its services on a primarily B2C basis to providing a 24/7 B2B service for a vast amount of core data. This demands a different incident handling process, around-the-clock support functions, and a whole new level of knowledge and response times. On top of this, banks have to enhance the functions of open banking on a continuous basis – a task that’s especially challenging if they have many different architectural components in place. A state-of-the-art open banking system comes in handy when it works – but it’s difficult and costly to support when it’s not. Extensive knowledge is needed before you even start to think about extending its functionalities in the future.
Our hands-on experience shows that while the scale of these challenges can be reduced by technology, many of them can’t be addressed by tech alone. There is a clear gap between the regulator’s intention with respect to a bank’s open banking service and the understanding of how a bank works from a technical perspective. The problem is exacerbated by the fact that the regulation doesn’t stop with the compliance deadline on September 14, 2019. What sounds easy in theory seems almost impossible in practice. Interested in finding out how we solved these problems? Stay tuned for more.
Want to talk to someone who can share hands-on experience with open banking? Contact us direct using the contact details below.
Open Banking