An AISP license in Europe authorizes a firm to provide regulated account information services under Directive (EU) 2015/2366 (PSD2). A pure AISP model usually does not rely on the same initial capital logic as a full payment institution; the core prudential focus is typically professional indemnity insurance or a comparable guarantee, plus governance, ICT security, GDPR discipline, and regulator-grade evidence that the firm can access account data lawfully through open banking interfaces.
An AISP license in Europe authorizes a firm to provide regulated account information services under Directive (EU) 2015/2366 (PSD2). A pure AISP model usually does not rely on the same initial capital logic as a full payment institution; the core prudential focus is typically professional indemnity insurance or a comparable guarantee, plus governance, ICT security, GDPR discipline, and regulator-grade evidence that the firm can access account data lawfully through open banking interfaces.
This page is an information resource, not legal advice. Authorization requirements vary by member state, business model, outsourcing structure, target markets, and supervisory expectations. In 2026, firms should assess both the current PSD2 framework and the transition path toward PSD3, PSR, DORA, and broader open finance developments.
Core authorization thresholds, timeline reality and the practical review lens in one block.
Classify the service perimeter, map data flows, identify whether the product remains pure AIS or crosses into PIS, PI, EMI, credit intermediation, or local consumer-law triggers.
Build the business plan, governance pack, ICT and security documentation, outsourcing register, GDPR framework, complaints handling, and PII structure.
Expect completeness checks and multiple Q&A rounds. Regulators often focus on consent architecture, data minimization, outsourcing, management competence, and operational resilience.
Operational readiness still matters after approval: eIDAS certificates, API onboarding, incident governance, host-state notifications, and local conduct compliance remain live workstreams.
An AISP license in Europe authorizes a firm to provide regulated account information services, not general payment services. In practice, this means the firm may access and process payment account data from one or more banks or other ASPSPs, with the payment service user’s explicit consent, to deliver dashboards, analytics, affordability checks, accounting integrations, treasury visibility tools, or embedded finance data features.
Typical AISP business models include personal finance management apps, SME cash-flow dashboards, lender affordability engines, accounting software connectors, subscription risk scoring, and multi-bank treasury reporting. The regulatory question is not whether the product is branded as fintech or SaaS. The real question is whether the firm is accessing payment account data as a regulated third-party provider under the PSD2 open banking perimeter.
AISP is not a “mini payment institution.” If the product starts moving money, storing value, controlling funds, or issuing payment instruments, the analysis changes immediately. That is why founders should map the customer journey screen by screen before filing an application.
The fastest way to choose the wrong license is to compare legal labels instead of operational permissions. The matrix below translates the founder question into supervisory logic: what service is being provided, whether funds are touched, what prudential regime applies, and where the main regulatory pressure sits.
For a pure AISP, the key distinction is that the prudential focus usually shifts from initial capital to professional indemnity insurance. For a PISP, EUR 50,000 initial capital is the headline threshold. For a payment institution, the applicable threshold is typically EUR 20,000, EUR 50,000, or EUR 125,000 depending on the services. For an EMI, the initial capital baseline is EUR 350,000 under Directive 2009/110/EC (EMD2).
| Parameter | PI | EMI | Specialized Bank |
|---|---|---|---|
| Primary activity | Provides regulated payment services beyond pure AIS or e-money issuance; can cover execution of payment transactions depending on scope. | Issues electronic money and typically provides related payment services around stored value or wallet models. | Used here as the AISP / PISP comparator: AISP reads account data; PISP initiates payments from the user’s bank account without holding funds in the AISP-only model. |
| Access to account data | Possible where relevant to the licensed services, but not the defining feature. | Not the defining feature; depends on product design and additional permissions. | AISP: core permission. PISP: may access data necessary to initiate a payment and confirm execution. |
| Can initiate payments | Yes, where licensed for the relevant payment services. | Yes, where the EMI also provides payment services within its authorization perimeter. | AISP: no. PISP: yes, this is the core service. |
| Can hold customer funds | Depends on the specific payment services and safeguarding obligations. | Yes, in the context of issued e-money and related payment flows, subject to safeguarding and prudential rules. | AISP: no. PISP: the model is not built on holding user funds. |
| Headline prudential threshold | Initial capital typically EUR 20,000 / 50,000 / 125,000 depending on services, plus own funds requirements. | Initial capital EUR 350,000, plus ongoing own funds and safeguarding. | AISP: usually PII or comparable guarantee. PISP: initial capital EUR 50,000 plus relevant prudential obligations. |
| Safeguarding relevance | Often central where customer funds are received for execution of payment transactions. | Core requirement because customer funds received in exchange for e-money must be safeguarded. | AISP: generally not a core feature because a pure AISP should not hold customer funds. |
| Main supervisory focus | AML/CFT, governance, safeguarding, own funds, outsourcing, incident reporting, conduct of business. | Capital, safeguarding, redemption rights, governance, AML/CFT, ICT resilience, outsourcing, financial crime controls. | AISP: consent management, data governance, PII, ICT security, GDPR, outsourcing, fit and proper. PISP: payment flow integrity, SCA, fraud controls, and capital. |
| Best fit | Payment execution businesses that do more than read data and do not need e-money issuance. | Wallet, stored-value, prepaid, or embedded money models requiring issuance of e-money. | AISP: analytics, aggregation, accounting connectors, affordability, treasury dashboards. PISP: pay-by-bank and account-to-account initiation. |
The current AISP authorization perimeter in Europe still sits on PSD2, but no serious 2026 planning exercise should stop there. A founder building an AISP today must design for four layers at once: the existing PSD2 service definitions, the technical obligations under the EBA RTS on SCA and common and secure communication, the personal-data rules under GDPR, and the operational resilience expectations now shaped by DORA, which has applied since 2025.
PSD2 remains the baseline because it is the legal source for account information services as a regulated payment service. That matters for authorization, passporting, and the relationship between the AISP, the ASPSP, and the payment service user. The practical effect is that your licensing file must still explain how the service qualifies as AIS, how consent is obtained and evidenced, how access is technically secured, and how the firm avoids drifting into a broader regulated perimeter.
GDPR is not a side note for AIS. It sits at the center of the model because AISP businesses process high-value financial data that can reveal income patterns, health-related spending, political preferences, religion, location habits, and household structure. Regulators increasingly expect firms to show purpose limitation, data minimization, retention logic, lawful basis analysis, and clear separation between product analytics and regulated service delivery.
DORA changed the tone of ICT supervision. Even where the legal authorization still comes through a payment-services framework, supervisors now look more closely at incident classification, testing, third-party ICT risk, business continuity, and board-level accountability for resilience. In practice, weak cloud oversight or a vague outsourcing model can now damage an AISP application even if the legal scope itself is correct.
PSD3, PSR, and the wider open finance agenda, including FIDA, matter because they influence product design now. Founders who build consent architecture, data lineage, fraud controls, and customer disclosures only to the minimum PSD2 standard may need to rework them later. The better strategy is to build a licensing pack and technology stack that already anticipates stricter harmonization, clearer fraud allocation logic, and broader financial-data sharing expectations.
A practical 2026 rule: treat PSD2 as the current authorization baseline, DORA as the operating standard for ICT governance, GDPR as the data-use boundary, and PSD3 / PSR / FIDA as the design horizon. Legislative timing and national implementation details remain subject to change.
| Framework | Why It Matters | Operational Impact |
|---|---|---|
| Directive (EU) 2015/2366 (PSD2) | Defines account information services and payment initiation services as regulated payment services. It is still the core authorization architecture for AISP licensing across the EU / EEA. | Your business model mapping, application perimeter, passporting logic, customer disclosures, and ASPSP interaction model all start here. |
| EBA RTS on SCA and Common and Secure Communication | This is the technical regulatory anchor for secure access to payment accounts, identification of third-party providers, and communication with ASPSPs. | AISP architecture must support secure API access, identification through the appropriate trust framework, auditability, and a consent model aligned with bank-side authentication flows. |
| GDPR | AIS depends on lawful processing of sensitive financial behavior data. GDPR governs lawful basis, transparency, minimization, retention, data subject rights, and processor arrangements. | You need a data inventory, records of processing, retention schedule, privacy notices, vendor contracts, and controls preventing secondary use beyond the agreed purpose. |
| DORA | DORA brings a more formal operational resilience regime for financial entities, including ICT risk management, incident handling, testing, and third-party oversight. | Boards must own ICT risk. Firms need an outsourcing register, incident procedures, vendor due diligence, resilience testing, and clearer accountability for critical ICT services. |
| PSD3 / PSR trajectory | The reform package is intended to modernize payment-services rules, reduce fragmentation, and sharpen fraud and open banking standards. | Founders should avoid building a licensing and product stack that only works under the narrowest reading of PSD2. Documentation should be future-compatible. |
| FIDA / open finance trajectory | Open finance expands the strategic context beyond payment accounts toward broader financial-data access and reuse frameworks. | AISP firms planning to evolve into wider data-access businesses should design governance, consent granularity, and data lineage with future expansion in mind. |
An AISP application succeeds when the regulator can see three things clearly: the service perimeter is correctly classified, the firm has people and controls that match the risk profile, and the technology stack can access and process account data without creating unmanaged legal or operational risk. Generic statements about being innovative or secure do not help. Supervisors want evidence.
The most overlooked point is prudential structure. A pure AISP is usually assessed through the lens of professional indemnity insurance or a comparable guarantee, not through the same initial-capital narrative used for full payment institutions. The second overlooked point is substance. Even in more fintech-friendly jurisdictions, regulators expect real decision-making, not a paper company with outsourced responsibility and no internal ownership.
In practice, the strongest files show a coherent governance model, a realistic three-year business plan, named accountable persons, a documented outsourcing perimeter, a tested incident process, and a data-protection framework that explains exactly what data is collected, why, for how long, and under whose authority.
A recurring supervisory issue in 2026 is the gap between a polished front-end product and weak retained control behind it. If the board cannot explain the consent model, the data lineage, the cloud dependency map, and the insurance structure, the application is usually not ready.
| Area | Regulatory Expectation | Evidence Pack |
|---|---|---|
| Professional indemnity insurance (PII) | A pure AISP usually needs PII or a comparable guarantee calibrated to the risk profile. Regulators look at coverage scope, exclusions, territorial reach, claims mechanics, and whether the policy actually covers AIS activity rather than generic tech liability. | Draft or bound policy, insurer term sheet, coverage analysis, explanation of how the amount was determined, and confirmation that the wording aligns with the AISP business model. |
| Business model and scope mapping | The firm must show that the service is genuinely AIS and identify any adjacent activities that may require PISP, PI, EMI, credit, broking, or local consumer permissions. | Customer journey maps, product descriptions, revenue model, data-flow diagrams, terms of service, and a perimeter memo mapping each feature to the legal basis. |
| Governance and fit and proper | Directors and key function holders must be competent, reputable, and able to oversee a regulated data-access business. Supervisors increasingly look for evidence that the board understands ICT and outsourcing risk, not just legal compliance. | CVs, criminal-record and reputation checks where required, fit and proper questionnaires, board matrix, role descriptions, and conflict-of-interest framework. |
| Local substance | The firm must demonstrate real management and control in the licensing jurisdiction. The exact staffing model varies, but regulators generally resist hollow structures where every material function is externalized. | Local office arrangements where relevant, management-residency plan, employment or service agreements, governance calendar, and evidence of decision-making in the home state. |
| AML/CFT framework | Even where the AISP model does not hold funds, regulators still expect a proportionate AML/CFT assessment because the business handles financial data, onboarding, and potentially fraud indicators. | Business-wide risk assessment, AML policy, customer-risk methodology, suspicious activity escalation lines, MLRO appointment where applicable, and sanctions-screening logic where relevant. |
| ICT security and open banking controls | The firm must show secure communication, access control, encryption, logging, vulnerability management, and resilience around the API stack and supporting infrastructure. | Security policy set, architecture diagrams, access-control matrix, key-management approach, incident-response plan, penetration-testing summaries, and vendor security due diligence. |
| GDPR and data governance | AIS requires disciplined use of personal financial data. Supervisors expect a narrow purpose statement, clear consent boundaries, retention rules, and controls against unauthorized secondary analytics. | Privacy notice, records of processing activities, retention schedule, lawful-basis analysis, DPIA where appropriate, processor agreements, and data subject rights workflow. |
| Outsourcing governance | Outsourcing is allowed, but responsibility is not transferable. Critical ICT providers, API aggregators, cloud hosts, and fraud-monitoring tools must be governed through contracts, oversight, exit planning, and concentration-risk analysis. | Outsourcing policy, outsourcing register, materiality assessment, vendor due diligence, SLA package, audit-rights language, and exit / substitution plan. |
An AISP authorization pack is a regulatory operating manual, not a marketing deck. The goal is to let the competent authority understand how the firm will function on day one, who is accountable, how the service fits within the legal perimeter, and how the main risks are controlled.
Most delays come from documents that look complete but do not align with each other. For example, the business plan says the firm is a pure AISP, while the customer journey implies payment initiation, or the privacy notice allows broader data use than the regulatory perimeter supports. Internal consistency matters as much as completeness.
| Document | Purpose | Owner |
|---|---|---|
| Regulatory business plan | Explains the model, target customers, revenue streams, rollout strategy, and regulated perimeter over a 3-year horizon. | Founders / legal / finance |
| Program of operations | Describes the exact AIS services, customer journey, channels, and operational setup. | Legal / product |
| Financial forecast | Shows viability, cost assumptions, runway, and stress scenarios, often for 3-5 years depending on regulator expectations. | Finance |
| PII or comparable guarantee package | Demonstrates prudential coverage appropriate for AIS activity, including policy wording and coverage rationale. | Finance / legal / insurance broker |
| Governance framework | Sets out board structure, reporting lines, committees, conflicts management, and decision-making authority. | Board / legal |
| Fit and proper files | Supports the suitability of directors, senior managers, and qualifying shareholders. | HR / legal / company secretary |
| AML/CFT policy and risk assessment | Shows how the firm identifies, assesses, escalates, and documents financial-crime risk. | Compliance / MLRO |
| Information security policy set | Documents access control, encryption, logging, vulnerability management, change control, and secure development. | CISO / CTO / compliance |
| ICT architecture and data-flow diagrams | Maps how data moves between user, AISP, ASPSP APIs, cloud services, and internal systems. | CTO / engineering |
| Outsourcing policy and register | Identifies all outsourced functions, materiality, oversight model, and exit arrangements. | Operations / legal / compliance |
| Incident response and business continuity plans | Shows how the firm handles operational disruptions, cyber events, and service recovery. | Operations / security |
| GDPR documentation pack | Covers privacy notices, records of processing, retention, processor management, and data subject rights handling. | DPO / legal / compliance |
| Complaints handling policy | Explains intake, triage, response timelines, escalation, and root-cause remediation. | Compliance / customer operations |
| Terms and conditions / consent wording | Defines the service, user permissions, data-use boundaries, and disclosures in a regulator-reviewable form. | Legal / product |
| Internal control and audit framework | Shows how the firm monitors compliance, risk, and control effectiveness after authorization. | Compliance / risk / internal audit |
The AISP licensing process is a supervised evidence exercise. The regulator is not only checking whether the form is complete; it is testing whether the firm understands its own perimeter, can govern outsourced technology, and can operate safely from day one. A realistic planning range is often 2-4 months for preparation and 3-12+ months for review, with total time commonly landing in the 6-18 month range depending on jurisdiction and file quality.
Define whether the model is pure AIS or whether any feature triggers PIS, broader payment services, e-money, consumer-credit, or local conduct issues. This stage should map user journeys, data categories, authentication flows, revenue logic, and outsourcing dependencies. The most expensive mistake is filing as an AISP when the product already behaves like a PISP or wallet.
Choose the member state based on supervisory style, language, local substance expectations, target markets, operational footprint, and investor or banking-partner preferences. The cheapest filing venue is not always the best venue if the business later needs strong market perception or local executive depth.
Prepare the business plan, governance documents, fit and proper materials, financial model, ICT and security pack, outsourcing register, AML/CFT framework, GDPR documentation, complaints process, and PII structure. Regulators usually test consistency across these documents, not just their existence.
Submit the file to the competent authority. The first supervisory reaction is often a completeness check. If the file is internally inconsistent or missing core evidence, the review clock may not move in the way founders expect.
Expect detailed questions on consent wording, data retention, API access model, insurance coverage, outsourcing materiality, board competence, and operational resilience. Good applications answer with evidence, not general assurances. A strong response pack often includes revised diagrams, policy extracts, and tracked changes to core documents.
Authorization is not the operational finish line. The firm still needs final onboarding with relevant providers, trust-service or certificate arrangements where applicable, internal reporting, complaints workflows, and production-grade monitoring. Many firms underestimate the gap between legal approval and controlled launch.
After authorization, the firm can notify for cross-border provision of services within the EEA. Expansion should be sequenced with local-language disclosures, customer support, complaints handling, and host-state conduct review rather than treated as a pure filing exercise.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Business plan and financial model | Anchor the commercial and prudential logic of the application. | Founders / finance |
| Program of operations and customer journey map | Show exactly how the AIS service works in practice. | Product / legal |
| PII package | Evidence prudential readiness for a pure AISP model. | Finance / legal |
| ICT security and outsourcing pack | Demonstrate secure operations, resilience, and vendor oversight. | CTO / compliance |
| Governance and fit and proper files | Support the competence and integrity of the control framework. | Board / legal |
The real cost of an AISP license in Europe is not the filing fee. The real cost is the combination of regulatory preparation, insurance, local substance, governance, security remediation, and annual compliance burn. Founders who budget only for legal drafting usually discover too late that the expensive items sit in people, controls, and technology assurance.
A practical cost model separates one-off setup from recurring operating cost. Year 1 is usually heavier because it includes application assembly, policy drafting, architecture work, insurance placement, and initial control implementation. Year 2 often shifts toward recurring compliance, audit, security testing, and supervisory reporting.
The numbers below are indicative ranges only. They vary materially by jurisdiction, complexity, outsourcing model, and whether the firm is building a pure AISP or a broader roadmap that later expands into PISP, PI, or EMI activity.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Legal and regulatory preparation | EUR 20,000 | EUR 80,000+ | Usually covers perimeter analysis, application drafting, policy set, regulator Q&A support, and submission management. Complex cross-border or investor-backed structures can push the range higher. |
| Professional indemnity insurance | Jurisdiction- and risk-dependent | Jurisdiction- and risk-dependent | Premium depends on activity profile, projected volumes, claims history, geography, security posture, and policy wording. Early insurer engagement is often necessary because unsuitable wording can slow the application. |
| Local governance and key personnel | EUR 30,000 | EUR 150,000+ annually | Includes directors, compliance leadership, MLRO or equivalent financial-crime oversight where relevant, company secretarial support, and retained advisory functions. |
| ICT security and resilience uplift | EUR 15,000 | EUR 120,000+ | Often includes architecture hardening, logging, IAM, penetration testing, vendor due diligence, incident playbooks, and DORA-aligned control improvement. |
| Regulator and corporate administration fees | Jurisdiction-specific | Jurisdiction-specific | Official fees vary by country and should be checked against the target competent authority’s current schedule. |
| Audit, assurance and recurring compliance | EUR 20,000 | EUR 100,000+ annually | Includes internal control testing, external assurance, policy maintenance, training, reporting, and remediation work after supervisory findings. |
| Operational banking and vendor setup | EUR 10,000 | EUR 60,000+ | Covers corporate account setup, payment or trust-service dependencies, monitoring tools, secure communications, and onboarding with critical vendors. |
A pure AISP typically does not hold customer funds, so classic safeguarding is usually not the main prudential issue. That is a critical distinction from payment institutions and electronic money institutions. If the business model receives funds, stores value, or controls customer money flows, the firm may already be outside the pure AIS perimeter.
The practical compliance question for an AISP is therefore not “how do we safeguard funds?” but “how do we prove we never take possession or control of funds in the first place?” Regulators often test this through the customer journey, contractual wording, settlement logic, and system architecture.
| Workflow Step | Control | Owner |
|---|---|---|
| Product design review | Check whether any feature receives money, controls funds, or creates stored value. Remove or separately license those features if present. | Product / legal |
| Contract review | Ensure customer terms do not promise payment execution, money transfer, or wallet functionality under the AISP service. | Legal |
| Revenue flow review | Verify that subscription or service-fee collection does not create unintended regulated payment handling. | Finance / legal |
| Regulatory perimeter monitoring | Reassess the license perimeter whenever new checkout, pay-by-bank, reimbursement, or stored-value features are added. | Compliance / product |
The technical stack is central to an AISP license. Supervisors do not view technology as a support function here; they view it as the regulated service itself. An AISP must show how it identifies itself to ASPSPs, how it manages user consent, how it protects data in transit and at rest, how it logs access, and how it remains resilient when a bank API, cloud provider, or critical vendor fails.
In practical terms, regulators expect more than “secure infrastructure.” They want to see protocol-level and governance-level controls: API security, authentication boundaries, role-based access, encryption, audit trails, incident escalation, change management, and third-party risk oversight. In 2026, a credible AISP file should be able to explain the interaction between the user, the AISP, the ASPSP, and the supporting ICT providers without hand-waving.
A useful mental model is this: PSD2 defines the service, the EBA RTS shapes secure communication, GDPR limits what you may do with the data, and DORA tests whether your operating model can survive stress. A weak answer in any one of those layers can damage the whole application.
Two technical nuances matter in practice. First, regulators increasingly ask whether the firm can evidence data lineage from API retrieval to storage, transformation, and deletion. Second, if the firm relies on an aggregator rather than direct bank integrations, the outsourcing and dependency analysis must be far more detailed than a standard vendor list.
| Area | Control | Owner |
|---|---|---|
| Consent management | Define consent scope, duration, purpose, renewal logic, and revocation handling. Keep a verifiable audit trail showing what the user authorized and when. A practical control many firms miss is versioning of consent text so the firm can prove which disclosure the user saw at the time of authorization. | Product / legal / engineering |
| Authentication and secure communication | Support secure communication with ASPSPs through the relevant open banking and trust framework. In practice this often involves API-based access, strong identification of the TPP, transport-layer protection, and disciplined credential handling. A pure AISP should not design flows that rely on storing user credentials contrary to supervisory expectations. | CTO / security |
| API and protocol layer | Document how the platform uses standards such as OAuth 2.0, OpenID Connect, REST APIs, mutual TLS where relevant, and the applicable trust-service or certificate model. Regulators increasingly ask for sequence-level clarity, not just architecture diagrams. | Engineering / security |
| Data protection and minimization | Collect only the account data necessary for the defined service. Separate regulated service data from optional analytics or product-improvement datasets. Apply retention schedules, deletion rules, and access restrictions aligned with GDPR and the stated service purpose. | DPO / compliance / data team |
| Logging and monitoring | Maintain immutable or well-controlled logs for consent events, API calls, privileged access, configuration changes, failed access attempts, and incident escalation. A sophisticated control is correlation across application, infrastructure, and vendor logs so the firm can reconstruct a disputed access event quickly. | Security operations / engineering |
| DORA incident and resilience framework | Implement incident classification, escalation, communication, recovery, and post-incident review. The board should receive meaningful reporting on ICT incidents and concentration risk, not just raw technical alerts. | Operations / security / board |
| Outsourcing and third-party ICT risk | Keep an outsourcing register covering cloud, API aggregators, KYC tools, analytics vendors, and security providers. Assess materiality, concentration risk, subcontracting chains, exit feasibility, and contractual audit rights. Under DORA, firms should be able to explain which providers are critical and why. | Compliance / procurement / CTO |
| Secure development and change control | Run code review, vulnerability scanning, secrets management, release approval, and rollback procedures. A frequent gap in early-stage AISP files is that production access is still founder-administered without formal segregation of duties. | Engineering leadership |
An AISP authorized in one EU / EEA member state can generally passport its services across the EEA through the home-state notification process. That is one of the main strategic advantages of obtaining an AISP license in Europe. The commercial mistake is assuming that passporting means frictionless market entry. It does not.
Passporting gives a legal route to cross-border service provision, but it does not erase host-state conduct expectations. Consumer disclosures, complaint channels, marketing rules, language requirements, tax registration, and local AML touchpoints can still matter depending on the operating model. For B2C products, these issues often become visible earlier than founders expect.
One point should be explicit: a UK authorization does not provide EU passporting after Brexit. The UK can still be relevant as a separate market, but it is not an EU passporting base.
Passporting is a legal distribution mechanism, not a substitute for operational localization. The better rollout sequence is: authorize, notify, localize disclosures and support, then scale.
| Topic | Details | Risk Note |
|---|---|---|
| Home-state authorization | The passport starts with authorization from the home competent authority in an EU / EEA state. The firm then notifies for cross-border services into host states. | If the original authorization scope is too narrow or the business model later changes, the passport may not cover the expanded activity. |
| Cross-border service provision | AISP services can be offered into other EEA states after the relevant notification process. This is often used for multi-market personal finance, accounting, and lender-data products. | Commercial rollout should wait until disclosures, support, and complaint handling are adapted for the target market. |
| Host-state conduct rules | Local consumer law, unfair commercial practices rules, language expectations, and complaint-handling standards may still apply even where the license itself is passported. | Ignoring local conduct rules is a common source of post-launch friction and supervisory attention. |
| AML and financial-crime localization | The home-state AML framework remains central, but cross-border distribution can create local onboarding, sanctions, or suspicious-activity handling nuances. | A one-size-fits-all AML framework may become inadequate as the customer base diversifies across jurisdictions. |
| UK comparison | The UK remains a separate regulatory market. Firms targeting both the EU and UK should plan for parallel regulatory analysis rather than assuming mutual portability. | Treating a UK license as an EU passport or vice versa is a basic perimeter error. |
Most AISP applications are not rejected because the idea is novel. They are delayed or challenged because the regulator sees a mismatch between the claimed scope and the actual operating model. The red flags below are the ones that repeatedly trigger questions, remediation rounds, or loss of supervisory confidence.
The practical pattern is simple: if the file looks templated, if the board cannot explain the technology, or if the insurance and outsourcing model are not mature, the review slows down quickly.
Legal risk: The application is framed as pure AIS, but the product flow includes payment initiation, merchant checkout, reimbursement handling, or wallet-like functionality.
Mitigation: Run a feature-by-feature legal mapping before submission and remove or separately structure any activity outside the AISP perimeter.
Legal risk: The insurance package does not clearly cover AIS activity, contains material exclusions, or is not calibrated to the actual risk profile.
Mitigation: Engage an insurer or broker familiar with regulated payment services and test the wording against the target authority’s expectations before filing.
Legal risk: The company appears to be a shell with outsourced functions and no credible internal control over compliance, ICT, or risk decisions.
Mitigation: Appoint accountable persons, define reporting lines, evidence local management and board oversight, and document retained decision-making.
Legal risk: Policies are copied from unrelated business models and do not match the actual customer journey, data categories, or risk profile.
Mitigation: Rewrite policies around the real AIS use case, including onboarding logic, fraud indicators, data minimization, and retention.
Legal risk: The file says the platform is secure but cannot explain API security, access controls, logging, encryption, incident response, or vendor dependencies.
Mitigation: Prepare architecture diagrams, control matrices, incident procedures, and a vendor map that a regulator can actually interrogate.
Legal risk: Terms, privacy notice, customer journey, and internal processing rules define consent and data use differently.
Mitigation: Create a single source of truth for consent wording, purpose limitation, and retention, then align all customer-facing and internal documents.
Legal risk: Revenue assumptions, staffing, market entry, and control functions are not credible for a regulated cross-border data business.
Mitigation: Use conservative forecasts, phase expansion, and show how compliance, security, and customer support scale with growth.
Legal risk: The operating model depends on one aggregator, cloud provider, or technical intermediary without adequate contingency planning.
Mitigation: Assess concentration risk, contractual protections, fallback options, and exit feasibility under the outsourcing framework.
The strategic choice is not only whether you can get an AISP license. It is whether you should get one now. In 2026, some founders are better served by launching through a regulated partner, agent structure, or white-label arrangement while validating the product, insurer appetite, and supervisory narrative. Others need their own authorization early because investor diligence, enterprise sales, or cross-border control requirements make dependency on a partner unattractive.
The right answer usually depends on three variables: how differentiated your regulated data-access capability is, how much control you need over customer experience and compliance, and how quickly you expect to expand across the EEA.
| Option | Advantages | Limitations | Best For |
|---|---|---|---|
| Build your own AISP license | Direct regulatory status, stronger control over product and consent architecture, cleaner enterprise credibility, and a clearer passporting path across the EEA. | Longer time to market, higher upfront compliance and insurance cost, and ongoing supervisory burden from day one. | Founders with a durable open banking product, a serious cross-border plan, and the budget to build governance and ICT controls properly. |
| Launch through a regulated partner or white-label model | Faster market entry, lower initial licensing burden, and the ability to validate customer demand before building a full in-house compliance stack. | Reduced control over onboarding, consent wording, API dependencies, commercials, and roadmap timing. Partner contracts can also limit data use and geography. | Early-stage teams testing product-market fit or firms that need a temporary route while preparing their own future application. |
| Hybrid path: partner first, license later | Lets the business prove demand, refine the customer journey, and collect evidence for a stronger later application while avoiding immediate full authorization cost. | Migration risk is real. Moving from partner infrastructure to own authorization can require contract rewrites, customer re-consent, and architecture changes. | Teams that already expect to seek their own AISP license but want to de-risk scope, insurer discussions, and supervisory positioning first. |
These are the questions founders, compliance leads, and product teams usually ask before deciding whether to pursue an AISP license in Europe in 2026.
An AISP license authorizes a firm to provide regulated account information services under the EU payment-services framework. In practical terms, it allows the firm to access and process payment account data from one or more ASPSPs, with the user’s consent, for aggregation, analytics, dashboards, affordability checks, or similar open banking use cases.
You usually need an AISP license when your business accesses payment account data from banks or other ASPSPs as a third-party provider under the PSD2 open banking perimeter. If your product only consumes data from the customer’s own uploaded files, the analysis may differ. If it initiates payments, AISP alone is not enough.
A pure AISP is usually not framed around the same initial-capital threshold logic used for a full payment institution or EMI. The key prudential requirement is typically professional indemnity insurance or a comparable guarantee. That distinction is central and is often misstated in generic licensing summaries.
An AISP reads and processes account information. A PISP initiates a payment from the user’s bank account at the user’s request. The prudential profile also differs: for a PISP, the headline initial capital threshold is EUR 50,000, while a pure AISP usually centers on PII rather than that capital threshold.
No, not in a pure AISP model. If the business receives, holds, or controls customer funds, the model may fall into a different regulated category such as payment institution or electronic money institution, depending on the exact structure.
A practical end-to-end range is often 6-18 months. Preparation commonly takes 2-4 months, and supervisory review can take 3-12+ months depending on the jurisdiction, the completeness of the file, and how many remediation rounds are needed.
Founders often compare jurisdictions such as Lithuania, Ireland, Luxembourg, Malta, the Netherlands, France, Cyprus, and Germany. The right choice depends less on headline speed and more on supervisory style, local substance requirements, language, ecosystem fit, and the business model’s complexity.
Yes, an AISP authorized in one EU / EEA state can generally passport its services across the EEA through the home-state notification process. However, passporting does not remove host-state conduct obligations such as consumer disclosures, complaint handling, language expectations, or certain local compliance requirements.
No. After Brexit, a UK authorization does not provide EU passporting rights. Firms targeting both markets should treat the UK and EU as separate regulatory environments and plan their licensing strategy accordingly.
The main focus areas are correct scope classification, PII readiness, governance and fit and proper, ICT security, consent architecture, outsourcing control, GDPR discipline, and whether the firm has enough real substance to manage a regulated data-access business. Weakness in any of those areas can trigger delay.
The core controls usually include secure API communication, consent logging, access management, encryption, monitoring, incident response, vendor oversight, and evidence that the firm can operate under the EBA RTS and DORA-style resilience expectations. In practice, regulators also care about data lineage and deletion discipline.
That depends on timing, budget, and strategic control. A partner model can reduce time to market and help validate demand. Your own license makes more sense when regulatory status itself is part of the product moat, investor requirement, enterprise sales process, or EEA expansion strategy.
The highest-value step before any filing is a real perimeter and readiness review: service mapping, jurisdiction fit, PII feasibility, governance gaps, and ICT / outsourcing risk. That usually saves more time than trying to accelerate a weak application.
