A VASP (virtual asset service provider) licence application is, at its core, a structuring exercise before it is a compliance exercise. The entity you choose, the jurisdiction where it sits, and the activity scope you declare in the application will define your regulatory exposure, banking access, tax position, and passporting rights for years. Getting those decisions wrong at the application stage is expensive to unwind – and regulators rarely grant do-overs without scrutiny.
Across the major licensing hubs – from VARA in Dubai to the MiCA CASP regime across the EU, and from MAS in Singapore to the SFC in Hong Kong – the structural choices made before the application is filed are the choices that determine whether the licence is granted, and on what terms. This analysis maps those decisions for the operator making them now.
Why Structure Comes Before the Application
The legal regime you apply under is not a post-incorporation formality – it is a strategic input that shapes every subsequent commercial decision. Every major VASP regime conditions its licence on the applicant's legal form, ownership structure, AML/CFT controls, and, in most cases, its physical presence in the jurisdiction. File the application with the wrong entity or the wrong activity scope, and you are not just facing a delay: you are handing the regulator a reason to look more closely at everything else.
In our cross-border practice, we see two recurring failure modes. The first is the operator who picks a jurisdiction because it looks fast and inexpensive, without mapping whether that licence is recognised – or even relevant – in the markets where its users actually sit. The second is the operator who chooses the right jurisdiction but applies under the wrong entity, triggering capital, governance, and AML obligations that were built for a different business profile. Both failures share a common cause: the structure was not stress-tested before the application was filed.
The MiCA regime introduced CASP (Crypto-Asset Service Provider) authorisation with EU-wide passporting rights, which changes the calculus for any operator serving European clients. A licence granted in one member state travels across the EU/EEA. That benefit is real – but it comes with a governance, capital, and AML baseline that the applicant must satisfy at the home-state level before any cross-border service begins.
Mapping the Activity Scope: What Are You Actually Doing?
The activity scope declared in a VASP licence application determines the regulatory perimeter, the capital requirement, and the ongoing compliance obligations – and it is the single most consequential structuring decision you make before filing. Most regimes now list regulated activities with specificity: exchange, custody, transfer and settlement, lending, advisory, broker-dealer. Each carries its own conditions.
VARA in Dubai operates on an activity-based licensing model: an operator that provides exchange services and custody services must hold authorisation for both activities. There is no single "crypto licence" that covers everything. The same logic applies under MiCA – a CASP providing custody and administration of crypto-assets operates under a different authorisation layer than one providing execution services. Under the MAS Payment Services Act in Singapore, the licence tier – standard payment institution or major payment institution – depends in part on transaction volume, not just activity type.
The practical implication: before any application is prepared, the operator must produce a precise map of every regulated activity it intends to conduct, including activities that may begin only in year two of operations. Applying for a narrow scope and expanding later is possible, but it requires a variation application and, in some regimes, a fresh regulatory review. Declaring a scope that is too broad, by contrast, may impose capital and governance obligations the business cannot currently meet. The right approach is forensic: identify every activity, then match it to the applicable regime provision.
The cross-border dimension adds a further layer. An operator licensed under MiCA for exchange services, serving users in Singapore, must also satisfy the MAS regime to the extent its services constitute regulated activities under the Payment Services Act. A licence in one jurisdiction does not displace the regulatory obligations of another. Operators we advise on multi-market builds routinely discover that the combination of jurisdictions they want to serve requires two or three separate licence applications, not one.
For a scoped analysis of your activity map and the licensing stack it implies, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis. Map your options.
How Does Entity Selection Affect a VASP Application?
Entity selection is not a legal nicety – it is a substantive licensing condition, and regulators in every major hub now look through the applicant entity to the group structure behind it. The question is not just which jurisdiction the applicant entity sits in, but how it connects to the parent, the operating entities, and any offshore holding layer.
Most flagship VASP regimes require the applicant to be a locally incorporated legal person or, at minimum, a locally registered branch. VARA in Dubai requires that the entity be incorporated in the emirate and have a substantive local presence: a physical office, a senior management team that is available in jurisdiction, and a governance structure that is not merely a shell referencing offshore directors. ESMA has published supervisory guidance under MiCA making clear that CASP authorisation is not available to entities whose substance is located elsewhere.
The question of group structure matters for a different reason: intra-group flows, related-party transactions, and the location of the operating wallet infrastructure are all examined by AML teams during the authorisation process. An applicant whose technology stack is owned by an offshore entity, whose fiat banking sits with a related party in a third country, and whose UBO resides in a jurisdiction that is on the FATF grey list will face questions that a simpler structure avoids entirely.
In our practice, the optimal structure for most multi-market operators is a two-entity build: a licensed operating entity in the primary hub, and a holding entity in a tax-efficient jurisdiction with a strong treaty network. The holding entity does not conduct regulated activity and does not appear in the licence application as an operating principal. The operating entity is properly capitalised, locally governed, and AML-compliant in its own right. That separation protects the licence from group-level risk events and simplifies the regulator's view of what is actually being authorised.
AML/CFT and the Travel Rule as Structuring Inputs
AML/CFT compliance is a licensing condition, not an operational afterthought, and the Travel Rule (the obligation to pass originator and beneficiary data with a virtual asset transfer) is now a hard requirement in every major VASP regime – including under FATF Recommendation 15, MiCA, the MAS Payment Services Act, and the VARA rulebooks. Failing to demonstrate at the application stage that the business can satisfy the Travel Rule in practice has caused application delays and refusals in every hub we work across.
The structuring implications of AML/CFT compliance run deeper than most operators expect. The business model determines the AML risk profile, and the AML risk profile determines the depth of the compliance programme the regulator will expect to see. A peer-to-peer exchange operator faces a materially different set of AML expectations than a custody provider serving institutional clients. A lending protocol that intermediates stablecoin flows between retail users faces more scrutiny than a B2B settlement service with a known counterparty base.
The Travel Rule data threshold and the technical solution for passing originator and beneficiary information must be selected before the application is filed, because the technical architecture of the product affects how those obligations are met. An operator whose technology cannot tag transfers with the required data fields will not satisfy the regulator's readiness test – regardless of the quality of the written AML policy.
Cross-border VASP structures also face a second AML problem: the regulator in the licensing jurisdiction will want to know how the AML programme applies to users and counterparties in other markets. If the applicant is licensing in Malta under MiCA but serving users in Asia, the MFSA will expect the AML programme to address how those users are onboarded, screened, and monitored. The answer "we will follow local rules in each market" is not sufficient. The programme must be designed as a coherent whole.
Which Jurisdiction Should You Apply In?
The jurisdiction decision is not a single variable – it is a matrix of regulatory speed, capital cost, banking access, passporting rights, and long-term supervisory relationship. The right answer depends on the operator profile, the target user base, and the activity scope. There is no universally optimal jurisdiction.
The relevant axes for most operators are: (1) the markets the operator intends to serve, and whether a licence in the chosen jurisdiction is respected there; (2) the regulatory timeline and the capital / governance baseline the jurisdiction imposes; (3) the availability of banking for a crypto-licensed entity in that jurisdiction; and (4) the ongoing supervisory cost and reporting burden.
Profile A – EU-facing exchange or custodian. For an operator whose primary user base is in Europe, a MiCA CASP authorisation from a member state with an established crypto supervision track record offers passporting across the EU/EEA. The authorisation process, timeline, and capital baseline vary by member state, but the passporting benefit is consistent across all of them. The trade-off is a governance and AML baseline that is more demanding than pre-MiCA national VASP registrations.
Profile B – Gulf-facing operator or regional exchange. VARA in Dubai is the primary licensing track for operators whose user base or banking relationships are centred in the Gulf region. The activity-based licence structure is well-matched to exchange and custody businesses. The FSRA in Abu Dhabi's ADGM provides an alternative for operators who prefer a common-law jurisdiction and a different regulatory approach. The two regimes are not substitutes for each other – they serve different market positions.
Profile C – Asia-Pacific operator. MAS in Singapore and the SFC in Hong Kong each offer a recognised licensing regime, but they serve different operator profiles. Singapore's Payment Services Act is suited to exchange and payment services; the SFC's VASP licensing regime in Hong Kong is focused on trading platforms. An operator serving both markets will, in most cases, need separate applications in both jurisdictions.
Profile D – Offshore holding with targeted market access. BVI and Cayman Islands VASP registrations under their respective VASP acts offer a lighter-touch regime, but they do not grant access to any major retail market and they do not substitute for a domestic licence where one is required. These regimes are appropriate for fund structures, B2B service providers, and holding entities – not for operators serving retail users in regulated markets.
If a prior application stalled or a banking relationship was lost after filing, a structural review can often identify the precise point of failure. Contact OBOLUS at info@oboluslaw.com or write to us via t.me/oboluslaw to discuss a second read on your structure. Map your options.
The Banking Problem in VASP Licensing
Banking access is the structuring variable that most operators underestimate – and its absence can render a perfectly obtained licence commercially useless. Across the major hubs, licensed VASPs frequently discover that domestic banks will not open accounts for crypto-licensed entities, that correspondent banking for crypto flows is restricted, or that the banking relationship that was in place before licensing becomes complicated after it.
The problem is structural. Banks in most jurisdictions apply their own AML risk appetite to crypto-licensed clients, and that appetite is often narrower than the regulatory permission the licence grants. A VASP licensed under MiCA for custody and exchange services may find that only a small number of credit institutions in the member state where it is licensed are willing to provide fiat settlement accounts – and that those institutions impose their own transaction monitoring, counterparty screening, and reporting obligations on top of the regulatory baseline.
The banking access question must be tested before the licensing jurisdiction is selected – not after. In our practice, we treat banking feasibility as a hard constraint in the jurisdiction decision matrix. An operator that selects a jurisdiction primarily for regulatory speed, without confirming that correspondent banking for its anticipated flows is available, is making a decision on incomplete information. The licence without the bank account is not an operating business.
In a recent matter, a payments company had obtained a crypto-asset service licence in a major EU jurisdiction and then spent several months unable to open a fiat settlement account with a domestic bank. The business could not settle trades, could not collect fees, and could not fund the capital reserve required by the licence. We worked through the banking feasibility analysis in parallel jurisdictions and identified an alternative structure – a second entity in a jurisdiction where banking access for the specific activity profile was demonstrably available – that resolved the problem. The lesson is not that banking is impossible for VASPs; it is that banking access is jurisdiction-specific and activity-specific, and must be scoped before the structure is committed.
What Are the Most Common Mistakes in a VASP Licence Application?
The most consequential mistakes in a VASP licence application are structural, not procedural. They are made before the application is filed, and they are difficult to correct without withdrawing the application or restructuring the business mid-review.
The first is activity-scope mismatch: applying under a scope that does not accurately reflect what the business does, either because it is too narrow (excluding activities that have already begun) or too broad (triggering obligations the business cannot currently meet). Regulators across every major hub now conduct substantive business-model assessments as part of the review process. An application whose described activities do not match the observable business model – the product, the website, the user flows – will generate questions the applicant is not prepared to answer.
The second is the offshore-person problem. Many VASP regimes require the operator to have real local substance: a local director, a local MLRO (money laundering reporting officer), a local office. An application that lists offshore directors or a nominee local director who has no operational role in the business will fail the substance test. The regulator's interest is in who is actually running the compliance function, who can be held accountable, and who is available for regulatory dialogue.
A common assumption – and it is one we encounter regularly – is that a single offshore VASP registration is sufficient to serve clients in multiple markets. It is not. A BVI or Cayman VASP registration does not create a right to solicit clients in the EU, in the UK, in Singapore, or in the UAE. Each of those jurisdictions has its own licensing or registration requirement for the relevant activities, and operating in those markets without the applicable authorisation exposes the business to enforcement action, not just regulatory friction.
The third common mistake is sequential rather than parallel processing. Operators who begin the licence application and then start the banking, AML systems, and governance build in series – rather than in parallel – consistently overshoot their timelines. The authorisation process typically runs concurrently with the build of the compliance infrastructure. Filing a complete application requires that the policies, the systems, and the governance appointments are already in place, not in progress.
How Does Token Classification Interact with a VASP Application?
Token classification is a licensing prerequisite, not a post-licence issue. The regime under which a token falls – payment token, utility token, security token, asset-referenced token, or e-money token – determines whether the VASP licence is the right instrument or whether a separate issuer authorisation is required, and in some cases whether the applicable regulator is the VASP supervisor or the securities regulator.
Under MiCA, a business that issues an ART (asset-referenced token) or an EMT (e-money token) faces issuer-level authorisation requirements that are separate from and additional to any CASP authorisation for exchange or custody services. Those issuer obligations include reserve composition requirements, redemption rights, and marketing restrictions. An operator who is simultaneously an issuer and a service provider for its own token must satisfy both regimes.
The FINMA token taxonomy in Switzerland – distinguishing payment, utility, and asset tokens – has been influential in structuring decisions globally, because it provides a framework for assessing whether an instrument is regulated as a security (requiring a securities licence) or as a payment token (requiring a money-services registration or VASP authorisation). The substance-over-label principle applies: the rights that a token confers determine its classification, not the terms used to describe it in the whitepaper or the marketing materials.
In our practice, token classification analysis is a pre-application step. Bringing the analysis after the application is filed – or, worse, after the token has launched – creates a remediation problem that is substantially more expensive and time-consuming than building it correctly from the outset. The classification also has tax implications: a token that is treated as a security in one jurisdiction and a utility token in another may produce different tax outcomes on issuance, transfer, and redemption in each market.
Related at OBOLUS
Related at OBOLUS
- Licensing & Registration for Digital-Asset Businesses – How OBOLUS maps the full licence stack across operating, custody and payment layers.
- VARA Licence Application in France: AMF/PSAN – Jurisdiction-specific analysis of France's crypto authorisation regime and the MiCA transition.
- How to Structure a Security Token Offering – Step-by-step guide to STO structuring, token classification and cross-border distribution.
FAQ
How long does a crypto licence take to obtain?
Timelines vary significantly by jurisdiction and by the complexity of the application. In well-resourced regimes with established review processes, authorisation can take several months from the point of filing a complete application; in others, the process may extend considerably longer. The timeline is heavily influenced by whether the application is complete at filing, whether the applicant's AML programme and governance structure satisfy the regulator's initial review, and whether the regulator requests additional information during the process. Preparation before filing is the most reliable way to compress the timeline.
Which jurisdiction is best for licensing my crypto business?
There is no single best jurisdiction – the right licensing hub depends on where your users are, what activities you intend to conduct, what banking access is available for your specific profile, and how the licence will interact with other jurisdictions in which you operate. For EU-facing businesses, a MiCA CASP authorisation provides passporting value that a non-EU licence cannot replicate. For Gulf-facing operators, VARA in Dubai or the FSRA in ADGM may be the more relevant choice. The analysis requires mapping your activity scope, user base, and banking requirements against the regulatory and commercial conditions in each candidate jurisdiction.
Do I need a separate custody licence?
In most major VASP regimes, custody of digital assets is treated as a distinct regulated activity that requires explicit authorisation. Under MiCA, custody and administration of crypto-assets on behalf of clients is a separately authorised CASP service. Under VARA in Dubai, custody is one of the activity-based licence categories. Under the MAS Payment Services Act, safeguarding digital payment tokens carries its own conditions. An operator that provides custody alongside exchange or transfer services will generally need authorisation covering both activities. The specific structuring of the custody function – including the legal title and segregation arrangements – is itself a licensing condition in most regimes.
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 that sit around them. Digital assets are the entirety of our practice, and we act only for businesses. We map the licence stack across operating, custody and payment layers before you commit – so the structure you build is the structure that holds up under regulatory scrutiny. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialising in the intersection of token architecture, protocol design and multi-jurisdiction VASP licensing strategy.
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.