SOCIETE GENERALE

LUXEMBOURG
PSD2 API Solution -
Documentation for TPPs
Addressees:
Business Analysts, Project Managers, Developers, Architects, IT

Version 1.0, July 20th, 2020

Disclaimer
This document is published by Société Générale LUXEMBOURG,“so-
ciété anonyme” under the law of the Grand Duchy of Luxembourg, regis-
tered with the Luxembourg Register of Commerce under number B 6061,
whose registered office is at 11, avenue Emile Reuter, L-2420 Luxem-
bourg.
SOCIETE GENERALE VAT No: LU10807024.
Contacts: (+352) 47 93 11 1.

SOCIETE GENERALE company is a credit institution authorised in Lux-

embourg, registered on the list of banking institutions drawn up by the
Commission de Surveillance du Secteur Financier ("CSSF"), whose regis-
tered office is located at 110 Route d'Arlon, L-2991 Luxembourg.

Support Contact
WORLD-PRIV-Support-PSD2-Sandbox@socgen.com

PSD2 API Solution - Documentation for TPPs

Table of Contents

1 Introduction ...................................................................................................................................... 3
2 Environment preparation .................................................................................................................. 5
2.1 Register and Login ................................................................................................................. 6
2.2 Upload TPP certificate ............................................................................................................ 7
2.3 Certificate Status Validation ................................................................................................. 10
2.4 Creating application .............................................................................................................. 11
2.5 Generate key ........................................................................................................................ 13
2.6 Add TPP Redirect (Callback) URL ....................................................................................... 15
2.7 Add the TPP SECRET .......................................................................................................... 16
2.8 Subscribe to API ................................................................................................................... 18
3 Using PSD2 API............................................................................................................................... 19
3.1 Pre-authentication ................................................................................................................... 19
3.2 Call API Endpoints ................................................................................................................. 24
4 References ....................................................................................................................................... 36
5 Glossary .......................................................................................................................................... 38

Document history

Version Description (remarks) Date Author(s)

1.0 Final version July 29th, 2020 SOCIETE GENERALE

PSD2 API Solution - Documentation for TPPs

1 Introduction
This document describes how Third-Party Providers (TPPs) can connect the PSD2 Solution of SOCIETE GENERALE
LUXEMBOURG. SOCIETE GENERALE LUXEMBOURG is a Société Générale subsidiary, duly established and
operating under the law of the Grand Duchy of Luxembourg, registered with the Luxembourg Register of Commerce
under number B 6061, whose registered office is at 11, avenue Emile Reuter, L-2420 Luxembourg (hereinafter the
“Bank” or “SOCIETE GENERALE”),

The document assumes that TPP has basic knowledge about Payment Services Directive 2 (PSD2) regulation of the
European Union, its terminology and use cases. Please refer to the References section below for an overview and
detailed information about the regulation. In addition, TPP will also find a Glossary below with the most important
PSD2 terms.

The document assumes that TPP is aware about the registration to the NCA in order to obtain the PSD2 authorization.

The document assumes that TPP is aware about the request for a PSD2 certificate from QTSP (Qualified Trust Service
Provider).

TPPs can use the SOCIETE GENERALE PSD2 Application Programming Interface (“API”) Solution (the “API
Solution”) to connect their services. SOCIETE GENERALE will rely on NextGenPSD2 Access to Account Interop-
erability Framework specified by The Berlin Group version 1.3.2 and available on the website https://www.berlin-
group.org/psd2-access-to-bank-accounts. To use the SOCIETE GENERALE public API, the TPP must sign up at
the integrated API Management tool. After login he can subscribe to the API PSD2. The subscription is mandatory to
use the API. This process is explained in this document.
The SOCIETE GENERALE API Solution will follow this Berlin Group Specification for the comply-only features.
Thus, it is possible for an end customer - amongst other functions - to get a balance or postings of the customer’s
payment accounts, make a payment initiation via a Third-Party Provider (TPP). All available methods will be de-
scribed in the section Call API Endpoints.

The solution comes with a full security process:

- Having received a request from a TPP, the API Solution will then identify the TPP before executing the request. If
the Account Servicing Payment Service Provider (ASPSP) (SOCIETE GENERALE) backend enforces a strong
authentication via the PSU (the user), a One Time Password (“OTP”) must be entered.
- A Transport Layer Security (“TLS”) connection between TPP and ASPSP must be established always including
client (i.e. TPP) authentication. For this authentication the TPP must use a qualified certificate for website authenti-
cation (“QWAC”). This qualified certificate must be issued by a Qualified Trust Service Provider (“QTSP”) according
to the eIDAS regulation (See Chapter Glossary). The certificate of the TPP must indicate all roles the TPP is authorized
to use. The QWAC must be fully compliant to the official standard ETSI TS 119 495.

