Frequently Asked Questions

This section provides answers to common questions about Enable Banking's API services. Whether you're wondering about pricing, session validity, or how to activate production application, you can find helpful information here.

# What are the terms ASPSP and PSU?

ASPSP stands for Account servicing payment service provider. This term is referring to banks, credit card companies or other similar financial institutions.

PSU stands for Payment Service User. It refers to a person who uses a service providing functionality involving interaction with payment accounts. In other words, the PSU is the end user interacting with the services provided to them. The PSU authorises payments or access to information about their accounts.

# Can I test the API before signing a contract with Enable Banking?

You can create an Enable Banking account and access both mock and production environments before signing a contract, but applications can't be made available to the public before a contract is signed.

# How much does it cost to use the Enable Banking API?

Our pricing is volume based. The cost depends on the number of accounts accessed and payments made per month. There is a minimum invoicing per month which includes a certain amount of accounts and payments. For a quota please contact sales at info@enablebanking.com.

When getting started you can use sandbox environment or link own accounts to your production application.

# When will my production application become active?

Your production application will become active once you have signed a contract with Enable Banking and completed the KYB process for your company. You can also activate your production application in the restricted mode by linking your own accounts to it (in this case only linked accounts would be accessible through the application).

# Do you provide access to business accounts?

In most cases both business and personal accounts are accessible, but there are some exceptions depending on ASPSPs. You can check whether business and personal accessibility has been integrated here (opens new window).

# Is it possible to identify an end user with this API?

Yes and no. In most cases you can get account holder name, be that the name of a company or the users name if it's a personal account. Some banks also provide the possibility to verify using users social security number, but this is not available in all countries (for example, in Finland this isn't possible, in Sweden it is).

# Why am I getting multiple balances for one account?

It's possible you are receiving multiple balance types and are displaying an unnecessary balance type. List of all supported balance types can be found here.

Each ASPSP supports only a limited number of balance types. The most common are CLBD, ITAV and XPCD.

# Why am I missing balances from an account?

It is possible you are trying to display a balance type that the ASPSP is not providing.

# Are there unique identifiers for transactions?

Unfortunately not for all ASPSPs, because some do not provide transaction entry references and some have duplication even though they should not. We always try to address issues arising from these as as quickly as possible.

In some cases when an ASPSP doesn't provide transaction entry references, we can generate "synthetic" entry references on our end. To be able to do this certain conditions need to be met.

# Why are bundled transactions not visible through API calls?

Some ASPSPs do not provide separate listings for bundled transactions.

# How far back transactions history can be fetched for an account?

Most ASPSPs provide access to at least one year of transactions. However, many ASPSPs offer access to an even longer period of history, ranging from two to three years or even longer, without any limitations.

It's important to note that access to historic transactions may be limited after a certain period has elapsed since the authorization to the account was made. This timeframe can vary depending on the ASPSP, but it's typically around one hour. After that time has passed, many ASPSPs limit access to transaction data from the past 90 days.

It's also worth noting that if a request is made for transactions before the date an account was opened, an error can be raised. This is important to keep in mind when querying transaction data for a specific account.

# Can I find somewhere how long history of transactions an ASPSP provides?

At this time, we do not provide information on the duration of transaction history that an ASPSP provides. This is because the availability of transaction history can vary depending on the account type, and the conditions vary a lot across ASPSPs.

We would recommend trying to fetch longer period at first (for example 3 years) and if not available, fallback to 2 years, 1 year, 6 months and eventually to 90 days. In case the requested period is not accessible, Enable Banking API will return WRONG_TRANSACTIONS_PERIOD error code.

# What are the PSU headers in the endpoints for fetching account details, balances, and transactions used for?

PSU headers serve the purpose of indicating that an end-user is actively using your application, indicating their current online interaction with it. When at least one PSU header is included, it informs an ASPSP (a bank) that the PSU (end-user) is actively using the application to request information. Consequently, any limitations imposed by the ASPSP on background transaction fetching, such as the maximum number of data fetches per day, do not apply.

We strongly recommend supplying as many PSU headers as possible whenever your application detects the presence of an end-user. These headers are ultimately forwarded to the target ASPSP, which may utilize the provided information to implement additional security measures. Among the PSU headers, Psu-Ip-Address and Psu-User-Agent are particularly valuable and likely to be required by the target ASPSP (see the next question).

To simplify, if person A triggers data retrieval, you should provide the headers specific to person A. Likewise, if person B initiates the data retrieval, you should provide the headers relevant to person B. Although the practical implementation may involve some complexities, the general rule is as follows:

If the application itself triggers data fetching (e.g., based on a predefined schedule), no PSU headers should be provided.
If a user triggers the data fetching (e.g., by selecting a date for which transactions have not been retrieved earlier), the PSU headers of that user should be included.

# Why am I getting 422 response code and PSU_HEADER_NOT_PROVIDED error code?

