PSD2 – Coming to America By Way Of Europe



What Are the Implications for Testing?

Across Europe, financial institutions are waking up to the impacts of PSD2 – the Payment Services Directive II of the European Union.

The purpose of the legislation is to improve consumer rights and services. One key aspect of this is to force financial institutions to provide open APIs to allow external entities, at the request of consumers, to access the consumer’s data held by the bank.

The logic of the EU is that financial institutions preserve their market domination by creating barriers to entry for new competitors.  One of the most significant of these is making access to the consumer data they hold difficult/impossible to access. PSD II will break that data monopoly and improve competition, to the benefit of consumers.

In the UK, any bankers thinking that BREXIT will alleviate them of this responsibility will be disappointed as the current government, despite its rhetoric about the EU, continues to mirror legislation of this type through domestic legislation.

Readers may wonder about the relevance of this change to the Paragon Edge Blog Community? 

The first relevance, I believe, is that it is worth remembering that GSM, EMV and immediate payments are all European Union-backed initiatives that have crossed the pond. Where Europe legislates for change, the US usually waits for market pressure to drive adoption. However, as our two markets are so interconnected in the modern world, it seems reasonable that adoption of this change by consumers in Europe will create the market pressure to drive adoption in the US.

The second relevance is that today, the banking community struggles to achieve the required level of end-to-end testing in its payment infrastructure, even when it controls all of the participants. Once the ecosystem is expanded beyond the legacy systems and legacy thinking of the traditional banks to encompass the more agile infrastructures and thinking of new entrants, banks will be unable to meet the expanded testing demands, that is if past practices continue to be preferred.

Traditional SME or risk-based testing will be inadequate. The ability to rapidly and exhaustively test and re-test connections with external parties will require automated testing with extensive coverage. The historic experience of bi-annual certification with the card schemes will not be an adequate baseline of experience for the type of testing required in this new API paradigm.

In this new model, banks, previously used to certifying their compliance to card schemes, will also have to certify service providers seeking connection to the systems used by banks and other financial services providers. Such certifications are unlikely to follow the regular patterns of the card schemes.

Remote self-certification by the service provider is more likely to mirror the model deployed extensively by Paragon on behalf of transaction processors around the world. This is because a transaction process system (TPS) is an information processing system for business transactions involving the collection, modification and retrieval of all transaction data. Characteristics of a TPS include performance, reliability and consistency. TPS is also known as transaction processing or real-time processing.

Obviously, while most all forms of testing have their own inherent complexities, it is easy to see the difference between those forms that are more static (compliance) and those that are dynamic (transaction processing).  While there seems to be a worldview that excludes either in the future, the disruption and convergence we are seeing would seem to suggest complexity, as regards transactional data and the systems that hold such, is on an exponential path to more and more complexity.  Such conditions require a different strategy and set of solutions when it comes to testing. 


Source link