If your product reads and aggregates your users’ bank accounts, you are providing an account information service. It is the cheapest way into the regulated payments world: no initial capital, but you need professional indemnity insurance and an application to the Bank of Spain that has to be built properly.
Does your product need an AISP license? We’ll tell you within 24 h
Tell us what data you read, whose data it is and what for. We tell you whether you are inside the regulatory perimeter, whether you are better off with your own license or relying on a third party’s, and what each route costs.
We don’t explain open banking here: we have dedicated pages for that. This is what has to be decided, built and filed so that your company is registered and can operate.
Before opening an application, look at the shortcut: providing the service as an agent of an authorized institution, or relying on a provider that already holds the registration. Less control and less margin, but you reach the market in a fraction of the time.
If your plan involves moving money (collections, transfers, wallets), AIS is not enough and the project moves up to a payment institution, with initial capital in the amounts set by law, safeguarding of funds and a much heavier application.
Reading accounts and initiating payments are two different services under two different regimes. If you are also going to initiate payments from the user’s account, that page is the one for you.
Many projects combine account information with another commercial or financial activity. In those cases, the corporate design and the scope of the license are decided before applying.
It depends on the services you provide: the list in Article 2 of Law 10/2010 has to be checked against your actual business model before taking anything for granted.
Account information, payment initiation, electronic money, credit or crypto-assets: each model has its own license type and its own regulatory cost.
Almost nobody sets out wanting a payments license. People end up here because their product needs to read the user’s account and someone asks on what legal basis that is done.
“The PDF statements our customers upload are not good enough: we want to read the account with their permission and decide in minutes. We have been told that is already a regulated service.”
“Our value is showing on one screen what the user has spread across five institutions. Without access to the accounts there is no product, and that access requires being registered.”
“We want bank transactions to flow into the software on their own and match the invoice. It is just one more feature of our ERP, but technically it is account information.”
“Rentals, supplier selection, customer onboarding: we ask for documents that can be forged in two minutes. Reading the account with consent is more reliable and faster.”
The AISP regime is the most affordable in payments, but that does not make it a mere formality. These three mistakes are the ones that cost the most money and the most months.
Thinking that asking users for their credentials takes you outside the perimeter: what defines the service is the activity, not the technical channel you use to access the data. If you consolidate information from your users’ payment accounts as a service, you need to be registered, whether you use the bank’s interface or any other method.
Opening an application before there is a product: many projects can validate the market on a third party’s license and apply for their own when volume justifies it. Applying for registration with a demo and no security team is the most expensive way to learn.
Filing the security and data sections essentially blank: an AISP application is won or lost on operational risk management, business continuity, access control and the processing of personal data. That is exactly what is most often dismissed with two generic paragraphs, and what triggers the most requests for information.
| Route | What it requires | When it makes sense |
|---|---|---|
| Your own registration as an AISP | An application to the Bank of Spain: program of operations, governance, security and professional indemnity insurance or a comparable guarantee. No initial capital required. | When aggregation is the core of your product, you want to control the relationship with the user and you plan to passport into other markets. |
| On a third party’s license | A contract with an authorized institution, registration as an agent where applicable, and operational and reputational dependence on the license holder. | When you need to go to market now or validate demand, or when account access is ancillary within a larger product. |
| Payment institution or hybrid payment institution | The full regime: initial capital in the amounts set by law, safeguarding of customer funds and a much heavier compliance structure. | When, in addition to reading accounts, you will initiate payments, collect funds on behalf of third parties or hold user funds. |
We analyze your product, the data you need to read and your commercial timeline, and tell you which of the three routes works best for you. If your own registration is the answer, we prepare the full application to the Bank of Spain: program of operations, governance, insurance, security and data protection.
An AISP is the provider authorized to offer the account information service: accessing, with the user’s consent, the data in their payment accounts and presenting it in consolidated form. It does not move money, does not initiate payments and does not hold customer funds.
If you are looking to understand the general framework (what open banking is or what PSD2 introduced), we have dedicated pages: open banking and PSD2. This page is about something else: the application that turns your company into a registered AISP.
None. It is the fact that surprises almost every project: the regime for account information service providers does not require initial capital. In return, it does require professional indemnity insurance or a comparable guarantee covering liability toward banks and toward users.
That does not mean the project is free: you have to fund the structure, security, compliance and audits. But the entry bar is incomparably lower than for a payment institution.
In many cases, yes, and it is the first question we ask. There are two common routes: providing the service as an agent of an authorized institution, or building your product on top of a provider that already holds the registration and provides access to the accounts.
Neither of them frees you from everything: you sign a contract with obligations, you depend on someone else’s license and your data processing is still your own. But they let you validate the market without opening an application. You should also review the exclusions from the payment services regime before assuming you are in scope.
We don’t give timelines: the deadline for a decision is the one set by law, and the real timeline is driven by something else. A complete application, with the security and data protection documentation genuinely done, moves forward; one that arrives half-finished enters a cycle of requests for information that can last longer than the entire preparation.
What we can tell you in advance is what they ask and in what order. That is the part that shortens the timeline: arriving with the answers written before the questions are asked.
Only if you are going to initiate payments from the user’s account. Reading and aggregating information is one service; initiating a transfer is another, with its own regime (one that does carry capital and insurance requirements), which we explain on our payment initiation service page.
Many projects start with AIS, check that users respond and add PIS later. If you already know you will end up there, design the program of operations and the structure with that expansion in mind, not as a later patch.
It has to be checked case by case, without assuming the answer either way. The list of obliged entities is in Article 2 of Law 10/2010, and how it applies depends on the services you actually provide: a project that only consolidates information is not in the same position as one that combines aggregation with other payment or financial services.
What you should be clear about from the design stage is know your customer and the traceability of access. We analyze it with you together with our AML/CFT service.
It is half of the application, and where most projects fall short. Access relies on explicit consent, limited to the specific purpose the user has accepted: you cannot reuse that data for other purposes or keep it longer than necessary.
That means designing data minimization, retention periods, internal access control, encryption, a record of processing activities and an impact assessment where applicable. The payments supervisor asks about it, and you also have the data protection regulator behind you: we handle it together with our data protection service.
Then you have an extra layer of regulation. Creditworthiness assessment and credit scoring of natural persons is a high-risk use case under the AI Act (Regulation (EU) 2024/1689), and most of its obligations for high-risk systems apply from August 2026.
In practice, for your project: model governance, data quality, technical documentation, human oversight and traceability of decisions. It is fully compatible with a well-built AISP, but it has to be designed in from the start. We cover it on our AI Act page.
Yes. The PSD3/PSR package, proposed by the Commission in June 2023, is still going through the legislative process, and the open finance regulation (FIDA) is under negotiation. Neither of them removes registration: they aim to reshape interfaces, responsibilities and access to data beyond payments.
Those already registered will arrive with their structure, contracts and controls in place; those who wait will start from scratch once the market has already moved. We follow both files on our PSD3 and FIDA pages.
An AISP application is short compared with a payment institution’s, but it is assessed with the same scrutiny where it matters: governance, security and data. This is the route.
We analyze what data you read, whose data it is, with what consent and for what purpose. That tells us whether you need your own registration, whether you are better off going through a third party, or whether your case fits one of the exclusions from the payment services regime.
Program of operations, corporate structure and fit and proper assessment, professional indemnity insurance, security policy and operational risk management, business continuity, outsourcing and data protection. All of it consistent across the board.
Certificates and connection to the institutions’ interfaces, contracts with users and providers, incident management, reporting to the supervisor and periodic review of insurance, policies and controls.
If your model will also move money, look first at the payment institution license or the hybrid payment institution structure, because the corporate design changes.
Terms you will come across in the application, in contracts with banks and in requests for information. Using them precisely saves weeks of misunderstandings.
An entity registered to access, with the user’s consent, the information in their payment accounts and present it in consolidated form.
Account information service: the regulated activity that triggers registration. It is defined by what you do, not by the technology you use.
Account servicing payment service provider: the institution that must allow access to the information when the user authorizes it.
The mechanism by which users authenticate with their bank to authorize access, using the independent elements required by law.
The channel that institutions make available to registered providers, with its own requirements on availability, performance and fallback mechanisms.
Insurance cover (or a comparable guarantee) that responds to account servicing institutions and to users for the provider’s activity.
The user’s explicit authorization, limited to the specific purpose accepted, revocable and documented with evidence of when and how it was obtained.
The public entry that proves you are allowed to operate. Banks check it before granting you access, and your customers should too.
The European framework lets you extend your activity to other EU countries by notification through your supervisor, on the terms set by law.
A precise description of what information is read, from which accounts, for what purpose and with what user journey, with no ambiguity about the scope of the service.
A service description with data flows and screens, architecture diagrams, user terms of use and a description of the technical and human resources.
An incorporated company with transparent ownership and a management body with the good repute and capability to run a supervised entity.
Deed of incorporation and articles of association, table of shareholders and beneficial owners, fit and proper questionnaires, documented CVs and criminal record certificates.
Cover or a comparable guarantee proportionate to the risk profile, the expected volume and the markets in which you will operate.
Policy or firm commitment from the insurer setting out scope and exclusions, a calculation supporting the amount and evidence of periodic renewal.
Documented management of operational and security risks, access control, encryption, incident management and the ability to keep operating through an outage.
Approved security policy, risk analysis, incident procedure with communication channels, business continuity plan and tests carried out.
Processing limited to the purpose consented to, with data minimization and limited retention, and critical providers under effective contractual control.
Record of processing activities, consent wording and evidence that consent was obtained, impact assessment where applicable, and contracts with providers and processors.
If you recognize yourself in any of these, stop and validate your fit before connecting to the first bank.
This page offers one specific thing: the AISP authorization and registration application to the Bank of Spain. If what you need is to understand the framework (what open banking is, what PSD2 introduced, what PSD3 will change or how far FIDA will take access to financial data), there are dedicated pages for each of these, and they will serve you better than this text.
The model of access to data and accounts that made this license type possible, explained from scratch and without application jargon.
Directive (EU) 2015/2366 and its transposition in Spain through Royal Decree-law 19/2018, with its services, parties and obligations.
The package proposed in June 2023 is still going through the legislative process: what is being negotiated and what to anticipate in your design.
Access to investment, insurance and pension data now being negotiated, and how it affects those who already aggregate accounts.
And if you want to get started, the order matters: first compare the payment institution agent route with your own registration, check whether your case fits one of the exclusions from the payment services regime and look at the fintech license map to place your project.
Tell us how your product works and what you do with your users’ account data. We’ll tell you whether you need your own registration and where to start.
Last updated: August 4, 2026
The account information service provider (AISP) is the entity type used to access, with the user’s prior consent, the information in their payment accounts in order to present it in consolidated form. Its framework is PSD2 (Directive (EU) 2015/2366) and, in Spain, Royal Decree-law 19/2018, and registration is handled by the Bank of Spain. This text does not explain open banking (for that, see our open banking page and our PSD2 page): here we explain how the application is built.
The fact almost nobody knows, and one that changes many business plans: the account information service provider regime does not require initial capital. In return, it requires professional indemnity insurance or a comparable guarantee that responds to account servicing institutions and to users for damage arising from your activity. That single difference separates two worlds: a payment institution starts out with capital in the amounts set by law and with an obligation to safeguard customer funds, while an AISP can be set up with a much lighter structure because it never touches the money. What it does share with other supervised entities are the qualitative requirements: governance, risk management, security, business continuity and control over providers. There is no lighter regime there. That is why the most common mistake in these projects is not underestimating the capital (there is none) but underestimating the cost of running a supervised entity: insurance policies to renew, internal policies to review, incidents to report and audits to pass. Our work starts right there, putting numbers and a timeline on that cost before you decide whether you want your own registration or would rather rely on a third party’s license while you validate the product.
An AISP application is shorter than a payment institution’s, but it is read with the same rigor where it really matters. The first section is the program of operations: what information you will read, from which accounts, for what purpose, with what user journey and with what technical architecture. It has to be so specific that anyone could draw the data flow just by reading it. The second is the structure: company, shareholders, beneficial owners and management body, with the good repute and capability of those who will run a supervised entity. The third is professional indemnity insurance or a comparable guarantee, with coverage justified against your volume and the markets where you will operate. The fourth (the one that triggers the most requests for information) is the security and operational risk package: access control, encryption, incident management, a business continuity plan and tests actually carried out, not promised. And the fifth covers personal data and providers: explicit and granular consent, data minimization, limited retention and outsourcing agreements with the third parties that support your connection. Five sections that must tell the same story: when the program of operations says one thing and the security policy says another, a request for information is bound to follow.
We would rather lose an engagement than sell you an application you don’t need. There are at least three situations in which an aggregation project can go to market without its own registration. The first: operating as an agent of an authorized institution, with a contract, registration where applicable and the umbrella of its license. The second: building your product on a provider that is already registered, which provides access to the accounts while you provide the value layer; you lose margin and control over the technical relationship, but you gain months. The third: confirming that your case fits one of the exclusions from the payment services regime, which do exist and sometimes solve the whole problem. None of the three is free: you remain responsible for data processing, for the contract with your user and for your own security, and with the first two you also accept financial and operational terms you do not control (fee per query, bank coverage, service quality and priority relative to the provider’s other clients). And none of them lasts forever: once aggregation becomes the core of the business, depending on someone else’s license turns into a strategic risk (changes in price, terms or ownership), and your own registration stops being a cost and becomes an asset. That transition should be planned, not improvised.
The framework is moving on two fronts. The PSD3/PSR package, proposed by the Commission in June 2023, is still going through the legislative process and aims to reshape account access, interfaces and the allocation of liability between banks and providers. And the financial data access regulation (FIDA, proposed in June 2023 and also under negotiation) seeks to take the model beyond payments, into investments, insurance and pensions, through authorized providers and data-sharing schemes. Neither of them removes the license type or the registration; both raise the bar on governance, security and contracts. The practical conclusion is the opposite of the intuitive one: those who register now will reach that scenario with an incorporated entity, controls already tested in practice and a relationship with the supervisor, and adapting will cost them a review; those who wait will start from scratch once the market has already been carved up. On top of that comes the rest of the perimeter that a financial data project brings with it: data protection, operational resilience and, if you make decisions with automated models, the AI Act. Getting it in order at the design stage costs a fraction of rebuilding it later, when you already have users, signed contracts with account servicing institutions and a supervisor asking you questions in writing. Our recommendation, once the business is validated, is not to wait for the perfect law: register under the current framework and keep the application ready to absorb whatever comes next.
This content is for general information purposes only and does not constitute legal advice. The legislation cited may have been amended after the update date shown: always check the version in force or contact us to analyze your specific case.
Key legislation, linked to the official text:
Legislation and links reviewed in .