When a regulated crypto project is late, the regulator is not always the cause. The project may already have lost weeks or months before a complete application reaches the authority. The real timeline begins with dependencies, not with filing.
That is the central planning error: treating the regulator’s review period as if it were the full project duration.
Key takeaways
- There are at least two clocks. The project clock starts while perimeter, ownership, people, capital and evidence are being assembled; the regulator’s review clock starts later.
- The critical path is usually a dependency chain. One missing person, ownership document, control framework, capital step or technology decision can hold up several workstreams at once.
- Banking and tax run alongside licensing. Even a well-managed application can produce an unusable structure if account access, accounting, tax residence or reporting are left until the end.
The wrong question: how long does the licence take?
It is understandable that founders ask for a number: three months, six months, nine months. The problem is not the desire for a timeline. It is the assumption that one number can describe every part of the project.
Regulators review applications. Projects have to become reviewable.
Before filing, the applicant may need to define regulated activities, choose the correct entity, identify beneficial owners, document source of funds, appoint senior people, prepare a regulatory business plan, build financial projections, establish governance, prepare policies, select technology and custody arrangements, evidence capital and resolve group or related-party questions.
Some of those tasks can run in parallel. Others cannot.
The project is therefore governed by a critical path: the longest chain of dependencies that must be completed before the next gate can be passed.
Perimeter comes before paperwork
The first delay can occur before a document is drafted.
A project that has not defined what it will actually do cannot reliably identify the licence it needs. “Crypto company” is not a regulated activity. Exchange, broker-dealer, custody, lending, transfer, advisory and issuance can sit in different parts of a regulatory framework and can trigger different capital, governance or technology requirements.
The same is true geographically. A business must know where the service is provided, which customers are targeted and which entity performs the activity.
If the perimeter changes halfway through the project, downstream work often changes with it. Business plans, policies, financial models, staffing and vendor architecture may need to be revisited.
The fastest way to waste time is to optimise a filing before fixing the activity it is supposed to describe.
People can become the longest dependency
A policy document is easy to schedule because it is a deliverable. A qualified person is harder to schedule because that person has to exist, be available, accept the role and satisfy the relevant regulatory conditions.
Depending on the regime, key functions may involve experience, fit-and-proper assessment, independence, location, residency or full-time expectations. Senior management may be interviewed. The regulator may ask how roles interact and whether responsibilities are genuinely owned.
A project that assumes key people can be found after the application is “almost ready” may discover that the staffing dependency determines the real filing date.
This is also why an organisational chart should not be built backwards from a template. The required people depend on the activity and the operating model.
Evidence is another hidden timeline
Ownership and source-of-funds evidence can look administrative until a missing link appears.
A complex shareholder chain, historic financing, multiple jurisdictions or inconsistent corporate documents can require reconciliation before the application package is credible. The same problem can arise with financial statements, capital evidence, close-link analysis or group arrangements.
The lesson is not that every structure must be simple. It is that complexity consumes verification time.
Evidence should therefore be treated as project infrastructure. If a material fact will have to be proved to the regulator, bank or auditor, the evidence path should be identified early.
Current VARA practice makes the two clocks visible
Dubai’s current VARA process provides a useful illustration rather than a universal timetable.
For new firms, VARA describes two stages. Stage 1 includes an Initial Disclosure Questionnaire, additional documentation such as a business plan and details of beneficial owners and senior management, and can result in an Approval to Incorporate. Only then can the firm finalise incorporation and operational setup such as office space and employee onboarding. VARA expressly says the firm may not carry on Virtual Asset activities at that stage.
Stage 2 involves the full VASP Licence application. VARA may provide feedback, conduct meetings or interviews and ask for further documentation. A licence may then be subject to operational conditions.
The structure of that process illustrates the planning principle: “application time” sits inside a wider sequence of legal and operational preparation.
Banking is not the last box
A common sequencing mistake is:
incorporate → apply → obtain licence → open bank account.
That sequence is tidy on a slide. It may be fragile in practice.
Financial institutions perform their own customer due diligence and risk assessment. They may need to understand ownership, business activity, geographies, source of funds, expected flows, counterparties and the firm’s controls. Those questions are connected to the same operating model being presented to the regulator, but the bank makes its own decision.
If the business depends on fiat settlement, payroll, reserve accounts or customer money movement, banking should be considered while the regulated model is being designed.
A licence can be necessary for the bankability story. It is not the whole story.
Tax and reporting have their own sequence
The same is true of tax.
The licence application does not determine where the company is tax resident, where it is effectively managed, whether activities create another taxable presence, how revenue is characterised, what indirect taxes may apply or what information-reporting obligations arise.
Those questions may depend on the same people and flows that drive the regulatory analysis. If senior decision-makers, customer contracts, wallets, bank accounts and operational staff are spread across countries, tax analysis cannot sensibly be postponed until after launch.
Reporting regimes also need data. A business cannot assume that a licence file or AML file will automatically contain everything required for tax reporting.
The best objection: regulators can cause real delays
Of course they can.
An authority may have a queue, request additional information, change its expectations, conduct interviews, scrutinise a novel business model or take longer than an applicant expected. No serious project plan should pretend otherwise.
But regulator uncertainty is precisely why controllable pre-filing dependencies should be managed tightly. A team cannot remove supervisory discretion. It can avoid adding its own avoidable delays to it.
The useful question is therefore not “how long will the regulator take?” but:
What must be true before filing, what can continue in parallel, and which dependency can stop the entire project?
What was knowable in 2022 — and what is clearer now
By the end of 2022, the core lesson was already visible: crypto regulation was becoming an operating problem, not merely a registration problem. Projects needed people, evidence and systems as well as legal forms.
Current frameworks make the dependency chain much more explicit. VARA now publishes a licensing process that separates incorporation and operational setup from the full VASP Licence. Its application material identifies governance, UBOs, key personnel, financial projections, capital, insurance and wind-down as part of the regulatory package.
The newer rules do not justify pretending that every regulator follows the same process. They do justify abandoning the idea of one universal “licence timeline”.
A better planning model
A regulated crypto project should maintain four linked schedules:
- Regulatory schedule: perimeter, application documents, regulatory questions and approval gates.
- Operational schedule: people, technology, policies, vendors, custody, finance and controls.
- Bankability schedule: account requirements, evidence, flow design and financial counterparties.
- Tax and reporting schedule: residence, accounting, registrations, data and filing obligations.
The project date is not the shortest of those schedules. It is the date on which the critical dependencies across all four can support lawful operations.
That is a less marketable answer than a promise of “X months”. It is also a much more useful one.
Sources
- VARA — Licence Applications
- VARA — Licensed Activities
- CBUAE Rulebook — Customer Due Diligence Measures
- CBUAE Rulebook — Federal Decree-Law No. 10 of 2025 on AML/CFT/CPF
Disclaimer
This article is general information about regulated-project planning. It does not provide a licensing timeline or legal, regulatory, tax, banking or investment advice. Requirements and processing times vary by activity, regulator, jurisdiction and applicant, and current rules should be checked before decisions are made.
