Operating without a correctly structured banking relationship is one of the fastest ways a digital-asset business stalls. An exchange that cannot settle fiat, a custodian whose correspondent line disappears at 48 hours' notice, a token issuer whose treasury account is closed mid-round – these are not edge cases. They are the recurring reality for institutional operators who treat corporate bank account opening (the formal onboarding of a business entity to a credit institution or e-money provider for settlement and custody of fiat) as a back-office afterthought rather than a regulated legal process.
Regulators and compliance officers at banks assess digital-asset businesses against a layered set of criteria: licensing status, AML programme quality, beneficial ownership clarity and the jurisdictional profile of the entity's counterparties. A business that cannot address each criterion in a single, coherent onboarding file will either receive a rejection or, worse, be onboarded provisionally and exited months later. The commercial damage of the latter outcome is routinely greater than the former. This page sets out the regulated basis for institutional bank onboarding, the practical process, the cross-border considerations, and the structural choices that determine whether a relationship holds.
Why Banks Exit Digital-Asset Clients – and Why It Matters Now
Banks exit digital-asset clients not because they dislike the sector but because the compliance cost of retaining a poorly documented client exceeds the revenue. That calculus has sharpened as supervisors in every major financial center have made clear that crypto-exposed correspondent lines are a supervisory focus. An institutional operator that presents itself without a clearly articulated regulatory perimeter – licence type, product scope, user jurisdiction map, AML programme with named MLRO and transaction-monitoring vendor – will fail an internal credit-risk review before it reaches a relationship manager.
The consequence is not merely inconvenience. Without stable fiat rails, a business cannot settle with liquidity providers, cannot pay staff or vendors in fiat, and cannot offer a deposit or withdrawal channel to institutional counterparties. The FATF Travel Rule – the obligation to pass originator and beneficiary data with a virtual-asset transfer – adds a second layer of scrutiny: a bank that cannot verify a VASP counterparty's Travel Rule compliance will treat every transfer as elevated-risk. In practice, operators we advise regularly find that their banking rejections trace to a gap at the AML-programme or Travel Rule documentation layer rather than to the business model itself.
The process above describes the standard path. Your facts – the entity's licence, the user base geography, the counterparty mix – change the analysis entirely. For a scoped assessment of your onboarding position, contact OBOLUS at info@oboluslaw.com.
What Is the Regulated Basis for Fiat Onboarding of a Digital-Asset Business?
A digital-asset business seeking corporate banking must satisfy two parallel compliance regimes simultaneously: the bank's own AML and risk-appetite framework, and the regulatory expectations set by the regulator of the digital-asset entity itself. Neither can be addressed in isolation. A VASP (virtual asset service provider) that holds a licence under, say, the MAS Payment Services Act in Singapore, or under the VARA regime in Dubai, or has obtained a CASP authorisation (Crypto-Asset Service Provider authorisation) under MiCA via a national competent authority in the EU, signals to a prospective bank that supervisory oversight exists and that an AML programme meeting FATF standards has been assessed. That signal is the single most important variable in the onboarding conversation.
Where no licence exists – because the operator is pre-licence or operates in a jurisdiction without a VASP-specific regime – the onboarding burden falls entirely on the entity's own governance documentation. In our practice, that situation rarely results in a relationship with a regulated credit institution of any scale. The practical answer is to sequence the banking mandate after the licensing mandate, not before it.
The FATF framework – specifically the recommendations addressing virtual assets and VASPs, including the Travel Rule – sets the international baseline that national regulators have adopted in varying forms. Banks in jurisdictions that have implemented FATF Recommendation 15 requirements will ask for evidence of Travel Rule compliance as part of due diligence. Operators who cannot produce that evidence are categorised as high-risk or declined.
How Does EMI Onboarding Differ from Traditional Banking for Crypto Businesses?
An EMI (electronic money institution) offers a regulated but structurally different product from a commercial bank: it can issue electronic money, hold client funds in safeguarded accounts and execute payment transactions, but it typically cannot provide credit or operate within the same deposit-protection schemes as a deposit-taking bank. For many digital-asset operators, an EMI relationship is the accessible first step toward stable fiat rails – and in several European jurisdictions, EMI onboarding has historically moved faster than full commercial banking.
The regulatory basis differs by jurisdiction. In the EU, the EMI regime operates under the Electronic Money Directive and the Payment Services Directive framework, with national competent authorities supervising authorised institutions. An EMI passporting across the EU/EEA under MiCA-adjacent payment rules can serve an operator's EU fiat settlement needs from a single regulated entity. In the UK, the FCA authorises EMIs under the Electronic Money Regulations; the FCA's separate cryptoasset registration under the Money Laundering Regulations is a parallel track.
The practical distinction matters for institutional operators. A commercial bank relationship typically unlocks SWIFT access, correspondent lines and potentially credit facilities. An EMI relationship typically covers SEPA, CHAPS or faster-payment settlement within its operating scope. Operators we advise frequently need both: an EMI for operational payment flow and a commercial banking relationship for treasury, prime brokerage counterparty settlement and larger-value wire infrastructure. The decision between them – or the sequencing of both – depends on the operator's settlement volumes, counterparty profile and jurisdictional footprint.
What Does a Successful Institutional Onboarding File Contain?
A well-constructed onboarding file does one thing: it converts the bank's compliance checklist into a structured narrative about the business, its controls and its risk profile. Banks do not make credit decisions on verbal representations. They make them on documents. The quality of those documents – their internal consistency, their alignment with the regulatory licence, their specificity about beneficial ownership – determines speed of approval and the depth of the relationship offered.
The core components of an institutional onboarding file are consistent across major jurisdictions, though the weighting of each element varies:
- A corporate registry extract and full group structure chart, showing every holding layer and the ultimate beneficial owners (UBOs) with verified identification documents.
- The regulatory licence or registration certificate, with a plain-English summary of the permitted activities and the supervising authority's name and public register reference.
- The AML/CFT policy, including transaction-monitoring methodology, Travel Rule implementation approach and the MLRO appointment letter.
- A business model summary: revenue streams, asset types held or transacted, customer categories (retail/institutional), and geographic scope of the client base.
- Financial statements or management accounts for at least the prior period, or a credible financial projection if the entity is newly incorporated.
- A counterparty list for any significant liquidity, exchange or custody relationships – including those counterparties' own regulatory status.
We have seen onboarding files rejected at the first review because the group structure chart omitted a dormant holding entity that appeared in a public registry search. That omission – easily explained – became a disclosure-quality concern. A bank's compliance team reads gaps as risk signals. The onboarding file must be complete at first submission.
What Cross-Border Banking Challenges Do VASP Operators Face?
The cross-border reality of digital-asset banking is structurally different from any other sector. A VASP licensed under the VARA regime in Dubai may hold a treasury entity in the Cayman Islands, operate its technology infrastructure through a BVI subsidiary and source institutional clients from Europe and Asia. Each of those jurisdictions has a different risk rating in the correspondent-banking world. The bank looking at that structure is not assessing one entity – it is assessing the risk of the full footprint.
Correspondent-banking de-risking – the withdrawal of correspondent banking lines by major banks from higher-risk or smaller-jurisdiction counterparties – has reduced the number of USD-clearing routes available to operators in certain jurisdictions. An operator whose entity sits in a jurisdiction that has experienced de-risking pressure may need to route USD settlement through a different clearing model, use a bank with its own USD nostro account in a US-regulated institution, or structure a parallel entity in a jurisdiction with stronger correspondent relationships.
In our cross-border practice, the most common structuring error is a mismatch between where the regulated entity sits, where the treasury account sits, and where the fiat liability to clients arises. When those three elements are misaligned – for example, when a licence is held in one jurisdiction but client funds flow through an account in a second jurisdiction under a third jurisdiction's client-money rules – the result is often a compliance hold at the bank rather than an outright rejection. Resolving that hold requires structural amendment, not additional documentation.
The ADGM/FSRA regime in Abu Dhabi and the AIFC/AFSA regime in Kazakhstan both present onboarding profiles that differ materially from Dubai's VARA. Operators we advise on regional expansion in the Gulf frequently discover that a single group banking relationship cannot span all three regulatory environments without adaptation. The banking strategy must follow the regulatory map.
Common Mistakes That Delay or Derail Bank Account Applications
The most frequent errors in institutional bank account applications are structural rather than documentary. Documents can be supplemented; structure has to be rebuilt. The four patterns we see most often are these.
First, the entity applying for the account is not the regulated entity. A common arrangement is for a group to hold its licence in one company and attempt to open a banking relationship in a separate holding or trading company. Banks assess the regulated entity; they do not extend that assessment automatically to affiliates. Each entity in the group that requires banking access must be assessed and approved in its own right.
Second, the AML programme is generic rather than product-specific. A policy written for a payment company that has been lightly adapted for a crypto exchange will fail a compliance review at any bank with a dedicated digital-asset desk. The transaction-monitoring methodology must describe the actual transaction types: on-chain deposits, exchange withdrawals, stablecoin settlements, staking distributions.
Third, the operator applies before the licence is issued. Pre-licence banking outreach is not categorically futile – some institutions will engage in relationship-building prior to licence grant – but the substantive onboarding process rarely advances to approval before a regulatory decision exists. Timing the banking process to run in parallel with, rather than ahead of, the licensing process is generally the correct sequencing.
Fourth, the beneficial ownership chain is incomplete. A UBO who holds an interest through a discretionary trust, a foundation or an intermediary holding company that is not disclosed in the onboarding file will be surfaced by the bank's own KYC search. The consequence is not merely delay – it creates a credibility problem that is difficult to recover from.
A second CTA is appropriate here. If a prior application stalled or an account was closed, a structural review can surface the underlying reason and identify the route forward. Write to OBOLUS at info@oboluslaw.com.
Decision Matrix: Which Banking Model Fits Your Operator Profile?
There is no single correct banking model for an institutional digital-asset operator. The right structure depends on settlement volume, jurisdictional footprint, licence type and the counterparty profile the business is building toward. The following profiles describe the decision branches we work through with clients.
Profile A – Exchange or trading platform with high settlement volume and institutional counterparties. This operator needs a commercial banking relationship with direct or near-direct access to major-currency clearing networks. The entity must carry a regulatory licence in a jurisdiction the prospective bank's compliance team can assess clearly – MiCA CASP, VARA, MAS DPT licence or equivalent. Timeline to banking approval for a well-documented file varies; operators should plan for a process measured in weeks to a few months depending on the bank's own onboarding queue. The primary risk is correspondent-banking footprint: if the entity's jurisdiction is subject to de-risking pressure, a structural review of the holding arrangement is warranted before applications are filed.
Profile B – Custodian or asset manager with lower transaction frequency but high-value balances. Client-money safeguarding is the defining requirement. The applicable rules – under MiCA, the FCA's client-asset framework or the MAS Payment Services Act – specify how client funds must be held, in what type of account, and with what segregation documentation. An EMI will typically not satisfy the safeguarding requirements that apply to a custodian holding assets at institutional scale. A commercial banking relationship, with segregated client-money accounts and the appropriate trust or statutory documentation, is the baseline requirement. Applying without that documentation in place is a Category 1 error.
Profile C – Token issuer or treasury-heavy entity without a retail-facing product. Banking needs here are narrower but not simpler. The entity needs a corporate treasury account for operational expenditure, a mechanism to convert token-sale proceeds to fiat and, if an ART or EMT is issued under MiCA, compliance with that regime's reserve requirements. Many banks remain cautious about onboarding entities whose primary activity is token issuance. An EMI relationship may cover the operational payment layer; a licensed credit institution in a jurisdiction comfortable with reserve-management mandates should hold the reserve assets. A structure that conflates treasury and reserve accounts creates both a regulatory and a banking problem.
Profile D – Fintech or payments company at the intersection of regulated payments and digital assets. This profile often already holds a payment institution or EMI licence and is seeking to add digital-asset services to an existing regulated entity – or to open a second entity for the digital-asset component. The banking question is whether the existing relationship can be extended to the new activity or whether a separate entity and separate banking relationship is required. Banks often prefer the latter; regulators may require it. The cross-border angle – particularly where EU passporting is involved under MiCA – will affect the answer.
Micro-Matter: Structured Onboarding After a Correspondent Exit
In a recent matter, a digital-asset lending and custody platform holding a licence in a Gulf financial free zone found its primary commercial banking relationship terminated at short notice following a change in its correspondent bank's crypto-sector risk policy. The platform's fiat settlement capacity fell to near zero over a matter of days. We were instructed to rebuild the banking structure. Working with allied counsel in the relevant Gulf jurisdiction, we assessed the platform's regulatory licence scope, restructured the group's entity arrangement to separate the licensed operating entity from the treasury-holding vehicle, prepared a compliant AML programme specific to the lending and custody activities, and coordinated outreach to three prospective banking relationships in parallel. The platform secured a working primary banking relationship and an EMI relationship for payment-flow purposes within a period measured in weeks. No client funds were at risk at any point; the structural rebuild meant the new arrangements were documentable from day one.
Self-Assessment Checklist Before You File a Banking Application
Before submitting an institutional bank account application, an operator should be able to answer each of the following questions with a documented yes:
- Does the applying entity hold a current regulatory licence or registration that is verifiable on the supervising authority's public register?
- Is the beneficial ownership chain documented to the level of natural-person UBOs, with verified identification for each?
- Does the AML/CFT policy describe the specific transaction types, asset classes and customer categories that apply to this entity's actual operations?
- Has the Travel Rule implementation been documented, including the name of the VASP-to-VASP data-transfer solution in use?
- Is the proposed account structure (operational, client-money, reserve) consistent with the applicable safeguarding rules for this licence type?
- Have all group entities – including dormant or holding companies – been identified and disclosed?
- Is the jurisdiction of the applying entity one that the target bank's correspondent network can service without elevated risk-transfer concerns?
A no to any one of these questions is a reason to pause the application and resolve the gap first. Filing a deficient application does not simply result in a rejection; it can affect the entity's onboarding profile at other institutions that share compliance intelligence through industry networks.
Related at OBOLUS
- Banking, Payments & EMI Onboarding for Digital-Asset Businesses – the practice overview covering the full fiat-rail and payment licensing mandate.
- Fiat On/Off-Ramp Banking in Abu Dhabi Global Market (ADGM) – jurisdiction-specific analysis of FSRA-supervised banking and payment relationships in ADGM.
- Staking and Rewards Taxation: The Structuring Angle – cross-cutting structuring analysis relevant to treasury and banking layer decisions.
FAQ
Why do banks close crypto company accounts?
Banks close digital-asset company accounts primarily for three reasons: a change in the bank's internal risk appetite for the crypto sector, a failure by the account-holder to maintain adequate AML programme documentation as the business scales, or a compliance concern surfaced by a periodic account review. In many cases the closure is not a legal finding – it is a commercial decision driven by the bank's assessment that the compliance cost of retaining the relationship exceeds the revenue. Operators with a current regulatory licence, a well-documented AML programme and a clean beneficial-ownership structure are materially less likely to face an exit.
How can a VASP onboard with an EMI?
A VASP seeking to onboard with an EMI follows a process broadly similar to commercial banking due diligence: entity documents, regulatory licence, AML programme, UBO verification and a business model summary. The distinguishing factor is the EMI's own regulatory scope – the services it is authorised to provide, the jurisdictions it can serve and the safeguarding model it operates. A VASP must confirm that the EMI's authorised activities align with the payment flows the VASP needs. Where an EMI operates under an EU authorisation with passporting rights, it can cover multi-jurisdiction fiat settlement from a single relationship. Timeline varies by institution and the completeness of the onboarding file at submission.
What does client-money safeguarding require?
Client-money safeguarding requires that funds belonging to clients are held separately from the firm's own assets, in an account or arrangement that protects those funds in the event of the firm's insolvency. The specific requirements vary by regime – under MiCA, the MAS Payment Services Act, and the FCA's client-asset rules, different segregation, documentation and bank-acknowledgement obligations apply. In practice, safeguarding requires a dedicated client-money bank account, a signed acknowledgement from the credit institution that the funds are held on trust and are not available to meet the firm's own creditors, and ongoing reconciliation records. An EMI cannot always provide the requisite acknowledgement; a regulated commercial bank typically can.
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 work that sits around them. We map the licence, banking and tax stack across operating, custody and payment layers before you commit – treating licensing, banking and tax as one integrated mandate rather than three disconnected workstreams. Digital assets are the whole of our practice. To discuss your corporate banking or EMI onboarding situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in VASP licensing, AML programme design and the regulatory basis for institutional bank onboarding across the EU, Gulf and common-law jurisdictions.
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.