Architecture and Benefits of Open Banking

Architecture and Benefits of Open Banking

It is necessary for a bank to have an effective open banking architecture in order to fully reap the benefits of open banking. Everyone in your organization, from your compliance officer to your open banking project director to your CTO, must have total trust in the open banking platform you select. Your open banking architecture has a major impact on how successfully you open up your APIs, deliver a smooth third-party experience, and ultimately give a better customer journey than your rivals.

Open Banking Architecture Proposal

Our goal is to safely expose internal data and services to external third parties via RESTful APIs with customer approval. Third parties can then use those APIs to create new services for the bank's clients. However, exposing APIs and creating a permission management layer aren't the only criteria for implementing an open banking platform; there are also API administration, API security, and other functional and operational needs.

Important Requirements

API Definition

To begin, each bank must create a good API definition to guarantee that how a bank provides internal data and services to other parties is standardized and well-defined. When considering current data and services, there may be some data that can be published through open APIs. Open APIs, for example, can reveal ATM locations, branch locations, exchange rates, and interest rates. However, if a bank wishes to reveal bank customers' account information or provide a service to process payments, those APIs must be exposed as protected APIs.

API Safety

Once the API definition has been created and exposed to the outside world, banks must consider how to limit access to the APIs to approved third parties exclusively. Banks must put in place a security layer for exposed APIs. Third-party authentication and authorization procedures based on OAuth2 tokens or certificates are commonly utilized in many open banking systems.

Customer Authentication that is Strong

Banks must get consumer authorization before sharing client data with third parties. To do so, the bank must first thoroughly identify the consumer. Authenticating users using only one authentication factor is insufficient. Multi-factor authentication should be employed, with at least two knowledge, ownership, and inherence factors being used.

Furthermore, different banks employ various methods for verifying people. The redirect technique and the decoupled approach are both popular authentication methods in various nations. In addition, embedded, mixed, and delegated techniques can be employed.

The redirect strategy involves redirecting the bank user from the third-party application to the bank's authentication gateway. After the user has been authenticated and given approval, the user will be forwarded to the third-party application. This redirection may be performed using either a browser or a mobile app.

The decoupled technique is one in which the bank user is not returned to the bank's authentication site, but the third-party application identifies the user and makes a back-channel call to the bank stating that the third-party application requires authorization from this specific user. The bank then contacts the consumer, maybe using the bank's mobile application, to obtain the user's agreement.

When a consumer makes a payment, they must go through all of the verification processes and offer their approval every time, even if the transaction is risk-free. Iteratively going through all of the authentication stages might result in a poor user experience. The capacity to detect the risk level of a transaction should be available, and if it is low, the bank should be able to exempt the user from having to go through all of the authentication requirements. This is referred to as Transaction Risk Analysis (TRA).

When considering an open banking platform, consider if it will have this capacity or whether your bank currently has a transaction risk analysis solution that can be connected with this open banking platform.

Management of Consumer Consent

Managing consent implies giving the bank client the ability to determine who can see his personal and financial data, for what purpose, and for how long. When sharing client data with third parties, the open banking platform should be able to obtain, preserve, and authenticate this consent.

Revocation of Consent

The ability to retract consent should be as simple as granting consent, and users of the bank should have the capacity to do so. In several open banking implementations, three methods for revoking provided user consents have been identified:

• The bank provides an interface via which bank users may log in and cancel consents.
• When a client comes to the bank and requests that the consent is revoked, the bank offers an interface for customer care personnel to search for and withdraw the consent on the customer's behalf.
• The bank provides an API for withdrawing consent so that third-party apps can provide revocation capability.

Onboarding of Third-Party Vendors

When a third party wishes to consume APIs from banks, they often go to the bank's API store, where they may browse already published APIs and discover what is available to create their apps. When they wish to utilize these APIs, they must subscribe to them, which requires them to be on-boarded as a registered third party with the bank.

Some banks do this by providing a signup form where other parties may come and fill out the form to gain access. When the bank gets the registration request, it can handle the onboarding process in one of two ways.

Some countries have implemented a directory service to give third-party onboarding capabilities, where both third parties and banks may register with the directory service and submit some credentials that can be used to identify third parties. When a third party contacts the bank using those credentials, the bank queries the directory service, validates the third party, and grants access to the APIs.

Capabilities for API and System Administration

In addition to the aforementioned needs, an open banking platform should provide suitable API administration capabilities to both third parties and the bank's API developers.

