NextGenPSD2
https://finapay.hr/psd2/portal/documentation/v_0_1_1/WhitepaperHUBV1_0_2_1.pdf
Overview
The Berlin Group NextGenPSD2 is the chosen standard utilized by all of the HUB members to
support the TPP APIs as mandated by the PSD2. This section further clarifies and specifies, which
methods are supported and the specific changes or additions of the HUB for the Croatian market in
the implementation of the NextGenPSD2.
ID Use Case
NGP1 Initiation of a single payment
NGP2 Initiation of a future dated single payment
NGP3 Initiation of a multiple/bulk payment
NGP4 Initiation of a recurring payment
NGP5 Cancellation of Payments
NGP6 Establish account information consent
NGP7 Get list of reachable accounts
NGP8 Get account details of a list of accessible accounts
NGP9 Get balances for a given account
NGP10 Get transaction information for a given account
NGP11 Use cases related to card information access
NGP12 Group signing baskets
NGP13 Get confirmation on the availability of funds
Required Authentication Methods
The NextGenPSD2 standard provides for different authentication methods or flows:
- redirect (not compliant with OAuth)
- OAuth redirect
- decoupled
- embedded
- redirect
- embedded
While all of these methods are allowed by the NextGenPSD2, the HUB standard envisions that all
ASPSPs will support at least one of the redirect flows, which must allow for the PSU to use any of
the credentials issued to it by the ASPSP.
It is within the decision of the individual ASPSP on which redirect flow it will support (OAuth or nonOAuth compliant) and this is documented in the ASPSP specific implementation guidelines.
Country Specific Interpretation of NextGenPSD2
The nation-wide standard specifies the following guarantees for the implementation of the NextGenPSD2 by all ASPSPs in Croatia:
- All ASPSPs will provide support for TPP messages on operational issues
- All ASPSPs will provide support for multi-currency accounts
- All ASPSPs will use the IBAN as the account representation
- All ASPSPs will support future dated payments
Additionally, the TPPs should note the following rules for certain fields specified by the NextGenPSD2, specifically: - the PSU-ID-Type is conditionally required, meaning that the TPP must provide the PSU-ID-Type whenever it provides the PSU-ID (see also: OpenAPI
specification for the PSU-ID-Type field) - the PSU-ID-Corporate-Type is conditionally required, meaning that the TPP must provide the PSU-ID-Type whenever it provides the PSU-ID (see also:
OpenAPI specification for the PSU-ID-Type field) - The ASPSPs will enforce the explicit start of authorization, whenever the TPP will provide the TPP-Explicit-Authorisation-Preferred header
- The ASPSPs will support at least one of the following formats for account information:
- Camt.053 (XML based)
- JSON
- MT940 (Text based)
- The ASPSPs will support at least one of the following balance types:
- openingBooked
- expected
- interimAvailable
- forwardAvailable
- closingBooked
The following services / requirements are ASPSP specific and their support is not mandated by the Croatian standard:
- Information on transaction fees transported through the XS2A interface support will be provided based on individual ASPSP decision
- PSU-ID field may be required by some ASPSPs
- PSU-Corporate-ID field may be required by some ASPSPs
- SCA exemptions will be provided by individual ASPSPs based on their own risk assessment and use of exemptions for their own services
- Signing basket support and individual restrictions for the signing baskets will be determined by ASPSPs based on their supported workflows and
processes - All optional endpoints for AIS services defined by the NextGenPSD2 are left to the individual ASPSPs
- The following optional query parameters support for AIS is left to the individual ASPSPs: bookingStatus with values “pending” or “both”
TPPs should review the ASPSP specific documentation for the points mentioned above.
TPPs should also review the Country Specific Changes described in the next paragraph.
NextGenPSD2 XS2A Framework 1.3.3 Mar 13th 2019
Summary
The NextGenPSD2 Framework Version 1.3.3 offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services (‘Banking as a Service’) by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The possible Approaches are:
- Redirect SCA Approach
- OAuth SCA Approach
-> Not supported - Decoupled SCA Approach
-> Not yet supported - Embedded SCA Approach without SCA method
-> Not supported - Embedded SCA Approach with only one SCA method available
-> Not supported - Embedded SCA Approach with Selection of a SCA method
-> Not supported
Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition.
Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.
Some General Remarks Related to this version of the OpenAPI Specification:
- This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API. It is not an replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API.
- This API definition contains the REST-API for requests from the PISP to the ASPSP.
- This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
- According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md\]
- “If in is “header” and the name field is “Accept”, “Content-Type” or “Authorization”, the parameter definition SHALL be ignored.”
- The element “Accept” will not be defined in this file at any place.
- The elements “Content-Type” and “Authorization” are implicitly defined by the OpenApi tags “content” and “security”.
- There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which need these field, one can easily use the predefined types. But the ASPSP need not to accept them in general.
- We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mention in the Implementation Guidelines. Therefore the implementer might add the in his own realisation of a PSD2 comlient API in addition to the elements define in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the PSD2 API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ’ +
Space
The Berlin Group - A European Standards Initiative - Website
Send email to The Berlin Group - A European Standards Initiative
Creative Commons Attribution 4.0 International Public License