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.
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.
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.
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.
ABN AMRO 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.
What can we do for you?
Visma Connect is a Technical Service Provider (TSP). We support companies in harnessing the benefits of PSD2 XS2A services, offer a standard service interface for Payment Initiation and Account Information services and we deliver a full range of services on our SaaS payments platform.
We regularly engage with market parties and regulators to keep up with regulatory, market and technological developments.
Visma Connect's critical payments team brings vast experience with - and knowledge of - business critical transaction processing and secure data integrations between different organizations in both the financial services and other sectors.
NB: In response to our previous article, ING has stated it supports Recurring Payments, but this has not been published in the sandbox as of 16-04-2019.