Given how third parties interact with the open banking platform, having an API store to display the APIs that the bank has published, as well as the ability to construct apps, subscribe to the APIs, generate keys, and monetize APIs, is critical. Aside from that, it is critical to provide statistics on how their apps are functioning and to deliver warnings when a defective invocation occurs or an odd API invocation trend is found. Third parties would be more likely to use the bank's open banking platform as a result of this.

Similarly, the bank's API developers must have an appropriate means to design and version APIs, as well as manage the lifespan of the APIs that the bank exposes. Bank API developers will not immediately publish the API. They may need to test such APIs before releasing them to the public. On the other side, when discontinuing support for a certain API, there should be a duration during which the API is deprecated so that third parties can migrate to new APIs. Aside from that, they should be able to do API analytics, reporting, and alerting.

Integration of a User Store

There are several users participating in this open banking ecosystem, including bank personnel who manage the platform as a whole, bank users who utilize the goods and services, and third parties that consume the APIs offered by the bank and build services.

Bank employees and bank users already dwell in separate user shops, and we would need to give a location for third parties. The user stores can be of many sorts, such as LDAP, AD, or JDBC, and different users should be able to grant varying levels of access. For example, customer service representatives should only be able to access the customer service portal, whereas third-party application developers should only be allowed to access the application developer site.

API Analytics, Business Insights, Fraud Detection, and Reporting are all available

It is quite beneficial to study the data going via the open banking architecture. API analytics may assist in determining how exposed APIs are performing and how they might be improved.

We can analyze the spending habits of bank clients and uncover some business insights to better the banking company by looking at the data that travels via an open banking platform.

Fraud can occur, especially when processing payments using the open banking network. So, a competent fraud detection solution should be connected to this platform, and if the bank currently has a fraud detection solution, it should be able to connect it without purchasing a new solution.

Customer Service

Customer experience is the most important of all the major needs. If the solution fails to deliver the intended customer experience, no one will utilize the open banking platform's goods and services.

Have quick and smooth navigation without any hiccups.

• Provide the necessary and proper information to bank clients in order for them to make an informed decision.
• Be as simple as a bank customer communicating directly with the bank.
• When deciding on an authentication technique or mechanism, consider how it will affect the bank's customers' user experience and if it will adhere to the confidence that the consumers currently have in the bank.

Requirements for Operations

When considering an open banking architecture, a bank must consider several operational considerations. Third-party providers (TPPs) must be able to rely on Account Servicing Payment Service Providers' (ASPSPs') highly available and high-performing dedicated interfaces in order to deliver reliable services to their clients. As a result, the open banking platform should be highly available and function at the same level whether it is busy or not.

How Different Regions Have Met These Requirements

Some countries have already taken the initiative to move towards open banking. They have come up with different standards and specifications that have evolved over time while doing a lot of experiments and gathering knowledge around this area. Therefore, it will be really useful if we consider these standards and specifications to implement an open banking architecture for your country or your bank.

• European countries

Based on the revised Payment Services Directive (EU 2015/2366, also known as PSD2) requirements and the European Banking Authority Regulatory Technical Standards (EBA RTS), Berlin Group NextGenPSD2 has worked on a detailed 'Access to Account (XS2A) Open Banking Framework' with the data model (at conceptual, logical, and physical data levels) and associated messaging.

Berlin Group NextGenPSD2 has been adopted in all EU nations (primarily on a national level), some non-EU countries in Europe, and countries outside of Europe that are committed to retaining reachability and compatibility with the European market. The Berlin Group NextGenPSD2 Framework has been deployed by more than 75% of European banks and hundreds of Third-Party Providers (TPPs).

• Australia

The Australian Government implemented the Consumer Data Right (CDR) in Australia on November 26, 2017. CDR will increase customers' access to and control over their data, as well as their capacity to compare and switch between products and services. It will promote competition among service providers, resulting in not just lower rates for clients, but also more creative goods and services.

The financial industry would be the first to benefit from CDR, followed by the energy sector. It is presently recommended that the telecoms sector follow suit. The current banking implementation timeline is accessible at the Commencement of CDR Rules. ?

• Nigeria

The Open Banking API Standard is provided to you by the Open Technology Foundation, an NGO supported by a consortium of banking, fintech, risk management, and other industry specialists. The growth of financial technologies is intended to alleviate these issues by offering APIs and other technologies that enable the development of novel financial apps and services. Nonetheless, due to a lack of standards and reference points, implementations for banks and Fintechs have been more flops than wins.

The Open Technology Foundation (OTF) was formed by a collection of industry leaders; the non-profit organization is promoting the development and acceptance of Open Banking standards in Nigeria.