For an established crypto exchange, custodian, or payments operator, the absence of a working fiat account is not a compliance inconvenience – it is an existential business risk. Banks and electronic money institutions (EMIs – licensed entities that issue e-money and operate payment accounts) continue to apply heightened scrutiny to digital-asset businesses, and an operator that built its licence stack without a parallel banking strategy often discovers the problem only when a correspondent withdraws or an application is declined without explanation. The window to act is shorter than most founders expect.
Corporate bank account opening for an established operator is a structured legal and commercial process, not a form-filling exercise. It requires matching the operator's regulatory status, AML posture, and business model to the right institution – whether a tier-one bank, a regional lender, or an EMI with an appetite for crypto banking (the provision of fiat payment infrastructure to virtual-asset businesses). Getting that match wrong costs months. Getting it right opens stable fiat rails (the banking and payments infrastructure that connects a crypto business to the traditional financial system) and allows the business to scale.
This page sets out the regulated basis for banking access, the practical application process, the cross-border decisions that operators routinely face, and the structural mistakes that cause accounts to close. A decision matrix at the end maps operator profiles to the most realistic institutional paths.
Why Banking Access Is a Regulated – Not Just Commercial – Question
Banks do not close crypto accounts arbitrarily. They close them because their own regulators – the FCA, the ECB's supervisory arm, the MAS, the NYDFS, and others – treat a crypto business as a high-risk client category requiring enhanced due diligence that most correspondent banking relationships cannot support economically. The legal basis is rooted in FATF Recommendations, particularly the provisions addressing virtual asset service providers (VASPs – entities that conduct exchange, transfer, or custody of virtual assets on behalf of clients) and the obligation of financial institutions to perform enhanced customer due diligence on that category.
An established operator that already holds a licence – a VASP registration under the BVI FSC, a CASP authorisation under MiCA, or a VARA activity licence in Dubai – has a significant advantage over an unlicensed entity. But a licence alone does not compel a bank to open an account. What it does is change the conversation from "do you have regulatory oversight" to "can we manage the residual compliance burden within our framework." That second conversation requires legal preparation, not just a licensing certificate.
In our practice, we regularly advise operators who underestimated this distinction. They secured a licence in a credible jurisdiction, then discovered that their banking applications were stalling because the institutional narrative – the way the business described its compliance architecture, its AML controls, and its on-chain monitoring – was not structured to address the bank's own risk committee concerns.
The Travel Rule (the obligation, derived from FATF Recommendation 16, to pass originator and beneficiary data with a virtual-asset transfer) is now a central diligence item for any bank reviewing a VASP client. An operator that cannot demonstrate a functioning Travel Rule compliance programme will find banking access materially harder across every jurisdiction.
What Institutions Actually Look For During Onboarding
Every institution performing due diligence on a crypto business is working through the same structural questions, even if the format differs between a Swiss cantonal bank, an EU EMI, and a Singapore-licensed major payment institution. The first question is always jurisdictional: where is the operating entity incorporated, where is it licensed, and where do its clients and liquidity sit?
A business incorporated in the Cayman Islands, licensed under the CIMA VASP regime, serving EU retail users, and seeking to bank in the Netherlands faces a multi-layer scrutiny problem. The Dutch bank must satisfy its own prudential supervisor – the DNB, acting as an NCA under the MiCA regime and the broader AML framework – that it understands the risk of the client's user base, not just the client itself. That is a materially different analysis from onboarding a domestic payments firm.
Institutions consistently weight four factors above all others:
- The quality and completeness of the operator's AML/KYC programme, including its transaction monitoring system and its procedures for high-risk wallets and counterparties.
- The operator's licensing status in the jurisdiction where it operates – and whether that licence is current and in good standing.
- The operator's on-chain transparency posture: whether it uses a recognised blockchain analytics provider and can produce monitoring reports on request.
- The concentration of the operator's business in sanctioned jurisdictions or with high-risk counterparties flagged on international designation lists.
Operators we advise routinely underestimate the fourth factor. A business that has no direct sanctions exposure but operates a cross-border corridor that routes through a flagged jurisdiction will trigger the same review as an operator with direct exposure. The bank cannot easily distinguish the two at the point of initial onboarding.
Preparing a structured compliance pack – a legal-grade document that addresses each of these factors in the bank's own risk language, not the operator's marketing language – is the single most impactful step in the pre-application phase. We have seen applications that stalled for quarters move to conditional approval within weeks after the compliance narrative was restructured.
Contact OBOLUS before you submit the next application. The application process above follows the standard path. Your entity structure, licence combination, and user geography change the analysis entirely. For a scoped pre-application review, contact OBOLUS at info@oboluslaw.com.
EMI Onboarding as an Alternative – and Often Faster – Path
EMI onboarding (the process by which a crypto business establishes a payment account relationship with a licensed electronic money institution) has become the primary fiat-rails solution for operators that cannot access tier-one commercial banking directly. EMIs operating under MiCA's predecessor regimes and under the Electronic Money Directive 2 have, in many cases, developed VASP-specific onboarding programmes that tier-one banks have not.
The practical advantage is speed and fit. An EMI that has already built a compliance programme for crypto-business clients can assess an operator's AML pack, conduct enhanced due diligence, and open a multi-currency payment account on a timeline that commercial banks rarely match. The trade-off is capacity: EMIs operate on payment account infrastructure, not full banking infrastructure. They can handle client-money receipt, payment execution, and fiat conversion, but they typically cannot provide credit facilities, trade finance, or the correspondent banking relationships that a large exchange ultimately needs.
For most growth-stage established operators, the right answer is a tiered structure: an EMI account for operational payment flows, combined with a banking relationship in a jurisdiction where the operator's licence footprint is strong. In our cross-border practice, we map that combination before either application is filed, because the two institutions will conduct independent due diligence and an inconsistency between them creates a risk that neither account is opened.
The Payment Services Act in Singapore, which MAS administers, and the VARA transfer and settlement activity licence in Dubai both create local frameworks within which an EMI-equivalent relationship can be structured for operators based in those hubs. An operator pursuing a cross-border structure through two or more of these hubs should treat banking and payment-licence mapping as a single integrated exercise, not two separate work streams.
How Should an Established Operator Approach a Cross-Border Account Structure?
The most consequential banking decision an established operator makes is not which institution to approach – it is which entity to use as the account-holding vehicle and which jurisdiction to anchor it in. That decision has regulatory, tax, and AML consequences that persist for the life of the business.
An operator holding a MiCA CASP authorisation passported across the EU has, in principle, the strongest case for opening a commercial bank account in any EU member state. The CASP passport signals to the bank that an NCA has reviewed and approved the operator's compliance architecture. But the practical reality is that banking appetite for VASPs varies significantly across EU member states, and the jurisdiction in which the CASP was initially authorised – say, Lithuania under the Bank of Lithuania's regime – may not be the jurisdiction with the deepest banking relationships for a particular business model.
Operators with ADGM or VARA licences in the UAE face a different set of choices. The DIFC Courts and the broader UAE legal infrastructure give operators in that hub access to a strong dispute-resolution environment, but banking for a UAE-licensed crypto entity is structurally dependent on relationships with UAE-domiciled banks that have their own VASP appetite frameworks. Operators we advise in Dubai frequently maintain a parallel EU account structure for EUR and GBP flows, with the UAE account handling AED and regional settlement.
For operators with a BVI or Cayman incorporation and a licensing profile that spans multiple jurisdictions, the cross-border account structure question is at its most complex. Allied counsel in the relevant jurisdiction can navigate local banking regulations, but the structural decision – which entity holds which account, which flows route through which account, and how the group treasury function is managed – requires an integrated legal and commercial view that a single-jurisdiction banking adviser cannot provide.
In a recent matter, a licensed exchange operating across three jurisdictions had its primary payment account suspended after a correspondent bank review. We worked through the entity structure, identified that the operating entity was receiving flows from a wallet cluster that appeared on a commercial sanctions screening list, and coordinated a remediation plan across the operator's AML team and allied counsel in the banking jurisdiction. The account was reinstated within a defined remediation period and the operator implemented a revised wallet-screening protocol that addressed the correspondent's specific concern.
Common Structural Mistakes That Get Accounts Closed
Account closures at established operators are rarely random. They follow a recognisable pattern that we have observed across multiple matters. Understanding that pattern is the most direct route to preventing the next closure.
The first and most common mistake is entity drift: the legal entity that holds the account grows in scope – adding new products, new jurisdictions, new user types – without updating the account-opening documentation filed with the institution. The bank's risk model was built on the operator's profile at the point of onboarding. When the actual business diverges from that profile, the compliance gap is picked up either in a periodic review or by a transaction monitoring flag. The account is then suspended pending a re-documentation exercise that the operator is often not prepared for.
The second mistake is inadequate AML programme depth for the account's actual transaction volume. A programme that was proportionate at a lower transaction volume may not satisfy the institution's expectations once volumes scale. Regulators across the leading hubs expect proportionality: an established operator processing significant daily flows should have a transaction monitoring system, a dedicated compliance officer, and documented escalation procedures that match that scale.
The third mistake – and the one most often overlooked – is failing to maintain a documented relationship with the account manager and compliance team at the institution. Banks are not monolithic. The risk committee that reviews an account closure has, in most cases, a different team from the relationship manager who opened it. Operators that treat banking as a utility relationship rather than a managed compliance partnership are consistently more exposed to closure without warning.
A common assumption in the market is that a single offshore licence is sufficient to maintain banking across multiple jurisdictions. It is not. Banking relationships are jurisdiction-specific compliance assessments. An operator with a CIMA VASP licence serving EU clients through a Cayman entity will face the same enhanced due diligence from a European bank as an unlicensed operator, because the Cayman licence does not confer regulatory equivalence within the EU's AML framework. The structural answer is a licence profile that matches the jurisdictions in which the operator actually operates – not just the jurisdiction that was most convenient to license in.
Decision Matrix: Which Banking Path Fits Which Operator Profile?
Not every established operator faces the same banking problem, and the right institutional path depends on the operator's specific licence, entity structure, and business model. The following profiles represent the patterns we most frequently encounter in practice.
Profile A – EU CASP-licensed exchange with a passportable authorisation. This operator's strongest path is a banking relationship in the member state of authorisation, combined with an EMI account in a second EU jurisdiction for operational payment flows. The MiCA passporting mechanism is a genuine advantage here, but it requires proactive communication of the CASP authorisation to the target bank before the application is filed. Timeline to first account: variable by institution, but typically shorter than for an unlicensed entity. Key risk: member-state banking appetite for VASPs is not uniform; jurisdiction selection matters.
Profile B – UAE-licensed operator (VARA or ADGM) with a global user base. The UAE hub provides a strong regulatory anchor for regional banking, but the operator's EU and UK user-flow requires a parallel account structure in a jurisdiction that recognises the UAE licensing regime as adequate for AML purposes. Key risk: correspondent banking for AED-denominated flows remains constrained; the EU account structure must be established independently, typically through an EMI-to-bank escalation path as volumes grow.
Profile C – Offshore-incorporated operator (BVI/Cayman) seeking to upgrade banking access. This operator faces the most complex path. The offshore incorporation and single-jurisdiction licence create an entity that most tier-one banks treat as highest-risk regardless of the operator's actual compliance maturity. The strategic response is a licensing upgrade – adding an onshore licence in a MiCA-equivalent or reciprocal regime – combined with a re-documentation exercise for the new entity before banking applications are filed. Timeline: determined by the licensing upgrade path, not by the banking application itself.
Profile D – Singapore-licensed DPT service provider seeking multi-currency rails. MAS-licensed operators have access to a well-developed EMI ecosystem within Singapore, but multi-currency rails for USD and EUR flows typically require a parallel banking relationship in a jurisdiction that recognises MAS oversight. The Payment Services Act licensing framework is respected in most leading banking jurisdictions as a credible supervisory signal. Key risk: MAS authorisation timelines are extended; operators in the licensing pipeline should not begin banking applications until the licence is granted, because a pending-licence status is not equivalent to a granted licence for banking diligence purposes.
If a prior application stalled, a banking account was suspended, or the operator is building a new entity for a licensing upgrade, a second structural review can identify the specific gap and the route to resolution. To map the licence, banking, and payment stack for your build, write to OBOLUS at info@oboluslaw.com.
What Does Client-Money Safeguarding Require for a Licensed Operator?
Client-money safeguarding (the obligation to hold client funds in a segregated account separate from the operator's own funds, so that client balances are protected in an insolvency) is a regulated obligation across every leading licensing regime, not a discretionary best practice. Under MiCA, under the VARA regime, under the Payment Services Act in Singapore, and under the FCA's rules in the UK, a licensed operator that holds client fiat balances must maintain those balances in a designated safeguarding account at an approved credit institution or, in some regimes, in a qualifying money-market instrument.
The practical banking consequence is that a licensed operator needs at least two distinct account relationships: an operational account for the business's own funds, and one or more segregated safeguarding accounts for client balances. Many institutions that are willing to provide operational accounts are not willing to operate as the safeguarding bank for a crypto operator's client balances, because the safeguarding obligation imposes additional regulatory obligations on the bank itself.
Operators that structure their account-opening exercise without addressing safeguarding from the outset regularly discover, at a late stage of due diligence, that the institution they targeted for operational banking is not willing to hold segregated client funds. The result is either a delayed launch or a sub-optimal safeguarding arrangement that may not satisfy the operator's licensor.
In our practice, we structure the banking approach to address operational and safeguarding requirements in a single coordinated outreach, targeting institutions that have demonstrated an appetite for both. This requires a clear articulation of the expected volume of client balances, the source of those balances, the withdrawal and redemption mechanics, and the regulatory regime under which the safeguarding obligation arises. That documentation is not standard in most banking application packs – but it is what the institution's compliance team will ask for if it is not provided upfront.
Related at OBOLUS
- Banking, Payments & EMI Onboarding for Digital-Asset Businesses – the practice-area overview covering the full institutional access framework for crypto operators.
- De-Risking and Account Closure Defence in Seychelles – legal strategies for operators facing account termination in an offshore banking jurisdiction.
- Corporate Bank Account Opening for Early-Stage Founders – the comparable guide for operators at the pre-licence or seed stage.
FAQ
Why do banks close crypto company accounts?
Banks close crypto accounts primarily because of the enhanced due diligence burden that digital-asset businesses impose under AML frameworks such as FATF Recommendation 15 and its domestic implementations. Specific triggers include entity drift (the business has changed materially since onboarding), inadequate transaction monitoring documentation, exposure to flagged wallet clusters, and the bank's correspondent banking relationships placing restrictions on the category. A well-prepared compliance pack and an ongoing relationship management programme significantly reduce this risk, but do not eliminate it entirely.
How can a VASP onboard with an EMI?
A VASP seeking an EMI account should prepare a structured onboarding pack covering its regulatory status, AML/KYC programme, transaction monitoring system, Travel Rule compliance posture, and expected account flows. EMIs that have developed VASP-specific programmes will assess these against their own risk appetite. A licensed VASP – particularly one holding a MiCA CASP authorisation, a VARA activity licence, or a MAS DPT service licence – has a materially stronger case than an unlicensed operator, but the quality of the compliance documentation determines the outcome more than the licence title alone.
What does client-money safeguarding require?
Client-money safeguarding requires a licensed operator to hold client fiat balances in a segregated account at an approved credit institution, separate from the operator's own operating funds. The specific requirements vary by regime – MiCA, VARA, the Payment Services Act in Singapore, and the FCA framework each set their own conditions – but the core obligation is the same: client balances must be protected from the operator's insolvency. Identifying a banking partner willing to act as a safeguarding institution, alongside the operational account, is a critical step in the pre-launch banking strategy.
OBOLUS is an independent digital-asset law boutique acting exclusively for businesses. We advise exchanges, custodians, token issuers, payment operators, and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the banking, payments, and compliance architecture that surrounds those activities. Digital assets are the whole of our practice. We map the licence stack across operating, custody, and payment layers before a client commits – because the sequencing of those decisions determines the banking outcome. Our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when recovery is required. To discuss your situation, contact info@oboluslaw.com or reach us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in the AML and licensing frameworks that govern banking access for digital-asset businesses across the EU, UAE, 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.