Why a reference architecture?

Open banking is transforming financial services, empowering the end customer and promoting the creation of new value chains. The second payment services directive (PSD2) accelerates this transformation across Europe, forcing banks to open their systems and enable customers to share their financial data with other organizations. Web APIs make these interactions possible through a secure and easily accessible communication channel.

As a bank, you are part of this ecosystem. Whether you like it or not, you are facing key technical challenges, including security, integration and adapting to an evolving ecosystem.

Let's look at each one in detail:

• Security. Exposing a payment API on the public web is difficult enough. In the “open ecosystem” promoted by PSD2 you have the further complication of not being in control of the vetting of your API consumers. You also must share account information handling all the risks related to data privacy and confidentiality.


• Integration. The level of complexity of the integration challenge can vary dramatically, depending on the maturity of your IT landscape. If you have a "clean" architecture with customer-centric systems of records that are decoupled from your digital channels you can count on a solid foundation. If the estate is patchier you’ll need to think about how to reach the data, before worrying about how to expose them to the external world.


• An evolving ecosystem. The lead architect of the open banking program of a major bank once mentioned: “We are like the Red Queen of Alice in Wonderland. We need to run faster and faster to stay in the same place”. You must move quickly and be agile. Your customers expect great digital services and your competitors partner with Fintech to launch new products. Even if your strategy is to do the bare minimum to achieve compliance you need to manage an uncertain environment. Not even the regulators have figured out all the pieces of the puzzle, while deadlines are fast approaching.

IBM has built significant experience in this space. We have supported the first banking groups exposing public payment initiation and account information APIs aligned to the UK Open Banking standards. We also have many customers across Europe that are developing their PSD2 solutions on a variety of standards, including STET PSD2 API, the Berlin Group Access to Account Framework and the Polish API.

The PSD2 Reference Architecture captures the proven solution patterns that have emerged from these implementations. It addresses the challenges described earlier in a way that is agnostic of the differences between API standardization initiatives. It calls out the components of an end to end implementation that can be replicated to reach a faster path to compliance. It shows how to reduce complexity by decoupling security from integration concerns and describes how cloud capabilities can be leveraged to move at the speed of the evolving ecosystem.

The Reference Architecture supports PSD2 through what the industry calls a “dedicated” interface” (i.e. APIs). It is worth noting that the latest opinions of the regulator allow the option of achieving compliance by opening the customer user interface to third parties. This is sometimes referred to as “screen scraping+”. Comparing the two approaches is outside the scope of what I am writing. However, this second approach goes against many common solution design good practices. For this reason, it is not covered in this post that focuses on proven solution patterns.

The solution requirements

I will not provide an introduction to the regulation or analyze its details. I am assuming you are familiar with the content of the directive. If this is not the case, you can find plenty of links covering that space in the references section. However, I want to discuss the core PSD2 requirements from an architecture point of view.

The actors

The PSD2 ecosystem includes four main actors, shown in Figure 1.

Figure 1 – Key PSD2 Actors

• The Payment Service User (PSU): me and you, end customers of a bank. We have an account from where we can perform electronic payments. We are the owners of our financial data and with PSD2 we can decide to give consent to other organization to access those data on our behalf.


• The Account Servicing Payment Service Provider (ASPSP): the bank responsible for exposing “access to account” interfaces giving to third parties a level of service aligned to the one that, as end users, we get through the bank’s digital channels. The bank is responsible for performing strong customer authentication, even when we access our data through the service of a third party. The bank is also the first point of liability in the case of fraud and disputes.


• The Third-Party Provider (TPP). A Third-party provider is a new regulated role for organizations that can offer value added services using the data hosted by the banks. Although, as mentioned, these third parties delegate customer authentication to the banks, they remain responsible for seeking the customer consent to acting on his behalf. This is meant to give to third parties the maximum level of freedom in designing innovative product and services, however it leads to a complex security model in which authorization and authentication are owned by two different organizations. If I use a third party to get my account information the bank needs to validate that I am who I claim to be; while the TPP must demonstrate that I have given consent to retrieve that information.


• National Competent Authorities. National Competent Authorities have a fundamental role required by one of the core principles of PSD2:  promoting an “open” ecosystem. With PSD2 banks cannot limit or control the access given to third parties. That responsibility is given to independent national authorities that certify the third parties, issue licenses, and maintain registries that can be used by the banks to verify the actors they interact with. Being a “European” regulation, PSD2 also defines passporting rights that a TPP with a license in one country can use to be able to do business across the single EU market. This creates the need for EU-wide TPP registries. If you want to know more about who is building them and how please refer to the links in the references section. For this blog, I will just refer to a generic “European Registry"

The interactions

From an architectural point of view, the PSD2 implementation of a bank needs to support two broad groups of use cases.

Third party on boarding

