The XS2A APIs, are developed on the basis of the Berlin Group PSD2 Access to Bank Accounts (XS2A) specification and the national BISTRA standard.

TPP Authentication


To access all endpoints of the PSD2 XS2A interface a third party provider (TPP) must present a valid PSD2 compliant Qualified Web Authentication Certificate (QWAC) according to ETSI TS 119 495.2. The certificate must be issued by one of the EU list of trusted providers and must specify the roles for which the provider is authorized:

In addition, the certificate must contain in the subject:organizationIdentifier the auhtorization number issued by a National Competent Authority.

In most cases the TPP can access the XS2A interface directly without any notification or registration. In some cases we may be missing the root CA in which cases you should send your certificate to psd2[AT]


Both the production as well as the sandbox APIs are hosted at two different domains. The difference is only in the supported HTTP and TLS protocols:

We recommend whenever possible to use in your configuration. The domain is useful mostly for testing via the developer protals.

Access Token

To access the main XS2A interface, the TPP must first obtain an access token from the /xs2a/token endpoint. It uses the OAuth 2.0 client credential grant type using MTLS client authentication with the PSD2 certificate. The client_id parameter is optional and if provided should contain the TPP authorization number.

After successful authentication at the token endpoint, the TPP will receive a long lived access token (usually 24h). It should be passed to all subsequent calls to the main XS2A interface as a bearer token in the Authorization header. Example token request with curl:

curl -E tpp.pem -X POST -d grant_type=client_credentials

   "access_token" : "uXrrgOaVQAy8iNEOxMVU7AJUAGnCBbLM",
   "expires_in" : 86400,
   "token_type" : "bearer"

Strong Customer Authentication

SCA Approach

Customer authentication is based on Redirect SCA Approach with support for authorisation sub-resources and Implicit Start of the Authorisation Process. After the creation of consent or payment resource the authorisation process is started immediately by implicitly creating an authorisation sub-resource.

The scaRedirect links will expire if the user is not authenticated within two minutes. After the user is authenticated, the scaStatus is changed to psuAuthenticated and the link cannot be used anymore for another user authentication. The scaStatus of the resource will then change either to finalised if the user was able to confirm the main resource or to failed if the session expired. Additional authorisation sub-resources could be created by an explicit POST to the corresponding endpoint. They could be used either by the same PSU or by a different PSU to implement multilevel SCA in case of corporate accounts.

Authentication Channels

Customers of Central Cooperative Bank can use three different channels to access their accounts:

A customer can have access to any of the above channels. Because we do not know in advance which is the PSU or to which channels he has access the scaRedirect link opens a generic login page where depending on the device the user will be able to select and login in the appropriate channel.

TPP Redirect

When creating a consent, payment or authorisation sub-resourse, the TPP can pass a TPP-Redirect-URI header. The customer will be redirected to this URL when the SCA process finishes regardless of wether the process was successful or not. The header TPP-Nok-Redirect-URI currently is not supported.

The final redirection to the TPP URL could happen on a different channel than the one on which the scaRedirect link was initially opened. For example a user is working on a desktop computer and opens the redirect link in a browser. In certain situations the browser may display a QR code which can be scanned by the mobile device of the user. The authentication and the confirmation then continues using the CCB Mobile application and the final redirect to the TPP-Redirect-URI will happen in an embedded browser in the mobile application. The TPPs should be aware of this detail and implement the redirect links accordingly.

Consent Models

The interface supports the following consent models.

Detailed Consent

The TPP submits detailed description of the required level of account access by providing non-empty access attributes (accounts, balances or transactions).

Global Consent

The TPP is requesting access to all customer accounts. This is done by submitting one of the following access attributes: availableAccounts, availableAccountsWithBalance or allPsd2 with the value allAccounts. The attribute availableAccounts requests access only to the account list and does not require a second factor for authentication. The attribute availableAccountsWithBalance requests in addition access to balances. Finally, allPsd2 requests full access wich also includes transaction details.

Developer Portals

The obtain login credentials for the sandbox environment please contact psd2[AT] Also note that sometimes this environment will contain upcoming changes to the API so that the TPPs will be able to test them before release.