Note: Additional identification of the TPP at application level with QSealC (Qualified Electronic Seal Certificates) is
not part of the solution. TPP must request data, ASPSP only responses to requests.

Representational state transfer (“REST”) is used for communication through requests and responses.

Please also note that TPP will have the possibility to use a non-production environment to test the solution. All URLs
will be written in next chapters.

PSD2 API Solution - Documentation for TPPs

PSD2 API Solution - Documentation for TPPs
2 Environment preparation
This section explains how to prepare the use of PSD2 API. TPP registration, application creation, certificate manage-
ment, etc.

Environment preparation process is the same in the non-production and production environment: The returned results
(AIS) when a consent is established between a client and the TPP are the same when a client logs directly to the
eBanking application. A certificate check will be done against the trusted center having issued it, role check, authori-
zation on the APIs according to the role.

Here are the steps in order to prepare the environment:

PSD2 API Solution - Documentation for TPPs

 2.1 Register and Login

TPP registration is made under API store website

API Store website URLs:

NON-PRODUCTION https://uat-api.privatebanking.societegenerale.lu/ebankingPsd2/store/
PRODUCTION https://api.privatebanking.societegenerale.lu/ebankingPsd2/store/

To be able to work in the API Store, the TPP must be identified and this requires a one-time registration,
To register, please click on the "Sign-up" button at the top of the page. A form will open in which TPP can enter the
necessary data.

Fill the following form:

PSD2 API Solution - Documentation for TPPs

After the registration is completed, TPP can log in to the store. To do this, please use the "Sign-In" button at the top
of the page:

TPP will now be asked for login data.

2.2 Upload TPP certificate

After logging to the API store, the TPP is redirected to the PSD2 Certificate upload form

• Click on the “Add certificate” button

PSD2 API Solution - Documentation for TPPs

• Click on “CHOOSE FILE TO UPLOAD” button

• Go to the file location and select the certificate file

PSD2 API Solution - Documentation for TPPs

 • Click on “Open” button

The TPP/Certificate informations will be extracted from the file:

➢ TPP_ID
➢ Cert_ID
➢ Certificate issuer
➢ Valid from date
➢ Valid to date
➢ PSD2 role(s)
➢ Certificate Status: First, the status of the certificate is “received” until the validation job running

PSD2 API Solution - Documentation for TPPs

 2.3 Certificate Status Validation

This action is automatically performed with a scheduled job, the solution will calls the CRLs: “Certificate Revoca-
tion Lists” provided by the Trusted center, if the certificate is not revoked, the status of the uploaded certificate will
be “VALID”

PSD2 API Solution - Documentation for TPPs

 2.4 Creating application

Afterwards TPP must select the application to use in order to "consume" it. This application practically serves as a
storage location for the later API.

Please click on the menu entry "APPLICATIONS"

Now another area opens, then an already created entry "DefaultApplication" is displayed. This application has already
been automatically added for TPP during the registration process, as a new application will be created the "DefaultAp-
plication" and can be ignored.

TPP Adds the first own application via the button "ADD APPLICATION".

TPP will now be guided through the installation with the following dialog. First give the application a meaningful
name such as the TPP company name. Enter this name in the upper field "Name".
TPP is welcome to fill in the other fields if required, but they are not mandatory for using the API.

PSD2 API Solution - Documentation for TPPs

The "Add" button completes the process and the application is ready. TPP can now open the newly created applica-
tion

PSD2 API Solution - Documentation for TPPs

 2.5 Generate key

In order to communicate with the API, the system needs keys, here called "Production Keys". These keys must be
generated once. Open the newly created application then click on the “Productions keys” tab.

The button "Generate Keys" initiates the generation. Please click on the button. No need to make any changes to the
settings above.

PSD2 API Solution - Documentation for TPPs

The newly created keys are displayed:
• consumer key
• consumer secret
• access token

PSD2 API Solution - Documentation for TPPs

 2.6 Add TPP Redirect (Callback) URL

Redirect URLs are a part of the OAuth flow. After a user successfully authorizes an application, the authorization
server will redirect the user back to the application with either an authorization code or access token in the URL.

• Click on “TPP-MANAGEMENT”

You will have to reauthenticate with same credentials.

