EST · MMXXVI
Home/Insights/Tech/Payment institution licensing: What Recent Enforcement Tells Operators
Banking, Payments & EMI Onboarding

Payment institution licensing: What Recent Enforcement Tells Operators

Payment institution licensing: What Recent Enforcement Tells Operators. Cross-border digital-asset legal counsel for business – licensing, disputes and structur

Operating without the correct payment institution licence exposes a digital-asset business to enforcement action, suspended fiat rails and account closures that can halt operations within days. Payment institution licensing – the regulatory permission to receive, hold and transmit funds on behalf of third parties – sits at the intersection of banking law, anti-money laundering obligations and, increasingly, VASP (virtual asset service provider) supervision. As regulators across the EU, the UK, Dubai and Singapore tighten their expectations, the enforcement record of the past two years carries a clear message: the licence stack matters as much as the product itself.

This analysis draws on the enforcement posture of the FCA, ESMA and its national competent authorities under MiCA, VARA in Dubai, and MAS in Singapore. It maps the common failure points, contrasting regulatory approaches and the decision logic that operators should apply before they build fiat infrastructure into a crypto product. Every section opens with a direct answer for readers who need to extract the core point quickly.

The regulatory shift operators missed

Regulators globally moved from registration-light models to full authorisation regimes, and many operators have not caught up. For years, a number of digital-asset businesses treated payment institution licensing as optional infrastructure – a formality to be deferred until scale justified the cost. Enforcement has corrected that view emphatically. The FCA's cryptoasset financial promotions regime and its parallel approach to unauthorised payment activity signal that regulators now treat unlicensed fiat handling by a crypto company as a standalone violation, separate from any VASP-specific infraction.

Under MiCA, the European Securities and Markets Authority coordinates with national competent authorities to supervise CASPs (crypto-asset service providers). MiCA's scope deliberately reaches payment-adjacent activities: an exchange that holds client euro balances pending execution is, in the view of most NCAs, engaging in regulated payment or e-money activity unless it sits inside an explicit exemption. The consequence is that a CASP authorisation alone may not be sufficient. The operator may simultaneously need an EMI (electronic money institution) authorisation or a payment institution licence in the same member state.

In Dubai, VARA's activity-based licensing model applies analogously. The transfer and settlement activity licence covers the movement of value between wallets and to fiat; running that function without the specific VARA authorisation is treated as an unlicensed activity regardless of any group-level permission held elsewhere. VARA has been explicit in its published guidance that mainland Dubai operations require VARA authorisation independent of any DIFC or ADGM authorisation that the same group might hold.

In our cross-border practice, we regularly see operators assume that a licence in one hub confers implicit permission in the others. It does not. The enforcement record is built largely on that assumption.

What enforcement actually looks like for a payment operator

Enforcement against unlicensed payment activity follows a recognisable pattern: a supervisory inquiry triggers a voluntary or compelled account review, banking counterparties receive a regulatory notice, and fiat rails are suspended before the operator has had an opportunity to respond. The speed is the operative risk. Unlike a licence application that takes weeks to assess, a banking suspension can occur within hours of a regulator contacting the operator's correspondent bank.

The FCA's approach in the UK illustrates the dynamic. Under the Money Laundering Regulations, a cryptoasset business must register before conducting relevant activity. Failure to register does not merely expose the operator to a fine; it renders the business a designated non-compliant entity for the purposes of de-risking decisions by UK banks. Once that designation is applied, accounts close on regulatory rather than commercial grounds, and the path to reinstatement requires a fresh compliance demonstration rather than a simple remediation plan.

MAS in Singapore applies comparable pressure through its Payment Services Act licensing tiers. An operator running a digital payment token service above the major payment institution thresholds without the corresponding licence faces both a civil penalty and the practical consequence of being ineligible for MAS-supervised banking relationships. Singapore banks, operating in a framework that requires them to conduct enhanced due diligence on digital-asset customers, treat an unlicensed counterparty as inherently high-risk – a category that typically results in termination rather than monitoring.

A common assumption among operators is that enforcement focuses on large, visible exchanges. The actual record suggests otherwise. Smaller fintechs and crypto-adjacent payment processors feature prominently in regulatory correspondence and supervisory notices, precisely because their lower public profile means compliance gaps persist longer before detection.

The enforcement pattern is consistent across the FCA, MAS and VARA: unlicensed activity triggers banking consequences faster than it triggers a formal regulatory penalty.

