Implementing a Successful Open Banking Architecture

Implementing a successful open banking architecture is critical for a bank to fully leverage the benefits of open banking. Everyone from your compliance officer to your open banking project manager to your CTO needs to have complete confidence in the open banking platform you choose. Your open banking architecture plays a large role in determining how effectively you open up your APIs, provide a seamless third-party experience and ultimately offer a better customer journey than that of your competitors.

This article will explain what are the key requirements that you need to consider when implementing a successful open banking architecture and how WSO2 as an open banking solution provider help banks to implement the open banking platform.

Proposed Open Banking Architecture

Figure 1

Our objective is to securely expose internal data and services to external third parties with customer consent via RESTful APIs. So then the third parties can consume those APIs and generate new services to the bank’s customers. However it isn’t just about exposing APIs and implementing a consent management layer, there are a lot of other requirements when implementing an open banking platform such as API management, API security, and other functional and operational requirements.

Key Requirements

Figure 2

API Specification

Firstly, each bank definitely needs to define a proper API specification to ensure how a bank exposes its internal data and services to external parties is standardized and well-defined. When thinking about existing data and services there can be some set of data that can be exposed via open APIs. For example, ATM locations, branch locations, exchange rates, and interest rates can be exposed by means of open APIs. But if a bank wants to expose account information of bank customers or needs to provide a service to make payments, those APIs need to expose as secured APIs.

API Security

Once the API specification is defined, and then exposed to the outside, banks need to think about how to restrict access to the APIs to authorized third parties only. Banks need to implement a security layer for exposed APIs. Mainly OAuth2 token or certificate based third party authentication and authorization mechanisms are widely used in different open banking systems.

Strong Customer Authentication

When sharing customer data with third parties, banks need to get customer consent. In doing that first the bank needs to strongly identify the customer. Authenticating users only via one authentication factor is not enough. There should be multi-factor authentication where at least a combination of two factors of knowledge, ownership, and inherence should be used.

Figure 3

Different banks use different combinations of authentication factors from basic, SMSOTP, Vasco, fingerprint, voice, Facebook, Google, and more. Additionally, different banks use different approaches to authenticating users. The redirect approach and the decoupled approach are widely used authentication approaches in different countries. Apart from that, embedded, mixed and delegated approaches can also be used.

Figure 4

Redirect approach is where the bank user is redirected to the bank’s authentication portal from the third-party application. After the user is authenticated and provided with the consent - the user will be redirected back to the third-party application. This redirection can be done either via a browser or via a mobile app.

Figure 5

Decoupled approach is where the bank user will not be redirected to the bank’s authentication portal, but the third party application identifies the user and does a back channel call to the bank saying the third-party application needs to get consent from this particular user. Then the bank calls the customer, maybe via a mobile application of the bank to get the user consent. Once the bank receives the user consent, it will share the required information with the third-party application. Our article on Strong Customer Authentication provides more details.

Transaction Risk Analysis

Figure 6

When a customer makes a payment, the customer needs to go through all the authentication steps and provide their consent every time, even if that transaction does not have a risk. Having to go through all the authentication steps iteratively can lead to bad user experience. There should be a capability to identify the risk level of a transaction and if it is low then the bank can exempt the user from having to go through all the authentication factors. That is what we call Transaction Risk Analysis (TRA).

When thinking about an open banking platform, you need to think about whether that platform will have this capability or if your bank already has a transaction risk analysis solution, and whether it can be integrated with this open banking platform.

Consumer Consent Management

Managing consent means it gives an authority to the bank customer to control his personal and financial data in terms of whom they may be shared with, for what purpose and for what period. The open banking platform should have the capability to capture, store and validate this consent when sharing customer data with third parties.

Consent Revocation

Revoking consent should be as easy as providing consent and the authority to revoke the consent should be available to the bank’s users. Three ways have been identified in different open banking implementations to revoke the given user consents:

• The bank provides an interface for bank users to log in and revoke the consents.
• The bank provides an interface to customer care officers to search for and revoke the consent on behalf of the customer when the customer comes to the bank and asks to revoke the consent. 
• The bank provides an API to revoke the consent so that third parties can provide a revoking functionality through their applications.

Third-Party Onboarding

When a third party wants to consume APIs from banks they would typically come to the bank’s API store where they can explore existing APIs that are published and see what is available to develop their applications. When they actually want to use these APIs they have to subscribe to them so they have to be on-boarded as a registered third party with the bank.

In doing that, some banks provide a signup form where third parties can come and fill the form to get access. When the bank receives the signup request, there are two ways of handling this onboarding process. Some banks want it to be fully automatic. In that case, all the information is checked and the approval happens automatically via a fully automated workflow. In certain cases, banks want the approval to be done through a manual process where someone would look at the information and approve it manually.

Some regions have introduced adirectory service to provide the third-party onboarding capabilities, where both third parties and banks come and register with the directory service and provide some credentials that can be used to identify the third parties. So when the third party communicates with the bank with those credentials, the bank calls to the directory service, verifies the third party and allows access to the APIs.

API and Application Management Capabilities

In addition to all of the above requirements, an open banking platform should provide proper API management capabilities to both third parties and API developers of the bank.

Considering how third parties engage with the open banking platform, having an API store to list the APIs that are published by the bank and capabilities to create applications, subscribe to the APIs, generate keys, and API monetization is essential. Apart from that, it is important to display analytics on how their applications are performing and send notifications when a faulty invocation happens or any abnormal API invocation pattern is identified. These would improve the confidence of the third parties to use the open banking platform exposed by the bank.

