Benefits of Providing Read/Write Sandboxes for Banks Supporting PSD2/ Open Banking

Benefits of Providing Read/Write Sandboxes for Banks Supporting PSD2/ Open Banking

Our previous blog described the options banks have in offering testing environments to comply with the Payment Services Directive 2 (PSD2) and offer open banking link. Here we discuss the advantages of offering a read/write sandbox to Third Party Providers (TPPs) and others who wish to access their Application Programming Interfaces (APIs).

What is a “read only” sandbox?

Many banks are offering ‘read only’ sandbox capability for testing. This means that while there is data in the sandbox, it cannot be modified and has no context. If we take a simple example of testing a payments process:

readonly-not-stateful

In this example, we want to:

  • Get the current balance for an account
  • Pay €100 into the account.
  • See the updated balance

Unfortunately because this is a read only sandbox, there is no context or state held, thus the balance that is returned after the payment into the account is the same as the first balance. Essentially anything paid into the account (or paid out from the account) is not reflected in the balance.

This seriously restricts the level of testing that can be done as essentially each request to the sandbox is stand alone and it’s impossible to test a full business process using this type of sandbox. In this case, it’s a relatively simple process, however, consider more complex processes that TPPs may want to test.

What is a “read/write” sandbox?

This is where services offered as APIs are actually interconnected and retain state, i.e. are continuously updated from the last action. So when an API call is made to a service to make a payment for example, one would expect a number of things to happen:

  • The account balance from which the amount is to be debited will be reduced by that amount.
  • The account balance to which the amount is to be credited will be increased by that amount.
  • The account from which the amount will be deducted will have a debit transaction to reflect the transaction that has occurred.
  • The account to which the amount will be added will have a credit transaction to reflect the transaction that has occurred
  • It may also be that there are different states for the balance as the payment may take some time to process.

So if we take the previous relatively simple example and how it would look:

readonly-stateful

In this case, the balance is correctly reflected and it will be possible to get transaction records related to the transaction.

Advantages of a Read/Write Sandbox

The provision of a read/write sandbox provides a number of advantages over read/only sandboxes

    • Full processes can be tested end to end with the ability to test the resultant changes all the way through the process.
    • The sandbox becomes a living, functional entity with data being created and modified regularly thus more accurately reflecting the real system.
    • Testing will occur with constantly changing data thus offering a much more comprehensive testing environment for applications.

While it is clear that offering a read/write sandbox will take more effort, this extra effort is outweighed by the fact that the testing process is as close to using the production environment as possible, resulting in better tested applications being deployed. In the next article, we will discuss how we can use a transactional read/write sandbox to implement a simple blockchain for each account.

Written by : Ostia Solutions