PSD2 API Solution - Documentation for TPPs

• Click on “ADD REDIRECT URL”

• Enter the URL

• Click on “SAVE” button the save the URL

2.7 Add the TPP SECRET

• Click on the “TPP-MANAGEMENT” item

PSD2 API Solution - Documentation for TPPs

• Click on the “ADD SECRET” button

• Click on the “Create” button

• The secret is created

This secret needs to be stored in a dedicated zone (such as password vault). As it will be used for all con-
sent creation requests, the secret should be stored in a TPP configuration file.

• Click on the “SAVE” button

PSD2 API Solution - Documentation for TPPs

 2.8 Subscribe to API

A subscription to the API is mandatory before consuming it. This process also only takes place once. Please click on
"APIs" in the left side menu. Then select the PSD2 API by clicking on the coloured icon

Select the newly created application and confirm the process with the button "Subscribe".

Please close the success message by clicking on the button "Stay on this page".

PSD2 API Solution - Documentation for TPPs

3 Using PSD2 API

The following workflows shows the process of creating a consent for account information, requesting account infor-
mation and initiating a payment via the Berlin Group API.
Each request (AIS, PIS) should be preceded by an authentication step (Pre-authentication)

3.1 Pre-authentication

We will follow the pre-authentication approach of Berlin Group.

A pre-step authentication is used to enable access to the system (login). However, the API calls required for this ex-
ist outside the PSD2 API. Hence the name "pre-step".

This means that login must be always the first step. After the login, the TPP can request AI, PI services.

The system therefore offers the Authorization Code Flow ("GUI") process:

The login is performed by the Authorization code flow (redirect approach) where the PSU enters the credentials
and the 2FA via the interface at the ASPSP. Thus, the relevant data traffic takes place between PSU and OAuth
without having to supply the TPP with confidential information.

After successful pre-step authentication the TPP will receive a session based PSD2 access token. This PSD2 access
token is needed for every Berlin Group API call.
The TPP must provide the token in the header field “PSD2-AUTHORIZATION”.

3.1.1 Authorization code flow

The PSU enters its credentials directly at the OAuth server, which significantly increases security. If a SCA is re-
quired, it is also mapped via the OAuth server and the TAN recorded there.

3.1.1.1 Authorization code flow-SCA necessary

• Required for the first API call: will give an exemption period (e.g. 90 days)
• Only necessary if SCA must be performed
• User enters credentials in OAuth GUI
User enters TAN in OAuth GUI

PSD2 API Solution - Documentation for TPPs

The authorization code flow (with SCA) can be represented by the following schema:

Here is the sequence of the TPP API calls:

a) POST {BASE_URL}/auth/token → request without credentials, response with PSD2 authoriza-
tion code
b) GET {BASE_URL}/auth/login → calls login page for PSU to enter his credentials
c) PSU interacts with GUI
d) POST {BASE_URL}/auth/token → response with PSD2 token after successful PSU login

The blackbox “SCA flow” is described in the next chapter.

PSD2 API Solution - Documentation for TPPs

 3.1.2 SCA flow

For your information, this flow shows the execution of the Strong Customer Authentication

No API call required here. Everything is encapsulated in GET {BASE_URL}/auth/login API.

PSD2 API Solution - Documentation for TPPs

3.1.2.1 Authorization code flow - SCA not necessary

• Not available at first login

• Within the exemption period (e.g. 90 days) from SCA.
This process must be initiated by the PSU

The TPP must send the Bank a Callback URL. Callback URL of TPP is necessary to deliver PSD2 access token af-
ter successful login. As a reminder, this URL is the one provided during the TPP registration.

The authorization code flow (without SCA) can be represented by the following schema:

Here is the sequence of the TPP API calls:

- POST {BASE_URL}/auth/token : Request without credentials, response with PSD2 authorization
code
- GET {BASE_URL}/auth/login : Calls login page for PSU to enter his credentials. User will enter
credentials and access token will be returned.

PSD2 API Solution - Documentation for TPPs

3.1.3 Possible error codes with Pre-Authentication

HTTP Code Error (Enumeration) Error description Detail

400 unauthorized Bad Credentials ClientID or ClientSecret wrong
400 unsupported_grant_type Unsupported grant type: <re-
ceived grant type>
400 invalid_client Given client ID does not match
authenticated client 400 inva-
lid_grant Bad Credentials
400 invalid_grant Bad Credentials Username or Password wrong
400 user_locked User is locked
400 unsupported_authoriza- If Password Credentials Flow de-
tion_method pends on two-factor authentication

