Crypto business banking: how exchanges and crypto companies actually get banked.

Crypto business banking is treated as a distinct underwriting category by almost every institution that offers it, and that is not prejudice, it is proportionate risk management applied to a genuinely different risk profile. A digital-asset business can move very large value very quickly, can transact with counterparties an institution has never heard of, and can be one smart-contract exploit or one compromised counterparty away from a headline the bank's compliance committee did not sign up for. Institutions that bank the sector well have built specific frameworks to manage that; institutions that do not have simply excluded the entire industry code at intake.

This guide sits alongside two companion pieces on this site rather than repeating them. If you want a broader survey of which institution types currently accept crypto mandates and how the market has moved, read our guide to crypto-friendly banks. If your business is specifically an exchange, OTC desk or fund holding client money, read our guide to banking for crypto exchanges, which goes deep on client-money segregation and settlement design. This page is the operating manual for the decision that sits above both: how a crypto company should actually be built, licensed and structured so that a banking application is a formality rather than a gamble.

The starting point is always the same question a good underwriter asks first: what, precisely, does this company do, and where does it sit relative to the regulatory perimeter for virtual asset activity in the jurisdictions it touches? An exchange, a token issuer, an OTC desk, a custodian, a payments company that happens to touch crypto, and a SaaS business that builds tools for crypto companies are five different risk profiles that get five different answers, and conflating them in an application is the single most common reason files get declined before anyone has read past the first page.

The second constant is that no institution, however experienced in the sector, will guarantee an outcome. Appetite moves with regulatory cycles, correspondent banking relationships, and individual institutions' own risk tolerance at a point in time. What a well-built file buys you is a fair hearing and a materially higher probability of acceptance, plus the ability to move to the next institution quickly when one declines. Xavion has spent more than a decade building relationships across 120+ banking and payment institutions in 19 jurisdictions specifically so that crypto mandates have somewhere real to go.

The remainder of this guide works through the pieces that actually determine the outcome: where your activity sits against licensing regimes, how fiat rails and ramps are actually built, how the different business models are underwritten differently, what blockchain analytics and the travel rule require of you operationally, how customer fiat should be segregated, how to design corridors that survive scrutiny, the practical difference between an EMI, a bank and a custodian as your banking partner, realistic timelines, and the failure modes that account for most of the accounts that close.

Every crypto banking conversation starts with the same question from the underwriter's side of the table: are you regulated for this activity, and if so, by whom? The answer shapes the entire file, because a licensed and supervised virtual asset service provider is a fundamentally different proposition to an unlicensed operator claiming the activity falls outside scope.

Most jurisdictions with a functioning digital-asset framework now define a perimeter of supervised activities — typically exchange between virtual assets and fiat, exchange between virtual asset types, transfer of virtual assets on behalf of others, custody or administration of virtual assets or the keys controlling them, and participation in or provision of financial services related to an issuer's offer of a virtual asset. Activities inside that perimeter generally require registration or licensing as a virtual asset service provider, money services business, or equivalent category depending on the jurisdiction. Activities outside it — pure token issuance without ongoing custodial services, non-custodial software, most treasury holding — generally do not, though the analysis has to be done against your actual product rather than assumed from the label you give the business.

For banking purposes, licensing status changes the conversation in three concrete ways. First, it gives the institution a named supervisor to rely on: a bank does not have to build its entire risk assessment from scratch when a recognised regulator has already assessed your fitness, your AML framework and your capital adequacy. Second, it typically comes with baseline obligations — a compliance officer, an AML policy, transaction monitoring, reporting lines to a financial intelligence unit — that a bank would otherwise have to verify you have built yourself, informally, with no external check. Third, and less discussed, it forecloses the argument that you can quietly operate outside the perimeter to avoid the licensing cost; institutions increasingly treat an unlicensed business performing what looks like a licensable activity as a hard decline rather than a negotiable risk.

Where the analysis finds you are inside the perimeter, plan for a real licensing timeline before banking becomes realistic in most jurisdictions: expect months rather than weeks for a full VASP or MSB application, covering fit-and-proper assessment of controllers, a business plan and activity description written for a regulator, AML and CTF policies calibrated to your actual product, custody and key-management arrangements, cyber security, capital adequacy and a wind-down plan. Where the analysis finds you sit outside the perimeter, document that analysis in writing and keep it current, because it becomes one of the first things a bank's compliance team asks to see.