Before contacting a bank a TPP must have registered with the relevant National Authority and obtained the electronic certificates, aligned with the eIDAS standards, proving its identity. During the on boarding process the bank uses those certificates to authenticate the TPP. It then verifies its level of authorization (for example if it is a payment initiation service provider or account information service provider) through the European Registry.

Figure 2 – TPP on boarding doesn’t involve PSU interactions

If it all goes well the third party is enabled to call the APIs of the bank. Note, however, that at this point the TPP still has no authority to execute payments or access account information on behalf of a customer.

Access to accounts

Figure 3 – Access to accounts

A TPP can invoke three groups of APIs: payment initiation, account information and confirmation of funds. The interactions between TPP, ASPSP and PSU vary depending of the type of payment, account and standard you consider.  However, at a high level, they are all broadly based on a three steps interaction pattern:

1. The TPP asks the bank to perform an action on behalf of the customer, for example initiating a payment


2. The bank authenticates the customer, effectively making the customer "sign-off" the action requested by the TPP


3. The TPP triggers the execution of the action

From a security point of view, the most reliable approach to manage these interactions is to leverage OAuth2.0, a proven standard framework for controlling API interactions in which the API client (the TPP), the data owner (the customer) and the API provider (the bank) are three different entities interacting through an open network.

The Architecture

Overview

Figure 4 – ASPSP Architecture Overview

Figure 4 presents an overview of the PSD2 reference architecture for an ASPSP.  At the boundaries, you see the external actors described earlier:  the third party, the customer using a third-party application, the TPP registry and the certificate authority issuing the eIDAS certificates.

In the middle, there is the bank exposing the access to accounts APIs. As a bank, you already have several of the components represented here. In grey, you see the back-end systems managing accounts and payments as well as an integration and messaging layer; while the elements in green control security and perform customer authentication. Depending on the maturity of your API strategy you might have or not the elements in dark blue. These include gateways to enforce API access policies, a developer portal to enable API consumers to find and subscribe APIs by self-service, API management and analytics components to control the API life-cycle and have visibility on the usage of the interfaces. There is also a monetization elements for billing API consumers. This is not actually required for psd2; however, it becomes critical when you expand your open banking strategy beyond compliance.

In light blue, you see application components that are specific to PSD2. The TPP registry provide access to the data stored in the European Registry. The account request and payment initiation services supports the “chatty” interactions between the TPP, the bank and its customer. These are required to verify that a business transaction is properly set up and has the right level of approval before it is executed. Finally, the Sandbox enables the TPP to test those interactions using mock data.

PSD2 has an impact across the end to end architecture. However, the solution decouples the elements dependent on the bank's core systems from the ones responsible for exposing standard interfaces to the outside world. The implementation of the grey components at the bottom of the diagram can vary dramatically for each individual bank. On the other hand, the external layer of the architecture can be standardized and replicated across organizations.

Note that banks want, on one hand, to expose a standardized set of compliance APIs to the TPPs, but on the other give a unique experience to their customer. I will discuss a couple of alternatives for handling that later, talking about the integration between the elements of an API platform and the customer authentication components

Let’s look at how the solution supports the requirements mentioned earlier.

Third party on boarding

Figure 5 – TPP On boarding

Figure 5 shows the interactions triggered by the on boarding process:

(1) The TPP invokes a set of APIs to subscribe to the Access to Account interfaces of the bank.

(2) The platform validates the eIDAS certificates provided by the TPP and uses the information carried by the certificates to identify the TPP

(3) The role of the TPP is verified against the data provided by the European Registry. This data can be "cached" by the solution to minimize calls to the external industry registry.

(4) If it is all OK, the TPP is registered as a valid subscriber of the bank’s Access to Accounts APIs.

Access to accounts

Figure 6 – Access to Accounts

Figure 6 shows the actual execution of a transaction, for example a payment or a request for account information. Here is a description of the flow represented by the arrows of the diagram, in the context of the three-step interaction pattern introduced earlier.

The TPP asks the bank to perform an action on behalf of the customer, for example initiating a payment

(1) The TPP obtains the security keys required to submit the request for the action

(2) The TPP submits the actual request

(3) The solution saves the request and returns a reference identifier to the TPP

The bank authenticates the customer

(4)(5) The customer is redirected (or contacted through a decoupled channel) to the customer authentication components. These perform strong authentication, obtaining the customer “sign-off” for the original TPP request. At this level of abstraction, the diagram is not representing the detailed flow, based on OAuth2.0, that guarantees security, confidentiality and non-repudiation of the interaction. However, note that at the end of that flow the TPP receives an access token that is linked to the specific action signed-off by the customer.

The TPP triggers the execution of the action

(6) The TPP uses the access token to trigger the execution of the action

(7) The solution verifies the access token against the action requested by the TPP

(8) If all the checks are successful the calls move down the architectures to the internal gateway that provides access to the back-end platforms