PSD2 API Solution - Documentation for TPPs

 3.2 Call API Endpoints

Once authentication is performed, TPP can call API endpoints to submit payments, to get accounts list, to get ac-
count details…

Each endpoint is described in the PSD2 API Swagger, with following details:

• URL: base URL ({BASE_URL}) for each environment

UAT https://uat-api.privatebanking.societegenerale.lu/ebankingPsd2
PRODUCTION https://api.privatebanking.societegenerale.lu/ebankingPsd2

• Input data (Optional/Mandatory)

o Parameters
o Authorization
o Headers
o Request body
• Data size
• Data format
• Output data
• Response http code

Note: all endpoints require X-Request-ID input in the header section. This parameter is the ID of the request, must
be unique to the call, and generated by TPP.

Swagger is available here:

You can also find the swagger file on both environments:

Non PRODUCTION https://uat-api.privatebanking.societegenerale.lu/ebank-
ingPsd2/store/api-docs/admin/PSD2/v1

PRODUCTION https://api.privatebanking.societegenerale.lu/ebank-
ingPsd2/store/api-docs/admin/PSD2/v1

Another full description is available in the store under API menu, and "API console" of the PSD2 API

PSD2 API Solution - Documentation for TPPs

 3.2.1 Account information

For each action, the following process should be respected

a) Pre-authentication (Described in the previous chapter)

b) If no consent is given to TPP, or the consent is rejected or expired
o Create AIS consent (Valid 90 days)
o Send AIS requests
o Receive AIS requests datas
c) If a consent is valid
o Send AIS requests
o Receive AIS requests datas

3.2.1.1 Create AIS Consent

The PSU must provide the account data (e.g. IBANs) to the TPP. The TPP will then explicitly request a consent for
these specific accounts at once.
Note: it is not possible to grant consent to a single account, all cash accounts are visible to PSU through TPP applica-
tion ("allPsd2": "allAccounts" all the cash accounts)
PSU and TPP need to agree on consent scope before TPP request the particular consent.

For each consent creation a Consent-ID will be generated and handed transmitted to the TPP. The TPP will need this
Consent-ID for each account information request later.

If a certificate gets invalid, the consent gets invalid. At every request the Consent-ID will get validated and its status
can change if the consent is not valid anymore.

The maximum number of accesses to an account will be determined and communicated by the ASPSP. In each case
it will be valid from 0 to maximum 24 hours.

3.2.1.1.1 Account balance access limit

For Account Informations Service (AIS), after giving his consent to TPP, the client can access with no limit to his
accounts through the TPP applications for 90 days without SCA.

TPP can access to the accounts informations without involving the client during this period, however, the access
number per day to account information when balances/transactions are requested should be limited.

The Following json is returned by the ASPSP to TPP and the access limit is defined under the key: frequencyPer-
Day
{
"access": {
"allPsd2": "allAccounts"

},
"recurringIndicator": false,
"validUntil": "2020-12-31",
"frequencyPerDay": 4,
"combinedServiceIndicator": false
}

PSD2 API Solution - Documentation for TPPs

The ASSP has limited the accounts access number when Balance/Transactions are requested to "frequencyPerDay":
"4"

Request Limited Limit

Get accounts without balances No No limit
Get accounts with balances Yes 4 per day
Get account details without balances No No limit
Get account details with balances Yes 4 per day
Get account balances Yes 4 per day
Get transactions Yes 4 per day

The limit is calculated per:

• TPP-ID
• PSU-ID
• IBAN

3.2.1.1.2 Consent status (Berlin group):

Once a consent is created, the following endpoints allow to get the consent status based on the {consentId}

➢ /v1/consents/{consentId}: which returns:

• Scope
• Validity date
• Frequency per day
• Status
➢ /v1/consents/{consentId}/status which returns only the status

Code Description
received The consent data have been received and are technically correct. The data is
not authorised yet.
rejected The consent data have been rejected e.g. since no successful authorisation
has taken place.
valid The consent is accepted and valid for GET account data calls and others as
specified in the consent object.
revokedByPsu The consent has been revoked by the PSU towards the ASPSP.
expired The consent expired.
terminatedByTpp The corresponding TPP has terminated the consent by applying the DELETE
method to the consent resource.

For creating a consent, a SCA will always be necessary.

These are the steps:

• POST {BASE_URL}/v1/consents: This method creates a consent resource

