The document discusses updates to the Berlin Group NextGenPSD2 API framework. Key points include: the framework now supports additional optional API endpoints for future dated standing orders and aggregated orders; payment initiation formats allow bulk submissions with one SCA for multiple payments; field names have been improved using more common conventions; data extensions are possible with bank approval; and the framework now allows for multicurrency accounts defined as collections of subaccounts addressed by the same IBAN but differentiated by currency.

1. Berlin Group NextGenPSD2 API framework
and
other API associated technical questions
Time is short: 25th May 2018 - 14th March 2019 - 14th September 2019

2. Qualified Certificates supporting PSD2
ETSI TS 119 495 standard, Published May’2018

3. Summary
• Qualified Certificates for Websites (Establishing Secure SSL)
• Qualified Certificates for Electronic Seals (Registering
evidences, Data authenticity
• ISSUED BY Qualified Trust Service Providers (QTSPs)
• To enable Identification and verification of the payment
institution by a third party
• Will include information about:
o the authorization number of the Payment Service Provider
o Its home country’s supervisory competent authority
o Its roles.
ETSI PSD2 Workshop Videos: http://www.etsi.org/news-events/videos/psd2-workshop-videos

4. EBA electronic central register under the
Payment Services Directive (PSD2)
EBA-RTS-2017-10 & EBA-ITS-2017-07

5. EBA-RTS-2017-10 & EBA-ITS-2017-07
• The RTS set out requirements for manual and automated
provision of information from CAs to the EBA and the timely
synchronization between the national public registers under
the PSD2 and the EBA Register….
• They also specify the procedure for accessing the
information in the EBA Register, which includes the
functionality for downloading its content.

6. EBA-RTS-2017-10 & EBA-ITS-2017-07
• The ITS specify the type of information that will be contained in
the register from a pre-defined list of institutions that is provided
by the PSD2 itself, including:
o payment and electronic money institutions, their agents and foreign branches;
o exempted payment and electronic money institutions and their agents;
o account information service providers, their agents and foreign branches;
o providers of services based on specific payment instrument that can be used
only in a limited way; and
o providers of electronic communication networks executing payment
transactions or providing services in addition to electronic communications
services.
o !!! but no banks and not all TPPs;
o Open Banking Europe PRETA (OBE) – is developing central repository for
TPPs is close the gaps in the EBA Register…

7. NCA and QTSP cooperation

8. NCA and QTSP cooperation
ETSI is suggesting that NCA has to
require QTSP to inform NCA about
certificate issuance, so that NCS
further can request revocation etc…

9. Berlin Group NextGenPSD2 API
framework

10. Berlin Group NextGenPSD2 API framework
• Version 0.99, 27.09.2017
• Version 1.0, 08.02.2018
• Version 1.1, 11.05.2018
• API standard for 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).

11. Berlin Group NextGenPSD2 API framework
• The API framework of Berlin Group provides a toolkit to build
your own PSD2 API standard.
o Payment initiation data structure & format: full JSON, ISO20022-XML
(pain.001 and pain.002)
o Payment initiation mode: single and/or bulk payments
o Account information data structure & format: full JSON, ISO20022-
XML (camt.052, camt.053, camt.054) or even SWIFT MT940, MT941,
MT942
o SCA approach: redirect, embedded, decoupled
o Consent management: OAuth2 performed in a pre-step only and/or in
an OAuth2-based SCA procedure

12. Berlin Group NextGenPSD2 API
framework – API changes

13. New optional API endpoints
• While the previous version supported a one-off payment
initiation only, the latest additionally supports submitting
o Future dated standing orders for recurring payments.
o Aggregated orders

14. 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)

15. Field names improvements
• The latest version comes with improved field names using
more commonly known conventions.
• Some of those are taken from ISO20022 standard—e.g., the
status attributes for the account balance are partially based
on ISO20022.
Btw: For example Open Banking UK completely relies on ISO20022 attributes.

16. Data Extension Possibility
• Banks might add additional data attributes to the response
messages,
o These need to be submitted to the Berlin Group first for approval.
o These additional fields need to be documented on the API
specification of the bank.

17. Currency options
• Besides Euro, the latest version allows multicurrency
accounts
o defined as a collection of different subaccounts addressed by the
same account IBAN.
o The subaccounts can be uniquely differentiated by the IBAN and
the currency identifier.

18. Aivars Belis
Principal Consultant
+371 2944 6951
aivars.belis@vedicard.eu
Interested in meeting PSD2 requirements?
Talk to us…
We can assist You From strategy advice to enterprise architecture
upgrade.