PSD2, RTS and Open API Projects in a Multinational Bank

Project Stories

Introduction

The PSD2 project aimed to prepare application-programming interfaces (APIs) for the applications being developed by other companies within the so-called open banking, as required by the European Directive of the same designation (PSD2).

At the time of the adoption of the amendments to the Directive (RTS), the project also changed its name - in the end it was called "Open API".

What it Will be About?

Project Introduction and Objective

Project Progress

What we Worked with

What we Have Overcome

What we Have Achieved

Project Objective

The aim of the project was to provide testing for APIs issued by the bank - those for informing about client 's accounts, for payments and those initiated by third party cards. In addition, the introduction of stronger client authentication (SCA) and testing of new security features when logging in to both internet banking and the portal for user applications issued from the bank's and client's point of view by third parties have been addressed.

Project Progress

The beginning was the year 2018, when the PSD2 directive came into force in the Czech Republic. This created the need for testing services for the newly introduced EU requirements - especially the development of application-programming interfaces for connecting banks with applications of companies offering indirect banking services.

The project itself followed the development of the European PSD2 Directive in terms of its amendments. Each requirement of the Directive or its amendment was analysed and the impacts on the entrusted area were assessed. The project team was often assisted in end-to-end testing across several internal systems, and often initiated the testing itself. The project ended several months after the entry into force of the RTS amendments in full (early 2020).

What we Worked with

For manual testing of the APIs themselves using basic REST queries, we used Postman primarily for automated SoapUI tests with scripts in the Groovy language. The Jenkins server was used to report the test results. In addition, it was also necessary to prepare data for tests in SQL-Developer.

We recorded the actual tests in HP's Application Lifecycle Management, which was used by the bank at the time.

What we Have Overcome

The project struggled personnel changes associated with the transition to an agile development methodology - for example, when the chief business analyst left the team in the middle of the project. This was overcome by several team members substituting him, as well as by greater involvement of testing within the "Agile".  The greater involvement in testing also paid off during the transition from the ČOBS API standard to the Berlin standard and, in fact, with any newly introduced API or its version.

We managed to automate an ever-increasing number of regression tests, and tests have proven useful for out-of-regression tests and for solving ad-hoc problems. Another major obstacle was the need for up to several dozen different permissions to systems and applications. However, everything has been successfully mapped and written into a clear internal manual, which has been used by the bank even after the end of the project. 

What we Have Achieved

Throughout its lifetime, the project's testing team was able to provide integration tests and assist in resolving data flow errors among the bank systems. It also managed to react flexibly to problems reported for production, and the automated tests also simulated simple performance tests (for example, entering several queries by the user in a short time sequence). Of course, the team was supportive in the agile transformation, and through better communication with developers, many bugs were identified at the very beginning.

Author: Pavel Bujárek