The jurisdiction you choose to license or register in matters almost as much as whether you do. A registration from a jurisdiction with a credible, internationally recognised supervisory framework opens doors that a registration from a jurisdiction known mainly for issuing licences cheaply and quickly does not. We work through this jurisdiction selection with clients as a first step precisely because the wrong choice here cannot be fixed by a better banking application later.

A retail or institutional exchange that matches customer orders and holds customer assets between transactions is banked, correctly, as a business holding other people's money. The file has to demonstrate onboarding standards at least as rigorous as the bank's own — identity verification, sanctions and PEP screening, source-of-funds checks above defined thresholds — plus transaction monitoring calibrated to detect structuring, rapid movement to unhosted wallets, and exposure to sanctioned or high-risk jurisdictions. Underwriters read exchange files for evidence of who your customers actually are, not just how many of them there are.

An OTC desk trades in size with a smaller number of known, often institutional, counterparties, and that composition genuinely changes the underwriting even though the notional value may be far larger than a retail exchange's. A well-documented desk with named counterparties, bilateral agreements, and clear settlement mechanics is frequently an easier file than a retail platform with ten times the customer count and none of the counterparty documentation. The desk's job in the application is to prove the counterparty list is real and vetted, not to prove the volume is impressive.

A token issuer that has completed its raise, holds treasury, and does not provide ongoing custodial or exchange services to third parties is a materially simpler banking file if — and only if — that description is accurate and documented. The moment an issuer starts running a staking product, a redemption facility, or anything that pools user funds, it has moved into activity that looks like custody or fund administration to an underwriter and needs to be assessed and disclosed as such. Treasury management itself needs its own narrative: what the treasury is invested in, who controls disbursement, and what the operating runway and burn actually look like, because banks are wary of accounts that exist to hold large idle balances of uncertain provenance with no visible operating activity behind them.

A software or infrastructure company that serves the crypto industry without ever touching customer assets or fiat on their behalf — analytics platforms, compliance tooling, wallet interface providers, blockchain developers — should, in principle, be one of the easiest crypto-adjacent files to bank, because it is a normal B2B SaaS revenue model. In practice these businesses are frequently miscategorised by risk teams that see the word crypto and decline without reading further, so the application has to work harder than the underlying risk justifies to get the description read correctly and past that first filter.

In every case, the discipline is the same: describe the actual mechanics of the business — who holds what, at which point, and who is on the other side of every transaction type — rather than a marketing description of the product. Underwriters approve mechanics they can verify, not categories they recognise.

Every crypto business eventually needs fiat to cross the boundary into and out of the digital-asset ecosystem, and the mechanics of that crossing are what a bank is actually underwriting, more than the digital-asset activity itself. An on-ramp takes a customer's fiat deposit — card, bank transfer, or increasingly open banking payment initiation — and converts it, directly or via an intermediary liquidity provider, into the digital asset the customer wants. An off-ramp reverses that. Every leg of that chain needs a named, documented provider, and the bank account sitting behind the fiat legs is what your banking application is actually about.

The most common design failure is treating the on/off-ramp as a single undifferentiated pipe when it is actually several distinct relationships that each need separate underwriting: the card acquiring relationship for card-funded deposits, the banking relationship for bank-transfer deposits and withdrawals, the liquidity provider or market maker relationship for the actual fiat-to-crypto conversion, and the correspondent or settlement relationship if any leg crosses currencies or borders. A bank asked to be all of these things at once for a young crypto business is being asked to take on concentration risk it did not sign up for and will usually decline.

Card-funded on-ramps carry chargeback and fraud risk that behaves differently to standard e-commerce, because a successful chargeback after the crypto has already been delivered and moved on-chain is effectively unrecoverable. Acquirers price and structure this with reserves, velocity limits and delayed settlement specifically because of that irreversibility, and any banking application that omits how chargeback risk is controlled at the card leg is missing a section an experienced underwriter will ask for by name.

Bank-transfer on/off-ramps are generally lower fraud risk but higher scrutiny risk, because the bank sitting behind the transfer is directly exposed to knowing its customer's customer — the end user funding or withdrawing from your platform — without ever seeing them directly. This is where segregated client-money accounts, real-time or near-real-time reconciliation, and a clear contractual chain between you, your customer and the receiving bank become the difference between a relationship that survives an audit and one that does not.

