What are the requirements for an eIDAS Organization ID?

→ An eIDAS Organization ID needs to be compliant with the Etsi documentation.

See also this page.

Are business/corporate accounts also accessible through API?

→ Yes business current accounts are also accessible with our API. A business user provides its credentials in the normal way, no additional steps are required from the TPP.

Can business accounts be recognised?

→ Currently it is not possible to recognise business accounts. See our documentation for more on what data is provided.

Do you make use of the redirect, decoupled or embedded approach for SCA?

→ We are using a redirect flow for SCA in our PSD2 APIs, redirecting to either a web-interface or the mobile application.

Can the PSU make use of biometrics (e.g. fingerprint) for authentication in the mobile app?

→ Within the app 2 app flow, the PSU can make use of fingerprint for transactions otherwise requiring  a PIN.
For all other transactions, a Digipass is still required at the moment.
A solution to replace the Digipass in the mobile app by fingerprint/pin usage is on the roadmap.

AIS: What is the maximum amount of days we can access the transaction history for?

→ Full transaction history is available in the first transaction history request of each consent. After that, it is limited to 90 days automatically (no error response, even when more than 90 days of history are requested).

AIS: Do you return card accounts together with other accounts, e.g. savings accounts?

→ We support current accounts only. CashAccountType as defined by Berlin Group / ISO20022 is always CACC.

AIS: Is it possible to select multiple accounts?

→ In the account selection flow we only support selection of a single account.

It is possible to specify multiple accounts in the request, as defined by the Berlin Group standard. I.e. the accounts, balances and transactions are lists which can specify multiple accounts. But then you need to ask the user for their accounts (e.g. IBANs) upfront before entering this flow.

What is the best way to see the difference between debit and credit transactions?

→ If the transaction contains a credit account it is a debit transaction from the PSU’s account, if a debtor account is present, it is a credit transaction to the PSU’s account.

Where do I find documentation to access German accounts?

→ To access German accounts, please redirect your request to [email protected]. They should be able to help you further.

Why is the Expected Balance amount not populated?

endpoint: accounts/{account-id}/balances

→ The account for which you request the balance might have been closed.

How are multiple account holders separated?

→ This is the official registered name of the account and it is language dependent.
In the Netherlands “en/of” is most frequently used but it can also be “eo” or “e/o”.  
In the UK it can be  “&” or “and”.

This field is historically limited to max 24 characters in our database so it will not always contain the full names of the account holders.

The information returned by the API is the same as what is displayed in our other online environments. 



Why do I get a 'X.509 Certificate Is Missing' error?

POST Error: 401: "error": "access_denied",  "error_description": "X.509 certificate is missing"

→  In the Sandbox environment you must pass the certificate we provided in both the TPP-Signature-Certificate and SSL-Certificate headers.

It is described on this page under heading “TPP-Signature-Certificate and SSL-Certificate headers”. 

Please note that in production you will not need to provide the SSL-Certificate header. Instead you must make Mutual TLS connection with your eIDAS QWAC certificate. 


Certificates and registration

Do you support Open Banking certificates?

→ Yes, we do support OBIE eIDAS-like certificates (OBSeal/OBWac) for access to UK accounts.

How to renew a certificate?

→  The certificate renewal process is very simple. If your eIDAS organisation ID is unchanged there is no need to take any special action, just start using your new certificate. The only potential issue is that our (short-lived) access tokens are certificate bound, but you can always get a new access token with the refresh token with your new certificate. 

Apart from that no specific API calls or onboarding are required. You don’t need to send us your new certificate, just start using it!

How to fix 'Unregistered Redirect URI' error?

→  The message describes the error quite well: you have not registered this redirect URI. See also this page.

Note: to register multiple redirect uris you need to specify the redirect_uris parameter multiple times in the request to the registration endpoint.

How to get a new client secret?

→  Just call the /registration endpoint one more time, with your client_id and certificate you used the first time, as described on this page. This will return a new client secret, you need to use from now on. Your old secret is removed right away.


Errors explained

Invalid sort code

PUT /xs2a-bg/uk/v1/payments/uk-domestic-transfers/{resource-id}/authorisations/{authorisation-id} Error: 400:{"tppMessages":[{"text":"uk-domestic-transfers failed validation: type [INVALID_SORT_CODE]","code":"PAYMENT_FAILED","category":"ERROR"}]}

