Fiat rails are the quiet constraint that determines whether a regulated digital-asset business actually operates. A virtual asset service provider (VASP) can hold every licence its regulator requires and still find that no bank or electronic money institution (EMI) will open the account that moves client money in and out of the system. That failure is not a banking inconvenience. It is a commercial stop. The purpose of this page is to explain the legal and structural work that gets a regulated entity into a working fiat relationship – and keeps it there.
Operating without the right banking stack exposes a regulated VASP to enforcement by its primary regulator, frozen payment rails at the point of a compliance review, and the reputational cost of emergency account migration. The risk is asymmetric: the business loses clients while the fix is underway, and the time to rebuild is rarely measured in days. We advise across the full mandate – licence, banking and compliance – because the three are not separable problems.
Why Fiat Rails Fail for Regulated Entities
Banks and EMIs decline crypto-company applications primarily because the risk-classification model applied to any financial institution (FI) counterparty assigns digital-asset businesses to a high-risk or non-standard category – regardless of the applicant's regulatory status. The approval decision sits inside the FI's financial-crime compliance function, not its commercial team. A VASP that presents itself without a credible compliance narrative will be declined at an automated filter before a human reviewer evaluates the business.
The structural problem is that most VASPs apply as though banking approval were a downstream administrative step. It is not. The banking relationship has its own regulated basis. Under the applicable anti-money-laundering provisions in most major jurisdictions – grounded in the FATF Recommendations, including the revised treatment of virtual-asset businesses – a bank or EMI onboarding a VASP must conduct enhanced due diligence on that business as a high-risk customer. The reviewing FI is asking whether it can satisfy its own regulator that it understands the VASP's flows, its own customer base, its AML controls and its licence validity. An application that answers those questions is reviewed. One that does not is declined.
In our cross-border practice, we regularly see the same pattern: a well-licensed exchange applies to three or four banks in sequence, receives a form decline from each, and interprets the result as a market-wide refusal of crypto business. The actual reason is almost always structural. The application did not address the bank's regulatory exposure. The entity structure placed the operating company in a jurisdiction where the bank had no local compliance resource to verify the licence. Or the client-money flows were described in commercial terms that triggered a transaction-monitoring flag rather than a compliance-narrative approval.
The path to a working fiat relationship is a prepared application that speaks the reviewing FI's compliance language: a clear licence summary, a mapped AML program with a named MLRO, a transaction-flow diagram keyed to the entity's specific activities, and a client-base profile with documented KYC standards. The process is not simple. But it is manageable when the application is built correctly from the start.
For a first read of your banking situation, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking target – change the analysis materially.
The Regulatory Basis for Fiat On/Off-Ramp Services
A fiat on/off-ramp is a regulated activity in most flagship jurisdictions, not a payment-adjacent service a VASP can deliver by implication from its digital-asset licence. The distinction matters because the relevant permissions and the entities that can provide them differ from the VASP licence itself.
Under MiCA (the EU's Markets in Crypto-Assets Regulation, supervised by ESMA and national competent authorities), a CASP (crypto-asset service provider) authorised to exchange crypto-assets against fiat currency has the regulatory basis to conduct that exchange activity. But the actual movement of fiat – the debit and credit that settles the exchange in euros – still requires either an in-house e-money or payment institution authorisation or a contractual relationship with an entity that holds one. The CASP authorisation and the payment-institution authorisation are not the same instrument, and passporting rules for each follow different mechanics.
In the UAE, under the VARA (Virtual Assets Regulatory Authority) regime applicable to mainland Dubai, the exchange and transfer/settlement activity-based licences address the crypto side. The fiat leg of any conversion relies on a banking or payment relationship that VARA itself does not license. The business therefore holds a VARA licence for the crypto activity and must separately maintain a fiat-settlement relationship with a bank or licensed payment provider inside the UAE. The same structural split applies in the ADGM environment, where the FSRA supervises virtual-asset activities and a separate payment-services layer sits underneath.
In Singapore, under the MAS Payment Services Act, a licensed digital payment token service provider may also need a separate payment-service licence tier if it accepts and transmits fiat as part of its business model. MAS has been explicit that the DPT licence does not automatically cover all fiat-handling activity. The same principle – that crypto-asset and fiat-payment permissions are layered, not merged – applies across the SFC regime in Hong Kong, the FCA registration and authorisation stack in the United Kingdom, and the state money-transmitter frameworks in the United States.
The practical implication is a licence-mapping exercise before any banking outreach. An operator who goes to a bank or EMI without knowing which entities in the group hold which permissions, and which activities each entity is authorised to conduct, will produce an application that the reviewing compliance officer cannot evaluate clearly. Clarity on the licence stack is a prerequisite, not a parallel workstream.
What Does the Banking Application Process Actually Involve?
A banking application for a regulated digital-asset entity is, in substance, a second regulatory review – conducted by a private FI rather than a public authority, but no less structured. The reviewing FI's compliance team will apply an internal risk-appetite framework to the application, and the applicant has very limited visibility into the criteria unless it has done targeted preparation.
The core documentation package required for most banking and EMI onboarding exercises for a regulated VASP includes the following elements. First, a corporate structure memorandum – not a commercial deck – that maps every entity in the group, its jurisdiction, its regulatory status and the activities it conducts. Second, the VASP's AML/CFT policy suite, including the KYC standard applied to its end-customers, the transaction-monitoring methodology and the escalation procedure for suspicious activity. Third, a financial-flows diagram that shows, with specificity, how fiat enters and exits the business, which accounts hold client money and which hold operational funds, and how settlement occurs between the crypto and fiat legs of any transaction. Fourth, a licence copy accompanied by a short explanatory note on what the licence authorises – because a compliance officer at a bank in, say, Germany reviewing a Cayman VASP Act registration will not know what that instrument covers without the note.
In practice, the application is rarely declined on the substance of the business. It is declined because the documentation package leaves questions unanswered that the reviewing compliance officer cannot resolve on their own timeline. A well-structured application addresses the anticipated questions before they are asked. That is preparation, not just assembly.
Timeline varies by institution and jurisdiction. In our experience, prepared applications to EMIs that actively work with digital-asset clients in the EU or UK resolve within a matter of weeks – sometimes faster. Applications to traditional banks in the same markets frequently take longer, and the timeline is less predictable because the decision-maker is further from the crypto-asset compliance function. Offshore banking applications for holding or treasury purposes follow their own timelines, which depend heavily on the specific institution and its current risk appetite.
A micro-matter from recent practice illustrates the common failure mode. A token-exchange operator in a mid-sized EU jurisdiction had held a valid VASP registration for over a year but had not successfully opened a business account with any bank in its home jurisdiction or in a neighbouring member state. The problem, when we reviewed the prior application materials, was that the AML policy submitted had been drafted for the regulator, not for a bank's compliance function. It addressed the regulatory standard in abstract terms and did not describe the specific KYC checks applied to the operator's end-customers or the transaction-monitoring thresholds in use. We restructured the package to answer the bank's due-diligence questions directly and to make the compliance narrative legible to a general financial-crime reviewer. The operator received a conditional approval within several weeks of the revised submission.
How Does the Cross-Border Structure Affect Fiat Access?
The cross-border reality for most digital-asset businesses is that the entity holding the licence, the entity holding the client assets, the entity that contracts with users and the entity that holds the fiat account are frequently in different jurisdictions. That structure is often intentional – driven by tax efficiency, regulatory access or investor requirements. But it creates a specific problem for fiat-banking access: the reviewing bank sees a chain of entities, each in a different regime, and must evaluate the compliance picture for the whole chain before it can open an account for any one of them.
The problem is compounded where the regulated entity is in a jurisdiction that the reviewing bank's group compliance function has limited familiarity with. A BVI FSC-registered VASP or a CIMA-supervised digital-asset fund seeking banking access in Europe will be evaluated through a correspondent-banking risk lens that was built for international business generally, not for digital-asset entities specifically. The reviewing FI's first instinct is to apply a blanket elevated-risk designation and to require a level of documentation that the entity may not have assembled in a banking-ready format.
The strategic question for an operator building its structure is therefore not only "which jurisdiction gives us the best licence?" but "which combination of entity jurisdiction, banking jurisdiction and payment-provider jurisdiction produces a workable fiat stack?" Those three choices interact. A VARA licence in Dubai, combined with an EMI relationship in an EU member state and a treasury holding structure in the ADGM, represents a coherent architecture – but only if the flows between each layer are properly documented and the compliance narrative for each FI relationship is independently prepared.
We advise on the full stack, which means we map the licence, banking and tax implications before the structure is committed. In our practice, operators who treat banking as a consequence of the licence decision consistently face longer resolution timelines than those who factor banking feasibility into the entity design from the start. The cross-border angle is not a complication to manage later. It is a design constraint to address at the outset.
If a prior application stalled or an account was closed, a structural review can identify the reason and the route forward. Write to info@oboluslaw.com. A second read of a declined application frequently surfaces issues that are correctable with preparation rather than a new structure.
EMI Onboarding as an Alternative Route
An EMI (electronic money institution) is a regulated entity authorised to issue electronic money and provide payment services – and, unlike most commercial banks, EMIs in the EU, UK and certain other markets have in recent years developed specific compliance frameworks for digital-asset business clients. That development reflects commercial reality: the digital-asset sector is a significant source of payment volume, and an EMI with a well-developed crypto-client due-diligence standard can serve that market while satisfying its own regulator.
EMI onboarding for a VASP is structurally similar to bank onboarding in its documentation requirements, but differs in several practical respects. EMIs are typically faster at initial due-diligence review because the compliance function is closer to the decision and has more direct familiarity with the digital-asset client profile. The account features available – IBANs, SEPA and SWIFT rails, multi-currency wallets, API-based payment initiation – are often more flexible than traditional bank accounts. The tradeoff is that an EMI account is not the same as a bank account for all purposes: credit facilities, certain correspondent arrangements and some institutional counterparties require a relationship with a deposit-taking institution.
The Travel Rule applies to the EMI relationship as well. Where a VASP uses an EMI to settle fiat obligations arising from crypto-asset transactions, the Travel Rule (the FATF obligation, implemented across major regimes, to pass originator and beneficiary data with a qualifying transfer) creates a data-sharing requirement that must be technically and contractually addressed between the VASP and the EMI. An EMI that accepts a VASP as a client without a clear Travel Rule protocol in place is creating a compliance gap for itself. A VASP that has not addressed Travel Rule compliance before approaching an EMI will find the conversation stalls at that point in the due-diligence process.
Operators we advise routinely work through the Travel Rule architecture as part of the EMI onboarding preparation, because it is invariably raised as a condition of account opening and it is not something that can be resolved on a short timeline without prior groundwork. The technical implementation – connecting to a Travel Rule solution provider, configuring the counterparty data flow – takes time. The legal element is identifying which transfers are in scope under the applicable regime, confirming the de-minimis threshold treatment (which varies by jurisdiction and should be verified against current implementing rules), and ensuring the contractual documentation with the EMI reflects the agreed data-handling standard.
Client Money Safeguarding and the Fiat Layer
Client-money safeguarding is a regulated obligation under most licensing regimes that authorise a business to hold fiat funds on behalf of customers. The practical requirement is that customer funds are held separately from the firm's own funds – either in a designated client account at a bank or with an EMI, or in ring-fenced assets of equivalent safety. The requirement applies to the entity holding the funds, not to the licence category in isolation.
Under MiCA and the applicable CASP provisions, a CASP holding client funds has explicit safeguarding obligations aligned broadly with the e-money and payment-services frameworks. Under VARA in Dubai, similar segregation expectations apply to licensed custodians and exchange operators. Under the MAS Payment Services Act in Singapore, safeguarding requirements for customer monies are built into the licence conditions for the relevant service tier. The principle is consistent across major regimes: client money must be identifiable, separated and protected against the insolvency of the service provider.
The fiat banking relationship is the mechanism through which safeguarding is implemented in practice. A VASP that cannot maintain a designated client-money account – because it does not have an appropriate banking relationship – cannot satisfy its safeguarding obligations, which means its licence conditions are not being met. That is a regulatory risk that escalates quickly: a regulator reviewing the business for any reason will identify the safeguarding failure as a material compliance gap, and the remediation timeline under regulatory scrutiny is far less comfortable than the timeline for a proactive solution.
Safeguarding arrangements must also be disclosed. Under most regimes, clients must be informed of how their money is held, by whom and under what protections. The disclosure obligation is not technically demanding, but it requires the business to have made the relevant decisions and documented them. An operator who has not resolved the banking structure cannot make accurate disclosures – which compounds the compliance exposure.
Decision Matrix: Which Banking Structure for Which Profile?
The right banking architecture depends on the operator's regulatory profile, geographic footprint, transaction model and growth stage. The following prose matrix describes the four profiles we most commonly advise.
Profile A – EU-licensed CASP (MiCA), retail exchange: The operator holds or is obtaining a CASP authorisation in an EU member state and serves retail clients across the EU through the MiCA passporting mechanism. The preferred fiat structure is an EMI relationship with a provider holding an EU payment institution or e-money licence, supplemented by a traditional bank account in the same member state for treasury and operational funds. The client-money account must be with a deposit-taking institution or in safeguarding-compliant instruments. Timeline for a prepared EMI application in this profile is typically a matter of weeks to a small number of months. The key risk is the Travel Rule protocol, which must be operational before the EMI account is live.
Profile B – Dubai VARA-licensed exchange, institutional clients: The operator holds a VARA activity-based licence and primarily serves institutional or high-net-worth counterparties in the GCC and internationally. The preferred fiat structure combines a UAE bank relationship for AED settlement with an EMI or payment provider for USD and EUR rails, often supplemented by a holding or treasury structure in the ADGM. The institutional client profile makes the AML narrative more straightforward – institutional KYC is easier to demonstrate than retail KYC at scale – but the cross-border funds-flow documentation between the UAE and offshore banking jurisdictions requires careful preparation. Timeline varies considerably by institution; proactive engagement with the bank's financial-crime team early in the process shortens it materially.
Profile C – BVI or Cayman-registered fund or holding structure, cross-border payments: The operator uses an offshore registered entity as the primary contractual entity but needs fiat banking for investor subscriptions, management fees and operational expenses. Traditional banks in most G10 markets apply elevated scrutiny to BVI and Cayman entities. The practical route is either a bank in a jurisdiction with established offshore-client compliance frameworks, or an EMI with a documented offshore-entity acceptance policy. The critical input is demonstrating that the ultimate beneficial owners are identified, documented and not on any relevant sanction list – FATF, OFAC or applicable national lists. Timeline is the most variable across these profiles; allow for a multi-step engagement.
Profile D – Early-stage VASP, seeking first fiat relationship before licence is granted: This profile is addressed in a separate page. The dynamics of pre-licence banking are materially different from the post-licence position. The short answer is that an application prior to licence grant is possible with some EMIs and niche banks, but the structure of the application and the documentary package required are different. See the related page below.
Common Mistakes That Delay or Block Fiat Access
The mistakes that cause fiat-banking failures for regulated entities are almost entirely procedural rather than substantive. The businesses involved are, in the large majority of cases, legitimately operating and capable of meeting the FI's requirements. The problem is presentation and sequencing.
The most common error is applying to a bank before the compliance documentation is ready. A VASP that submits an application with a licence copy, a corporate structure chart and a bank reference is submitting perhaps thirty percent of what a reviewing compliance officer needs. The gap is filled with follow-up information requests, which extend the timeline and create a second opportunity for a decline. Building the full documentation package before initial submission is not only more efficient – it signals to the reviewer that the applicant understands the compliance relationship it is seeking to enter.
The second common error is misidentifying the decision-maker at the FI. At most commercial banks, the relationship manager is not the person who will determine whether the account is opened. That decision sits with the financial-crime compliance function, and sometimes with a global financial-crime committee if the business is in a high-risk category. An application that persuades a relationship manager but does not address the compliance function's questions will fail at the internal review stage – often without the applicant receiving clear feedback on the reason.
A common assumption among operators is that a single offshore licence is sufficient to support a global banking application. It is not. A bank in, say, France reviewing an application from a Cayman-registered entity with a CIMA VASP registration is not asking whether the entity has a licence. It is asking whether it can satisfy the Autorité de contrôle prudentiel et de résolution that it has conducted adequate due diligence on a high-risk financial-sector counterparty. The regulatory basis of that assessment is the FI's own AML obligations, not the applicant's licence. That distinction matters for how the application is constructed.
Regulators in the leading hubs increasingly expect VASPs to maintain documented evidence of their banking and safeguarding arrangements as part of the ongoing licence condition review. An operator without a functioning fiat relationship is therefore not only facing a commercial problem – it is facing a potential compliance finding on the next regulatory review cycle.
Related at OBOLUS
- Banking, Payments & EMI Onboarding for Digital-Asset Businesses – the full practice overview, covering all service lines in this cluster.
- Corporate Bank Account Opening: The Compliance Burden in Practice – a detailed analysis of the compliance documentation burden in current bank onboarding practice.
- Fiat On/Off-Ramp Banking for Early-Stage Founders – the pre-licence banking path for founders at formation stage.
FAQ
Why do banks close crypto company accounts?
Banks close digital-asset company accounts primarily when a periodic compliance review concludes that the business presents a higher financial-crime risk than the institution can document and manage within its own regulatory obligations. Triggers include changes in the bank's risk appetite, gaps in the client's AML documentation, unexplained transaction patterns or adverse media. A VASP can reduce this risk by maintaining current compliance documentation and engaging proactively with the bank's financial-crime team rather than waiting for a review notice.
How can a VASP onboard with an EMI?
A VASP onboards with an EMI by presenting a prepared due-diligence package that addresses the EMI's financial-crime compliance requirements directly: a current licence summary, a structured AML policy, a transaction-flow diagram, UBO documentation and a Travel Rule compliance protocol. EMIs that actively serve digital-asset clients have internal frameworks for evaluating VASPs, and an application that maps to those frameworks is reviewed rather than declined at intake. Timeline from a prepared submission varies but is often shorter than a traditional bank process.
What does client-money safeguarding require?
Client-money safeguarding requires that funds held on behalf of customers are kept in accounts or instruments that are separate from the firm's own funds, identifiable as client money and protected against the insolvency of the service provider. Most major regimes – including the applicable CASP provisions under MiCA, the VARA regime in Dubai and the MAS Payment Services Act in Singapore – impose explicit safeguarding conditions as part of the licence. Implementation requires a designated client-money bank account and documented procedures for reconciliation and client notification.
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 stack across operating, custody and payment layers before you commit, and we structure 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 or message us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in the regulatory basis and compliance documentation for fiat-rail access across EU, UAE and Asia-Pacific licensing regimes.
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.