The major difference between payment initiation and account information (or confirmation of funds) interactions lies on the frequency in which step (4) must be performed. A customer must explicitly approve every payment initiation; hence the associated access token will be valid only for a single transaction. That is not the case for account information and confirmation of funds: in those scenarios, the TPP receives tokens that can be used to perform multiple requests.

I rarely used the term “consent” so far. I think it is overused, abused and confused in PSD2 and GDPR discussions. However, for the sake of clarity, it is worth spelling out how consent is managed in this architecture. In the context of PSD2, “consent” is the permission given by the customer to the TPP to perform an action on his behalf. Reference [3] discusses the advantages of managing customer consent so that it is shared between TPPs and banks. In the approach presented here that happens in step (2). At that point the TPP communicates to the bank the consent received by the customer by submitting a request describing what the customer wants to do. This information is persisted by the account request and payment initiation services. If a consent is long lived, as in the case of account information, it can be managed and revoked by the end customer at any time using the Authorization Management interface.

Figure 7 – Consent revocation

Security Integration options

The internal gateway, shown in Figure 4, acts as the access point to the integration fabric of the bank and the line of demarcation between components implementing a standard PSD2 behavior and the core back end systems that the bank has grown organically over time.

The second significant integration boundary connects the elements responsible for supporting the TPP interactions (dark and light blue) and the ones responsible for authenticating the customer. To address this complex area you can leverage two proven solution patterns.

The first one is most commonly used by banks that want to reuse their existing customer authentication infrastructure to provide a consistent experience across channels, without impacting existing technology stacks. If that is the case you can configure the OAuth2.0 provider of the API platform, as shown in Figure 8, to expose authorization APIs to the TPPs and then delegate to the existing infrastructure the customer authentication and transaction authorization processes. When that is done, the control goes back to the API platform that generates the security tokens.

Figure 8 – Security Integration: Pattern 1

On the other hand, there are also organizations that do not have a security infrastructure implementing the strong customer authentication requirements mandated by PSD2, or are not able to update their current solution within the time frame mandated by the compliance deadlines. In that case, you can leverage a second pattern, in which you introduce new user access management components to handle customer authentication. These are configured to integrate with the bank user registry and implement a customer journey aligned with the experience that the bank wants to give to its customers.

Figure 9 – Security Integration: Pattern 2

The IBM stack supports both options. In the first case IBM API Connect integrates with the infrastructure of the bank, while in the second the API platform is complemented by IBM Security Access Manager, responsible for performing strong customer authentication.

PSD2 as a service

In order to speed compliance with PSD2, banks may be interested in taking advantage of PSD2 as a service

Figure 10 – External vs Internal interface “chattiness”

Figure 10 shows in black the numerous interactions required to perform authentication and authorization of a third party and manage the customer consent. They all happen in the outer layer of the architecture, before a request hits any of the back end systems of the bank (red arrows).

Figure 11 – ASPSP Hybrid Architecture

This gives you the opportunity of consuming this layer as a cloud service in the context of a hybrid architecture shown in Figure 11.

This approach addresses three risk areas:

• Technology: you offload to the cloud service provider the responsibility for scaling and securing the part of the infrastructure that is most exposed to the unpredictable load generated by third parties


• Delivery: you achieve a faster path to compliance by connecting your infrastructure to a solution built leveraging the lessons learnt from multiple previous implementations


• Maintenance: you move to the service provider the responsibility keeping your interfaces aligned with evolving standards

Figure 12 – Dimensions of the PSD2 Managed Service

Summary

PSD2 is just another regulation. However open banking, in its broader term I discussed in Reference [9], will continue to transform financial services, well beyond the compliance deadlines. The solution presented here offers a low risk path towards compliance and, at the same time, gives you a flexible platform to support your future digital strategy. The opportunity of consuming it as a service simplifies its adoption and removes the attrition of evolving API standards, so that you can focus what truly differentiates your organization.

Below you find additional information on the solution and technologies described here.

If you have questions, please let me know.  Connect with me through comments here or via LinkedIn to continue the discussion.

References

Review the regulation

[Ref 1] EU Directive, Payment Services

[Ref 2] Regulatory Technical Standards on Strong Customer Authentication and Secure Communication

Learn about different approaches to consent management

[Ref 3] Customer consent under PSD2

Review the API and eIDAS standards

[Ref 4] UK Open Banking

[Ref 5] The Berlin Group Access to Accounts Framework

[Ref 6] ETSI eIDAS standard for PSD2

Learn more about TPP registries

[Ref 7] Open Banking Europe

[Ref 8] UK Open Banking Directory

Learn how the API economy is transforming financial services

[Ref 9] Open Banking APIs are open for business

Get familiar with the tools

[Ref 9] IBM API Connect

[Ref 10] IBM Security Access Manager

Try out the APIs

[Ref 11] IBM Open Banking Sandbox

Achieve compliance through a managed service

[Ref 12] Managed service by Prolifics & IBM
#APIEconomy
#openbanking
#psd2