The error occures when you are trying to fetch either account details, balances, or transactions providing one or several PSU headers, but not all PSU headers required by the ASPSP where data is being fetched. Please notice that either all required PSU headers (in case of online data fetching) or none of PSU headers (in case of background data fetching) are to be provided. The list of required PSU headers is returned for each ASPSP in response to the GET /aspsps request. However we recommend providing all PSU headers available to your applications.

# Why am I getting 429 response code? Are there rate limits for the API?

The 429 error most likely comes with the ASPSP_RATE_LIMIT_EXCEEDED error in the response body, which means that the target ASPSP (i.e. a bank or a similar financial institution) doesn't currently allow more requests.

Most often rate limits are reached when you are doing so-called background data fetching, as many ASPSPs have the limit of 4 times a day for data fetches when PSU (i.e. the end-user) is not online in the solution using the data. Whether a data fetch is made in background or online is determined based on absence or presence of so-called PSU headers. For more information about PSU headers, please refere to this FAQ.

If you get ASPSP_RATE_LIMIT_EXCEEDED when fetching data in background, there is no way to avoid limits. So we recommend to continue data fetching after 6 hours.

# How can I get the authorization token?

Authorization token needs to be generated. You can do this by using applications' RSA private key. Instruction on how to generate this can be found here.

# How long is the validity of the authorization token?

The validity of the token is set when you encode it. Maximum allowed time-to-live for token is 86400 seconds (24 hours). Tokens created with longer TTL are not accepted by the API. For each API request, a new token can be generated.

# Does the authorization token identify an end user?

No. The authorization token only identifies the application that is making API requests. With one authorization token you are able to access all account information sessions and payments initiated by the application. Multiple sessions and payments may belong to different users.

# Can authorization tokens be shared with end users?

Authorization tokens can't be shared with end users, as the token can be used by an end user to access other users data or initiate payments.

# Do you support decoupled authentication approaches?

Yes, for ASPSPs which support decoupled authentication. When you request the list of integrated ASPSPs for each ASPSP, you will receive a list of available authentication methods. To check the approach type used by an authentication method, use approach field of the auth method data structure.

# How shall we handle error responses from the API containing the error code ASPSP_ERROR?

ASPSP_ERROR error code occures when interaction with an ASPSP fails while an attempt to retrieve account details, transactions, balances or a payment status. The error code belongs to different uncategorised errors received from ASPSPs. Mainly these errors are failures on the ASPSPs` side (cause by maintainance windows, bugs, etc).

In case the ASPSP_ERROR error code is returned, we recommend retrying the operation resulting in the error several times with increased intervals between retries. For example, after 1 minutes, after 1 hour, after 2 hours and after 4 hours. In case the error still occures after several retires, you may want to manually review the problem, you may find extra details on the error at the request log available for each application in the control panel (opens new window).

# How long is session validity?

Session validity is provided by the API client when initiating a session. This is done by setting the valid_until field to a future date. The longest validity you can set is dictated in maximum_consent_validity returned for each ASPSP. The value is in seconds. For the majority of ASPSPs this is 90 days.

# How can I know if a session was authorized by an end user?

After an end user has completed authorization, they will be redirected to the callback URL provided by your application when the session is initiated. The query string of the URl would contain code parameter and its value needs to be passed to the request completing authorization.

# Is it possible to run authorisation flow for end-users in iframe?

No, it is not possible. Modern web browsers will disallow cross-origin iframes, which means that if the domain name and scheme inside an iframe are different from their counterparts on the page containing the iframe, the browser will block it. It is only possible to enable cross-origin iframes by sending proper CORS headers from the server behind the URL in the iframe.

In the case of Enable Banking, CORS headers allowing cross-origin iframes are not set, because even after redirection to an ASPSP, CORS headers won't be provided, and web browsers won't render the ASPSP authentication interface.

If you are interested in embedding Enable Banking's terms of service for data sharing or payment initiation, which are displayed to end-users prior to their authentication with an ASPSP, you can utilize the UI widget for terms consent.

# What statuses does a payment go through after being created through the Enable Banking API?

The following state diagram illustrates the life cycle of payment initiation after an application makes the POST /payments request.

Payment initiation state diagram

# Can a TPP use Enable Banking API under their own license?

Absolutely. Enable Banking API can use eIDAS certificates (QWAC and QSealC) of a licensed TPP and connect to ASPSP on behalf of the TPP. In this case Enable Banking will be acting as a technical service provider. Dedicated (single-tenant) environment will be used and TPP's domain name will be used for handling redirection of PSUs between TPP's applications and ASPSPs. This would make Enable Banking completely invisible for PSUs.

No, that is not required. However, as a TPP, you will need to set up an eIDAS broker, which is a microservice provided by Enable Banking. The eIDAS broker handles the cryptographic signing of requests and mTLS connections to integrated ASPSPs (Account Servicing Payment Service Providers). You can access the source code and a pre-built Docker image of the microservice on our Github repository: https://github.com/enablebanking/open_banking_eidas_broker (opens new window)

By implementing this approach, there is no need for you to entrust the private keys of your eIDAS certificates to Enable Banking.

Alternatively, if you prefer to have Enable Banking manage the private keys of your eIDAS certificates, it is possible but would require an additional contract.