Corridor selection compounds all of this. On-ramps and off-ramps that route fiat through jurisdictions with weak AML supervision, or that involve currencies subject to capital controls, add a layer of scrutiny that a straightforward domestic or major-currency corridor does not carry. Building the ramp architecture around a small number of well-documented, well-supervised corridors, even if it costs some flexibility, is consistently the choice that keeps banking relationships alive.

On-chain monitoring has moved from a differentiator to a baseline expectation for any business handling digital assets at scale. A bank underwriting a crypto mandate will ask, specifically, which blockchain analytics provider you use, what risk-scoring thresholds trigger manual review versus automatic block, how you handle assets that arrive from mixers, unhosted wallets, sanctioned addresses or jurisdictions of concern, and how frequently your risk rules are recalibrated against the provider's updated intelligence. A business that cannot answer this in specifics, only in general assurances, reads as unmonitored regardless of what its marketing says.

The travel rule — the requirement that originator and beneficiary information travel with a virtual asset transfer above a defined threshold, mirroring the wire-transfer rule long applied to traditional payments — is now live in enforceable form in a growing list of jurisdictions and is treated by banks as a proxy for whether a crypto business takes its compliance obligations seriously generally. Implementing it requires either direct integration with a travel-rule messaging network connecting you to counterparty VASPs, or a documented, defensible position on why a given transfer falls outside the requirement. Neither 'we haven't got to it yet' nor 'our counterparties don't comply either' is an answer that survives an underwriting conversation.

Sanctions screening deserves its own line item because the consequences of getting it wrong are categorically different from ordinary AML failures. Address-level sanctions screening against updated designated-persons and designated-address lists, screening of the beneficial owners behind any corporate counterparty, and a documented escalation path when a match or a near-match occurs are all things a bank will ask to see evidenced, not just described. Institutions have exited entire crypto banking programmes after a single serious sanctions failure by a client, which is why this is treated as close to non-negotiable.

The honest operational reality is that no analytics tool or travel-rule integration eliminates risk entirely; digital assets can and do move through obfuscation techniques that even the best providers cannot fully unwind in real time. What a bank is actually assessing is whether your risk management is proportionate, current and demonstrably applied — whether you can produce, on request, the transaction history, the risk score at the time, the decision made and the person who made it. Build that evidentiary trail from day one, because reconstructing it retrospectively during a bank's periodic review is far harder and far less convincing.

This is general information rather than a compliance manual for your specific jurisdiction; travel-rule thresholds, sanctions regimes and analytics expectations vary by jurisdiction and change frequently, and the specific framework you need should be built with qualified compliance counsel against your actual flows.

Any crypto business that holds customer fiat balances — pending conversion, awaiting withdrawal, or sitting as platform float — has to answer one question cleanly before a bank will engage seriously: whose money is this, on whose balance sheet does it sit, and what happens to it if the company fails? Commingling customer fiat with operating funds is the single fastest way to turn a promising banking application into a declined one, because it converts every customer deposit into an unsecured claim against the company rather than a ring-fenced asset held on the customer's behalf.

The standard, bank-acceptable answer is a segregated client-money or safeguarding account, held at a regulated institution, in the company's name but designated and operated as holding client funds rather than company assets, with the company's own operating funds held entirely separately. Reconciliation between the client-money ledger and the actual balance in the segregated account needs to happen frequently — daily, in most well-run operations — and needs to be evidenced, because a bank reviewing the relationship six months in will ask for reconciliation records, not just a policy document describing the intent.

Interest earned on segregated client balances, and who is entitled to it, is a detail that sounds minor and is not: contracts with customers need to state clearly whether interest accrues to the customer, to the company, or is waived, because an ambiguous position here is a recurring source of regulatory findings against payment and e-money businesses generally, well beyond crypto specifically.

Where the business also holds customer digital assets in custody, the same segregation logic applies on-chain: customer assets held in wallets clearly distinguished from company treasury wallets, with documented key-management and multi-signature or multi-party-computation controls, and — increasingly expected by both regulators and banks — periodic proof-of-reserves or attestation demonstrating that customer asset holdings are actually backed one-to-one rather than rehypothecated or commingled with company or other customers' assets.

Getting segregation right is not only a banking requirement; it is what allows the business to survive its own operational failures. A company with genuinely segregated customer funds that experiences a technical outage, a cyber incident, or even insolvency can, in principle, return customer assets intact. A company that has commingled funds has no such option, and that difference is exactly what a bank's risk committee is trying to protect itself, and by extension its own regulator, against when it asks these questions in underwriting.