If your fiat infrastructure is ahead of your licence stack, the risk is immediate. The process above describes the standard enforcement path. Your entity structure, user base and banking relationships change the precise exposure – and the available response. Map your options before a supervisory inquiry lands.

Why crypto banking and EMI onboarding remain structurally difficult

The core friction in crypto banking is not regulatory prohibition – it is the compliance cost asymmetry that licensed banks face when onboarding a VASP. A bank that accepts a digital-asset business as a customer inherits, under FATF Recommendation 15 and its domestic implementations, an obligation to apply enhanced due diligence to that relationship. That obligation is ongoing: the bank must monitor for Travel Rule compliance, assess the VASP's own AML programme and, in some regimes, take comfort on the VASP's licensing status in each jurisdiction where it operates.

For a medium-sized bank, the compliance cost of a single VASP relationship can exceed that of a portfolio of conventional corporate clients. The rational response – and the one that dominates the market – is to concentrate VASP banking relationships in specialist units or to exit the sector entirely. The resulting de-risking (the withdrawal of banking services from categories of client deemed high-risk regardless of individual conduct) is the structural condition that operators encounter when they seek fiat rails.

EMIs offer a partial alternative. In the EU, an EMI authorised under MiCA-adjacent e-money rules can issue e-money tokens (EMTs) and hold client funds against those tokens. For a VASP seeking fiat connectivity, an EMI relationship can substitute for a direct bank account in certain use cases – receiving customer deposits, processing withdrawals, settling trades. But EMIs themselves are subject to client-money safeguarding requirements that limit how they can use those funds, and some EMIs have tightened their own VASP onboarding criteria in response to regulatory pressure from their home NCAs.

Operators we advise routinely underestimate the lead time for EMI onboarding. An EMI's compliance review of a VASP applicant mirrors, in many respects, a bank's enhanced due diligence – AML policy review, governance assessment, jurisdictional risk analysis. That process rarely completes in under six to eight weeks, and in our experience, applications that arrive without a fully documented compliance programme typically stall at the initial screening stage.

How MiCA reshapes the payment licence stack for EU operators

MiCA introduces a unified CASP authorisation regime across the EU/EEA, with passporting rights that allow an authorised CASP to offer services across member states from a single authorisation. That is the headline benefit. The less-discussed consequence is that MiCA's CASP authorisation does not displace the need for an EMI or payment institution licence where the operator's activity involves holding client funds in fiat form or issuing instruments that meet the legal definition of e-money.

The distinction turns on what the operator actually does with client value at rest. A CASP that receives euro from a client to execute a crypto purchase, settles the trade and returns any residual fiat within the settlement window may argue that its activity falls within the CASP permission. A CASP that holds euro balances, allows clients to make fiat payments to third parties or issues a card product linked to the client's account is engaging in activity that most NCAs will characterise as e-money or payment services – requiring a parallel EMI or PI authorisation.

ESMA has indicated in its supervisory convergence work that NCAs should apply the substance-over-form test rigorously. The label an operator applies to its product – "crypto wallet," "trading account," "settlement reserve" – carries no weight. The question is whether the economic reality of the client relationship involves the operator holding and transmitting funds.

Lithuania, historically a favoured EU entry point for crypto businesses, is illustrative. Under the Bank of Lithuania's MiCA transition guidance, a business that previously held a VASP registration must assess whether its activity now requires a CASP authorisation, an EMI licence or both. The assessment is fact-specific, but the default assumption of the Bank of Lithuania, consistent with ESMA's convergence guidance, is that any fiat-holding function requires a separate payment-regime authorisation.

VARA and the Dubai payment licence question for digital-asset businesses

Dubai's VARA regime is the most granular activity-based framework currently in operation, and its approach to fiat handling is instructive for any operator building in the Gulf. VARA's transfer and settlement licence covers the movement of value – including fiat – in connection with virtual-asset transactions. An exchange that settles trades in AED or USD through its own accounts, rather than routing through a licensed payment processor, is operating in the transfer and settlement activity space and requires the corresponding VARA authorisation.

