That order matters more than it sounds. On a standard business IBAN, any sign of crypto exposure, a deposit that traces back to an exchange, a wire description mentioning tokens, tends to trigger a decline at application stage or a freeze after the fact. A crypto IBAN works the opposite way: the crypto exposure is disclosed upfront, assessed on its own merits, and monitored on an ongoing basis, rather than hidden or discovered later.
This guide focuses specifically on what changes when the applicant is crypto-native, not on the general mechanics of high-risk IBAN structures. If you haven't already, our companion guide on choosing a high-risk IBAN provider covers named-account versus pooled-account structures in general terms that apply to any high-risk sector. Here, we go deeper on the parts that are unique to crypto: on-chain provenance checks, VASP and MiCA registration gating, wallet-address screening, and Travel Rule obligations.
Direct Answer
A crypto business gets an IBAN by first establishing its VASP registration or MiCA-alignment status, since most IBAN providers gate onboarding on this before anything else, then providing on-chain provenance and wallet-ownership evidence, then completing standard corporate KYB, with the resulting account explicitly disclosed and monitored for crypto-adjacent activity throughout its life.
What Is a Crypto IBAN, and How Is It Different from a Standard IBAN?
A crypto IBAN is an IBAN issued to a crypto business, either directly by a bank or, more commonly, via a crypto-friendly electronic money institution (EMI), that can receive and send fiat currency while being explicitly disclosed and monitored for crypto-adjacent activity.
The distinction from a standard business IBAN is not the account number format, an IBAN is an IBAN structurally. The distinction is disclosure and risk classification. A standard business IBAN issued to a consultancy or a logistics company carries no crypto risk flag. If crypto-linked funds start moving through it, whether from an exchange payout, an over-the-counter desk, or wallet-to-fiat conversion, most transaction-monitoring systems will flag it as undisclosed activity outside the account's approved profile, typically resulting in a freeze pending review or an outright closure.
A crypto IBAN avoids that outcome because the crypto activity is declared and priced into the relationship from day one. The provider knows the business trades, custodies, or processes crypto, has assessed that exposure specifically, and has built monitoring around it rather than treating any crypto-linked transaction as an anomaly.
The Onboarding Sequence: VASP/MiCA Status First, Then Provenance, Then KYB
For a generic high-risk business, corporate KYB (directors, UBOs, source of company funds, business plan) is usually the starting point, with sector-specific checks layered on top. For a crypto business applying for an IBAN, the sequence is typically inverted.
VASP registration or MiCA-alignment status comes first. Most IBAN providers active in this space will not proceed past an initial screening call until they have seen evidence of the applicant's regulatory standing as a crypto business: a Virtual Asset Service Provider (VASP) registration number and jurisdiction, or documented progress toward MiCA authorisation where the business operates in or serves the EU. A business that cannot produce this, or that is deliberately operating in a jurisdiction with no VASP framework at all, is typically declined before the file even reaches underwriting.
On-chain provenance and wallet ownership come second. Once regulatory status is established, the provider wants a clear description of where the business's crypto-derived funds actually originate, which wallets it controls, and how ownership of those wallets can be demonstrated rather than merely claimed.
Standard corporate KYB comes third. Directors, ultimate beneficial owners, incorporation documents, and a description of the business model are still required, but they typically arrive after the crypto-specific gates, because there is little point running a full KYB file on an application that will fail on VASP status or wallet provenance regardless.
How Does a Provider Assess On-Chain Provenance and Wallet History?
This is the part of a crypto IBAN application that has no real equivalent in a generic high-risk file, and it is worth understanding in some detail.
On-chain provenance means tracing a wallet's holdings back to an identifiable, lawful source: proceeds from exchange trading under the business's own account, revenue from a protocol or product it operates, token-issuance proceeds, or client funds under a documented custody arrangement. A wallet whose history runs through unattributed mixing services, or that received large inbound transfers with no explainable counterpart, is typically treated as unverifiable rather than automatically fraudulent, but unverifiable is usually enough for a decline.
Wallet ownership has to be demonstrated, not asserted. Providers commonly ask for a cryptographically signed message from the wallet address in question, a statement from a custodian or exchange confirming the sub-account belongs to the applicant, or on-chain evidence linking the address to a transaction the business can independently corroborate (an invoice, a contract, an exchange trade confirmation).
Wallet-linked transaction history is then reviewed in much the same spirit as a bank statement, using blockchain-analytics screening to check the wallet's counterparties for exposure to sanctioned addresses, known darknet-linked clusters, or high-risk mixing services. A wallet with a long, clean history of counterparties tied to regulated exchanges and identifiable business activity clears this step comparatively quickly. A wallet with even indirect historical exposure to flagged clusters typically draws further questions, and sometimes a decline, even where the business itself has done nothing wrong.
None of this replaces standard KYB. It sits on top of it, as an additional layer that a generic high-risk applicant, an adult platform or a forex brokerage, simply does not face.
Where Does the Travel Rule Fit into a Crypto IBAN Relationship?
The Travel Rule, FATF Recommendation 16, requires that originator and beneficiary information travel with a transfer of value once it crosses a reporting threshold, a rule built for wire transfers and extended to virtual-asset transfers as crypto has moved into the mainstream financial system. Thresholds and implementing detail vary by jurisdiction and continue to evolve alongside MiCA-linked technical standards, so treat any specific figure as indicative rather than fixed.
For a crypto IBAN, this obligation becomes practically relevant whenever fiat moves between the IBAN and a crypto exchange or wallet above the applicable threshold. When a crypto exchange sends a fiat payout into the business's IBAN, the IBAN provider will typically expect, or actively request, Travel Rule data identifying the originator, and the counterpart exchange's own VASP status will usually be checked as part of that transfer's review. When the business sends fiat outward that will ultimately be converted back into crypto, the same data-sharing obligation can apply in reverse.
In practice, Travel Rule compliance between an IBAN provider and a counterpart exchange or VASP is not always fully automated. Smaller or newer EMIs sometimes rely on manual data exchange for this specific step, which can add real delay to individual transfers, particularly larger ones. It is worth asking a prospective provider directly how it handles Travel Rule data exchange with counterpart VASPs before onboarding, rather than discovering the gap the first time a payout stalls.
Why Two Separate Rails, Not One Provider Doing Both?
A recurring operational pattern among crypto businesses that bank successfully is deliberately keeping two rails distinct: a crypto-facing relationship (an exchange account, a custody arrangement, or a wallet infrastructure provider) and a separate fiat IBAN, rather than searching for a single provider willing to handle both under one roof.
There are practical reasons for this beyond availability. Very few institutions are set up to both facilitate crypto activity and issue a fully compliant fiat IBAN with equal underwriting rigour on both sides. Combining the two with one provider also concentrates risk: if that provider's appetite shifts or it runs into its own regulatory difficulty, both rails can be affected simultaneously. Keeping them with separate providers means a problem on the exchange side does not automatically freeze the operating fiat account, and vice versa.
This is the structure BMC's Crypto & Digital work is generally built around: pre-approving and structuring a fiat IBAN placement that stays operationally distinct from the client's crypto exchange or custody relationship, with fiat settlement bridging the two rather than one provider trying to be both.
That bridging is the actual operational pattern a crypto IBAN exists to serve: receiving a fiat payout from a crypto exchange after a client withdrawal, or paying fiat suppliers, payroll, or tax obligations out of revenue that originated as crypto. The IBAN is the fiat side of that bridge, not a crypto-holding account in itself.
Crypto Business vs Generic High-Risk Business: What Changes in the IBAN Application
| Criterion | Generic high-risk business (e.g. forex, adult) | Crypto business |
|---|---|---|
| On-chain provenance disclosure | Not applicable | Typically required upfront: source of wallet holdings must be traceable to identifiable, lawful activity |
| VASP/MiCA registration requirement | Not applicable | Often a hard gate; most providers will not proceed without evidence of VASP registration or MiCA-alignment progress |
| Wallet-address screening | Not applicable | Ongoing: wallet counterparties screened against sanctions lists and known high-risk clusters |
| Travel Rule obligations | Not applicable | Applies above jurisdiction-specific thresholds when funds move between the IBAN and a crypto exchange or wallet |
Figures, thresholds, and specific documentation requirements above are indicative and vary by provider and jurisdiction.
What to Consider
- VASP/MiCA status documented before you apply. Have registration numbers, jurisdiction, and scope of activity ready in writing, not summarised verbally on an intro call.
- Wallet ownership evidence prepared in advance. Signed messages, custodian confirmations, or exchange sub-account statements save weeks compared with sourcing them mid-application.
- A clean, explainable on-chain history. Where a wallet's history includes anything unusual, be ready to explain it proactively rather than waiting to be asked.
- Two providers, not one, for the crypto rail and the fiat rail. Resist the temptation to consolidate everything with a single institution for convenience.
- Travel Rule readiness confirmed on both sides. Ask how the provider exchanges originator/beneficiary data with counterpart exchanges before you rely on fast settlement.
- Ongoing monitoring expectations understood upfront. A crypto IBAN is not a one-time approval; source-of-funds evidence and wallet screening continue for the life of the account.
What Ongoing Monitoring Applies to a Crypto IBAN?
Approval is the start of the relationship, not the end of the scrutiny. Crypto IBANs typically carry monitoring obligations that a standard business account does not.
Wallet-address screening continues on an ongoing basis, not just at onboarding. Providers commonly re-screen the wallets a business transacts with each time a new counterparty address appears, checking against sanctions lists and updated blockchain-analytics data.
Source-of-funds evidence is expected for on-chain-derived deposits as they occur, not only as a one-off file submitted at account opening. A deposit that clearly matches an established, previously disclosed revenue pattern usually clears with minimal friction; an unusual inbound transfer from a new wallet typically prompts a fresh request for evidence.
Travel Rule data-sharing between the IBAN provider and the counterpart exchange or VASP continues each time a qualifying transfer occurs, which is why these relationships work best when both sides have mature, tested processes for exchanging this data rather than handling it as an exception.
Example
A composite mid-sized crypto exchange operator, registered as a VASP in an EU member state and working toward full MiCA authorisation, needed a euro-denominated IBAN to receive periodic fiat payouts from client withdrawal settlements and to pay local suppliers and payroll. Its first application, chosen mainly for a fast advertised turnaround, stalled for weeks because the business had not prepared wallet-ownership evidence in advance and the provider's Travel Rule process was largely manual. A second application, made after assembling signed wallet-ownership statements, a clean provenance summary, and confirmation of the counterpart exchange's own VASP status, cleared underwriting considerably faster, with the fiat IBAN kept deliberately separate from the exchange relationship itself.
Final Takeaway: A crypto business gets an IBAN faster by proving VASP/MiCA status and wallet provenance before applying, not by hoping a generic high-risk compliance file will be enough.
Conclusion
A crypto IBAN is not a special account type so much as a standard IBAN wrapped in crypto-specific disclosure and monitoring: VASP or MiCA status confirmed before onboarding, on-chain provenance and wallet ownership demonstrated rather than claimed, Travel Rule data flowing between the IBAN provider and counterpart exchanges, and ongoing wallet screening that continues long after the account opens. Treating it as just another high-risk business account, and leading with generic KYB instead of crypto-specific evidence, is the most common reason crypto businesses stall in onboarding queues that better-prepared applicants clear in a fraction of the time.
How BankMyCapital Helps
BankMyCapital is not a bank, EMI, or payment service provider, and does not hold or move client funds directly. For crypto businesses specifically, we assess VASP/MiCA registration status, help structure a clear on-chain provenance and wallet-ownership file before it reaches an underwriter, and map that against the actual (not marketed) risk appetite of relevant banking and EMI partners, structuring the fiat IBAN placement to sit cleanly alongside, rather than inside, the client's existing crypto exchange or custody relationship. Our own fee starts from 1,500 EUR, with any EMI onboarding fee charged separately by the institution itself. Our /services/crypto-and-digital page covers the fuller range of crypto banking and structuring support this guide sits alongside.