A crypto licence does not create a right to a bank account. The regulator and the bank are different gatekeepers answering different questions.
The regulator asks whether the firm may perform a regulated activity under the applicable framework. The bank asks whether it can understand, monitor and accept the risks of the customer relationship under its own legal duties and risk appetite.
Those decisions can point in different directions without either institution contradicting the other.
Key takeaways
- A licence is evidence, not a banking entitlement. It can strengthen the file, but the bank must still perform its own due diligence and risk assessment.
- Bankability depends on the operating facts. Ownership, customers, countries, fiat flows, tokens, counterparties, source of funds and AML controls can matter independently of licensing status.
- Banking should be tested before the structure is finished. A legally valid crypto business can still be commercially impaired if its payment and settlement architecture does not work.
Two gatekeepers, two mandates
It is tempting to see a licence as an institutional endorsement of the whole company.
That overstates what regulatory approval means.
A sector regulator defines a perimeter, assesses an applicant against its requirements and authorises specific activities subject to conditions and continuing supervision. A bank is not delegated that decision. It has its own obligations toward its customer relationship.
Under the UAE AML framework, financial institutions apply risk-based customer due diligence and ongoing monitoring. They must identify and understand customers and beneficial owners, understand the nature of the business relationship and scrutinise transactions for consistency with the information and risk profile available to them, including source of funds where necessary.
A VASP licence may answer part of that inquiry. It does not answer all of it.
What the licence can contribute
A licence can be highly relevant to bank onboarding.
It can identify the regulator, the authorised entity and the permitted activity. It can show that the business has passed an external regulatory gate and is subject to continuing obligations. It can also provide a framework for the bank to understand which activities the customer is legally expected to conduct.
But that evidence sits inside the bank’s wider customer file.
The bank may still need to understand:
- ultimate beneficial ownership and control;
- the experience and integrity of senior management;
- customer segments and target markets;
- countries and corridors involved;
- expected fiat inflows and outflows;
- custody and wallet architecture;
- tokens and counterparties;
- source of funds and, where relevant, source of wealth;
- AML, sanctions and transaction-monitoring controls; and
- the commercial purpose of the requested accounts.
The exact questions differ by institution and relationship. That variation is part of the point.
Why a regulator’s “yes” is not the bank’s “yes”
A regulator assesses whether the applicant meets the rules for the regulated activity. A bank assesses the money-laundering, sanctions, fraud, conduct, operational, reputational and commercial risks that arise from maintaining the account and processing transactions.
There is overlap. Both may care about ownership, governance, controls and source of funds.
But overlap does not make the decisions identical.
The current UAE framework expressly requires risk-based CDD and ongoing monitoring by financial institutions. A bank cannot outsource that responsibility to the fact that the customer has a VASP licence.
This supports a practical inference: regulatory approval can improve the quality of the banking case, but it cannot eliminate the bank’s independent decision.
Bankability is about explainability
The strongest banking file is not necessarily the entity with the longest list of licences or legal documents. It is the one whose business can be explained coherently from ownership to transaction.
The bank needs a plausible answer to questions such as:
Who owns the company? What does it sell? Who are the customers? Why do payments arrive from these countries? Why are they sent to those counterparties? What role do virtual assets play? Which flows are company revenue, customer money or treasury activity? How are unusual transactions detected and escalated?
A complicated structure may be legitimate. But if it makes those questions harder to answer, it can create bankability friction even when every entity in the chain is legally valid.
This is why banking belongs inside structure design rather than after it.
Operational readiness matters to the bank too
A bank does not only see the licence. It sees the company that must operate under it.
If the firm has weak reconciliation, unclear wallet ownership, poor segregation, inconsistent contracts or no convincing control over its transaction data, the banking problem is also an operating problem.
The same applies to people. Senior management, compliance, finance and operations need to be able to explain the model consistently. A policy written for the regulator but disconnected from day-to-day flows is unlikely to solve the bank’s practical questions.
The principle is the same across both gatekeepers: documentation is strongest when it describes reality.
The tax position is another independent layer
A bank account is not evidence that the tax structure is correct, just as a licence is not evidence that the bank must open an account.
Tax residence, corporate tax, indirect tax, permanent establishment and information-reporting obligations are determined under their own legal frameworks. The location of a bank account can be a fact in the wider picture, but it does not override those rules.
For an international crypto business, the coherent position must connect the entity, the people who manage it, the regulated activity, the commercial flows, the bank accounts, the accounting records and the applicable reporting obligations.
A disconnect between those layers creates more than a tax problem. It makes the entire business harder to explain.
The best objection: licensed firms do obtain banking
Of course they do.
The claim is not that banks reject licensed crypto businesses, nor that bankability is impossible. It is that licensing and bank onboarding are not the same decision.
A well-regulated firm with transparent ownership, credible management, clear transaction flows and strong controls may present a much better risk case than an unregulated or opaque business. That is exactly why the licence matters.
But “matters” is not the same as “guarantees”.
Risk-based regulation necessarily leaves room for financial institutions to differentiate between customers and relationships.
What changed since 2023
By 2023, UAE financial-sector guidance already embedded risk-based CDD, beneficial-owner identification and an understanding of the customer’s business relationship into onboarding and monitoring.
The UAE has since replaced and updated important parts of its AML legal framework. Federal Decree-Law No. 10 of 2025 and its Executive Regulations reinforce risk identification, CDD and continuous monitoring obligations across financial institutions and VASPs.
The current rules make the structural point even clearer than the market debate did in 2023: both regulated crypto firms and the financial institutions serving them operate inside their own compliance duties.
One licence cannot perform both jobs.
Design bankability before the application is finished
A regulated crypto project should build a bankability file in parallel with its licensing file.
That file should be capable of explaining, with evidence:
- the ownership and control structure;
- the regulated activities and business model;
- management and compliance responsibility;
- expected customers, countries, transaction volumes and flows;
- source of funds and funding history;
- custody, wallet and settlement architecture; and
- the relationship between fiat accounts, virtual-asset activity and accounting records.
The purpose is not to imitate one bank’s questionnaire. It is to test whether the business can be understood by an independent risk function.
A crypto structure is not operationally complete when the licence arrives. It is complete only when the permissions, people, controls, banking, accounting and tax or reporting position form one defensible operating reality.
Sources
- VARA — Licence Applications
- VARA — Public Register
- CBUAE Rulebook — Customer Due Diligence Measures
- CBUAE Rulebook — Federal Decree-Law No. 10 of 2025 on AML/CFT/CPF
- CBUAE Rulebook — Cabinet Resolution No. 134 of 2025
Disclaimer
This article is general information about regulation, banking and business structuring. It does not constitute legal, regulatory, banking, tax, investment or financial advice, and it does not predict whether any bank will accept a particular customer. Banking decisions are institution- and fact-specific, and current regulatory and AML requirements should be checked before action is taken.
