A PISP license in Europe is the authorization used for regulated payment initiation under Directive (EU) 2015/2366 (PSD2). It is relevant for pay-by-bank checkout, account-to-account ecommerce flows, invoice payment initiation and certain embedded finance models where your company initiates a payment order from the user’s payment account held with an ASPSP bank. The core strategic question is not only where to apply, but whether your product is truly a PISP, whether you also need AISP scope, whether a broader PI license is more appropriate, and whether passporting or a partner model is the faster route.
This page is an informational legal-practical overview, not legal advice. Exact authorization scope, prudential treatment, local substance expectations, outsourcing controls, AML design and timeline depend on the business model, target markets and the national law implementing PSD2 in the chosen EU or EEA jurisdiction. UK authorization is outside the EU passporting regime after Brexit.
Core authorization thresholds, timeline reality and the practical review lens in one block.
Define whether the model is PISP-only, AISP-only, combined, or better structured as a broader PI or EMI application.
Prepare business plan, financial projections, governance file, AML framework, ICT and outsourcing documentation, shareholder pack and fit-and-proper materials.
Expect completeness checks, substantive review, clarification rounds, management interviews and remediation requests.
After authorization, cross-border expansion into other EU or EEA states usually follows a notification process, but local consumer, AML and support obligations still matter.
A PISP license in Europe covers the regulated service of initiating a payment order from the user’s payment account held with another payment service provider, usually a bank acting as the ASPSP. In practical product terms, this usually appears as a pay-by-bank or account-to-account payment flow where the customer selects their bank, authenticates with the bank through a PSD2-compatible interface, and the merchant receives confirmation that the payment has been initiated.
The perimeter question is decisive because many founders incorrectly describe any payment-related software as PISP activity. A pure technical gateway that never enters the regulated chain may fall outside the perimeter; a provider that actively initiates the payment order at the user’s request may fall inside it. The distinction is legal, operational and architectural. Regulators look at the real customer journey, the API interactions, the contractual role, the consent flow and the liability model—not only at your website wording.
A PISP authorization does not automatically let you hold client funds, issue e-money, operate a wallet, or provide every payment service listed in Annex I PSD2. If your model includes stored value, merchant settlement chains, acquiring-like features or broader execution services, the correct route may be a broader payment institution license in Europe or an electronic money license in Europe.
The most common structuring mistake is to treat PISP, AISP, PI and EMI as interchangeable labels. They are not. AISP is about access to account information; PISP is about initiating a payment order; PI is the broader category for payment institutions authorized for one or more payment services under PSD2; EMI adds the right to issue electronic money under Directive 2009/110/EC. The capital, insurance, safeguarding and operational burden can change materially depending on the chosen perimeter.
Founders should model the license around the actual product. A merchant-facing pay-by-bank button usually points toward PISP. A dashboard consolidating balances and transaction history across banks usually points toward AISP. A wallet with stored value usually points toward EMI. A broader execution business may require PI scope beyond payment initiation.
| Parameter | PI | EMI | Specialized Bank |
|---|---|---|---|
| Primary activity | Broader payment services under PSD2, potentially including execution of payment transactions depending on scope. | Issuance of electronic money plus related payment services. | Deposit-taking and wider banking activities under a banking regime, not a PSD2-only perimeter. |
| Where PISP fits | PISP authorization is typically structured within the payment institution framework, but the exact service scope matters. | An EMI may also provide payment services, but EMI status is usually unnecessary if the model is pure payment initiation without e-money. | A specialized bank route is generally disproportionate for a pure open banking payment initiation model. |
| AISP distinction | AISP is a separate regulated service focused on account information access and is not identical to PISP. | EMI status does not replace the need to assess whether account information services are separately in scope. | Bank status does not remove the need to map the exact regulated service perimeter for open banking features. |
| Client funds | Depends on service scope. A broader PI may handle payment flows, with safeguarding obligations where relevant. | Yes, in the context of issued e-money and related payment services, subject to safeguarding. | Client money and deposits are handled under banking rules, not PSD2-only logic. |
| Initial capital reference points | Common PSD2 thresholds discussed in Europe are €20,000 / €50,000 / €125,000 depending on the payment services provided. | €350,000 initial capital under the e-money regime. | Bank capital expectations are materially higher and outside the normal fintech PISP entry route. |
| Insurance angle | For AISP and, where applicable, PISP-related services, regulators also focus on professional indemnity insurance or comparable guarantee. | Insurance may still be relevant operationally, but EMI prudential logic is not reduced to the AISP/PISP PII question. | Banking supervision focuses on a broader prudential framework. |
| Best fit product examples | Pay-by-bank checkout, payment execution models, merchant settlement services depending on design. | Wallets, stored-value products, prepaid structures, e-money-backed payment ecosystems. | Full banking proposition with lending, deposits and broader regulated activities. |
A PISP license in Europe sits inside a layered regulatory stack. The base layer is Directive (EU) 2015/2366 on payment services, usually referred to as PSD2. The technical layer is Commission Delegated Regulation (EU) 2018/389, the RTS on strong customer authentication and common and secure communication. The data layer is GDPR — Regulation (EU) 2016/679. The operational resilience layer in the 2026 environment is DORA — Regulation (EU) 2022/2554. On top of that sits national law implementing PSD2 and national supervisory practice.
This matters because a PISP application is not judged only on corporate documents. Regulators assess whether the business model fits the PSD2 perimeter, whether the authentication and communication flows are compliant, whether customer data is processed lawfully, whether outsourcing and cloud dependencies are controlled, and whether the firm can withstand incidents without losing control over critical services.
A practical nuance many pages omit is that open banking compliance is partly legal text and partly supervisory expectation. The European Banking Authority, national competent authorities, and market infrastructure around eIDAS trust services shape how PISPs actually operate. In real applications, the weakest point is often not the legal memo but the mismatch between the legal description and the product architecture.
The strongest applications link each legal layer to a concrete control owner. For example, PSD2 defines the service, RTS defines secure communication and SCA expectations, GDPR defines data governance, and DORA defines ICT resilience and third-party oversight. Regulators increasingly reject siloed documentation where legal, product and engineering narratives do not match.
| Framework | Why It Matters | Operational Impact |
|---|---|---|
| PSD2 — Directive (EU) 2015/2366 | Defines payment services, authorization perimeter, passporting logic, prudential concepts and the legal basis for PISPs and AISPs. Annex I service mapping is the first licensing step. | You need a defensible service classification, a compliant operating model, governance, AML controls and ongoing prudential monitoring. |
| RTS on SCA and secure communication — Delegated Regulation (EU) 2018/389 | Sets the technical-regulatory expectations for strong customer authentication, secure communication and elements such as dynamic linking. | Your bank connectivity, authentication journey, consent evidence, API controls and audit trails must align with regulated payment initiation flows. |
| GDPR — Regulation (EU) 2016/679 | Open banking models process personal data, transaction data and account-related identifiers. Lawful basis, data minimization, retention and data subject rights are not optional. | You need data mapping, retention controls, role-based access, processor governance and product-level privacy design. |
| DORA — Regulation (EU) 2022/2554 | PISPs are part of the financial sector ICT risk environment and are expected to maintain stronger resilience, incident handling and third-party risk governance. | Expect scrutiny on ICT governance, incident classification, testing, outsourcing registers, concentration risk and critical supplier oversight. |
| National PSD2 implementation laws and regulator practice | PSD2 is harmonized at EU level, but authorization mechanics, supervisory intensity, substance expectations and procedural style differ by jurisdiction. | Jurisdiction selection affects timeline, local staffing, language, application quality threshold and post-license supervisory burden. |
| AML/CFT laws and guidance | Payment institutions remain high-focus entities for customer due diligence, sanctions controls, suspicious activity escalation and governance around MLRO responsibilities. | You need a risk-based AML framework linked to product flows, customer types, geographies, fraud patterns and outsourcing arrangements. |
A PISP application succeeds when the regulator sees a controlled institution, not just a promising fintech product. The core requirement set usually covers ownership transparency, fit-and-proper management, governance design, compliance and AML capability, ICT security, outsourcing oversight, financial planning, internal controls and evidence of real operational substance in the chosen jurisdiction. The exact threshold varies by country, but the direction of travel across Europe is consistent: nominal directors, template policies and outsourced-everything models are viewed skeptically.
Governance is usually assessed through the lens of competence, independence and accountability. Regulators expect directors and key function holders who understand payment services, operational risk, AML/CFT and the actual technology stack. A recurring weakness in applications is the absence of a credible second line of defense. If the same small team writes the policies, runs the product, approves outsourcing, monitors incidents and signs off AML exceptions, the governance model will look fragile.
Substance also matters more than many founders expect. Even in relatively fintech-friendly jurisdictions, regulators increasingly ask where decisions are made, where records are kept, who owns the customer relationship, who manages incidents, and whether outsourced providers can be challenged in practice. A local registered office alone is not substance.
A useful practical test is this: if a regulator asks who can stop a risky product launch, who owns the AML risk appetite, who can challenge the cloud provider, and who signs the incident report, the application should produce named roles and documentary evidence within minutes.
| Area | Regulatory Expectation | Evidence Pack |
|---|---|---|
| Shareholders and beneficial owners | Transparent ownership chain, source-of-funds clarity and no unresolved integrity concerns. Qualifying holdings are typically examined in detail. | Corporate structure chart, UBO declarations, source-of-funds documents, group governance explanation and shareholder questionnaires. |
| Board and senior management | Fit-and-proper directors with relevant experience in payments, compliance, risk, finance and technology. Regulators expect real decision-makers, not placeholders. | CVs, criminal record extracts where required, reference materials, role descriptions, time commitment analysis and interview readiness. |
| Three lines of defence | A workable separation between business ownership, control functions and independent assurance, proportionate to the size of the institution. | Governance map, committee structure, reporting lines, conflict management policy and internal control matrix. |
| AML/CFT framework | Risk-based customer due diligence, sanctions screening, transaction monitoring, suspicious activity escalation, training and independent review. | AML manual, business-wide risk assessment, customer risk scoring, sanctions workflow, escalation log design and MLRO appointment. |
| ICT security and API environment | Secure architecture, access controls, encryption, logging, incident response, change management and resilience around open banking connectivity. | Security policy, network and application architecture, IAM model, incident response plan, vulnerability management and logging standards. |
| Outsourcing and cloud governance | Critical providers must be identified, contractually controlled and monitored. Outsourcing does not transfer accountability to the vendor. | Outsourcing register, materiality assessment, due diligence files, SLA/KPI framework, exit planning and concentration risk analysis. |
| Financial resources and prudential planning | Founders must evidence sufficient capital, funding runway and a realistic view of ongoing own funds and compliance cost. | Initial capital evidence, 3-year financial projections, prudential model, stress assumptions and liquidity planning. |
| Local substance | The regulator wants to see where the institution is genuinely managed and supervised. Expectations vary, but real local presence is increasingly important. | Office arrangements, local staffing or function allocation, board calendar, recordkeeping location and operational responsibility map. |
A PISP application pack is a regulated operating model translated into documents. The strongest packs are internally consistent: the business plan matches the financial model, the AML framework matches the customer journey, the ICT documents match the real architecture, and the outsourcing register matches the vendor stack. Most delays come from contradictions between these documents, not from missing prose.
National competent authorities publish their own forms and checklists, but the following categories appear repeatedly across EU and EEA applications for payment institution and open banking-related authorizations.
| Document | Purpose | Owner |
|---|---|---|
| Regulatory scope memorandum | Explains why the business model falls within PISP scope, whether AISP scope is also needed, and why PI or EMI perimeter is or is not applicable. | External counsel with founders and product lead |
| Business plan and target operating model | Describes services, customer segments, transaction flows, revenue model, outsourcing structure, target markets and control ownership. | Founders and strategy lead |
| Financial projections | Shows revenue assumptions, cost base, headcount, capital runway, prudential planning and stress scenarios over a multi-year horizon. | Finance lead |
| Program of operations | Maps the exact regulated services, payment flows, customer journey and operational steps from onboarding to incident handling. | Operations lead |
| AML/CFT manual and business-wide risk assessment | Documents customer due diligence, EDD, sanctions screening, monitoring, escalation, reporting and training controls. | MLRO / compliance |
| Governance and internal control framework | Defines board structure, committees, reporting lines, conflicts management, three lines of defence and control responsibilities. | Board secretary / compliance |
| Fit-and-proper file for managers and key function holders | Supports suitability assessment of directors, senior managers, MLRO, compliance and other controlled roles. | HR / legal |
| ICT security documentation | Explains architecture, IAM, encryption, logging, vulnerability management, change control, BCP/DR and incident response. | CTO / CISO |
| Outsourcing policy and outsourcing register | Identifies critical providers, materiality, due diligence, oversight, SLAs, audit rights and exit arrangements. | Operations / legal / procurement |
| Data protection documentation | Maps personal data processing, lawful basis, retention, processor oversight and data subject rights handling. | DPO / privacy counsel |
| Shareholder and UBO documentation | Supports ownership transparency, qualifying holdings review and source-of-funds analysis. | Corporate legal |
| Evidence of capital and insurance arrangements | Shows initial capital funding and, where applicable, professional indemnity insurance or comparable guarantee planning. | Finance / legal / broker |
A PISP license in Europe is usually won or lost before submission. The decisive work happens in scoping, jurisdiction selection, control design and document consistency. Once the application is filed, the regulator will test completeness, challenge assumptions, review governance, scrutinize outsourcing and often ask management to explain the model in plain language. A realistic plan assumes preparation first, review second, and only then passporting and launch.
Classify the product against PSD2 services and determine whether the model is PISP-only, AISP-only, combined PISP/AISP, broader PI, or EMI. This stage should also identify whether the firm ever touches client funds, whether merchant settlement creates a broader payment service, and whether the technical role is truly regulated or merely ancillary.
Compare jurisdictions by regulator style, local substance expectations, language, banking ecosystem, hiring feasibility, cost of compliance, and practical launch goals. Lithuania, Ireland, France, Luxembourg, Malta, the Netherlands and Germany are often considered, but there is no universally 'best' country.
Define governance, AML ownership, ICT controls, outsourcing model, incident workflow, customer support model and evidence retention. This is where product, legal and engineering must align. A mismatch here creates months of Q&A later.
Draft the business plan, program of operations, financial model, AML manual, governance documents, fit-and-proper files, ICT and outsourcing documents, shareholder pack and capital evidence. Most authorities expect a coherent pack, not isolated attachments.
The authority checks whether the file is sufficiently complete to enter substantive review. Incomplete or inconsistent packs can stall at this stage.
Expect questions on service perimeter, financial assumptions, outsourcing, local substance, management competence, AML calibration, security controls and launch sequencing. In practice, 2–5 rounds of questions are common in complex applications.
Authorization is only the start. Before launch, firms usually need final operational readiness checks, banking and insurance arrangements, internal reporting setup and, where relevant, passporting notifications for other EU or EEA markets.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Business plan | Explains the commercial model, customer segments, services, markets and operating assumptions. | Founders |
| Financial projections | Supports capital adequacy, runway and ongoing prudential planning. | Finance |
| AML/CFT framework | Shows how the institution will identify, monitor and escalate financial crime risk. | MLRO / compliance |
| ICT and security pack | Demonstrates secure communication, access control, resilience and incident management capability. | CTO / security lead |
| Governance and fit-and-proper file | Supports the suitability of the management body and control framework. | Legal / HR |
The real cost of a PISP license in Europe is not the filing fee. Founders need to budget for legal scoping, application drafting, local substance, governance build-out, AML design, ICT remediation, insurance, audit and ongoing compliance operations. The total project cost varies materially by jurisdiction and complexity, so the correct way to budget is by cost bucket rather than by a single headline number.
For planning purposes, it is useful to separate one-off authorization costs from recurring post-license costs. A lean PISP with narrow scope and strong internal readiness will spend differently from a multi-market open banking platform with combined PISP/AISP functionality and a heavy vendor stack.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Legal scoping and application drafting | Project-specific | Project-specific | Usually includes perimeter analysis, jurisdiction comparison, application drafting support and regulator response coordination. |
| Corporate setup and local substance | Project-specific | Project-specific | Includes incorporation, registered office, local directors or staff where needed, governance support and administrative setup. |
| AML/CFT framework build | Project-specific | Project-specific | Covers business-wide risk assessment, AML manual, sanctions workflow, monitoring design and MLRO support. |
| ICT security and architecture remediation | Project-specific | Project-specific | Often underestimated. May include IAM hardening, logging, incident response, vendor due diligence, API security and evidence generation. |
| Insurance and prudential setup | Project-specific | Project-specific | May include professional indemnity insurance or comparable guarantee planning and capital structuring. |
| Banking and operational onboarding | Project-specific | Project-specific | Includes operational accounts, vendor onboarding, trust-service dependencies and launch readiness. |
| Post-license recurring compliance | Project-specific | Project-specific | Includes compliance staff, MLRO, reporting, training, audits, DORA-related ICT governance and ongoing legal support. |
A pure PISP model is often attractive because it usually does not rely on holding client funds. That said, founders should not assume safeguarding is irrelevant without mapping the actual money flow. The key question is whether the institution ever receives or holds funds in a way that triggers safeguarding obligations under the broader payment institution framework. If the model remains pure payment initiation, the safeguarding burden may be limited compared with broader PI or EMI structures.
The practical trap is product drift. A company starts as a pay-by-bank initiator, then adds merchant settlement timing, reconciliation balances, reserve handling or stored-value features. At that point, the original perimeter analysis may no longer hold. Regulators look at the real operational chain, not the original pitch deck.
| Workflow Step | Control | Owner |
|---|---|---|
| Customer initiates payment | Confirm whether the institution only transmits initiation instructions or also receives funds or settlement value at any point. | Product and legal |
| Merchant confirmation | Define whether confirmation is informational only or linked to a broader settlement service. | Operations |
| Product change request | Run a perimeter review before adding balances, reserves, delayed settlement or wallet-like features. | Compliance and product governance |
| Ongoing monitoring | Review actual operational flows against documented flows to detect unauthorized perimeter expansion. | Risk and internal control |
A PISP is a regulated technology business. In 2026, regulators expect more than a generic information security policy. They want to see how your institution authenticates to bank interfaces, manages certificates, protects API sessions, records consent evidence, controls privileged access, classifies incidents, oversees cloud and connectivity providers, and restores critical services after disruption. This is where PSD2, the RTS on SCA, DORA and EBA outsourcing expectations meet in practice.
The strongest applications explain the real technical stack. They identify whether the firm uses direct bank integrations or an aggregator, how mutual TLS is handled, how eIDAS trust services fit into the model, how consent and session events are timestamped, how fraud signals are escalated, and how critical vendors are monitored. A common weak point is that the architecture diagram shows one reality while the outsourcing register shows another.
A technical nuance often missed in licensing projects is that fallback risk is not only a bank-side issue. Even where an ASPSP has a dedicated interface and any exemption logic applies on its side, the PISP still needs internal contingency design for degraded bank connectivity, certificate failure, message reconciliation and customer communication.
| Area | Control | Owner |
|---|---|---|
| API access and secure communication | Document how the firm connects to ASPSP interfaces, including secure transport, certificate lifecycle, request integrity and evidence of authorized access. Market practice often involves REST APIs, OAuth-style patterns, OpenID Connect elements and mTLS, but implementation varies by bank and market. | CTO / security architecture |
| eIDAS trust services | Plan the use and lifecycle management of relevant certificates such as QWAC and QSealC where required in the open banking environment. Certificate expiry, rotation and incident fallback should be governed, not improvised. | Security operations |
| SCA and customer journey | Map redirection, decoupled or app-based authentication flows and show how the institution handles initiation requests, status updates, dynamic linking dependencies and failure states. | Product / engineering / compliance |
| Consent management and audit logs | Maintain evidence of customer request, timestamps, consent parameters, revocation events, re-authentication triggers and key API actions. Logs should be tamper-resistant and usable in complaints, fraud review and supervisory inquiries. | Product operations / security |
| Identity and access management | Restrict privileged access, enforce role-based access control, MFA for internal users, joiner-mover-leaver controls and periodic access reviews. | IT / security |
| Encryption and key management | Protect data in transit and at rest, manage secrets securely and separate duties around key access. Regulators increasingly ask how cryptographic material is governed in cloud environments. | Security engineering |
| Incident response and DORA readiness | Define incident classification, escalation, communication lines, forensic preservation, recovery playbooks and management reporting. Link severe incidents to regulatory reporting triggers where applicable. | CISO / operations / compliance |
| Business continuity and disaster recovery | Set recovery objectives proportionate to critical services, test failover assumptions and document dependencies on cloud, API gateways, telecoms and trust-service providers. | Operations resilience lead |
| Outsourcing and third-party risk | Maintain an outsourcing register, classify critical providers, assess concentration risk, negotiate audit rights and define exit or substitution strategies. | Vendor management / legal / risk |
An authorized PISP in one EU or EEA jurisdiction can usually expand cross-border through passporting, either by providing services on a freedom-to-provide-services basis or through a branch. This is one of the main strategic advantages of obtaining a PISP license in Europe. It allows one authorization to support multi-market growth without a full relicensing exercise in every target country.
But passporting is not a free pass. The home-state authorization does not eliminate local consumer law, complaints handling expectations, marketing rules, language requirements, AML nuances, tax touchpoints or operational support obligations in the host state. In practice, successful expansion depends as much on localization and compliance operations as on the passport notification itself.
A practical expansion sequence is often: authorize in the home state, stabilize operations, complete first supervisory reporting cycle, then passport into priority markets with localized customer support, complaints handling and fraud monitoring calibrated before scale-up.
| Topic | Details | Risk Note |
|---|---|---|
| Freedom to provide services vs branch | Freedom to provide services is usually lighter from an establishment perspective and is often used for digital-first expansion. A branch may be appropriate where the business needs deeper local presence, staff or support infrastructure. | Choosing the lighter route while operating as if you have a de facto local establishment can create supervisory friction. |
| Notification mechanics | Passporting generally follows a notification process after authorization through the home regulator. Timing is usually shorter than the original licensing process, but it is still procedural and should be planned before launch commitments are made. | Commercial launch dates should not be fixed before the notification pathway and local operational readiness are confirmed. |
| Local consumer and disclosure rules | Even with passporting, firms often need localized terms, complaints channels, customer communications and disclosure formats adapted to the target market. | A single English-only support model can be commercially and sometimes regulatorily weak in retail-facing markets. |
| AML and fraud operations | The home-state AML framework remains central, but local risk factors, sanctions exposure, fraud typologies and escalation expectations may differ by market. | Cross-border growth without recalibrating transaction monitoring and fraud rules is a common control failure. |
| Agent and partner structures | Expansion may also involve agents, distributors or technical partners. These relationships need clear regulatory mapping and oversight. | Poorly documented partner roles can blur the perimeter and create unauthorized activity risk. |
| UK boundary | The UK is not part of the EU passporting regime after Brexit. A UK-authorized firm cannot rely on EU passporting rights, and an EU-authorized firm must assess the UK regime separately. | Marketing a UK authorization as if it gives EU passporting rights is a red flag. |
The most common reason a PISP application fails is not that the product is impossible. It is that the application describes a business the regulator does not believe can be controlled. Weak scope analysis, nominal governance, unrealistic financials, shallow AML design and generic ICT policies are the recurring failure points. Regulators can usually spot a template application quickly because the documents do not reflect the real transaction flow or vendor stack.
The best way to reduce rejection risk is to treat the application as an operating model audit before the regulator performs one. Every key statement in the pack should be traceable to a real owner, a real control and a real system or process.
Legal risk: Wrong perimeter analysis can lead to the wrong license strategy, prudential miscalculation and loss of regulator confidence.
Mitigation: Prepare a detailed legal scope memo, transaction flow maps and product boundary analysis before drafting the application.
Legal risk: The regulator may conclude the firm is undercapitalized, operationally unrealistic or not prudentially prepared.
Mitigation: Link headcount, compliance spend, fraud tooling, vendor cost and own funds planning to realistic volume scenarios.
Legal risk: Fit-and-proper concerns can delay or derail authorization.
Mitigation: Strengthen the board and key function holders early, define role clarity and prepare management for interviews.
Legal risk: Template policies suggest weak operational readiness and poor understanding of the risk profile.
Mitigation: Build an AML framework around actual customer types, geographies, transaction patterns, fraud vectors and escalation logic.
Legal risk: Contradictions between architecture, security policy and outsourcing register undermine the entire application.
Mitigation: Run a technical-document consistency review involving legal, compliance, engineering and vendor management.
Legal risk: Insufficient substance can trigger concerns about effective supervision and governance.
Mitigation: Document where decisions are made, who owns local functions and how the institution is managed in practice.
Legal risk: Loss of momentum can materially extend the timeline and reduce trust in management capability.
Mitigation: Create a controlled Q&A process with named owners, version control and one source of truth for the application narrative.
Not every pay-by-bank or open banking business should obtain its own PISP license in Europe. The correct choice depends on speed to market, strategic control, margin retention, product roadmap, geography and compliance maturity. In early-stage or narrowly scoped products, partnering with a licensed PI, EMI or open banking provider can be commercially smarter than building a regulated institution from day one. In scale-stage products, direct authorization can become rational because it improves control over economics, data flows, market access and regulatory dependency.
The honest strategic question is whether regulation is your moat or your bottleneck. If your value lies mainly in distribution, UX or merchant acquisition, a partner model may be enough. If your value lies in owning the payment flow, expanding across multiple EU markets, controlling compliance architecture and reducing dependency on third parties, licensing becomes more attractive.
| Option | Advantages | Limitations | Best For |
|---|---|---|---|
| Obtain your own PISP authorization | Direct regulatory status, stronger control over product roadmap, cleaner passporting strategy, better long-term margin control and less dependency on a sponsor’s commercial priorities. | Longer time to market, higher upfront cost, governance burden, ongoing prudential and compliance obligations, and heavier ICT and supervisory accountability. | Founders with a clear multi-market roadmap, strong funding, mature product architecture and willingness to build a real regulated institution. |
| Partner with a licensed PI, EMI or open banking provider | Faster launch, lower initial regulatory burden, easier testing of product-market fit and reduced need to build a full compliance stack immediately. | Lower control over economics, dependency on partner onboarding and risk appetite, contractual restrictions, possible data or UX limitations and weaker strategic autonomy. | Early-stage teams, single-market launches, pilots, and products still validating demand or refining the regulatory perimeter. |
| Hybrid path: partner first, license later | Combines speed with a future path to independence. Lets the team collect transaction data, refine controls and validate the business case before licensing. | Migration risk, contract renegotiation, dual architecture periods and the need to redesign controls for direct authorization later. | Growth-stage teams that expect to become regulated but want to delay the full burden until volumes and funding justify it. |
These are the questions founders, CFOs, product teams and investors usually ask when evaluating a PISP license in Europe.
A realistic range is usually 6–16 weeks for preparation and 3–12+ months for regulator review, depending on jurisdiction, application quality, business complexity and the number of Q&A rounds. Any promise of a guaranteed short timeline should be treated cautiously.
A pure PISP model is generally about initiating a payment order, not holding client funds. If the business starts receiving, controlling or storing funds in a way that changes the payment flow, the safeguarding analysis and possibly the license perimeter may change.
If your product accesses and consolidates account information, AISP scope may be required even if you already provide payment initiation. The correct answer depends on the real functionality, data flows and customer permissions. Many open banking products need a combined perimeter analysis.
A PISP initiates payments from a user’s bank account held elsewhere. An EMI issues electronic money and can provide related payment services. If your product is a wallet or stored-value model, EMI analysis is usually required; if it is pure pay-by-bank initiation, EMI may be unnecessary.
For payment institutions, common PSD2 initial capital thresholds discussed in Europe are €20,000 / €50,000 / €125,000 depending on service scope. For EMIs, the reference point is €350,000. Founders should also model ongoing own funds and, where relevant, professional indemnity insurance or comparable guarantee.
No. After Brexit, UK authorization does not provide EU passporting rights. A UK firm must assess the EU regime separately, and an EU-authorized firm must assess the UK regime separately.
Commonly considered jurisdictions include Lithuania, Ireland, France, Luxembourg, Malta, the Netherlands and Germany. The right choice depends on regulator style, local substance, language, cost, banking access, launch strategy and the maturity of your management team.
The exact checklist depends on the authority, but applications usually require a business plan, program of operations, financial projections, governance documents, fit-and-proper materials, AML/CFT framework, ICT security documentation, outsourcing register, shareholder pack and capital evidence.
Check the legal entity in the official register of the national competent authority and cross-check the authorization scope and passporting status in the EBA Register where relevant. Red flags include vague claims like 'licensed in Europe' without a legal entity name, authorization number or scope description.
The decisive first step is not filing documents. It is confirming the correct regulatory perimeter, the right jurisdiction and whether direct licensing is commercially superior to a partner model. If needed, the next practical layer is building a regulator-ready application pack that aligns legal analysis, product flow, AML design and ICT architecture.
