Get an eIDAS Certificate
For production, there is no additional onboarding for Deutsche Bank required. If you are a licenced TPP with a valid productive eIDAS certificate, you are ready to use our PSD2 XS2A API.
However, we recommend to get onboarded to our Sandbox and test our API with non-production accounts first.
Request our PSD2 XS2A Technical Documentation
Please request Deutsche Bank's detailed Technical Documentation via xs2a-sandbox.api@db.com
Get an eIDAS Certificate
For production, there is no additional onboarding for Deutsche Bank required. If you are a licenced TPP with a valid productive eIDAS certificate, you are ready to use our PSD2 XS2A API.
However, we recommend to get onboarded to our Sandbox and test our API with non-production accounts first.
This process allows us to subscribe your denoted e-mail address(es) for future updates of our PSD2 XS2A Technical Documentation. We will keep you up to date!
Deutsche Bank will provide the PSD2 XS2A Technical Documentation at no charge upon request by an authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments or payment service providers that have applied to their competent authorities for the relevant authorisation as stated in the RTS Article 30(3). Therefore please also provide us with evidence for the application or refer to the register of the relevant national competent authority.
Identify the PSU’s Online Banking
Deutsche Bank offers an harmonized API entry point into its different subsidiaries and branches, hence allowing you to use one global URL structure to connect to all our legal entities.
The identification of the correct region is done based on the PSU’s Online Banking.
Please find more information within our PSD2 XS2A Technical Documentation ('Supported Service Endpoints per Region')
Send and Receive Data via the XS2A API
After identifying the correct region, you have all information to choose the correct API service endpoint, based on the generic URL structure.
Please consider that certain regions require certain attributes and / or pre-determined attribute values (e.g. for the ‘PSU-ID-Type’) to process the request successfully.
Please find more information within our PSD2 XS2A Technical Documentation ('Data Dictionary').
Follow the flow
Deutsche Bank will embed a hyperlink together with a "tag" for the semantics of this hyperlink into the responses and to all succeeding requests within the services. This hyperlink will then be a relative link for the host starting e.g. with "/v1/payments/sepa-credit-transfers".
Please find more information within our PSD2 XS2A Technical Documentation ('API Steering Process by Hyperlinks')
PSD2 XS2A Quickstart Guide for Deutsche Bank Group
Getting started
Introduction
Welcome to the PSD2 XS2A API of Deutsche Bank. This guide helps you to perform the first steps to access bank accounts through our API. The scope of this API is to provide you access to payment accounts which are online enabled.
Deutsche Bank adapted the Berlin Group Standard, based on the NextGenPSD2 XS2A Framework, Implementation Guidelines, The Berlin Group Joint Initiative on a PSD2 Compliant XS2A Interface.
For more information, please request our latest PSD2 XS2A Technical Documentation, which is based on the above mentioned document in form and content. On the respective locations, the document has been adapted to demonstrate the Deutsche Bank specific information and aspects to consider as a TPP using our XS2A API.
You have questions regarding PSD2 and its implementation within Deutsche Bank? Are you facing technical difficulties? We might already have the answer. Please click on our FAQ section.
FAQ
How can I use the test environment?
Please contact us via xs2a-sandbox.api@db.com and request to be registered for our Sandbox environment and the detailed Test Guideline. All you require is a valid test eIDAS certificate
Deutsche Bank will provide the PSD2 XS2A Test Documentation at no charge upon request by an authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments or payment service providers that have applied to their competent authorities for the relevant authorisation as stated in the RTS Article 30(3). Therefore please also provide us with evidence for the application or refer to the register of the relevant national competent authority.
My test certificate changes. What do I need to consider?
Please contact us via xs2a-sandbox.api@db.com and request to be registered with your new test eIDAS certificate. The Sandbox onboarding is being performed based on the certificate TPP ID, hence a new certificate will be rejected.
Which test data is being provided for Sandbox?
The sandbox system offers you predetermined and ready-to-use test data (incl. applicable error situations emulated). Actual accounts can only be used with the production XS2A interface.
Which test certificates are supported in Sandbox?
We support a list of QTSP's across Europe, which we have onboarded to our trust store for our Sandbox environment. We are dependent on the provisioning because for test root certificates as they are not publicly available like they are for production. The following states an extract of QTSP's supported within Sandbox: D-Trust, Bankverlag, DESRC, InfoCert, Microsec Ltd, Athens Stock Exchange (AthexGroup), Aruba Posta Eletronica Certificata, Buypass, BV Trust, Professional S.A. or FirmaProfessional S.A., InfoNotary PLC, A-Trust, Actalis, LuxTrust.
How does the AIS in Sandbox work? Are download links provided?
For all retail regions, we support JSON based formats for the account information only. Hence we do not provide back any XML download link for those but provide the account information in the JSON response directly.
Will you still support third party providers to access DB's data via FinTS?
Currently, we do not foresee to block any existing interfaces, however please consider legal obligations when accessing them.
What shall I provide as PSU-ID?
The PSU-ID is the login name for a clients online access channel. The PSU-ID-Type is a predetermined, static value based on the underlying region / online access channel.
For details, please refer to our PSD2 XS2A Technical Documentation ('Supported Service Endpoints per Region')
Where do I find the KPIs on performance and availability of the dedicated interface?
Statistics on KPIs which allow you to compare the daily performance and availability between the dedicated interface (API) and different client online access channels can be found here.
Which XS2A API standard does DB support?
Deutsche Bank adapted the Berlin Group Standard, based on the NextGenPSD2 XS2A Framework, Implementation Guidelines on a PSD2 Compliant XS2A Interface.
How can I get started?
For production, there is no additional onboarding for Deutsche Bank required. If you are a licenced TPP with a valid productive eIDAS certificate, you are ready to use our PSD2 XS2A API.
However, we recommend to get onboarded to our Sandbox and test our API with non-production accounts first. See here for more information on our Sandbox.
Deutsche Bank Group detailed Technical Documentation to be requested via xs2a-sandbox.api@db.com
This process allows us to subscribe your denoted e-mail address(es) for future updates of our PSD2 XS2A Technical Documentation. We will keep you up to date!
How can I subscribe to DB's developer portal?
There is no registration within DB's developer portal required. Deutsche Bank Group detailed Technical Documentation can be requested via xs2a-sandbox.api@db.com
This includes a machine-readable API documentation (Swagger file).
If you have any additional technical questions, please contact us under the same e-mail address.
Which Host URL shall I use?
Deutsche Bank AG offers a harmonized API entry point into its different subsidiaries and branches, hence allowing you to use one global URL structure to connect to all our legal entities. The chosen path parameters {country-code} & {business-entity} are denoting which region is being approached.
For the URL, please refer to our PSD2 XS2A Technical Documentation ('XS2A Interface API Structure').
Which SCA approaches is DB offering?
This depends on the entity / region you are approaching and therefore differs.
An overview which SCA approaches are supported by which region can be found in our PSD2 XS2A Technical Documentation ('SCA Method Configuration').
Which SCA exemptions does DB support?
This depends on the entity / region you are approaching and therefore differs.
An overview which SCA exemptions are supported by which region can be found in our PSD2 XS2A Technical Documentation ('Applicable Exemption from Strong Customer Authentication per Region').
Which payment types can I initiate?
All payment types supported within the client online channel, are also supported for the referring API access.
For a detailled overview, please refer to our PSD2 XS2A Technical Documentation ('Supported Service Endpoints per Region').
Is there a daily limit?
Initiating payments via the XS2A interface is also subject to the daily limits in online banking. If the customer has a limit in Internet (online) banking, this limit will be applied.
How can I retrieve the PSU's account number?
To offer a way of payment initiation without requiring the PSU to manually enter the IBAN, we offer the following solutions for most of the regions:
Either we support a consent for an account list (of all the PSU's accounts). In this case, you can have the PSU establish a consent for an account list as a first step, then read this account list and have the PSU choose the account / IBAN for payment initiation afterwards. Alternatively, we offer an ASPSP driven consent model, where the PSU chooses the accounts visible for the TPP during SCA. In this case, a TPP can establish a consent for an account details with the PSU selecting the account(s) as a first step. The TPP can then read an account list referring to this consent and offer the ASPSP the list of visible accounts / IBANs to the PSU to choose one of them as the debtor account of the payment.
An overview which consent model is supported by which region can be found in our PSD2 XS2A Technical Documentation ('AIS Consent handling').
Which formats are you supporting?
For all retail regions, we support JSON based formats for the payment initiation.For details, please refer to our PSD2 XS2A Technical Documentation ('Supported Service Endpoints per Region').
Which period of transaction data is available using the GET /transactions endpoint?
The maximum transaction history which can be requested via the XS2A API is determined by the same within the Client Online Access Channel. Hence if the client can see e.g. 180 days within his online banking, the same transaction history can be requested by the TPP via the XS2A API.
The TPP might need a new SCA of the PSU e.g. in case to access transaction data older than 90 days while there is still a valid recurring consent. In this case, the TPP can choose how to deal with the consent: The TPP can either apply for a one off consent, enabling the access to the transaction history or the TPP applies for a new recurring consent. In the latter case, the old recurring access is expiring, and the new recurring access with a validity of e.g. 90 days is valid.
How is DB counting the AISP consent access?
DB has implemented the "Full counting solution" introduced by NISP. DB is counting every access for each access level and account-id independently, hence e.g. a recurring consent can be used to retrieve 4 times / day balances and 4 times / day transactions for each underlying account-id, based on the recurring indicator. An one-off consent can be used to retrieve each access level and account-id once! Pagination on transactions are resulting in counting all accesses to this transaction report as one access. Then it will get the status ‘expired’.
How do I deal with account information access with PSU involvement?
As per Berlin Group, the TPP is mandated to indicate whether he is working with or without PSU involvement by providing or not providing the IP address of the PSU device.
So the ASPSP can track every access per account information endpoint and consent, with or without PSU involvement, and can guarantee to not admit more than 4 times access of an AISP without PSU involvement per day. In that matter, an AIS retrieval will be rejected with a proper error message in case the TPP is indicating that the PSU is involved (via PSU-IP-Address) and using an existing recurring consent. A (new) one-off consent has to be created for such a case. One-off consents do not overwrite existing recurring consents for a PSU.
Is another SCA required if the PSU is involved (One-off consent creation)?
The decision whether to involve PSU authentication (SCA) when the TPP asks for an access to account information with PSU involvement (by creating a one-off consent) depends on the usage of the SCA exemption for AIS access in the client online channels. If the ASPSP requires a PSU authentication, then the TPP might need to ask for any of these account information requests an one-off consent for account access first:
- SCA exemption following RTS article 10 not used by the PSU in his online channels:
- In this case, access to account information with PSU involvement indicated in the request is only granted after SCA. The XS2A API in this case mandates the TPP to first let the PSU authorise a one off consent to the related account information. The resulting new consentId is then used for the account access with PSU involvement.
- Account access with a recurring consentId will be rejected if PSU involvment is indicated.
- SCA exemption following RTS article 10 used by the PSU in his online channels with first factor check
- In this case, access to account information with PSU involvement indicated in the request is only granted after a check of a first authentication factor (e.g. a password) in analogy to online banking procedures. The NextGenPSD2 API in this case mandates the TPP to first let the PSU authorise a one off consent to the related account information, which is then granted by the use of the first factor only. The resulting new consentId is then used for the account access with PSU involvement.
- In this case, access to account information with PSU involvement indicated in the request is only granted after a check of a first authentication factor (e.g. a password) in analogy to online banking procedures. The NextGenPSD2 API in this case mandates the TPP to first let the PSU authorise a one off consent to the related account information, which is then granted by the use of the first factor only. The resulting new consentId is then used for the account access with PSU involvement.
How many consents can I create?
The Berlin Group XS2A API admits only one consent per TPP and PSU (with one ASPSP) at a time. The XS2A API permits access by a TPP only if this consent has been submitted by the same TPP.
Which consent types are supported?
This depends on the approached region. We recommend using a bank driven consent, if available, which allows the PSU to individually choose the accounts and access levels within the authorization process.
An overview which consent model is supported by which region can be found in our PSD2 XS2A Technical Documentation ('AIS Consent handling').
How can I retrieve the Account Holder Name?
All consent models support the extension of the consent with the request for account holder name
The existing consent structure is extended with another access level “additionalAccountInformation”.
For details, please refer to our PSD2 XS2A Technical Documentation ('AIS Consent handling').
How can I retrieve the list of standing orders for a PSU?
The list of standing orders is being provided within the “bookingStatus”: “information” which means: Entry is only provided for information, and no booking on the account owner's account in the account servicer's ledger has been performed (for example not yet executed standing orders).
What does an error "ACCESS_EXCEEDED" mean?
The maximum number of access without PSU involvement for a certain consent (as per the recurring indicator) has been exceeded.
Which formats are provided?
For all retail regions, we support JSON based formats for the account information. For details, please refer to our PSD2 XS2A Technical Documentation ('Supported Service Endpoints per Region').
How do I create a card contract?
The PSU has to his/her consent for confirmation of funds requests by a specific TPP in its role as PIIS prior to a first request. This is being done via self service within his client online access channel (Online Banking).