Consents API
home
NextGenPSD2 XS2A Framework
Summary
The NextGenPSD2 Framework Version 1.3.11 offers a modern, open, harmonized 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 authorized) access to their bank accounts and financial data.
The possible Approaches are:
* OAuth SCA Approach
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 a 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 needs these fields, 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 mentioned in the Implementation Guidelines.Therefore the implementer might add these in his own realization of a PSD2 comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the PSD2 API has 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
#BOI-REMARK: The Hebrew alphabet must be supported as part of the character set
א ב ג ד ה ו ז ח ט י כ ך ל מ ם נ ן ס ע פ ף צ ץ ק ר ש ת
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space
/v1/consents:
POST:
summary: Create consent
description: |
This method create a consent resource, defining access rights to dedicated accounts of
a given PSU-ID. These accounts are addressed explicitly in the method as
parameters as a core function.
**Side Effects**
When this consent request is a request where the "recurringIndicator" equals "true",
and if it exists already a former consent for recurring access on account information
for the addressed PSU, then the former consent automatically expires as soon as the new
consent request is authorized by the PSU.
BOI-REMARK:
BOI is differentiating ASPSPs in the role of banks and of credit card processors.
For banks, the detailed consent will differentiate between payment accounts and card
accounts- payment accounts are addressed by the IBAN as offered in the generic
NextGenPSD2 standard. If card related information is also addressed, the TPP shall not use
PANs of a credit card. The TPP may use the IBAN with the additional cashAccountType
"CARD". When card related information is addressed the meaning is that the consent is given
to all credit cards related to the same IBAN.
For credit card processors, all cards which are to be consented for account information need
to be addressed by maskedPANs specifically in the Detailed Consent Model. Credit card
processors are mandated to offer in addition the Bank Offered Consent Model, i.e. in a first (or follow up) consent request, the TPP can let the PSU choose all cards to be addressed during authorization on the ASPSP authorization page. The TPP will retrieve the maskedPANs of all related cards in the GET /card-accounts/… calls.
Optional Extension:
As an option, an ASPSP might optionally accept a specific access right on the access on all PSD2 related services for all available accounts.
As another option an ASPSP might optionally also accept a command, where only access rights are inserted without mentioning the addressed account.
The relation to accounts is then handled afterwards between PSU and ASPSP.
This option is not supported for the Embedded SCA Approach.
As a last option, an ASPSP might in addition accept a command with access rights
* to see the list of available payment accounts or
* to see the list of available payment accounts with balances.
operationId: createConsent
tags:
- Account Information Service (AIS)
/v1/consents/{consentId}:
GET:
summary: Get consent request
description: |
Returns the content of an account information consent object.
This is returning the data for the TPP especially in cases,
where the consent was directly managed between ASPSP and PSU e.g. in a redirect SCA Approach.
operationId: getConsentInformation
tags:
- Account Information Service (AIS)
DELETE:
summary: Delete consent
description: The TPP can delete an account information consent object if needed.
operationId: deleteConsent
tags:
- Account Information Service (AIS)
/v1/consents/{consentId}/status:
GET:
summary: Consent status request
description: Read the status of an account information consent resource.
operationId: getConsentStatus
tags:
- Account Information Service (AIS)