Bank Provisioned Test Environments to Support PSD2 / Open Banking

Bank Provisioned Test Environments to Support PSD2 / Open Banking


Our previous blog described the architecture banks must provide to comply with PSD2 and offer open banking link. Here we discuss how banks are proposing to on board and provide testing access to Third Party Providers (TPPs) and others who wish to access their Application Programming Interfaces ( APIs).

Single Test Environment for On Boarding and Testing

In many cases that we have seen, the banks are simply offering the following to TPPs and external parties wishing to on board or test into the future:

PSD2 Single Test Environment Diagram

While offering this can support a limited number of TPPs or users of this single shared environment, as the eco system expands and demand increases, it is not practical simply to offer a single ‘test’ environment, for the following reasons:

On boarding of TPPs

The PSD2 directive implies that once a TPP is approved as an Account Information Service Provider (AISP) and/or Payment Initiation Service Provider (PISP) by their local regulatory body, they are entitled to get access to a banks APIs immediately. While regulatory approval defines them to be a valid AISP or PISP, it says nothing about their technical competence. Even a technically competent TPP will make mistakes in their usage of APIs as it is part of the development process.

Ongoing Testing by TPPs

The goal is that multiple TPPs will continue to work with banks going forward as they improve and increase their offerings to users. This will involve ongoing development and testing of their systems interacting with the back office APIs.

Consequences of only offering a Single Share System

There are a number of risks involved with this approach:

  • Any TPP can potentially bring down the availability of the test environment, thus impacting on other TPPs using the test environment.
  • Any TPP has the potential to cause issues deeper into the bank’s infrastructure which could impact on the wider operation of the bank.
  • Any TPP developing today will be using Agile development methodologies which require Continuous Integration and Continuous testing capabilities to function. This is incompatible with a shared testing environment where state changes continuously.
  • The costs involved in maintaining this over the years is likely to increase exponentially as this type of infrastructure involves massively expensive resources.

Probably worse still are the ‘unknown unknowns’ in terms of what impacts this will have down the road.

API Testing for On Boarding and Testing

Some banks are simply offering an API based infrastructure for on boarding and testing much like the following:

API test environment diagram

In these cases, the API will return a valid response to the various API calls with valid data which is a good test of whether an API is being called correctly in isolation. This is done using any of the standard API Gateways out there today or there are other API test tools that can do this. However, this has a number of drawbacks:

  • How consistent is the data between calls? If a payment is made using an API, is this reflected in account balances?
  • What about authorization and authentication which are not tested as part of this?
  • Finally the full customer journey is not covered by this in terms of how a Payment Service User (PSU) sets up access to their accounts and consents to the bank that they wish their data to be made available?

Providing an API only testing environment is very much like testing an airline pilots flying skills by having someone else do the take-off and landing (i.e. the difficult parts of the process) while asking the pilot under test to simply fly the plane while it is in the air.

Individual Test Sandbox Environments for On Boarding and Testing

The key to protecting your back office systems from risk and ensuring that TPPs and other external testers do not stand on each other’s toes is to provide fully functional, independent sandboxes that simulate exactly how the back office works.

API test environment diagram

These sandboxes can be run behind the API Gateway or without it, on premise or in the cloud but their key attribute is that they can be created and made available in seconds on demand. This means this infrastructure can then scale easily without risk to your back office systems as more and more TPPs and external users of the test APIs are brought on board.

Test Environment Used for Validation

This can ensure that your actual test environment is simply used as a final validation of a new release of software as follows:

API test environment diagram

This will take pressure off your test environments whilst also protecting them from the risk of corruption and impact during the on boarding, developing and testing cycles that will be part of the PSD2 and Open banking environment for many years to come.

This illustrates there are some major choices ahead for banks. In the next article, we will discuss the advantages that having a truly transactional read/write sandbox can bring to testing.


Written by : Ostia Solutions