Enable Banking Docs

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.

# Is it possible to retrieve a historic balance on a specific date?

No, it is not possible to directly retrieve a historic balance for a specific date, as ASPSPs do not provide APIs for this purpose. However, some ASPSPs provide information about the available balance after each transaction, which is available in the balance_after_transaction field of the transaction data structure. Therefore, it is possible to use the last transaction of the day to estimate the balance on that specific day.

# 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 (containing the end-user's IP address) and Psu-User-Agent (containing identification of a web browser or an application used by the end-user) 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 180 days.

# Why does the API return EXPIRED_SESSION when the session has valid_until in the future?

For a number of reasons, sessions may still expire prematurely, and in such cases, the EXPIRED_SESSION error is returned similarly to when the valid_until time has been reached.

Although sessions do not often expire prematurely, it becomes more likely to receive EXPIRED_SESSION errors as more sessions are initiated by your application. Therefore, it is highly recommended to handle this error. The error is accompanied by a 401 response status code; however, a 401 response code may occur for other errors as well. Thus, it is recommended that API clients base their logic on errors rather than response codes. Upon receiving an EXPIRED_SESSION error, API clients should initiate a new authorisation and prompt end users to complete it.

The most common reasons for prematurely expiring sessions are:

  • In the sandbox environment, some ASPSPs do not support session validity.
  • The ASPSP does not support multiple authorisation sessions for one PSU (end user); i.e. authorising a new session will expire a previous one.
  • The ASPSP expires the end user's session because certain actions are required from the end user. Most often, a yearly KYC survey needs to be completed by the end user before they can continue using the ASPSP's services (including open banking).
  • The ASPSP does not support seamless migration between old and new certificates used by TPPs (e.g. providers like Enable Banking).

It is possible to check the session status using the GET /sessions/{session_id} endpoint prior to fetching account information. However, it is still possible for the session to expire or for expiration to be detected during the fetch of account information. In such cases, the EXPIRED_SESSION error will be returned, even if the previous response indicated that the session was valid.

# 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.

# Why is the terms of service page shown before ASPSP authentication?

When your application relies on Enable Banking accessing ASPSPs as a regulated entity, we must ensure that end users (PSUs) are fully aware of the service they are using. It is crucial that they understand and agree to the terms and conditions under which these services are provided. This ensures that Enable Banking complies with legal obligations and regulatory requirements, protecting both the user and your application.

Transparency is key in building user trust, especially in financial services. By displaying the terms of service before ASPSP authentication, we demonstrate a commitment to openness and transparency, which can enhance user confidence in the service and trustworthiness of your application.

In order to smoothen the user experiense we provide the UI widget for terms consent, which can be embedded into your application. After making the POST /auth request your application shall display the widget. If the end user gives their consent to the terms of service using the widget, the terms of service page will be skipped when they visit authorisation URL. The appearance of the widget can be adjusted using CSS.

If your company is a licensed TPP and Enable Banking acts only as a technical service provider, your applications will be able to manage end user consents on their end. The service can be configured so that the step of consent with the terms of service is always skipped.

# 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.

Also it is possible to use our auth flow widget and embed the authentication steps preceding interaction with ASPSPs' UI into your application. For decoupled authentication flows, this will allow a direct switch between your application and applications used for strong customer authentication, e.g. Mobile BankID in Sweden or ASPSPs' own applications.

# Why am I getting CORS errors when using Enable Banking UI widgets?

You may encounter errors like Access to fetch at 'https://tilisy.enablebanking.com/api/start_consent_external' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. occuring in the web browser after you put one the UI widgets on your web page.

There are two probable reasons for the problem:

  1. Either the origin of the web page on which the UI widget is used is not whitelisted for your application;
  2. or the sandbox attribute set for the widget does not correspond to the environment where your application is registered.

Whitelisting of the origins can be done through the control panel:

# 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.

# Does a TPP using their own eIDAS certificates need to share the private keys of the certificates with Enable Banking?

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.

# Where can I find the credentials when testing the connectivity through sandbox?

In cases where the ASPSP requires credentials like username and password when accessing sandbox data, you can find the relevant credentials in the Sandbox Credentials page.