A corridor, in banking terms, is the specific path a payment takes: which currency, between which two countries, through which correspondent or settlement network, for which purpose. Crypto businesses that design their corridors deliberately, rather than accumulating them ad hoc as customers sign up from wherever they happen to be, consistently bank more easily and keep their accounts open longer.

The design exercise starts with mapping where your actual customers and counterparties are, not where you would like them to be, and then matching that map against the corridors your banking and payment partners can actually support at acceptable risk. A corridor between two well-supervised, FATF-compliant jurisdictions with an established correspondent banking relationship is fundamentally different underwriting from a corridor touching a jurisdiction on enhanced monitoring lists, even if the customer volume looks similar on a spreadsheet.

Concentration within a corridor is its own risk factor. A single large counterparty or a single customer segment representing a disproportionate share of volume through one corridor draws scrutiny, because it looks either like a single point of failure or like activity that has not been diversified for a reason worth investigating. Spreading volume across several counterparties and, where the business allows it, several corridors, is both better risk management and a better-looking file.

Currency choice within a corridor matters more than founders often expect. Settling in major, freely convertible currencies through well-established rails is materially easier to bank than structures built around currencies subject to capital controls or thin liquidity, even where the underlying commercial rationale for that currency choice is sound. Where an exotic-currency corridor is genuinely necessary for the business, expect it to require its own dedicated banking relationship and its own justification file, separate from the rest of the business's flows.

Finally, corridors should be documented as part of the banking file itself: a table of expected corridors, approximate volumes, counterparty types and the compliance controls applied to each is one of the most persuasive single documents a crypto business can hand an underwriter, because it demonstrates the flow has been designed rather than discovered after the fact.

Crypto companies default to assuming they need a traditional bank account, when in practice the right partner is often an electronic money institution, a specialist payments institution, or a regulated custodian, each of which is structurally different from a bank and suited to different parts of the business.

A traditional bank offers deposit-taking, credit facilities where relevant, and often the deepest correspondent network, but the largest banks are also the most conservative on crypto appetite and the slowest to onboard a genuinely novel business model. Where a bank does take on crypto mandates, it is frequently through a dedicated high-risk or digital-assets desk with its own underwriting track, distinct from mainstream business banking, and it is worth confirming you are being routed to that desk rather than a generalist relationship manager who will eventually escalate and decline.

An electronic money institution typically moves faster, has more calibrated risk appetite for crypto-adjacent flows because that appetite is often central to its business model, and can issue IBANs, cards and payment rails without the full weight of banking-licence conservatism. The trade-off is that EMI-held funds are safeguarded rather than covered by deposit insurance in the way bank deposits typically are, and EMIs vary widely in their own resilience and regulatory standing, so due diligence on the EMI itself is as important as the EMI's due diligence on you.

A regulated custodian is the right partner specifically for the digital-asset side of the business — the actual holding of customer crypto assets under institutional-grade key management, insurance and audit — and is a separate relationship from wherever the fiat side sits. Conflating custody and banking into a single relationship, or assuming a bank will also warehouse your digital assets, misunderstands what each type of institution is licensed and equipped to do.

The realistic architecture for most established crypto businesses is a stack rather than a single relationship: an operating bank account for payroll, suppliers and corporate expenses; an EMI or payments relationship for customer-facing fiat rails; a regulated custodian for digital-asset holding; and, ideally, a second relationship in at least the banking and EMI categories held in reserve, opened before it is needed rather than scrambled for after the primary relationship gives notice.

Set expectations early: a well-prepared crypto banking application realistically takes several weeks from submission to a funded account at institutions that genuinely underwrite the sector, and licensing or registration work, where required, adds months on top of that if it has not already been completed before the banking search starts. Applications that move faster than this are the exception, not the rule, and should be treated with some caution rather than celebrated uncritically.

The file itself needs to answer the same five questions every underwriter is ultimately asking, regardless of how the application form is phrased: who ultimately owns and controls the company, what does it actually do and how does it make money, where does money come from and where does it go, what is the source of funds and source of wealth behind the initial and ongoing capital, and what controls exist to stop the account being used for something other than its stated purpose.

In practical document terms that means certified corporate documents and good-standing evidence, a full ownership and control chart with verified identification for every controller, licensing or registration evidence (or a documented perimeter analysis where none is required), the AML and travel-rule framework actually in operation, the blockchain analytics provider and risk-scoring methodology in use, projected transaction volumes broken down by corridor and counterparty type, evidence of client-money segregation arrangements where relevant, and a business description written for a compliance reader rather than an investor pitch deck.