The distinction between mainland Dubai (VARA's jurisdiction) and the DIFC financial free zone (where the DFSA applies its own digital-asset framework) is operationally significant. A business authorised by the DFSA to conduct digital-asset activities in the DIFC does not thereby acquire permission to conduct those same activities – or the associated payment functions – in mainland Dubai. Operators that structure a DIFC entity and then serve mainland Dubai users are a recurring source of regulatory friction, and VARA has been clear in its published supervisory communications that this structure does not meet the authorisation requirement.

In a recent matter, an operator in the Gulf region had structured its payment function through a group entity in a jurisdiction outside the UAE, in the belief that an intercompany arrangement would satisfy VARA's requirements. The structure did not. We advised on a restructuring of the payment flow to bring the fiat-facing function within a VARA-licensed entity, which resolved the supervisory concern before it escalated to a formal notice. The matter concluded in a single quarter.

The Travel Rule and payment institution obligations: where they converge

The Travel Rule – the obligation under FATF Recommendation 15 to pass originator and beneficiary data with a virtual-asset transfer – creates a direct interaction with payment institution obligations that many operators manage as separate workstreams. That separation produces compliance gaps. When a VASP sends value to a payment processor or bank, and when that payment processor or bank is subject to correspondent banking screening obligations, the absence of Travel Rule data is visible to the receiving institution and triggers a compliance flag that can result in the transaction being held or the relationship being reviewed.

FATF's guidance treats VASPs and financial institutions as operating in a shared chain of obligations. A payment institution that receives funds from a VASP without Travel Rule data is itself potentially non-compliant with its own AML obligations, depending on the domestic implementation of the FATF standards. In the EU, under MiCA's AML provisions and the parallel Transfer of Funds Regulation, the obligation to collect and transmit originator/beneficiary data extends to crypto-asset transfers above the applicable de-minimis threshold – and those obligations apply regardless of whether the transfer touches a licensed payment institution at one end.

The practical consequence is that a VASP seeking to maintain banking relationships must not only satisfy the bank's onboarding criteria; it must also demonstrate that its Travel Rule compliance is systematic rather than best-efforts. Banks and EMIs in our experience increasingly request evidence of Travel Rule tooling – a compliant VASP compliance infrastructure solution – as part of their ongoing monitoring programme, not merely at onboarding.

If your Travel Rule programme and your payment institution relationships are managed in separate silos, the risk of a compliance gap is structural. A second read of the intersection can surface the gap before a banking counterparty does. Map your options

Decision matrix: which operator profile needs which licence combination

The licence requirement depends on the specific activity the business conducts, the jurisdictions where it operates and the profile of its users. No single licence combination is universal. The following profiles capture the most common configurations we encounter.

Profile A – a crypto exchange settling in fiat, EU users: requires a CASP authorisation in an EU member state with passporting rights, plus an EMI or payment institution licence in the same state if the operator holds client fiat between trade settlement cycles. Timeline qualitatively: a CASP authorisation process is typically measured in months, not weeks; an EMI authorisation process in parallel extends the critical path further. The key risk is assuming the CASP authorisation covers the fiat-holding function.

Profile B – a payments fintech adding crypto rails, UK-based: requires FCA cryptoasset registration under the Money Laundering Regulations as a minimum, in addition to the existing payment institution authorisation. If the operator issues instruments that qualify as e-money, an EMI authorisation is separately required. The FCA's financial-promotion rules apply to any marketing of the crypto service to UK users, regardless of where the operator is incorporated. Timeline: FCA registration processing times have varied considerably; current guidance should be verified directly with the FCA.

Profile C – a VASP with Gulf-region users, Dubai-domiciled: requires a VARA licence for the relevant activity (exchange, transfer and settlement, custody – often a combination) and, if the operator processes fiat, the VARA transfer and settlement authorisation in particular. A parallel ADGM/FSRA authorisation may be relevant if the business serves ADGM-domiciled counterparties. The key risk is structuring through a free-zone entity and assuming mainland coverage.

Profile D – a token issuer seeking global fiat connectivity: the issuer's own activity may not trigger a payment institution requirement, but any infrastructure partner that holds or transmits fiat on the issuer's behalf will. The issuer bears indirect risk if its payment partners are not correctly licensed, because banking counterparties will assess the issuer's entire payment chain during due diligence. Structuring the issuer separately from the payment function is correct, but the issuer must still be able to demonstrate that the payment function is clean.

What client-money safeguarding requires in practice

Client-money safeguarding – the regulatory obligation on a licensed payment institution or EMI to hold client funds in a manner that protects them from the institution's own creditors – is one of the most practically demanding aspects of payment institution licensing, and one that is frequently underestimated during the build phase. Under the EU's e-money and payment services regimes, as implemented and now being updated in the MiCA context, a licensed operator must segregate client funds, hold them in a designated safeguarding account with an approved credit institution, and maintain records that allow the full reconciliation of each client's position at any point.

The safeguarding obligation has a direct interaction with the crypto product. If a payment institution or EMI holds client fiat that will be used to execute crypto purchases, the period during which that fiat is "in transit" – after receipt but before the crypto is delivered – is a period during which the safeguarding obligation applies. An operator that uses client fiat in that window for any other purpose – including short-term liquidity management – is in breach of its safeguarding obligations, regardless of the brevity of the use.

Regulators, including the FCA, have taken enforcement action against payment institutions that treated safeguarding as a reporting obligation rather than an operational one. The consistent theme in those actions is that the operator had the correct policy documentation but had not built the operational process to match it. The gap between the written programme and the actual cash management practice is the enforcement vector.

In our practice, the safeguarding review is a standard component of any payment institution licensing mandate. We have seen applications stall at the authorisation stage because the applicant's proposed safeguarding model relied on an account with a bank that would not accept the business, creating a structural circularity that had to be resolved before the application could proceed.

A common assumption – and why it does not hold

A common assumption in the digital-asset sector is that a single offshore licence – typically a BVI VASP registration, a Cayman VASP Act registration or a similar light-touch registration – is sufficient to operate a global payment-adjacent service. The VARA regime, MiCA, the FCA and MAS all reject this assumption explicitly. Each regime applies on the basis of where the service is provided to users, not solely where the operator is incorporated.

The BVI FSC's VASP Act and CIMA's VASP regime under the Cayman Virtual Asset (Service Providers) Act are legitimate and well-administered registrations for businesses with a genuine connection to those jurisdictions. They are not substitutes for the authorisation required in the jurisdiction where the operator's users are located or where the operator's fiat infrastructure is based. An operator that relies on an offshore registration to cover EU, UK or Gulf users is operating on a legal analysis that the relevant regulators explicitly do not accept.

The practical consequence of that misalignment is not abstract. Banks and EMIs that onboard a business on the basis of its offshore registration, and that later discover the business is serving users in a regulated market without the corresponding local authorisation, face their own regulatory exposure. That exposure is the commercial reason why onboarding standards have tightened: the EMI's compliance team is, in effect, running a jurisdictional analysis of the VASP's licence stack as a precondition to account opening.

Operators we advise who have built on the offshore-only model typically require a restructuring that adds an EU or UK-licensed entity, an application for a VARA or MAS licence, or both – depending on where the user base actually sits. The restructuring is possible, but it takes longer when it is reactive than when it is planned.

Related at OBOLUS

FAQ

Why do banks close crypto company accounts?

Banks close crypto company accounts primarily because the compliance cost of maintaining those relationships – enhanced due diligence, Travel Rule monitoring, jurisdictional licensing assessment – exceeds the commercial return. Regulatory pressure from supervisors also plays a role: a bank that onboards a VASP with an incomplete licence stack can face its own regulatory scrutiny. The closure decision is usually commercial, not a finding of wrongdoing by the crypto company, but the effect on operations is the same.

How can a VASP onboard with an EMI?

A VASP seeking an EMI relationship must typically demonstrate a documented AML/CFT programme, Travel Rule compliance infrastructure, a clear jurisdiction-by-jurisdiction licence map, and governance that shows the VASP's own compliance function is adequately resourced. EMIs apply onboarding criteria comparable to those of a bank. The process is rarely completed in under six to eight weeks, and applications without full documentation routinely stall. Allied counsel familiar with the specific EMI's home regulator can materially improve the outcome.

What does client-money safeguarding require?

Client-money safeguarding requires a licensed payment institution or EMI to segregate client funds from its own funds, hold them in a designated account with an approved credit institution, and maintain real-time reconciliation records. The safeguarding obligation applies from the moment client funds are received. Using client fiat even briefly for the operator's own liquidity purposes is a breach. Regulators treat a gap between written safeguarding policy and actual cash management practice as an enforcement matter, regardless of intent.

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 payment stack across operating, custody and payment layers before you commit – structuring licensing, banking and tax as one mandate rather than three disconnected workstreams. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.

By Roman Levitt, Technology & DeFi Counsel – specialising in regulatory analysis for payment-adjacent digital-asset infrastructure and cross-border licensing strategy.

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.

Tell us the task — we'll map your options in 30 minutes.

Fixed-fee packages with defined scope and SLAs. The first call is free and under NDA. Business clients only.

Map your optionsinfo@oboluslaw.com · t.me/oboluslaw · reply < 2 hours