In the same way, the API developers of the bank need to have a proper way to create and version APIs and manage the lifecycle of the APIs that are exposed by the bank. Bank API developers will not publish the API straightaway. They might need to test those APIs before exposing them externally. On the other hand, when terminating the support of a particular API, there should be a timeframe where the API is in a deprecated state so that third parties can move to new APIs during that time. Apart from that, they should have API analytics, reporting, and alerting capabilities too.

Banking System Integration

When exposing an API, we need to connect to our existing banking systems. Those banking systems may work with different message formats (JSON, XML) and different massage transports (HTTPS/S, VFS, JMS, TCP). So the open banking platform should have the capability to connect with any type of internal or external banking system.

User Store Integration

Within this open banking ecosystem, there are a number of users involved, i.e. bank staff who maintain this whole platform, bank users who use the products and services, and third parties who consume the APIs that are exposed by the bank and develops services.

Bank staff and bank users already reside in different user stores, and we would need to provide a place to keep the third parties. The user stores can be of different types such as LDAP, AD or JDBC and different users should be able to provide different access rights. For example, customer care officers should be able to access the customer care portal only and third party application developers should be able to access the application developer portal only. So the open banking platform should have the capability to integrate different user store types and manage different user access rights.

API Analytics, Business Insights, Fraud Detection, and Reporting

It is really useful to analyze the data that is passing through the open banking architecture. API analytics can help see how the exposed APIs are performing and how they can improve.

When considering the data that passes through an open banking platform, we can see spending patterns of bank customers and identify some business insights to improve the banking business.

Especially when making payments through the open banking platform, frauds can happen. So there should be proper fraud detection solution connected to this platform and if the bank already has a fraud detection solution a bank can be able to connect it without buying new solution.

Reporting capabilities are needed to generate reports for bank management, third parties and for relevant stakeholders to see how the open banking platform is performing and to take necessary business decisions.

Customer Experience

Among all the key requirements, customer experience also takes the highest priority. If the solution doesn’t meet the expected customer experience, no one will use the products and services that are provided through the open banking platform.

For example, if we look at the strong customer authentication and consent capturing flow, it should

• Have a simple and easy navigation without any delay
• Provide the required and correct information for bank customers to take a decision
• Be easy as how a bank customer would communicate with the bank directly

When selecting the authentication approach or mechanisms, you should think about how it would affect user experience for the bank’s customers and whether it will conform with the trust that the customers already have with the bank.

The user interfaces, emails, alerts, reports and error messages of the API calls should also provide better user experience and everything should be according to the standard which is specified by the bank.

Operational Requirements

There are some operational requirements that a bank needs to consider when thinking about an open banking architecture. Third-party providers (TPPs) need to be able to rely on highly available and well-performing dedicated interfaces provided by Account Servicing Payment Service Provider (ASPSPs), so that they can, in turn, provide reliable services to their customers. So the open banking platform should be highly available and should perform at the same level even during the peak time or non-peak time.

The bank should properly design how to test and verify the whole platform before putting it in production. There can be different types of testing involved including integration, system, security, user acceptance, and stress testing. Especially when considering stress testing, the bank should replicate the real banking environment and verify that the whole platform to provides an obstacle-free solution. Robust stress-testing will ensure that the open banking platform is capable of dealing with not only anticipated demands but also higher-than-usual peak periods.

Banks can provide testing facilities to the third parties before their application goes live so that banks can identify and fix issues early. At the same time, with the involvement of third parties, banks can get more feedback to improve the functionality of its open banking platform and provide good service for the third parties.

When a third party encounters a problem with a bank's open banking platform, it could have a direct impact on a third party's ability to provide its service, which in turn has the potential to cause loss of business, reputational risk, additional resource requirements and negative outcomes for customers. So having an effective problem resolution system is a must. This service can be provided through an online support or ticket management system. The bank staff should be trained to handle and fix the incidents within the defined service-level agreement (SLA). If the SLA is not met, there should be a way to escalate to the proper management.;

Further, any change such as changing the infrastructure, software, or configuration, updating the whole open banking platform, fixing a bug, and publishing a new API version, may impact a third party's ability to deliver its services to their customers. As such, the ability to identify and communicate to third parties the potential impact that the proposed changes may have is also key to a successful open banking ecosystem.

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.

Here are some of the standards and specifications that different countries around the world follow:

• United Kingdom - https://www.openbanking.org.uk
• Europe - https://www.berlin-group.org/psd2-access-to-bank-accounts
• France - https://www.stet.eu/en/psd2
• New Zealand - https://www.paymentsnz.co.nz
• Australia - https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0
• Nigeria - https://openbanking.ng

WSO2 Open Banking

Considering all the above key requirements and how the different regions have met these requirements, we have created WSO2 Open Banking. Currently, it supports the openbanking.org.uk, Berlin Group NextGenPSD2, and STET specifications. We are working towards the Australia CDR specification too.

WSO2 Open Banking is developed on the WSO2 Integration Agile Platform, which consists of API management, identity and access management, enterprise integration, and analytics products. These WSO2 products are well used and well tested with different customers and use cases around the world. Further, they are 100% open source and fully extensible, so if your country has not defined any specification for open banking but your bank wants to have your own implementation, that can be supported via WSO2 Open Banking.

Conclusion

Implementing a successful open banking architecture is critical for a bank to fully leverage the benefits of open banking. To identify what the key requirements of an open banking platform are and how they can be implemented, selecting the right technology is a top priority. WSO2 Open Banking was built by considering the standards and specifications that different regions and banks have followed. Banks can leverage this technology to create a successful open banking architecture thereby improving their customer services and banking business.