IT Architecture to Comply with PSD2 and Open Banking

IT Architecture to Comply with PSD2 and Open Banking

Over 40 years ago, the banks were one of the first industries to fully embrace the potential for computing to improve their businesses. For this reason, they have built up very complex systems and processes around those systems that have served them well over the years. Open Banking represents a seed change in this process and this blog will outline some of the complexities and challenges current banking architecture represents.

An Architectural Overview

The following picture illustrates just some of the complexity involved in making Open Banking Application Programming Interfaces (APIs) available to Third Party Providers (TPPs). Each part will be described in more detail in subsequent sections.


The Various Environments

Banks generally do not have just one back office system; in fact there are likely to be multiple systems that have built up independently over the years or as banks have merged over time. In simple terms there may be a system dealing with current and savings accounts, a different system dealing with credit cards, other systems dealing with loans, investments etc. In more complex environments, there may be multiple systems dealing with current and savings accounts perhaps following mergers or acquisitions. In the past, this will have presented itself to customers through having to call different numbers for different accounts. While banks have consolidated their call centres over time, the back office is likely to remain fragmented.


Auditing and logging are now a key component of any banking systems so that when queries appear about past transactions or access attempts, there is a full record of how that has happened and the identities of the parties involved. Real time monitoring is becoming critical in the battle against fraud and invalid access to banking information. By analysing behaviours of customers, monitoring can pick up abnormal behaviours and thus fraudulent access to accounts or worse, withdrawals from accounts. As banks must now by definition open their systems to customers via TPPs, this becomes an even more critical element in their systems.


Authorization is the control over who accesses what data and when. In all cases, this must move towards a more ‘policy based’ approach so that ‘who’ will generally have a role to determine when and what can be accessed. Some examples of roles:

  • The owner of the data (generally the customer) should be able to access their data at any time.
  • Bank employees should be able to access the data but only while they are working and based on legitimate access requirements. For example, they cannot simply access the data for their own personal reasons.
  • Limited access requests. This will happen more and more where a data owner wishes to give some entity (e.g. a mortgage advisor) limited access for a specific period of time to their data.

With the advent of open banking, these roles are likely to expand further and further.


Authentication is the key component to the success of open banking. Whereas previously, the bank dealt directly with the customer individually and could then therefore directly verify who they were, now requests will be appearing via third parties so a person’s ‘digital identity’ is critical. Methods for identifying people using biometrics are now very advanced but the key to this is how to successfully transmit this identity across multiple providers.

API Gateway

Most banks have used one of a number of ‘API Gateways’ available as their mechanism to expose their APIs to the outside world. All of these API Gateways are functionally rich and provide excellent levels of support to expose APIs, however, they are just one piece of a very complex chain to provide a functional API to external parties.

The Complexities Involved

It is clear from the above that the provision of access to functional APIs involves a lot more than just an API Gateway. In fact the access to APIs is only a minor part of the battle with the balance being in delivering functional APIs and processes that TPPs can develop, test and transact against in production. Some other issues raised by this complexity:

  • How can banks provide a defined level of response through Service Level Agreements (SLAs) when levels of access and numbers of ‘users’ is simply unknown?
  • How can banks plan for capacity in terms of resources required to support an unknown number of users?
  • A test system will or should replicate the production system exactly and therefore in itself will be an expensive resource that must be used sparingly.

All of the above illustrates the architectural challenges the banks have to face in order to support PSD2 and Open Banking. In the next of these blogs, we will discuss, based on this IT architecture, the choices available to the banks to provide test access to their APIs and the positives and minuses associated with each.