3 challenges in implementing the PSD2 APIs

3 challenges in implementing the PSD2 APIs

3 challenges in implementing the PSD2 APIs

As a follow-up on my previous article on the diversity of the PSD2 APIs as published by four Dutch banks, this article will dive deeper into some of the challenges that present themselves when implementing these APIs. Specifically, the error codes in the non-happy flow scenarios and what information they offer TPPs, the data dictionary used by the banks and the differences in the process flows. As a disclaimer, this article is based on the status of documentation published by the banks at the time of writing and only covers some of the highlights.

By Steven Schouten, Business Consultant at Visma Connect (formerly ebpi

Error codes

There seems to be little alignment between the Dutch Banks in the use of error codes. The Rabobank has implemented the Berlin Group standards to the letter (including the Norwegian specific REQUIRED_KID_MISSING error code), where ING has implemented a subset (10 out of a potential 32 for Payment Initiation Service (PIS)) of the Berlin Group error codes. Both the Rabobank and ING have implemented the codes in the exact definition of the Berlin Group, which should ease the implementation at the side of the TPP.

ABN AMRO has implemented proprietary error codes, and with 43 codes for the PIS response alone, at a very detailed level (the most detailed of any bank yet). This level of detail is very valuable to the TPP, as they get very specific information on the error and thus on the way to take the necessary steps to correct it. The downside of using proprietary codes is the necessity to implement a translation table. In a landscape with over 7.000 banks in Europe, this is not very TPP-friendly.

Volksbank has not published any specific error codes beyond the pure HTTP response codes.

Data Dictionary

For the data dictionary, there is more alignment visible, as Rabobank, ING and Volksbank all have followed the dictionary as prescribed by the Berlin Group. ABN AMRO however uses a different naming convention. For example, in the PIS, Rabobank, ING and Volksbank use the Berlin Group specified creditorAccount as tag for the identification of the beneficiary, while ABN AMRO uses counterpartyAccountNumber. ABN AMRO uses amount, while Rabobank, ING and Volksbank use the Berlin Group specified instructedAmount.

Next to the Berlin Group specified JSON messages, ING also offers the option to initiate payments via the industry standard ISO20022 XML format (pain.001.001.03).

While the implementation of ABN AMRO results in very efficient JSON messages, as they consistently use minimal tags and only use the necessary tags in each message, ABN AMRO is obliging the TPPs to implement a specific interface. Not only does this result in extra one-time implementation effort, it is a continued burden as with any new release (either by ABN AMRO or the TPP), a cross check needs to be done and potentially message mappers need to be updated.

Process Flows

All the banks have implemented OAuth2 as a support for the authorization of the PSU towards the TPP and all use the Redirect SCA approach. In this approach, the Payment Initiation Request is followed by an explicit request of the TPP to start the authorization. This is followed by a redirection to the ASPSP SCA authorization site. A status request might be requested by the TPP after the session is redirected to the TPP’s system.

However, ABN AMRO has taken a slightly different approach, where the initial payment initiation request is followed by the SCA redirect and the authorization by the PSU, but where the payment needs to be explicitly executed through a PUT payment request. Rabobank, ING and Volksbank have already executed the payment at this stage.

Although the process is not fundamentally different between the banks (in all cases the payment is initiated through a POST Payment request, followed by an explicit authorization by the PSU via an SCA redirect), the final step for ABN AMRO is to execute the payment via a PUT Payment request, while for Rabobank, ING and Volksbank, a GET Payment request can be executed to get the result of the payment initiation request.

Conclusion

The detailed assessment of the differences in the APIs offered by the Dutch banks show that there is still a way to go in terms of alignment and standardization. However, the differences show that each of the banks have thought deeply on their implementations. Rabobank has chosen to align very closely to the Berlin Group standards, thus trying to make it as easy as possible to connect, while ABN AMRO clearly has chosen a different path. Their minimal implementation offers benefits in terms of performance, while their extensive error code implementation offers benefits in tracing and solving issues. Next versions of the implementations may very well see a convergence where hopefully the benefits of these two approaches are combined.


About Visma Connect

Visma Connect designs, builds and delivers working solutions and services for highly secure, fast and reliable qualified information exchange. They process large volumes of digital and business critical messages, exceeding 300 million messages in 2018, and deliver services to the business community, municipalities, agencies and national governments.

Share
Share on facebook
Share on google
Share on twitter
Share on linkedin
Related Posts
Featured
Weekly fintech update in your mailbox? Sign up for our Global Fintech Update, sent every friday.
This infographic gives an overview of how the different sectors within the ecosystem are positioned in the financial services value chain.

This website uses cookies to ensure you get the best experience on our website.
To learn more, read our privacy policy.

X
X
X