Expect follow-up questions as a normal part of the process rather than a sign of trouble — good underwriters ask precise, sometimes uncomfortable questions about edge cases in your flow, and answering them thoroughly and quickly is what moves a file from pending to approved. Expect, too, that at least one institution in any serious search will decline for reasons that have little to do with the quality of your file and everything to do with that institution's current internal appetite; this is normal in the sector and is exactly why applications should be run in parallel across several institutions rather than sequentially, one at a time.

Xavion runs crypto banking searches this way as standard: multiple applications positioned in parallel against institutions whose stated appetite genuinely matches the profile, with the file built once and adapted for each institution's specific requirements rather than started from scratch each time. Fees for this work are quoted on scoping once we understand the licensing position, the flow and the jurisdictions involved.

Most crypto banking relationships that fail do not fail at the application stage; they fail months or years in, when an account that was opened correctly is closed because something changed and nobody caught it in time. Understanding these failure modes is as important as understanding how to get banked in the first place.

The single most common failure is drift between what the account was opened to do and what it is actually being used for. A business licensed and banked as a token issuer that quietly starts offering a yield or staking product, or an exchange that expands into a new asset class or a new customer geography without updating its bank, is running activity its banking relationship was never underwritten for. Banks discover this through periodic reviews or transaction monitoring flags, and the discovery is far more damaging to the relationship than proactively disclosing the change would have been.

The second is concentration risk crystallising: a business that relied on a single banking or EMI relationship for its entire fiat rail, with no contingency in place, loses that relationship — because the institution changed its sector appetite, was itself the subject of a regulatory action, or simply exited the market — and has no fallback. This is entirely foreseeable and entirely avoidable, and the fix, a second relationship opened and kept warm before it is needed, is inexpensive relative to the cost of a business that cannot pay its staff or its suppliers for weeks while it scrambles for a replacement.

The third is a serious sanctions or fraud incident that was not caught by the business's own controls but was caught by the bank's, or worse, by a regulator or a journalist. A single material failure of this kind can end a banking relationship immediately and make every subsequent application to any other institution materially harder, because banking history is checked and a prior de-risking event is disclosed, formally or informally, in due diligence for years afterward.

The fourth, quieter failure mode is simple neglect of the maintenance obligations that come with the account and any underlying licence: annual filings, updated beneficial ownership information, refreshed source-of-funds documentation, and responsiveness to periodic review requests. Banks close dormant or unresponsive relationships as a matter of course, and a business that treats its banking relationship as a one-time achievement rather than an ongoing one is the business most likely to be surprised by a closure notice.

Our work on a crypto banking mandate starts with the same activity analysis a licensing application would need: what the business actually does, who holds what at each step, where the licensing perimeter sits, and where the customers and counterparties are. That analysis drives everything that follows, and getting it right before approaching any institution is what separates a fast, clean process from a long one that burns relationships with declined applications along the way.

Where licensing or registration is needed, we coordinate that work with qualified counsel in the relevant jurisdiction as part of the same engagement, so the licence and the banking narrative are built to support each other rather than assembled separately and reconciled later. Where the analysis shows the activity sits outside a licensing perimeter, we document that position formally, because it is one of the first things a bank will ask to see.

On banking specifically, we position applications across our network of more than 120 banking and payment institutions across 19 jurisdictions, matching the flow, the licensing position and the corridor profile to institutions whose current appetite genuinely fits, rather than running a single application and hoping. We build the layered architecture described in this guide as standard — an operating account, a customer-facing payments relationship, custody where relevant, and a contingency relationship held in reserve — because concentration is the risk that most often materialises in practice.

After the account or accounts are live, we stay engaged on the maintenance that keeps them open: periodic review support, updated documentation as the business evolves, and early warning when a change in the business's activity needs to be disclosed to or re-underwritten by the bank before it becomes a discovery. Every engagement is scoped and quoted before it starts, and we tell clients plainly, before any work begins, where we think a plan will not get banked as designed.

No institution and no adviser can guarantee an account; every bank and EMI decides independently, and appetite changes over time. What we can guarantee is a properly built file, a search run across institutions genuinely positioned to say yes, and a straight answer about the parts of your business model that will make banking harder, before you have spent months finding that out the hard way. This is general information and not legal or tax advice; the specific licensing and structuring analysis for your business should be run against your actual facts.