Choosing the right PSD2 API standard out of the Berlin Group NextGenPSD2 API framework

On 13th January 2018, the second Payment Services Directive (PSD2) came into force. With it – amongst other rules, banks are will be required to open their systems to third-parties and provide interfaces that would allow them to initiate payments, retrieve account information and a conformation of availability of funds. 

But the regulation leaves open the details of the application programming interfaces (APIs) that third-parties will use to connect with banks. The recently published final Regulatory Technical Standards (RTS) on strong customer authentication on 13th March 2018 specifies only technical framework conditions and no interface standard. Moreover, there is a lack of API standardization in the EU. To help fill this gap, the Berlin Group—consisting of almost 40 banks, associations and PSPs from across the EU—has defined a common API standard called "NextGenPSD2" for the use cases specified in PSD2. Initiatives are also being launched in Poland (PolishAPI), Slovenia and France (STET). 

In December 2017, I published a blog on Finextra comparing the Berlin Group NextGenPSD2 API framework and the Open Banking UK API standard. Before publishing, I had participated in the Berlin Group consultation phase of version 0.99. The latest Version 1.0, published on 8th February 2018, is worth checking out to see what the major changes are and what a bank should make out of them. 

Here are the major changes I observed between version 0.99 and 1.0 of the NextGenPSD2 API framework:

• Payment use cases: While the previous version supported a one-off payment initiation only, the latest additionally supports submitting future dated, standing orders for recurring payments.
  
  
• Payment initiation formats: The previous version allowed the submission of a single payment in JSON, JSON encapsulated pain.001 and pain.002 (ISO20022 XML). The latest version now allows on top of a single payments, multiple payments in one single bulk submission by applying SCA once for all transactions in one run in JSON or pain.001 and pain.002. Standing orders come as a JSON or combination of JSON and pain.001 (multipart).
  
  
• Data fields: The latest version comes with changed field names according to more commonly known conventions. Partially field and attribute naming conventions are taken from ISO20022 standard—e.g., the status attributes for the account balance are partially based on ISO20022. Whereas, Open Banking UK completely relies on ISO20022 attributes.
  
  
• Data Extension: Banks might add additional data attributes to the response messages, but these need to be submitted to the Berlin Group first for approval. These additional fields need to be documented on the API specification of the bank.
  
  
• Currency options: On top of the Euro, the latest version allows for multicurrency accounts—defined by the Berlin Group as a collection of different subaccounts addressed by the same account identifier such as the IBAN. The subaccounts can be uniquely differentiated by the IBAN and the currency identifier.

Where is the API standard to facilitate a pan-European ecosystem?

NextGenPSD2 is an API framework and not a single standard such as Open Banking UK. There are efforts for harmonized PSD2 API standards and API performance running at the API Evaluation Working Group of the Euro Retail Payments Board on Payment Initiation Service (ERPB on PIS). But what can banks decide upon now if they chose Berlin Group. The API framework of Berlin Group provides a toolkit to build your own PSD2 API standard. A Berlin Group API standard is not equal another Berlin Group API standard, and there are multiple options that can be assembled with the following main API design aspects:

• Payment initiation data structure & format: full JSON, ISO20022-XML (pain.001 and pain.002)
• Payment initiation mode: single and/or bulk payments
• Account information data structure & format: full JSON, ISO20022-XML (camt.052, camt.053, camt.054) or even SWIFT MT940, MT941, MT942
• SCA approach: redirect, embedded, decoupled
• Consent management: OAuth2 performed in a pre-step only and/or in an OAuth2-based SCA procedure

The above list of main design aspects can be combined with various options of API standards—which could lead to a fragmented API landscape in Europe. Banks should follow best practices in API design principles. Nothing speaks against an API standard that allows multiple options, but at a minimum:

• RESTful JSON (full JSON format) for payments and account information by using standardized ISO20022 attribute naming conventions, single payment mode, embedded SCA approach and with full OAuth2-based SCA procedure

Time is short. By 14th September 2019, banks are mandated to be RTS-compliant and even make APIs available for testing and piloting six months before the market launch. Having the optimal APIs in place that follow best practice principles will be crucial for banks’ “Beyond PSD2” open banking strategy.