• POST {BASE_URL}/v1/consents/{consentId}/authorisations:
Start the authorisation process for a consent

• PUT {BASE_URL}/v1/consents/{consentId}/authorisations/{authorisationId}:
Read the SCA status of the consent authorisation

PSD2 API Solution - Documentation for TPPs

PSD2 API Solution - Documentation for TPPs
A consent is necessary to perform this AIS request since a consent-ID is needed in the call.

GET/v1/accounts → must be initially the first call. But only first time because after the call the account-ids are set.
From now on this call is optional.

Now the following requests are possible:

GET {BASE_URL}/v1/accounts/{account-id}/balances/ to read account data with balances

GET {BASE_URL}/v1/accounts/{account-id}/transactions/ to get transaction for a particular

account

PSD2 API Solution - Documentation for TPPs

3.2.1.2 Get accounts
Here is the field “withBalance” explicitly allowed though it is not a mandatory field.
GET {BASE_URL}/v1/accounts

PSD2 API Solution - Documentation for TPPs

3.2.1.3 Get Balances

GET {BASE_URL}/v1/accounts/{account-id}/balances

PSD2 API Solution - Documentation for TPPs

3.2.1.4 Get Transactions

GET {BASE_URL}/v1/accounts/{account-id}/transactions/

PSD2 API Solution - Documentation for TPPs

3.2.1.5 Get Transactions older 90 days

SCA is necessary if transactions are older than 90 days.

GET {BASE_URL}/v1/accounts/{account-id}/transactions/

PSD2 API Solution - Documentation for TPPs

 3.2.2 Payments

➢ There will always be a SCA necessary for each payment. No SCA exemption is foreseen.
➢ Whitelist beneficiaries are not managed in PSD2 solution
➢ Client should use eBanking application to initiate account transfers

3.2.2.1 Payment initiation

First step: Pre-Step Authentication

POST {BASE_URL}/v1/{payment-service}/{payment-product}: Payment initiation request
POST {BASE_URL}/v1/{payment-service}/{paymentId}/authorisations:
Start the authorization process for a payment initiation
Last step: SCA flow

PSD2 API Solution - Documentation for TPPs

3.2.2.2 Get Payment

Returns the content of a payment object.

First step: Pre-Step Authentication

GET {BASE_URL}/v1/{payment-service}/{payment-product}/{paymentId}

PSD2 API Solution - Documentation for TPPs

3.2.2.3 Get payment status

First step: Pre-Step Authentication

GET {BASE_URL}/v1/{payment-service}/{payment-product}/{paymentId}/status

PSD2 API Solution - Documentation for TPPs

4 References
Description Hyperlink

Short introduction to PSD2 by Berlin https://docs.wix-

Group Initiative static.com/ugd/c2914b_c6a8a0dca83e4af8859be266415d3d79.pdf

Directive (EU) 2015/2366 of the European English:

parliament and of the council on payment https://eur-lex.europa.eu/legal-con-
services in the internal market (PSD2) of tent/EN/TXT/?uri=CELEX:32015L2366
25 November 2015

Regulatory Technical Standards on strong https://www.eba.europa.eu/regulation-and-policy/payment-ser-

customer authentication and secure com- vices-and-electronic-money/regulatory-technical-standards-on-
munication under PSD2 (RTS document) strong-customer-authentication-and-secure-communication-un-
der-psd2

Commission delegated regulation (EU) https://eur-lex.europa.eu/legal-con-

2018/389 tent/EN/TXT/?uri=OJ:L:2018:069:TOC
of 27 November 2017 supplementing Di-
rective (EU) 2015/2366 of the European
Parliament and of the Council with regard
to regulatory technical standards for strong
customer authentication and common and
secure open standards of communication

Consultation on RTS specifying the re- https://www.eba.europa.eu/regulation-and-policy/payment-ser-

quirements on strong customer authentica- vices-and-electronic-money/regulatory-technical-standards-on-
tion and common and secure communica- strong-customer-authentication-and-secure-communication-un-
tion under PSD2 der-psd2/-/regulatory-activity/consultation-paper

Discussion on RTS on strong customer au- https://www.eba.europa.eu/regulation-and-policy/payment-ser-

thentication and secure communication vices-and-electronic-money/regulatory-technical-standards-on-
under PSD2 strong-customer-authentication-and-secure-communication-un-
der-psd2/-/regulatory-activity/discussion-paper

EBA Fallback document https://eba.europa.eu/-/eba-publishes-final-guidelines-on-the-ex-