→ The sort code you are using is invalid.
Please note: UK IBAN GB29NWBK60161331926819, which is often listed as an example via Google, has an invalid sortCode (601613).

Consent invalid

Just after generating a consent, when calling GET /xs2a-bg/nl/v1/accounts Error: 401:{"tppMessages":[{"text":"Operation not possible on consent [XXXXXXXX-XXXX-XXXXXX] with status received","code":"CONSENT_INVALID","category":"ERROR"}]}

→ This error indicates that you have not yet completed the authorisation process for the consent, i.e. the consent still has status received, you must use the access token to approve the consent, then the consent will have status valid.
Use HTTP PUT to update the authorisation sub-resource with the access token to complete the authorisation process.
Please refer to this page for more info, section: Authorise the authorisation sub-resource

Payment Not Sepa Compliant

POST /xs2a-bg/nl/v1/payments/sepa-credit-transfers Error: 400:{"tppMessages":[{"text":"Payment is not Sepa compliant","code":"SERVICE_INVALID","category":"ERROR"}]}

→ The creditor bank is not configured on our Sandbox environment, it is best to use a creditor bank from the Netherlands, Belgium or the UK in our Sandbox environment.

Path does not chain with any of the trust anchors

On production: "GetAuthorisations" call that returns 401

{"tppMessages":[{"text":"Failed to validate X.509 certificate path from Subject [SERIALNUMBER=XXXXXXXX, OID.,, O=API C=XX, OID., OID. Organization, L=Place, OID.] to Issuer [CN=Buypass Class 3 CA 2, O=Buypass AS-XXXXXXXXX, C=NO]: Path does not chain with any of the trust anchors","code":"CERTIFICATE_INVALID","category":"ERROR"}]}

→ You are probably using a Qwac certificate for signing. Please make sure you use a Qseal certificate for signing. 

On sandbox:

{"tppMessages":[{"text":"Validation of TLS certificate failed: Failed to validate X.509 certificate path from Subject [, O=COBASE, OID., L=Amsterdam, C=NL] to Issuer [, O=TriodosBank, OID., L=Zeist, C=NL]: Path does not chain with any of the trust anchors","code":"CERTIFICATE_INVALID","category":"ERROR"}]}

→ After an upgrade of our Sandbox database, it is needed for you as TPP to regenerate your certificate.

Serial number [xxxxx] in keyId must be in hexadecimal format and match the serial number of the signing certificate

The most common 3 problems with the key id are:
→ As mentioned in the error message the certificate issuer distinguished name must be in RFC1779 format (see which it is not.
→ The issuer name should be after SN=XXX,CA= (see above) which it is not.
→ Our http proxy does not accept non-ascii characters in http headers. For this we have a workaround, namely to urlEncode the full Distinguished Name of the Certification Authority. When there are no non-acsi characters, encoding is not needed.

As UK TPP I do not get access to tenant according to passport

"text": "TPP with organization id [] has no access to tenant [uk] according to passport.",             "code": "CERTIFICATE_BLOCKED",             "category": "ERROR"

→ Since Brexit, access to UK requires manual processing on our side. Please contact us on [email protected].

Access token is blocked or expired

"text":"Access token [<redacted token>] is blocked or expired","code":"TOKEN_INVALID","category":"ERROR"}

→ This message indicates that the hardware token (also known as “the identifier”) of the account holder that is associated with the access token is blocked or expired. 
The access token is linked to that hardware device since that is what was used to authorize the consent, so when that device expires/ is blocked  the access token can no longer be used and a new consent must be obtained. The customers can contact customer services for issues with their token.

There should be at least one redirect URI

body: {"error":"invalid_request","error_description":"There should be at least one redirect URI"}

→ Please check if the content type of your request is application/json.
Be aware that you need to send the request with content type application/x-www-form-urlencoded instead of application/json

If you refer to this page you can see an example that shows how to send form parameters with curl by using the –data option and content-type header application/x-www-form-urlencoded

curl ''  -H 'Content-Type: application/x-www-form-urlencoded'  -H 'Accept: application/json'  -H 'TPP-Signature-Certificate: Your signing certificate' -H 'Authorization: Bearer --data 'redirect_uris=...'

Browser support: error opening Auth URL with app

Some browsers do not support the redirect done when opening an auth URL with the app.

Browsers we do support are the last two versions of: Edge, Chrome, Safari and FireFox.