For an early-stage digital-asset founder, the gap between a working product and a working business often comes down to one thing: access to regulated payment rails. Without the right payment institution authorisation, a crypto business cannot hold client funds, cannot settle fiat in and out, and cannot open the institutional banking relationships that underpin scale. Operating without that authorisation – or operating on rails that do not cover the jurisdictions where your users actually sit – exposes the business to enforcement action, account termination and the kind of regulatory scrutiny that halts a fundraise.
Payment institution licensing (the authorisation that permits a legal entity to provide payment services, hold client e-money and access settlement infrastructure) is the foundational instrument for any digital-asset business that touches fiat. The applicable regime varies by jurisdiction – the Payment Services Directive transposition in EU member states, the Electronic Money Institution (EMI) regime under MiCA-adjacent frameworks, the FCA's e-money authorisation in the UK, and equivalent regimes across Singapore, Hong Kong and the Gulf hubs – but the core obligation is the same: if you move client money, you need authorisation before you do it.
This page sets out the regulated basis for payment institution licensing, the practical application process, the common structural mistakes that early-stage founders make, and the cross-border interaction between a payment licence and a VASP authorisation. A decision matrix by operator profile and a micro-matter close the analysis.
Why does payment institution licensing matter for a crypto founder specifically?
A digital-asset business that operates a fiat on-ramp, a custodial wallet with fiat settlement, or a crypto-to-crypto exchange with EUR/USD withdrawal is providing payment services. Full stop. The label on the product – "wallet", "treasury tool", "DeFi gateway" – does not change the regulatory characterisation. Regulators across the EU, the UK, Singapore and the UAE consistently apply the substance-over-label principle: if the economic reality is that your entity holds or moves client fiat, you need a payment licence or an EMI authorisation.
The consequences of getting this wrong are immediate. Banks apply enhanced due diligence to any entity that moves money without authorisation. In our practice, we regularly see early-stage founders who built a compliant VASP structure but omitted the payment layer – and whose banking accounts were closed within months of launch, because the bank's compliance team identified unlicensed payment activity in the transaction flow. That closure cascades: it pauses settlement, it triggers user complaints, and it creates a regulatory referral risk that follows the entity.
The risk is not only enforcement. It is also the loss of the institutional counterparties – banking partners, payment processors and liquidity providers – whose commercial onboarding terms typically require a live payment authorisation before they will sign. For a founder raising a Series A, demonstrating a cleared payment licence is increasingly a prerequisite, not a differentiator.
To map your specific payment authorisation needs before you sign a banking term sheet, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity's jurisdiction, the user base, the fiat currencies involved – change the analysis materially.
Which regulatory regime applies to your payment institution?
The applicable payment services regime turns on where your legal entity is incorporated, where your users are located, and the specific services you intend to provide. There is no single global payment licence. Each major hub has its own authorisation framework, and operating across hubs means holding – or passporting – authorisations in each relevant jurisdiction.
In the European Union, the Payment Services Directive (transposed into national law by each member state) and the e-money regime (now converging under MiCA-adjacent supervisory practice) govern payment institutions and EMIs respectively. A CASP (crypto-asset service provider) authorisation under MiCA does not itself confer payment institution status: a VASP that also provides fiat settlement services requires a separate payment institution or EMI authorisation from the relevant national competent authority. Passporting then allows that authorisation to cover the wider EU/EEA, but passporting is a notification process, not automatic – and regulators in the host state have the power to restrict it.
In the United Kingdom, the FCA administers the e-money and payment institution authorisation regime under the transposed Payment Services Regulations. The FCA's registration process for cryptoasset businesses under the Money Laundering Regulations is a distinct track from an e-money authorisation; founders routinely confuse the two, and the error is costly in time.
In Singapore, the Monetary Authority of Singapore (MAS) licences payment service providers under the Payment Services Act across three tiers – money-changing, standard payment institution and major payment institution – with different capital and safeguarding thresholds applying to each. A Digital Payment Token (DPT) licence covers crypto-to-crypto exchange; a separate e-money or account issuance licence covers fiat holding and issuance. In Hong Kong, the SFC's VASP licensing regime for virtual-asset trading platforms does not extend to fiat settlement, which requires engagement with the HKMA's payment institution framework.
In the UAE, VARA (the Virtual Assets Regulatory Authority in Dubai) governs the crypto-specific activity, while fiat payment services for entities not in a financial free zone fall under the Central Bank of the UAE. ADGM's FSRA has its own payment services authorisation track for entities in the Abu Dhabi financial free zone. The interaction between these regimes is a common source of structural error among Gulf-based founders.
What does the payment institution application process actually involve?
A payment institution application is a governance, documentation and policy exercise before it is a legal one. Regulators across the leading hubs assess the same core elements: legal entity structure, ownership and control, governance and management fitness, business model review, AML/CFT policies and the client-money safeguarding arrangement. Getting the documentation package right before submission is the single most important factor in timeline.
The process moves through broadly consistent phases. First, the entity is incorporated or confirmed in the target jurisdiction – this is where many founders make their first error, trying to retrofit a payment application onto an entity whose ownership structure or beneficial ownership disclosure does not meet the regulator's standards. Second, the governing documents – the business plan, the risk framework, the AML/KYC policies, the IT security summary and the safeguarding plan – are prepared to the regulator's template. Third, the application is submitted with the required fees and supporting evidence. Fourth, the regulator enters a review period, during which it will typically issue a list of follow-up questions; the quality of the responses to those questions determines whether the application proceeds or stalls.
Timelines vary. Regulators with well-resourced payment licensing teams – including certain EU member states that have historically been efficient entry points – have processed straightforward applications in a matter of months. More complex applications, or applications at regulators with a large queue, can extend considerably. We advise founders to build a realistic runway into their financial model: the payment licence should be in hand before the product goes live, not applied for after launch.
The Travel Rule (the obligation under FATF Recommendation 15 to pass originator and beneficiary data with a transfer) applies to VASPs and, in overlapping form, to payment institutions in most major hubs. The application package for a combined VASP/payment institution should demonstrate that the Travel Rule compliance solution covers both the crypto and fiat legs of the transaction flow.
What are the most common payment licensing mistakes early-stage founders make?
In a recent advisory matter, a fintech startup had structured its EU entity purely as a VASP under its home-state transposition of the prior VASP directive, then launched a fiat wallet feature without a payment institution authorisation. When the startup's bank reviewed the transaction profile eighteen months later, it identified unlicensed e-money issuance and suspended the account. We advised the founder on the parallel application process, the interim operational structure and the disclosure posture with the bank – and the account was reinstated while the payment authorisation was in process. The delay cost several months of business development and a material legal spend. The lesson: the payment and VASP layers are separate; plan them together from the start.
The most frequent structural errors we see in early-stage payment licensing work fall into a consistent pattern. First: single-jurisdiction thinking. A founder incorporates in one EU state, obtains a payment institution authorisation, and assumes passporting will cover operations across the bloc without further process. Passporting requires active notification, host-state acceptance and – in some cases – a local physical presence or agent arrangement. Second: the banking-partner gap. A payment licence does not guarantee that a bank will onboard the entity. Banks impose their own enhanced due diligence requirements on payment institutions, particularly those serving crypto clients; the licence is a necessary condition, not a sufficient one. Third: the safeguarding misfire. Payment institutions and EMIs are required to hold client funds in safeguarded accounts, segregated from the entity's own money, with a qualifying credit institution. Early-stage founders often underestimate how difficult it is to open a qualifying safeguarding account, and how long the bank's own onboarding process takes.
A fourth error, specific to the crypto context, is the assumption that a VASP authorisation covers the fiat settlement leg of a crypto transaction. It does not. VARA in Dubai, the SFC in Hong Kong and ESMA-supervised NCAs in the EU have each confirmed – in their respective supervisory communications – that VASP and payment institution status are distinct. Running fiat through an entity that holds only a VASP licence is unlicensed payment activity.
If a prior application stalled, an account was closed, or you are rebuilding a payment structure after regulatory contact, a second read can surface the structural reason and the route forward. Write to OBOLUS at info@oboluslaw.com.
How does a payment licence interact with a VASP authorisation across jurisdictions?
The cross-border interaction between a payment institution authorisation and a VASP licence is where most multi-jurisdictional digital-asset businesses encounter their most complex structuring decisions. A business that operates an exchange in one jurisdiction, a custody entity in a second and a payment settlement entity in a third needs to map the regulatory perimeter in all three, and then confirm that the intercompany flows between those entities do not themselves constitute unlicensed activity in any jurisdiction.
In the EU, the combination of a CASP authorisation under MiCA and an EMI authorisation under the e-money regime in the same entity is permissible in some member states and restricted in others; the applicable rule varies by national implementation. Some operators prefer a group structure: a MiCA CASP for the crypto activity and a separate EMI entity for the fiat rails, with an intercompany service agreement governing the settlement flow. This structure has the advantage of regulatory clarity but the disadvantage of complexity in the safeguarding and capital allocation between entities.
In Singapore, MAS has published guidance on the combination of DPT service licences with e-money or account issuance licences under the Payment Services Act; the thresholds for major payment institution status are set at a level that catches most exchange-scale operators. Operators we advise routinely find that their projected transaction volumes push them into the major payment institution tier, with correspondingly higher capital and reporting obligations, well before they anticipate it in their financial models.
Banking is the central practical constraint in cross-border payment licensing. A payment institution or EMI in a smaller EU jurisdiction may find that the banks willing to provide safeguarding accounts in that jurisdiction are limited, and that the correspondent banking routes available to those banks do not cover all the currencies the business needs. In our practice, we regularly see founders who obtained the licence efficiently but then spent as long again finding a qualifying safeguarding bank – and whose correspondent banking limitations effectively constrained the geographic reach of their business more than the licence itself did.
For Gulf-based operators, the interaction between VARA's crypto licensing regime, the UAE Central Bank's payment services framework and the ADGM/FSRA's separate track for Abu Dhabi entities creates a three-way analysis that turns on where the entity sits, where the clients are and where the fiat settlement happens. A business that sits in a VARA-regulated free zone but processes payments for UAE-resident retail users through a UAE-incorporated entity may find that the Central Bank's payment services regime applies to the UAE entity regardless of the VARA free zone status of the holding company.
Which payment institution structure fits your operator profile?
The right payment authorisation structure depends on the operator's profile, the intended user base and the fiat currencies to be supported. The following matrix describes the most common configurations in qualitative terms; the right choice for a specific business requires analysis of the actual facts.
Profile A – EU-focused early-stage exchange, fewer than five fiat currencies, EU/EEA user base. This operator typically targets a single EU member state EMI or payment institution authorisation with passporting across the EEA. The critical decisions are the choice of home-state regulator (which affects timeline, cost and the availability of qualifying safeguarding banks) and the governance structure of the entity. The key risk is underestimating passporting process time and launching into host states before the notification is confirmed.
Profile B – VASP with a global user base and USD/EUR/GBP settlement needs. This operator typically requires a multi-entity group structure: a MiCA CASP or EU EMI for the EUR leg, an FCA-registered entity or e-money authorisation for the GBP leg, and either a US money transmitter licence stack or a Singapore MAS Payment Services Act authorisation for the USD/SGD leg. Consolidating all of this into a single entity is generally not practical; the group structure is the norm. The key risk is intercompany transfer pricing and the regulatory treatment of intercompany settlement flows under each applicable regime.
Profile C – Gulf-based operator, USDT/AED settlement, VARA-regulated exchange. This operator requires a VARA activity licence for the crypto services and a separate UAE Central Bank payment institution authorisation or an ADGM FSRA licence for the fiat settlement, depending on the entity structure. The interaction between VARA's rulebooks and the Central Bank's payment services framework is an evolving area; we advise founders in this profile to seek a formal pre-application meeting with both regulators before committing to a structure.
Profile D – Asia-Pacific operator, Singapore or Hong Kong base, crypto and fiat. This operator typically targets a MAS Payment Services Act licence (DPT service plus account issuance or e-money service) in Singapore, or an SFC VATP licence combined with an HKMA payment institution authorisation in Hong Kong. MAS has been active in supervising the transition of registered DPT entities to full licensee status; the timeline for full licence grant has extended for many operators. The key risk is the gap between registration and full licence grant, during which the operator's activities may be restricted.
Self-assessment: are you ready to apply for a payment institution licence?
Before committing to a payment institution application, founders should be able to answer each of the following questions affirmatively. If one or more answers is "no" or "not yet", the application is likely to stall at the regulator or at the safeguarding bank.
- The legal entity is incorporated in the target jurisdiction and the ownership structure is clear, documented and capable of ultimate beneficial owner disclosure to the regulator's standard.
- The business plan describes the payment services to be provided, the user base, the projected transaction volumes and the fiat currencies, in terms the regulator's template requires.
- The AML/CFT policies are drafted to the standard of the applicable regime – including the Travel Rule compliance solution for the crypto settlement leg, where relevant.
- A qualifying safeguarding bank has been identified and, ideally, has provided a soft indication that it will onboard the entity. If no bank has been identified, the application may proceed, but the timeline risk is material.
- The management team includes a nominated Money Laundering Reporting Officer (MLRO) and a compliance function that the regulator will accept as genuinely independent.
- The capital available to the entity meets the minimum requirement for the relevant payment institution or EMI class – and the capital is sourced from a documented, explainable origin.
- The IT and cybersecurity summary meets the regulator's published expectations for a payment institution of the proposed scale.
In our experience advising founders through the application process, the items that most frequently cause delay are the safeguarding bank identification and the AML/CFT policy quality. Regulators increasingly expect AML policies that are tailored to the specific business model, not adapted from a generic template. A payment institution serving crypto clients will face questions about its risk appetite for crypto-originated funds that a generic template does not address.
Related at OBOLUS
- Banking, Payments and EMI Onboarding for Digital-Asset Businesses – the practice overview covering fiat rails, safeguarding and banking onboarding for VASPs
- EMI Onboarding for VASPs in Turkey – jurisdiction-specific analysis of the Turkish EMI authorisation route for crypto operators
- Staking and Rewards Taxation for Established Operators – tax structuring for the yield and rewards layer that sits alongside payment operations
FAQ
Why do banks close crypto company accounts?
Banks close crypto company accounts primarily because the account holder does not hold the required payment or EMI authorisation for the activity on the account, or because the transaction profile generates AML risk flags that the bank's compliance framework cannot accommodate. A demonstrably licensed entity, with a documented AML programme and a clear business model, is materially easier for a bank to onboard and retain than an unlicensed operator. In some cases, account closure reflects a bank's internal policy decision to exit the crypto sector entirely, regardless of licensing status – in which case the solution is finding a bank with an active digital-asset client base, which typically requires specialist intermediation.
How can a VASP onboard with an EMI?
A VASP (virtual asset service provider) seeking EMI onboarding must demonstrate that its AML/KYC programme meets the EMI's own compliance requirements, which are typically higher than the minimum regulatory standard. The VASP should be prepared to share its latest independent AML audit, its MLRO contact details, its Travel Rule compliance solution and its transaction monitoring methodology. EMIs in the EU increasingly require VASPs to hold a MiCA CASP authorisation – or to be in a documented transition process – before the EMI will proceed with onboarding. The process takes time; plan it in parallel with, not after, the payment licence application.
What does client-money safeguarding require?
Client-money safeguarding requires a payment institution or EMI to hold funds received from users in a segregated account at a qualifying credit institution, separate from the entity's own operational funds. The account must be held with a bank that meets the regulator's standards for a safeguarding institution. Funds in the safeguarding account must not be commingled with the entity's own money, and the entity must be able to demonstrate that segregation at any point in time. Some regimes also require a safeguarding insurance policy or a guarantee as an alternative to full bank-account segregation, subject to regulator approval.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. We map the licence, banking and safeguarding stack across operating, custody and payment layers before you commit – so the structure you build is the structure that clears banking and regulatory review. Digital assets are the whole of our practice. Our disputes team also coordinates freezing relief and on-chain tracing across leading common-law forums when payment rails are misused. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory and Compliance Analyst – specialist in payment institution and VASP authorisation structures for digital-asset businesses across EU, Gulf and Asia-Pacific hubs.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.