Risks to Banks providing Open Banking Ecosystems and Developer Portals

Risks to Banks providing Open Banking Ecosystems and Developer Portals

There are always risks to any innovative endeavours and the provisioning of Open Banking / PSD2 Ecosystems and Developer portals is no different. Here we discuss these risks and the potential to mitigate or even eliminate those risks.

Technical Risks

The banks’ existing systems are hugely complex, expensive to build and maintain and are highly regulated environments. The nature of Open Banking necessitates opening channels to those systems in the form of Application Programming Interfaces (APIs). Due to the cost and complexity of these systems, they are a rare resource and thus need to be shared. With the best will in the world, this creates enormous risk that Third Party Providers (TPPs) testing against these systems have the potential to bring these systems down. This will definitely impact on other TPPs using the system and has the potential to cause even further problems deeper into the banks technology stack depending on where the problem manifests itself.

On boarding Risks

Each TPP that is entitled to access the banks’ APIs must be approved as an Account Information Service Provider (AISP) and/or Payment Initiation Service Provider (PISP) with the regulatory authority in their respective country. This simply proves their business credentials but says nothing about their technical competence. The risks of them causing problems during an on boarding process are extremely high.

Testing Risks

Shared test systems between TPPs testing their applications leads to a lot of testing risk. Often the action of one TPPs’ test activities will cause changes which impact on other TPPs. This can have the impact of a TPP spending hours, or even days, looking for issues caused by other TPPs changing the shared system. This can also lead to erratic results during testing which causes even more confusion and wasted time. Finally a shared test system simply is not compatible with agile development methodologies as the lack of a well-defined state of a test system means that it cannot be used in a continuous testing scenario as the likelihood is that it will regularly fail.

Regulatory Risks

There is more and more regulation around usage of data specifically in Europe with the introduction of the General Data Protection Regulation (GDPR). As TPPs and the banks will be dealing with incredibly sensitive personal and financial data, there is massive risk of data being misused inadvertently, thus opening the risk of massive fines. Isolating TPPs from each other in a shared test environment is extremely problematic.

Reputational Risks

This frightens banks the most. While any of the previous risks would cause some issues, a major news story that data had leaked, technology had broken or even the experience is poor could cause significant reputational damage to a bank.

Eliminating These Risks

The key to eliminating or reducing all of these risks is to offer standalone, isolated ‘sandboxes’ with synthetic data which simulate the operation of the actual test system. This offers the following benefits:

  • A standalone sandbox for the initial on boarding of TPPs eliminates any risks related to the on boarding process as they can only cause problems for themselves in their own environment.
  • These sandboxes can further be used for on-going testing by the TPP of new developments prior to testing with the real system. In fact, the final test with the real test system can become purely an acceptance test as all testing should have been completed with the sandbox simulation. This will reduce the load on the actual test system.
  • As each TPP will have their own isolated sandbox environment, the only developers they can impact on are their own developers which can be coordinated internally.
  • The standalone sandbox is a perfect fit for the agile development process as sandboxes can be created as Docker instances which can be fired up on demand for the Continuous Testing (CT) and Continuous Integration (CI) processes.
  • Regulatory risk is eliminated as the sandboxes will use synthetic data initially and any data added to or updated on the system by the TPP will only be available to developers within that TPP thus ensuring they can manage access to that data internally from a regulatory point of view.

All of the above significantly reduce the potential for reputational risk to the bank which is a key ask of the banks. In the next of these blogs, we will discuss the IT architecture choices available to the banks to comply with the PSD2 regulation in particular and to participate in Open Banking in general.

Written by : Ostia Solutions