For a digital-asset business, fiat rails are not a commodity. They are the operational boundary between a functioning product and a frozen one. When a bank closes a crypto company's account – often without written notice and without a statutory right of appeal – the knock-on effect can suspend payroll, block client withdrawals and trigger regulatory scrutiny from the very authorities whose approval the business spent months obtaining. The question is not whether banking is hard for crypto operators. The question is what the structure of the business, its licence stack, and its counterparty relationships actually tell the bank's compliance team – and whether that story is coherent.
Corporate bank account opening for a digital-asset business is, at its core, a structuring problem. The entity that holds the licence, the entity that touches client money, and the entity that interfaces with the payment system are not always the same company – and banks know it. A well-constructed corporate structure, paired with the right regulatory footprint, converts a high-risk applicant into a recognised financial institution. A poorly constructed one converts a licensed operator into a de-risking casualty.
This analysis examines the structuring variables that determine banking success: entity design, licence selection, jurisdictional footprint, and the interaction between those elements and a bank's or EMI (electronic money institution) compliance process.
Why Banking for Crypto Companies Is a Structuring Problem
Banks do not refuse crypto companies because they dislike digital assets categorically. They refuse – or exit – because the risk-reward calculus of their own compliance departments makes onboarding a structurally opaque crypto entity more expensive than the revenue it generates. The solution is not to obscure the crypto activity. The solution is to make the structure legible, regulated and low-friction for the bank's automated and manual review processes.
The core issue is that most digital-asset businesses carry multiple legal personalities across multiple jurisdictions before they have a single bank account. A token issuer may be incorporated in the Cayman Islands, hold a VASP (virtual asset service provider) licence in Lithuania under the applicable provisions of the Bank of Lithuania's VASP supervision regime, and onboard users from the EU, MENA and Southeast Asia simultaneously. Each layer – the issuing entity, the operating entity, the custody entity – is a separate compliance question for the bank. Banks are not equipped to reverse-engineer that structure at onboarding. The applicant must present it in a form the bank can assess.
In our cross-border practice, the businesses that succeed in opening and keeping fiat rails are those that design the entity structure around the banking requirement before the first application goes out. Those that approach banking as an afterthought – once the product is live and the licence is in hand – face timelines measured in quarters, not weeks.
The FATF Recommendation 15 framework, which designates VASPs as obliged entities under anti-money-laundering standards, has altered the baseline expectation globally. A VASP without a documented AML/CFT programme, a credible beneficial-ownership trail and a plausible source-of-funds narrative for its own treasury is not a viable banking applicant, regardless of which regulator has licensed it.
Which Entity Should Actually Open the Account?
The licensed operating entity is not always the right applicant – and choosing the wrong one is among the most common and costly structural errors we see. The entity that opens the primary fiat account must be the entity whose regulatory status the bank can verify directly, whose beneficial ownership is clean and documentable, and whose transactional flow makes commercial sense in isolation.
Consider a structure where a BVI holding company owns a Malta CASP licensee and a Cayman fund vehicle. The BVI entity cannot open a tier-one bank account on the strength of the Malta licence – the BVI entity is not the licensee. The Malta entity can, but only if its own corporate documentation is complete, its AML programme aligns with MFSA expectations under the transitioning VFA-to-MiCA framework, and its anticipated transaction volumes are coherently explained. The Cayman vehicle is a fund, not a payment processor, and should not be commingling operational treasury flows with fund assets in any event.
This distinction matters because a number of operators try to use an intermediary holding entity as the bank account holder to shield the licensed entity from direct bank scrutiny. The strategy is counterproductive. Banks escalate holding-company applications to group-level review, the disclosure requirements multiply, and the timeline extends. A direct application from the regulated entity is typically faster and more predictable.
Where a group genuinely needs accounts at multiple layers – treasury, operations, client money – the structure should map each account to a specific regulatory purpose and a specific entity with standing to hold that account. That map is part of the application package, not an afterthought to the cover letter.
To scope your entity architecture before the first application, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis significantly.
What Does a Licence Actually Signal to a Bank?
A regulatory licence signals supervisory oversight, not transactional safety – and banks understand the difference. The question a bank's financial crime team asks is not "is this company licensed?" but "what does the licence require the company to have in place, and can we verify that those controls exist?"
Licence quality varies considerably across regimes. A VARA (Virtual Assets Regulatory Authority) licence in Dubai, issued under VARA's activity-based rulebooks, carries detailed capital and conduct requirements that a bank's compliance team can review in a published regulatory instrument. A Lithuania VASP registration, historically one of the lighter-touch EU entry points, carried fewer substantive requirements before the MiCA transition. Banks operationally aware of that distinction will weight the two licences differently in their onboarding risk matrix.
This does not mean a Lithuania-registered entity cannot bank. It means the application must compensate for the lighter regulatory signal by providing more detailed proprietary compliance documentation – a fuller AML policy, a more granular transaction-monitoring framework, a more explicit source-of-funds narrative. The MiCA transition to CASP authorisation (Crypto-Asset Service Provider) across EU member states, supervised by national competent authorities and ultimately coordinated by ESMA, is raising the floor for EU-licensed entities. Operators who complete full CASP authorisation will find their regulatory signal materially stronger in banking applications than those still operating on legacy registrations.
Operators we advise routinely underestimate the value of what their licence package actually says. A complete VASP or CASP file – with the regulatory decision letter, the approved AML programme, the fitness-and-propriety documentation for key persons – is the core of a successful bank application, not merely its preamble.
EMI Onboarding as a Fiat-Rails Strategy: When Is It the Right Move?
An EMI (electronic money institution) or a payment institution operating under a licence from the FCA, the MFSA, the Bank of Lithuania or another competent authority can provide fiat settlement infrastructure to a VASP without the VASP holding a bank account at all in the conventional sense. For many crypto operators, EMI onboarding is not a fallback – it is the primary architecture.
The mechanism is straightforward in outline. The EMI holds a safeguarding account at a credit institution, issues an IBAN to the VASP's operational entity, and processes incoming and outgoing EUR, GBP or USD flows under the EMI's own AML programme. The VASP becomes the EMI's customer, not a bank's customer directly. The onboarding due-diligence burden shifts to the EMI, which has more commercial incentive to understand the VASP's business model than a retail or commercial bank does.
The structural risk is concentration. A VASP relying on a single EMI for all fiat settlement is one account-termination event away from an operational crisis. The best structures we map include at least two EMI relationships across different jurisdictions and, where volumes justify it, a direct banking relationship for treasury.
There is also a regulatory-interaction point that operators often miss. Where the VASP is providing payment-adjacent services – converting fiat to crypto on behalf of clients, or holding client fiat pending conversion – the VASP may itself need a payment service licence or be acting within the scope of an EMI activity in the relevant jurisdiction. In that circumstance, the VASP is not simply the EMI's client. It is a regulated entity in its own right with obligations that the EMI will expect to review. The MAS Payment Services Act framework in Singapore, and the applicable provisions of MiCA for EUR-denominated flows, both address this boundary.
The Cross-Border Complication: Where the Entity Sits vs. Where the Users Are
A VASP licensed in one jurisdiction and serving users in multiple others does not enjoy a clean compliance story for any bank it approaches. The bank must assess not only the jurisdiction of incorporation but the jurisdictions of customer exposure, the jurisdictions of banking counterparties, and the jurisdictions of the founders and key persons.
The EU passporting mechanism under MiCA – which allows a CASP authorised in one member state to offer services across the EU/EEA without further authorisation – is a meaningful structural advantage. A Malta or Lithuanian CASP that has passported into Germany, France and the Netherlands is not, from a bank's perspective, a single-country operator. It is a regulated EU-wide business. That characterisation matters when the bank's risk appetite for EU-regulated financial institutions is materially better than its appetite for pure-crypto businesses.
Outside the EU, the cross-border picture is more fragmented. A BVI FSC-registered VASP under the VASP Act 2022 that serves customers in the Gulf, Sub-Saharan Africa and Latin America faces three distinct compliance questions for any bank in any of those regions. The BVI registration addresses the entity's home-jurisdiction obligations. It does not create a regulated-entity footprint in any of the markets being served. Banks in those markets will ask about local registration, local tax obligations and local AML coverage – and in the absence of credible answers, the application will fail.
The practical resolution is a deliberate jurisdiction map: the entity in the jurisdiction that provides the strongest regulatory signal for the target banking markets, paired with the compliance documentation that fills the gaps. That map is not standardised. It is built around the operator's specific customer base, transactional flow and growth horizon.
If a prior banking application stalled, or an account was closed without adequate explanation, write to OBOLUS at info@oboluslaw.com. A second read of the structure can surface the specific gap the bank's compliance team identified – and the route to resolving it.
Decision Matrix: Which Operator Profile Needs What?
Not every digital-asset business faces the same banking problem. The structuring solution depends on the operator's profile, the target banking market and the regulatory footprint already in place.
Profile A – Early-stage exchange, EU focus, no existing banking: The optimal path is CASP authorisation in a mid-tier EU member state with an active CASP programme, paired with EMI onboarding from a licensed EU EMI for initial fiat settlement. The CASP licence provides the regulatory signal; the EMI provides the account infrastructure. Direct banking follows once the business has a transaction history. The timeline from CASP application to operational fiat rails is measured in months – the authorisation process itself varies by member state but is not a matter of weeks for a substantive application.
Profile B – Established VASP, multi-jurisdiction, existing bank relationship at risk: The priority is structural reinforcement, not a new application. This means an audit of the entity structure against the bank's publicly disclosed risk appetite, an update to the AML programme to reflect current FATF standards, and a proactive disclosure to the relationship manager before the next periodic review. In our practice, operators who engage the bank before the review receive materially better outcomes than those who respond reactively to a termination notice.
Profile C – Fund or institutional trading desk, custody-layer complexity: The banking requirement is distinct from the operating entity. A Cayman-regulated fund vehicle under the applicable CIMA framework needs a prime-brokerage or institutional banking relationship, not a retail or commercial bank account. The structure must segregate fund assets from operating treasury, document the custody arrangement clearly, and present the fund administrator and auditor as verification anchors. EMI infrastructure is generally not appropriate at the fund level.
Profile D – Web3 project with token issuance, minimal regulatory footprint: This is the highest-risk profile for banking. Banks price token-issuing entities as potential issuers of unregistered securities and as high-AML-risk entities simultaneously. The structuring resolution is to separate the token-issuing vehicle – which may legitimately be a foundation or a Cayman entity – from the operating company that actually touches fiat and client money. The operating company must have its own licence, its own AML programme, and a banking application that does not lead with the token narrative.
What Are the Common Structural Mistakes That Cause Account Closures?
Account closures rarely result from a single compliance failure. They result from an accumulation of signals that collectively exceed the bank's risk tolerance at the moment of periodic review. Understanding those signals in advance is what structuring is for.
The first and most common mistake is transactional opacity. When a company's fiat flows do not match the business model described at onboarding – because the product has evolved, because a new service line was added without disclosure, or because client money and treasury were not properly segregated – the bank's transaction-monitoring system generates alerts that the relationship manager cannot easily explain. The company did not intend to be deceptive. But the bank cannot distinguish intent from effect.
The second mistake is failing to update beneficial-ownership information when the cap table changes. Banks' KYC refresh cycles are typically annual or triggered by a material event. A new investor at ten percent or above is a material event. Not disclosing it is a breach of the onboarding agreement and, in jurisdictions with enhanced beneficial-ownership registers, potentially a regulatory breach.
The third – and structurally most avoidable – mistake is entity proliferation without a documented group structure. Operators who create new entities for each product line, jurisdiction or funding round without a coherent group organogram are generating unanswerable questions for every bank, EMI and payments counterparty they approach. A clean, filed, up-to-date group structure chart is not a nice-to-have. It is an onboarding prerequisite.
In a recent matter, a payments company in the EU mid-market had its account suspended following a periodic review that flagged a mismatch between its stated business – licensed payment processing – and its actual transactional flow, which included a significant proportion of crypto-to-fiat conversion on behalf of VASP clients. The company had acquired that service line after opening the account and had not disclosed the change. We assisted in preparing a remediated disclosure package, including an updated business description, an amended AML programme and a revised transaction-monitoring policy. The account was reinstated within the relevant review period.
Client-Money Safeguarding and the Banking Layer
The interaction between client-money safeguarding obligations and the banking layer is a structuring question that sits at the intersection of payment regulation, custody law and corporate governance. Getting it wrong has consequences in two directions: the regulator can take enforcement action, and the bank can exit the relationship on risk grounds.
Under most regulated frameworks – including the applicable provisions of the MiCA regime, the FCA's payment-services rules, and the MAS Payment Services Act – a licensed entity holding client money must segregate those funds from proprietary assets and maintain them in a designated safeguarding account at a credit institution or in qualifying liquid assets. That segregation requirement is not simply an accounting entry. It requires a specific account structure at the banking layer: a named safeguarding account, typically at a bank that has acknowledged in writing that the funds are held on trust or in a regulatory-designated capacity.
Banks that provide safeguarding accounts to payment institutions and EMIs are performing a defined regulatory function. Not all banks offer this service. Those that do have their own onboarding requirements, often more stringent than their commercial banking equivalent, because the safeguarding relationship creates a direct fiduciary exposure for the bank if the payment institution fails. The operator must identify a bank willing to provide safeguarding infrastructure early in the structure-design process – not after the regulatory application is filed.
Operators we advise who treat the safeguarding account as a secondary concern consistently encounter the same problem: their regulatory licence is approved, but they cannot operationalise it because no qualifying credit institution will provide the safeguarding infrastructure in the timeline required. The licence sits unused while the account search runs in parallel. Sequencing the banking and licensing workstreams together, from the outset, is not an operational preference. It is a structural requirement.
The Travel Rule and What Banks Now Expect on Compliance
The Travel Rule – the FATF obligation to pass originator and beneficiary data alongside virtual-asset transfers above a defined threshold – has become a practical banking prerequisite, not merely a regulatory compliance item. Banks onboarding VASPs are now routinely asking for evidence of Travel Rule implementation as part of their institutional due diligence, because a VASP that cannot demonstrate Travel Rule compliance is not fully FATF-aligned and therefore represents a higher AML-risk counterparty.
The Travel Rule threshold varies by jurisdiction – it is not a globally uniform figure, and the applicable threshold in any given market should be verified against current local legislation. But the principle is consistent: the bank expects the VASP to have a technical solution in place, to have documented its approach to Travel Rule data exchange with counterpart VASPs, and to have a policy for handling transfers where the counterpart VASP does not participate in a recognised Travel Rule protocol.
In practice, this means the VASP's application package should include a Travel Rule policy, the name of the technical solution deployed, and a description of the sunrise issue management approach – that is, how the VASP handles transfers to and from jurisdictions where the Travel Rule is not yet enforced. Banks that have become sophisticated in VASP onboarding will test this documentation against their own AML team's knowledge of current Travel Rule coverage. A vague or template policy will be identified as such.
The broader compliance picture that banks now expect includes: a documented AML/CFT programme aligned to FATF Recommendation 15; a transaction-monitoring system with defined parameters and escalation procedures; a sanctions screening programme covering at minimum OFAC, EU consolidated, and UN designations; and a fit-and-proper assessment for the MLRO and senior management. This is the compliance baseline. Operators who present it as a complete, coherent package – rather than an assembly of separate documents without a unifying narrative – consistently achieve faster onboarding timelines.
A Common Assumption: One Offshore Licence Is Enough
A common assumption among founders building their first regulated crypto business is that a single offshore licence – a BVI VASP registration, a Cayman registration under the applicable CIMA framework, or a similar light-touch instrument – provides sufficient regulatory cover to open accounts globally and serve customers in major markets. It does not, and the consequences of acting on that assumption are operationally severe.
An offshore registration establishes the entity's home-jurisdiction compliance posture. It does not create a regulated presence in the markets where customers sit, and it does not satisfy the AML/CFT supervision expectations that tier-one banks apply to onboarding decisions. A BVI-registered VASP serving UK customers is subject to FCA financial-promotion rules and potentially to MLR registration obligations regardless of its BVI status. A Cayman-registered entity processing EUR flows for EU customers may face obligations under MiCA. An ADGM-licensed operator serving customers in Singapore is subject to MAS guidance on outsourcing and AML regardless of the ADGM licence.
The resolution is a jurisdiction map that begins with the question "where are my customers and what does that jurisdiction require of me?" rather than "what is the easiest licence to obtain?" Those are very different analytical starting points, and the first is the one that produces a banking-ready structure. In our practice, we map the licence stack across operating, custody and payment layers before the client commits capital to a structure – because the cost of restructuring after the fact consistently exceeds the cost of designing it correctly at the outset.
Related to this is the myth that a holding company in a favourable jurisdiction insulates the operating entity from scrutiny in other markets. Holding structures are well understood by bank compliance teams. The question they ask is not "where is the holding company?" but "where is the regulated activity occurring, and who is supervising it?" A holding company that does nothing is not a risk-mitigation tool. It is a transparency question.
Related at OBOLUS
- Banking, Payments & EMI Onboarding – our practice page on fiat-rails strategy for licensed digital-asset businesses
- Corporate bank account opening in Nigeria – jurisdiction-specific guidance for digital-asset operators seeking Nigerian fiat access
- Smart contract legal review in Guernsey – analysis of Guernsey's legal treatment of on-chain instruments and their transactional implications
FAQ
Why do banks close crypto company accounts?
Banks close crypto company accounts primarily because the transactional profile of the business becomes inconsistent with the risk model applied at onboarding. The most common triggers are: a mismatch between declared and actual transaction flows, failure to disclose changes in beneficial ownership or business activity, and an AML programme that does not keep pace with the evolving scope of the business. Periodic compliance reviews surface these gaps. The structural remedy is proactive disclosure and a business model that is legible to the bank's financial crime team at every stage of the company's development – not only at account opening.
How can a VASP onboard with an EMI?
A VASP onboards with an EMI by presenting the same core documentation the EMI would require from any high-risk financial-services customer: a complete corporate structure, a verified beneficial-ownership chain, a documented AML/CFT programme aligned to FATF standards, a Travel Rule policy, and evidence of the applicable VASP or CASP licence. The EMI will also assess the VASP's transaction-monitoring controls and may require enhanced due diligence on the VASP's own customers. The VASP should approach the EMI relationship as a regulated-entity-to-regulated-entity engagement, not as a standard commercial account opening. A well-prepared application package materially shortens the onboarding timeline.
What does client-money safeguarding require?
Client-money safeguarding requires a licensed entity to hold client funds separately from its own proprietary assets in a designated account at a qualifying credit institution. The account must be clearly identified as a safeguarding account, and the credit institution must typically acknowledge the arrangement in writing. The specific requirements – including permitted asset classes, acknowledgment obligations and reconciliation frequency – are set by the applicable regulatory regime, whether MiCA, the FCA payment-services rules or another framework. Operationally, this means the safeguarding banking relationship must be secured before the licensed entity can accept client funds – making it a pre-launch structuring requirement, not a post-licence administrative task.
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 capital to a structure – because redesigning after the fact costs more than designing correctly from the start. We also work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when banking disputes escalate to litigation. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – advising on the intersection of smart-contract architecture, payment-system design and multi-jurisdiction regulatory structuring for digital-asset operators.
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.