Enable Banking Knowledge Base
Coverage
Which countries and banks does Enable Banking cover?We cover all 30 countries in the European Economic Area, connecting you to 2,700+ banks and financial institutions. All 30 fall under PSD2, so open banking access is regulated across the board. How each bank delivers that access varies widely, which is where our harmonisation comes in.
The full list: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden.
Explore the full list of ASPSPs and integrated APIs here.
Getting Started
How do I get started with Enable Banking?Fast. Our API is designed for fast setup, and most developers complete the technical integration in a day. Some partners pairing our API with AI-assisted workflows have gone from nothing to a working prototype in a couple of hours.
For a full production launch, the timeline depends on completing the contractual and business verification steps. However, you can test live scenarios immediately in "restricted mode" by whitelisting and linking your own real bank accounts while your application is pending.
What’s the estimated time to production with Enable Banking?It helps to think of it in three stages.
Sandbox testing is immediate. Register an application in the Control Panel and start testing against mock bank data straight away, entirely self-service. Most people can get a rudimentary prototype up and running in a few hours, and increasingly it isn't only developers doing it, we hear from people who point an AI assistant at our documentation and build one the same afternoon.
Restricted live testing is also immediate. While your production application is still pending, you can test with real data right away by whitelisting your own bank accounts. So you can check your integration works on live data before any paperwork is finished.
Full production launch adds the business side to the technical work. Most developers complete the full technical integration in about a day; going live to the public then depends on a signed contract and cleared KYB (Know Your Business), as covered in the onboarding requirements above. The technical build can run in parallel with the contract and KYB, so the two don't happen back to back, and once they're done, moving from your build to public launch is essentially a change of setting.
Once you're live, maintenance is low-effort. When we update our APIs, you don't need to change anything on your end.
Payments
Does Enable Banking offer payments?
Yes, we offer Payment Initiation Services (PIS), for licensed entities. Through a single API you can initiate a range of payment types across Europe, including SEPA, Instant SEPA, domestic payments in several non-euro markets.
How it works depends on your environment:
In the sandbox, payment initiation is enabled automatically for every newly registered application, so you can start testing right away.
In production, launching live payments requires your company to hold a Payment Initiation Service Provider (PISP) licence (or a license allowing providing Payment Initiation Service, e.g. Credit Institution license), in line with the regulatory requirements.
For companies holding that licence, Enable Banking operates as your Technical Service Provider. The service can run under your own domain, keeping Enable Banking completely invisible to your end-users.
Compliance
Who is the data controller when using Enable Banking?You are always a data controller for the account data you receive, since you determine how it's stored, used, and processed in your own application. What changes depending on your setup is whether Enable Banking is a controller as well.
If you operate under Enable Banking’s AISP authorisation, Enable Banking is also the data controller. We access the end-user's account information on their behalf under our own terms of service, and we take on the responsibilities that come with that, including KYB and AML/CTF due diligence on every application before it reaches live data, plus ongoing monitoring. End-users can review and terminate their active data-sharing consents at any time through our consent-management service.
If you operate under your own TPP authorisation with Enable Banking as your technical service provider, you are the data controller and Enable Banking acts as your data processor, following your instructions. In this model Enable Banking is invisible to your end-users, and your own terms of service apply rather than ours.
What are the onboarding requirements and legal requirements to start working with Enable Banking?Getting started involves three parts: two onboarding steps and one legal requirement for your end-users. You can complete the technical setup and start building in our sandbox straight away, the contract and KYB are only needed to go live in production.
Technical onboarding: Sign up for an account, register an API application in the Control Panel,.
Business onboarding: To activate a production application, you sign a contract with Enable Banking and clear our KYB (Know Your Business) checks.
Everything a developer needs is in our developer docs, which are built to get you to production quickly.
Can a TPP use the Enable Banking API under their own authorisation?Yes. The Enable Banking API can use an authorised TPP's own eIDAS certificates (QWAC and QSealC) to connect to banks on the TPP's behalf, with Enable Banking acting purely as a technical service provider. You get a dedicated, single-tenant environment, and PSU redirections between your application and the banks run under your own domain, so Enable Banking stays completely invisible to your end-users.
There's more on this on our TPP Infrastructure as a Service page.
Can we leverage Enable Banking's AISP authorisation? Yes. Our service is designed so that you don’t need your own AISP authorisation. Instead, as a registered AISP, Enable Banking fetches the data from the bank, and with the consent of the end-user shares the data with you.
When you use our authorisation (regulated by local financial authorities), Enable Banking acts as the regulated entity. In this setup, your end-users (PSUs) must review and accept Enable Banking's Terms of Service and Privacy Notice before they are redirected to their bank to authenticate. You can embed this consent step directly in your app with our UI widget, or let it appear on an Enable Banking page before the user reaches their bank.
Alternatively, if your company holds its own Third-Party Provider (TPP) authorisation and eIDAS certificates, Enable Banking can operate purely as a technical service provider under your licence. You manage consents on your end, and your end-users won't see Enable Banking's Terms of Service at all.
Data
Does Enable Banking enrich or categorise transaction data?Not with a layer of our own. Enable Banking harmonises data; it doesn't enrich it. We fetch data directly from each bank and map it into a single, standardised format, rather than running proprietary or third-party AI categorisation on top. Because the API connects directly to banks, with no intermediary databases in between, the data reaches you as the bank provided it, structured cleanly and consistently.
Banks do often attach their own categorisation fields to the data, and where they do, those fields come through in our standardised format. That includes the bank's own transaction type codes, merchant category codes (the ISO 18245 standard for the kind of goods or services a merchant provides), and payment purpose codes that flag things like salary, tax, or dividend payments. The exact fields are in our developer docs.
This gives you a clean, consistent foundation to run your own enrichment on, and to feed accurate, real-time data into your credit risk models, accounting software, or whatever you're building.
For third-party providers using our infrastructure under their own authorisation and for enterprise partners, the data fully unharmonised is available too.
How often can I fetch data with Enable Banking?Except for rate limits preventing misuse of our API, Enable Banking doesn't limit how often you fetch data, and there's no extra fee for fetching more, since pricing is per connected account rather than per request. The only limits come from the banks themselves under PSD2, and they depend on whether your end-user is present.
When your user is actively using your application, you can fetch as often as you need; signalling that the user is present lifts the background limit. For scheduled background fetches when the user isn't present, many banks cap access at four times a day. For the majority of banks, a single consent lasts up to six months, after which the end-user re-authenticates with their bank to continue.
Reliability and Support
Does Enable Banking offer public status pages for transparency?We provide status monitoring and transparency directly within our Control Panel for registered users. Through the Control Panel, you have access to end-to-end visibility, ASPSP status monitoring country by country, and self-service troubleshooting to ensure real-time tracking, access to oversight of your data and the ability to manually troubleshoot.
How does Enable Banking handle failures, outages, and support?Our Control Panel gives you full visibility into your connections. You can see the live status of every bank (ASPSP) we monitor, country by country, with any current issues flagged, and drill into the request logs to investigate specific errors yourself without waiting for help.
You can also subscribe to status alerts for the countries you operate in. Whenever a bank's availability changes, you get an email listing the affected banks and their updated status, so you can tell your own users about outages and recovered connections in real time. It means you're rarely the last to know when a bank goes down.
For anything you can't resolve on your own, our support team is made up of open banking specialists who work with you from initial setup through to optimisation.
Enable Banking Pricing
Do we pay per account /per user/ per API call?Our pricing is strictly volume-based. You pay for two things: each connected bank account per month, and each payment you successfully initiate.
Usage on top of that doesn't change the cost of an account. Not the volume of data, not the number of API calls, not the number of end-users, and not re-authorisations.
So, however much data you fetch, and however often, the cost per account stays the same. Adding more end-users doesn't raise it, because the API doesn't identify or track individual users. And if an end-user re-authorises access to an account you're already connected to, it isn't counted as a new account, so there's no additional charge.
The result is pricing you can predict as you scale. You can fetch real-time data and retrieve millions of transactions a month at no additional cost, while leaving all the PSD2 integration, development, and maintenance to us.