emption-from-the-fall-back-mechanism-under-the-rts-on-sca-and-
csc

NextGenPSD2 Access to Account Interop- https://www.berlin-group.org/nextgenpsd2-downloads

erability Framework (Berlin Group Stand-
ard)
• Documentation
• Technical documentation / API
description
• OpenAPI File

WSO2 API Manager Description:

https://wso2.com/api-management/

Documentation:
https://docs.wso2.com/display/AM250/WSO2+API+Man-
ager+Documentation

WSO2 Analytics https://docs.wso2.com/display/AM250/Analytics

WSO2 Admin Guide https://docs.wso2.com/display/AM250/Product+Administration

PSD2 API Solution - Documentation for TPPs

PSD2 API Solution - Documentation for TPPs
5 Glossary

PSD2 Meaning Usage

abbreviation

2FA Two Factor Authentication

AIS Account Information Service means an online
service to provide consolidated information on
one or more payment accounts held by the pay-
ment service user with either another payment
service provider or with more than one payment
service provider; according to article 4 (16) of
[PSD2] and as regulated by article 67 of [PSD2].
This service may be used by an AISP
to request information about the ac-
count of a PSU. The account is man-
aged by the ASPSP providing the
XS2A Interface. Functionality and re-
strictions of this service comply with
the requirements defined by article 67
of [PSD2].

AISP Account Information Service Provider means a

payment service provider pursuing account infor-
mation services, according to article 4 (19) and
Annex I of [PSD2].

ASPSP Account Servicing Payment Service Provider

means a payment service provider providing and
maintaining a payment account for a payer, ac-
cording to article 4 (17) of [PSD2]. For example,
a bank.

FCS Fund confirmation service This service may be used by a PIISP to

request a confirmation of the availabil-
ity of specific funds on the account of a
PSU. The account is managed by the
ASPSP providing the XS2A Interface.
Functionality and restrictions of this
service comply with the requirements
defined by article 65 of [PSD2].

eIDAS electronic IDentification, Authentication and

trust Services is an EU regulation on electronic
identification and trust services for electronic
transactions in the internal market. It is a set of
standards for electronic identification and trust
services for electronic transactions in the Euro-
pean Single Market. It was established in EU
Regulation 910/2014 of 23 July 2014 on elec-
tronic identification and repeals directive
1999/93/EC from 13 December 1999.

MVP Minimum Viable Product Focus on scope in agile development

NA/NCA National (Competent) Authority. Holds a list of

TPPs registered in that particular country.

PIS Payment Initiation Service means a service to ini-
tiate a payment order at the request of the pay-
ment service user with respect to a payment ac-
count held at another payment service provider
according to article 4 (15) of [PSD2] and as regu-
lated by article 66 of [PSD2].
This service may be used by a PISP to
initiate a single payment on behalf of a
PSU using a given account of that PSU.
The account is managed by the ASPSP
providing the XS2A Interface. Func-
tionality and restrictions of this service

PSD2 API Solution - Documentation for TPPs

 comply with the requirements defined
by article 66 of [PSD2].

PISP Payment initiation service provider means a pay-

ment service provider offering a PIS to its cus-
tomer, according to article 4 (18) and point (7) of
Annex I of [PSD2].

PIISP Payment Instrument Issuer Service Provider ac-

cording to article 4 (14) and 45) of [PSD2]. A
PIISP can use the service "Confirmation on the
availability of funds" as regulated by article 65 of
[PSD2].

PSU Payment Service User

means a natural or legal person making use of a
payment service in the capacity of payer, payee,
or both according to article 4 (10) of [PSD2].

QTSP Qualified Trust Service Provider, e.g. a trust cen-

tre issuing qualified certificates. Luxembourg:
LuxTrust S.A.

SCA Strong Customer Authentication – authentication

procedure based on two factors compliant with
the requirements of [PSD2] and [EBA-RTS].

TPP Third Party Provider – generic term for

AISP/PIISP/PISP.

TSP/QTSP Trust Service Provider according to [eIDAS].

Within the context of the XS2A interface specifi-
cation only qualified TSPs (QTSPs) according to
section 3 of [eIDAS] issuing qualified certificates
for electronic seals and/or qualified certificates
for website authentication which are compliant
with the requirements of [EBA-RTS] are rele-
vant.

XS2A Access to account interface – interface provided

by an ASPSP to TPP for accessing accounts.

QSealC Qualified Electronic Seal Certificates

QWAC Qualified Website Authentication Certificates

PSD2 API Solution - Documentation for TPPs