Agile Testing Sandboxes PSD2

Agile Testing Sandboxes help to address the requirement of the Payment Services Directive 2 (PSD2)

The Payment Services Directive 2 (Directive 2007/64/EC), perhaps better known as PSD2, was adopted by the European Parliament and Council and is set to impact the payments industry across Europe. PSD2 seeks to:

  • Further standardise and make interoperable card, internet and mobile payments
  • Reduce barriers to entry, in particular for card and internet payments.

The main scope of PSD2 is to encourage new players to enter the payment market, and it does this by mandating Financial Services Institutions (FSIs) – Retail banks to “open up the bank account” to external parties. These Third-Party Players (TPP) are divided in two types:

  • Account Information Service Providers (AISPs) – are providers that can connect to bank accounts and retrieve information from them.
  • Payment Initiation Service Providers (PISPs) – players that can initiate payment transactions.

The FSIs have to adapt. Currently bank accounts are siloed and, with a few exceptions, banks do not grant access to the information stored in customer accounts. Under the new regulation, they are asked to “open up”, but the burden of developing technical solutions is on the banks themselves, creating the APIs to be used by the TPP. For example, to create APIs such that external parties to the FSIs can access financial records on behalf of their clients who have accounts with the FSI.

To comply, whilst preparing for the implementation of PSD2, it has become clear that the FSIs wish to offer all the TPPs’ access through a dynamic simulation of their as their back-office systems transform to PSD2 compliance; without overloading the current test environment. The creation of Agile Testing Sandboxes means that a number of the internal controls and data security issues that appear with the presentation of an open “API” to the TPPs can be addressed. These Agile Testing Sandboxes ensure that:

  • Only authorised TPPs gain access to the controlled test system, a cost-effective way of providing a standalone testing environment.
  • Only data related to authorised individuals is made available to the external party.
  • APIs are being used correctly by external parties, validation is completed that the external party is using the APIs correctly and legally before allowing access to the real systems.
  • Cross contamination of data between external parties does not occur, that data is obscured, they are isolated from the banks data and other external party’s data, there is no risk of data loss or data governance issues.
  • Current Data Protection and upcoming General Data Protection Regulation (GDPR) demands can be addressed.
  • Workload from the TPPs can be managed and controlled, does not impact any production service, used for performance and load testing to determine how much load the external party is likely to place on the back-office systems.
  • Help the FSI to develop and test their own strategies and policies in relation to PSD2 and how it can be implemented.

ost-sandbox-PSD2-001

In addition, an Agile Testing Sandbox running in the Cloud, Docker or on premise using commodity hardware and software can quickly be deployed to simulate the back-office environments, and be used for Agile Design, Development and Test.

Ostia Portus EVS technology delivers the dynamic Service Virtualisation technology demanded by our customer’s Development and Testing teams to create these Agile Testing Sandboxes. EVS technology builds on established record/replay technology. It extends this capability/function and is able to simulate the request/response interaction, providing a fully customizable approach to creating virtual services. Ostia Portus EVS technology:

  • Uses metadata definitions and structures to create services, as a series of components, to simulate the real services, within a Java development environment, thereby isolating the TPPs from the FSI’s critical production and test and back-office services
  • Uses the simulated service components and Java to integrate and build contextual services to represent the interdependency between services in an end to end environment, where the dynamic response from one service can easily be used within the request in subsequent services. This is critical in representing a complex interconnection or automated process such as a FSI back-office system.

The application under test thinks it’s talking to the real end to end system but is talking to simulated service(s) using the Portus EVS framework technology running on commodity hardware and software, which can be cloned as often as necessary, so test systems of this nature can be made available on demand.

 

Written by : Ostia Solutions

    Detect location

    2500 Characters left