Fiat banking is the pressure point that breaks most digital-asset businesses before regulatory enforcement ever does. An exchange can hold a VASP (virtual asset service provider) licence, pass its KYC audit and maintain clean on-chain records — and still find its payment accounts closed, its settlement delayed and its users locked out of withdrawal, all because the banking layer was built on the wrong structure. The question this guide addresses is not whether a crypto business needs banking access. It is how to build that access on a legal foundation that survives compliance reviews, cross-border regulatory friction and the next round of de-risking.
The short answer: securing fiat on/off-ramp banking requires a sequential approach — entity structure, licence mapping, banking-partner selection and ongoing compliance — each step resolving a specific risk before the next step is attempted. Skipping any step does not save time; it compounds the remediation cost later. This guide walks through each stage, identifies the common structural error at that stage, and explains the cross-border considerations that distinguish a viable rails architecture from one that collapses on the first correspondent-bank review.
Step 1: Understand Why Fiat Rails Fail for Crypto Businesses
Most fiat-rail failures are structural, not incidental — the banking relationship was built on a foundation the bank could never sustain under its own compliance obligations. Retail and commercial banks operate under AML/CFT (anti-money laundering and counter-financing of terrorism) obligations calibrated for traditional payment flows. A crypto business presenting as a general corporate account — without the transaction-monitoring architecture, counterparty disclosure and licensing documentation that regulators now expect — triggers de-risking. The result is an account closure that appears without warning but was, in retrospect, predictable.
Three structural causes repeat in our practice. First, the entity presenting to the bank is not the regulated entity: a holding company applies for the account, but the regulated VASP sits in a subsidiary. Banks review the applicant, not the group. Second, the business model is described at a high level rather than at the product level: "payments and exchange services" tells a compliance officer nothing; a specific flow-of-funds schedule with jurisdictional scope does. Third, the business holds no licence or holds a licence in a jurisdiction the bank's correspondent network cannot clear — even a credible licence in a jurisdiction outside the correspondent's risk appetite produces the same result as no licence at all.
Understanding the mechanics of de-risking is the precondition for the steps that follow. Each subsequent step addresses one of the three causes above.
Step 2: Structure the Regulated Entity Before Approaching a Bank
Banking onboarding begins with the entity design, not with a bank relationship manager. The entity that applies for the account must be the entity that holds — or is applying for — the relevant licence, and its constitutional documents, UBO (ultimate beneficial owner) register and beneficial-ownership disclosure must be current and consistent with what the bank will see in its own KYC process.
The regulated basis for this step sits at the intersection of FATF Recommendation 15 (which requires VASPs to be licensed or registered and subject to AML/CFT supervision) and the AML/KYC due-diligence obligations that banks themselves carry. A bank onboarding a VASP is, in effect, treating that VASP as a higher-risk customer. It will conduct enhanced due diligence. The documents it requests — ownership structure charts, source-of-funds evidence, a compliance-manual extract, a list of supported assets — are not administrative formalities. They are the bank's own regulatory record.
The cross-border note is material here. Where the banking entity and the licensed entity sit in different jurisdictions — a common structure for operational, tax or cost reasons — the bank's compliance team will need a clear, documented explanation of why the group is structured that way and how regulatory obligations flow from the licence-holder to the banking entity. Absent that, the structure reads as obfuscation rather than legitimate corporate planning.
Common mistake at this step: registering the banking entity in one jurisdiction and the licensed entity in another without a formal group-structure memorandum that explains the relationship. A two-page flow chart is not enough. The bank needs a written narrative of the group's regulated perimeter, how client funds move and where the licence sits.
Step 3: Map the Licence Stack Across Operating, Custody and Payment Layers
A single licence rarely covers the full scope of a crypto business's regulated activities — and the banking layer requires evidence of coverage at every activity level the bank can see in the transaction flow. Before approaching a financial institution, an operator must identify which activities it conducts, which regulatory regimes govern each activity, and whether each activity is covered by an existing licence or by a licence-in-progress.
The three layers that matter most to a banking counterpart are: (1) the operating layer — the exchange or brokerage function, typically licensed as a VASP or equivalent under the relevant national regime; (2) the custody layer — the holding of client digital assets, which is a separately regulated activity under most flagship regimes including MiCA (the EU's Markets in Crypto-Assets Regulation), the VARA regime in Dubai, and the MAS (Monetary Authority of Singapore) Payment Services Act framework; and (3) the payment layer — the receipt and transmission of fiat, which may require an EMI (electronic money institution) licence, a payment-institution licence, or a money-services-business registration depending on the jurisdiction of the bank and the jurisdiction where the fiat originates and terminates.
In our cross-border practice, the payment layer is the most frequently underweighted. An operator holds a VASP licence and assumes that covers the receipt of fiat from clients. It does not, in most flagship regimes. The receipt of funds and the issuance of an electronic balance — even temporarily, during conversion — engages payment-services law. The bank's compliance team will ask what licence covers that activity. If the answer is "our VASP licence," the onboarding typically stalls.
Common mistake at this step: treating the licence stack as a post-onboarding compliance project rather than a pre-banking prerequisite. A bank that discovers mid-relationship that its client is conducting unlicensed payment activity will exit the relationship, not wait for the licence application to resolve.
For a scoped assessment of your licence stack before you approach a banking partner, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts — the entity, the user base, the banking geography — change the analysis materially.
Step 4: How to Select the Right Banking Partner for Crypto Fiat Rails
Selecting a banking partner for a digital-asset business is not a product comparison — it is a risk-appetite match. The question is not which bank offers the lowest fees; it is which institution's compliance policies, correspondent relationships and jurisdictional reach are compatible with the operator's business model, client base and transaction volumes.
The relevant financial institutions fall into three broad categories. Traditional commercial banks with a published crypto-engagement policy represent the most stable but hardest-to-access tier. Their correspondent networks are deep, their SWIFT access is unencumbered and their regulatory standing gives them the widest clearing reach — but their onboarding timelines are typically measured in months and their eligibility criteria are the most exacting. EMIs licensed under the EU's Payment Services Directive or its national equivalents represent the middle tier: faster to onboard, increasingly crypto-familiar, but with correspondent-bank dependencies that can produce secondary de-risking. Specialist payment institutions and crypto-native banks — licensed under regimes such as the AIFC/AFSA framework in Kazakhstan, the MFSA's payment-institution track or equivalent structures in Seychelles and other offshore payment hubs — represent the most accessible entry point but carry the narrowest clearing reach and the highest correspondent-bank risk for high-value or cross-currency flows.
The cross-border consideration is decisive. A business serving users across the EU, the Gulf and Southeast Asia will need banking access in multiple currency zones. No single banking partner — even a well-resourced EMI — can typically provide clean clearing across all three. The practical architecture is a primary banking relationship in the entity's home jurisdiction supported by secondary EMI or payment-institution relationships in each material currency zone. Each layer requires its own onboarding, its own AML documentation and its own maintenance obligation.
Common mistake at this step: approaching a single bank without a fallback and without a correspondent-bank analysis. When the primary relationship fails — and a meaningful proportion do fail, often without warning — an operator with no secondary rail faces a service interruption that is immediately visible to clients. The time to build the secondary relationship is before it is needed.
Step 5: What Does a Bank's Compliance Team Actually Need?
A banking onboarding package for a digital-asset business is substantively different from a standard corporate account-opening submission, and assembling it correctly determines whether onboarding proceeds or stalls at the compliance gate. The package must answer — pre-emptively, in writing — every question a compliance officer applying enhanced due diligence to a higher-risk VASP customer will ask.
The core components are standard across most institutions: corporate constitutional documents, UBO register and certified identification for all material beneficial owners and directors, a current AML/KYC policy, a compliance officer's CV, a transaction-monitoring procedure extract and a funds-flow schedule showing how fiat enters, how it is converted, where it is held and how it exits. These are the minimum. For a digital-asset business, the bank will additionally want: a copy of the current licence or registration certificate, a description of the supported assets (fiat pairs, stablecoin involvement, whether the operator touches privacy coins), a geographic scope statement identifying where clients are located and where transactions originate, and — increasingly — a summary of the operator's travel-rule compliance posture.
The Travel Rule (the obligation, derived from FATF Recommendation 16, to pass originator and beneficiary data alongside a virtual-asset transfer) has moved from a theoretical compliance concern to a live onboarding criterion. Banks and EMIs that serve VASPs are now routinely asking whether the VASP has a compliant travel-rule solution in place, because the bank's own regulators expect it to know that its VASP clients are not the weak link in the chain. An operator that cannot answer this question clearly will find onboarding paused while it does.
Common mistake at this step: submitting a template AML policy rather than a policy that reflects the operator's actual business model and transaction profile. A compliance officer reviewing a policy that could belong to any business — with no reference to the operator's specific assets, client types or monitoring logic — will treat it as evidence of a compliance function that exists on paper only.
Step 6: How to Maintain Banking Access After Onboarding
Securing a banking relationship is not a one-time event. The ongoing compliance obligations that accompany a bank account for a digital-asset business are more intensive than those for a conventional corporate, and failure to meet them is a leading cause of post-onboarding account closure.
The key obligations are: periodic AML/KYC refreshes (the bank will request updated UBO confirmation, audited financials and a compliance-programme update on a cycle it sets, typically annually or more frequently for higher-risk accounts); transaction-monitoring cooperation (where the bank's transaction-monitoring flags a pattern, the operator must respond promptly with documentation — delays are treated as uncooperative conduct); geographic-scope notifications (material changes to the operator's user geography — expansion into a new market, particularly a higher-risk jurisdiction — require advance notice, not retrospective disclosure); and product-change notifications (adding a new supported asset, launching a staking product or introducing a peer-to-peer function changes the risk profile and the licence coverage question; the bank must be informed).
Operators we advise routinely underestimate the relationship-management dimension of banking. A bank does not close accounts purely on regulatory grounds; it closes them when the risk-management cost of maintaining the relationship — in staff time, compliance exposure and correspondent-bank friction — exceeds the commercial value. The preventive measure is proactive communication: an annual compliance summary sent to the bank's relationship manager before the bank's own review cycle, not in response to a query.
Common mistake at this step: treating the banking relationship as passive once it is established. An operator that goes silent after onboarding, submits late AML refreshes and fails to notify product changes is signalling, to the bank's compliance function, that its internal controls are as passive as its communication. That signal produces account reviews that typically resolve in the bank's favour, not the operator's.
If a prior banking relationship has stalled or an account has been closed, a structural review can identify the cause and the remediation path — contact OBOLUS at info@oboluslaw.com. A second read of the onboarding package frequently surfaces the structural issue the first submission missed.
Step 7: How Does the Cross-border Reality Change the Fiat-Rail Architecture?
A digital-asset business operating across multiple jurisdictions faces a fiat-rail architecture problem that no single banking relationship resolves — and the legal complexity compounds at every layer. The entity jurisdiction, the user jurisdiction, the transaction-origination jurisdiction and the settlement jurisdiction can each engage a different regulatory regime, a different AML obligation and a different banking-risk classification.
The starting point is a regulatory perimeter map: a jurisdiction-by-jurisdiction analysis of which activities the operator conducts in each market, which licence or exemption covers each activity and whether the fiat flow associated with that activity can be cleared through the proposed banking structure. This is not a theoretical exercise. A business that onboards EU clients through a bank in Singapore without a European payment-institution licence or an EMI licence may be conducting regulated payment activity in the EU without authorisation — a position that exposes the operator to regulatory action in the EU regardless of where the bank sits.
We regularly advise on structures where the banking architecture is designed around the regulatory perimeter map: a primary regulated entity in the jurisdiction where the most demanding regulatory requirements apply, supported by licensed payment intermediaries in secondary markets, with the fiat-flow design built to ensure that each leg of the transaction sits within the licensed perimeter of one of the group entities. This is materially more complex to build than a single offshore account — but it is the architecture that survives correspondent-bank review, regulatory examination and the periodic de-risking exercises that banks conduct across their entire book.
One anonymized micro-matter illustrates the stakes. In a recent mandate, a payments company had structured its fiat rails through a single EMI in a smaller EU member state. When that EMI's own correspondent bank exited its crypto book — a de-risking decision made at the correspondent level, not by the EMI — the operator lost SEPA clearing across all of its EU users simultaneously. We engaged allied counsel in the relevant jurisdiction, identified two alternative EMI relationships with distinct correspondent chains and rebuilt the fiat-rail architecture across a parallel banking path within the operator's existing licensed structure. The operational disruption was measured in weeks rather than months because the licensing groundwork was already in place. Without that groundwork, the reconstruction would have required a new licence application first.
The cross-border lesson is direct: single-point-of-failure fiat architecture is an operational and legal risk, not just a commercial inconvenience. Building redundancy into the banking layer, across distinct correspondent chains, is a legal-compliance measure as much as an operational one.
A Common Assumption: Why One Offshore Licence Is Not Enough
A persistent assumption in the digital-asset industry is that a single offshore licence — obtained in a fast-track jurisdiction with minimal capital requirements — provides adequate legal cover to serve clients globally and to access banking in the major currency zones. This is incorrect, and the error is expensive when it surfaces during banking onboarding rather than earlier in the planning process.
The reason is structural. A licence granted in Jurisdiction A covers regulated activities conducted in Jurisdiction A under Jurisdiction A's rules. It does not create a regulatory permission to conduct those same activities in Jurisdiction B on Jurisdiction B's terms. Where Jurisdiction B's rules require local authorisation — and most flagship regimes, including MiCA across the EU, the VARA regime in Dubai and the MAS Payment Services Act in Singapore, require local authorisation rather than accepting foreign licences by default — the offshore licence is not a substitute. It is not recognised.
Banks understand this. A correspondent bank in Frankfurt reviewing a VASP client that holds a single offshore licence but has material European user exposure will identify the regulatory gap before the operator does. The account application will not proceed, or if it does, it will be suspended at the correspondent-bank level rather than at the direct banking relationship. The operator will not always be told why.
The practical answer is the licence stack described in Step 3 above: coverage at each activity level, in each material operating jurisdiction, with a banking architecture designed around that coverage. This takes longer to build than a single offshore registration. It costs more. It is also the only structure that sustains fiat-rail access as regulatory expectations continue to tighten across every major banking jurisdiction.
To map the licence, banking and tax stack for your build before you commit resources, write to info@oboluslaw.com or message us at t.me/oboluslaw.
Related at OBOLUS
- Banking, Payments & EMI Onboarding for Digital-Asset Businesses – the full practice overview for licensing, banking structure and EMI onboarding strategy.
- Payment Institution Licensing in Seychelles – the regulatory framework, application process and suitability analysis for offshore payment-institution licences.
- Utility Token Legal Opinion for Regulated Entities – token classification analysis for operators that need a defensible legal position before approaching a bank or regulator.
FAQ
Why do banks close crypto company accounts?
Banks close crypto accounts primarily because of structural compliance gaps, not necessarily because of regulatory prohibitions. The most common causes are: the presenting entity is not the licensed entity; the business model description is too vague to support the bank's own AML documentation; the licence held does not cover the full scope of activities the transaction flow reveals; or the operator fails to respond promptly to periodic compliance requests. Each cause is addressable before onboarding if the structure is reviewed in advance.
How can a VASP onboard with an EMI?
An EMI treats a VASP as a higher-risk institutional client and will apply enhanced due diligence. The VASP must present its current licence or registration, a detailed funds-flow schedule, a current AML/KYC policy specific to its business model, travel-rule compliance documentation and UBO disclosure to the beneficial-owner level the EMI's regime requires. Some EMIs also require a third-party AML audit for VASPs above a transaction-volume threshold. Preparation of the full onboarding package before approach shortens the process materially.
What does client-money safeguarding require?
Client-money safeguarding requires that fiat received from clients is held separately from the operator's own funds, typically in a designated safeguarding account at a credit institution or through qualifying insurance. The specific obligation depends on the payment-services licence or EMI licence applicable to the operator. Under most flagship regimes, including the EU Payment Services Directive framework and its national implementations, the safeguarding obligation attaches as soon as client fiat is received, regardless of how quickly it is converted. Breaching the obligation is a regulatory matter as well as a contractual one.
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 — 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 Victor Olsen, Regulatory & Compliance Analyst — specialises in VASP licensing analysis, AML/CFT compliance design and cross-border regulatory perimeter mapping for digital-asset businesses.
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.