Crypto Exchange License + Compliant Website: What Regulators Check Before Approval

Your legal team has the application file ready. Share capital confirmed, policies drafted, directors vetted, AML manual signed off. Then the supervisor opens your website in a browser tab, and the questions start.

The homepage says "regulated exchange". The footer names a company that is not the applicant entity. The fees page is behind a login. There is no restricted-countries notice, and the About page still lists a jurisdiction you withdrew from.

None of that is in the application file. All of it is now part of the assessment.

A crypto exchange licence and a compliant website are not two separate workstreams. In most regimes the public site is the first place a regulator checks whether your claims hold up, and mismatches between the site and the filing generate requests for information that cost weeks. This article covers the website side only: the VASP website requirements a reviewer actually looks for, and how to build a site that survives the check.

Why Your Website Is Part of the Crypto Exchange License Application

Supervisors read the public website as part of the application file. Nothing in most application forms says "attach your homepage", but assessment teams verify representations, and the fastest way to verify what a firm tells the public is to look at what the firm tells the public.

For a CASP authorisation under MiCA, a UK FCA registration, a VARA licence in Dubai or a Bahamas DARE registration, the reviewer is answering one question: does the applicant's outward-facing story match the file?

Here's where most teams lose time. The website was built by a marketing team eight months before the filing, using copy written for investors rather than regulators. Nobody re-read it against the final application.

What a Reviewer Actually Opens

In practice, six pages carry almost all the risk:

• Homepage: headline claims about regulation, authorisation and safety

• About / company page: legal entity name, registration number, registered address

• Fees and pricing page: whether it exists, and whether it is public

• Legal footer: links to terms, privacy, AML statement, complaints

• Terms of service: the contracting entity, governing law, service scope

• Restricted countries page: which territories you say you do not serve

If those six are consistent with each other and with your filing, most website questions disappear.

Where Website Problems Delay Approval

Website problems rarely cause a refusal. They cause requests for information, and each round costs calendar time.

The recurring pattern is an inconsistency, not an omission:

What this means: the cost of a weak website is measured in weeks of RFI cycles, not in refusal letters. If you are still deciding on jurisdiction and structure, the crypto exchange licence process itself is a separate exercise, and worth resolving before the site copy is finalised.

The Legal Pages That Must Exist at the Moment of Filing

At the moment of filing, the site should already carry a complete set of crypto exchange compliance pages, published and reachable without a login. Reviewers do not accept "it is ready internally". If it is not live, it does not exist.

The exact set varies by regime, but the grouping is stable.

Core Documents Every VASP Website Needs

Identity

• Legal entity name, company registration number, registered address

• Regulatory status statement, worded accurately for your current stage

• Group structure disclosure where a brand differs from the contracting entity

Terms

• Terms of service naming the contracting entity and governing law

• Service descriptions matched to the services you actually applied for

• Complaints and dispute-resolution procedure with a stated response time

Risk

• Risk disclosure covering volatility, loss of capital and technology risk

• Asset-specific disclosures where you list or intend to list tokens

Data

• Privacy policy and cookie policy, with a working consent mechanism

• Data-retention and cross-border transfer statements

Fees

• Public pricing, costs and fees policy, reachable without an account

Most of this mirrors what regulated brokers have needed for years, and our broker website compliance checklist covers the shared ground in more detail. Crypto adds asset-level disclosure and territorial controls on top.

Entity Identity and Licence Status Disclosure

Regulatory status disclosure is where accurate wording matters most, because the honest version and the marketing version are rarely the same sentence.

If your application is pending, say that. "Authorisation applied for" is defensible. "Regulated" is not. A regulator's logo on a pre-approval site is worse again, and in several regimes is itself a breach.

Three sentences that work before approval:

• "X Ltd has applied to [regulator] for authorisation as a crypto-asset service provider. Services are not yet offered to clients in [territory]."

• "X Ltd is not currently authorised in [territory]. This page is corporate information only."

• "Services described here will be offered only after authorisation is granted."

What this means: every claim about your status needs a date, an entity and a regulator attached to it, or it should not be on the page.

MiCA Website Disclosures: Fees, Risk Warnings and Sustainability Data

MiCA Article 66 puts four obligations directly on the website:

1. Fair, clear and not misleading information, with marketing communications identified as such (Article 66(2))

2. Risk warnings about crypto-asset transactions, plus hyperlinks to the relevant whitepapers (Article 66(3))

3. Policies on pricing, costs and fees, publicly available in a prominent place on the website (Article 66(4))

4. Information on principal adverse climate and environmental impacts of each crypto-asset's consensus mechanism, also in a prominent place (Article 66(5))

That list is short and specific, which makes it the single most useful reference point for anyone building an EU-facing exchange site. The full obligation text sits in ESMA's rulebook entry for the article.

Article 66 in Practice

Three of those four obligations turn into build decisions, not copy decisions.

"In a prominent place" is undefined. MiCA does not tell you what prominence means, which makes it an information-architecture question. A fees policy linked only from a small-print footer, in low-contrast grey, three clicks from any page a client uses, is present but not prominent. Accessibility criteria give you a defensible standard: contrast ratios, target size and reading order under WCAG 2.2 are the closest thing to an objective test of whether a disclosure can actually be found and read.

The whitepaper hyperlink obligation is a data model. Article 66(3) means every asset you list needs a resolvable whitepaper link. Hardcode fifty of them and you own fifty broken links within a year. Model assets as CMS records with a whitepaper URL field, and the obligation becomes a content task.

Sustainability data is per-asset too. Adverse climate and environmental impact information attaches to each crypto-asset's consensus mechanism, so it belongs on the asset record beside the whitepaper link, not in a single static page.

Risk warning placement follows the same logic: one warning component, referenced everywhere an asset or trading action appears, so the wording changes in one place.

Separating Regulated and Unregulated Services

Unlike a single-product broker site, a crypto exchange usually mixes MiCA-regulated services with services MiCA does not cover, and ESMA has been explicit about how that must look on your site.

In its July 2025 statement on access to unregulated activities, ESMA set out expectations that read like a site specification:

• Separate sections on any website you operate for regulated activities and any other activities

• Regulatory status clearly visible in all marketing communications, not disclosed only inside terms and conditions

• A pop-up requiring confirmation that the client has read and understands the unregulated status, before they access those products

• No using your MiCA authorisation to market unregulated offerings, which ESMA describes as a halo effect

• No unregulated subsidiary operating through the authorised entity's client interface

What this means in practice: your navigation, not your legal page, carries the compliance burden. If a single product grid mixes authorised exchange services with unregulated staking, the fix is structural. You need separate routes, distinct visual treatment, and an interstitial acknowledgement on the boundary.

Geo-Blocking and Restricted-Country Notices

Geo-blocking requirements are not stated as a single rule. They follow from territorial scope: if your licence permits you to serve certain territories, your site should not be soliciting business in the ones it does not cover.

That gives you three implementation levels, with real tradeoffs:

• Notice layer: a restricted-country notice on relevant pages plus a public restricted-jurisdictions list. Lowest friction, weakest evidence of control.

• Gated onboarding: content stays open, but sign-up and KYC reject restricted territories. Balanced, and usually the right default.

• Hard block: IP-level denial of the whole site. Strongest evidence, and the most costly.

Here's the honest tradeoff. A hard block is the safest reading of territorial scope and the worst outcome for reach. It removes you from search visibility in blocked markets, breaks crawler access, and blocks legitimate visitors on VPNs or travelling. For most applicants, gated onboarding plus a clear restricted-country notice is the proportionate answer, but that judgement belongs to your compliance counsel, not your designer.

How Regulators Test Your Territorial Claims

Reviewers test territorial claims by looking for contradictions between what you say and what your site does.

The common ones:

• A restricted-jurisdictions list that omits territories your own terms exclude

• Language versions or currency options for markets you claim not to serve

• Paid campaigns or hreflang tags targeting excluded countries

• Sign-up forms that accept a restricted country in the address field

What this means: geo-blocking requirements are only credible if the notice, the terms, the onboarding form and your marketing all name the same list. One list, one source, referenced everywhere.

What You Can and Cannot Publish Before the Licence Is Granted

Before approval, you can publish corporate information. You cannot publish anything that solicits business you are not yet permitted to offer, and this is where most pre-licence sites fail.

Rules differ by regime, and the differences are practical:

United Kingdom. The FCA treats cryptoassets as Restricted Mass Market Investments. Its financial promotion rules require clear risk warnings, ban incentives to invest, and add positive frictions, client categorisation and appropriateness assessments. Those requirements apply to the website itself, not only to advertising, and an unauthorised firm promoting to UK consumers without an approved communicator is a separate problem.

Dubai. VARA's marketing regulations impose mandatory disclaimer and prominence requirements on marketing content directed at Dubai, including websites, and apply before you hold a licence rather than after.

Singapore. MAS guidance from January 2022 discourages public promotion of digital payment token services: no advertising in public areas or through third-party channels. Your own corporate website, app and official accounts remain permitted, which makes the site the primary sanctioned surface and worth building properly.

European Union. Under MiCA, marketing communications must be identified as such and must not contradict whitepaper information, and unauthorised firms cannot present themselves as authorised.

Safe pre-licence content: company information, team, technology, jobs, contact details, investor material, and a clearly worded statement of application status.

Unsafe: live fee tables presented as an offer, token listing pages with buy buttons, "open an account" flows, referral bonuses, "regulated" or "licensed" claims, and regulator logos.

Jurisdiction Comparison: What Each Regulator Looks For

VASP website requirements diverge enough that one site cannot serve every market on identical terms. This comparison covers the website-facing obligations only, not licence scope or capital.

What this means: if you are targeting more than one of these markets, plan for geo-aware content from the start. Retrofitting territorial variants into a site built for one audience is more expensive than designing for it.

Pre-Submission Website Audit: A Practical Checklist

Run this sequence four to six weeks before you file. It takes two to three working days for a small site, longer if legal content needs drafting.

1. Inventory every page and every claim. Export the sitemap and list each factual assertion about regulation, entity, territory and services. This is the artefact your counsel reviews, not the site itself.

2. Reconcile the inventory against the application file. Any claim that is not in the filing, or contradicts it, is either corrected or removed. No exceptions for hero headlines.

3. Publish the missing legal pages. Terms, privacy, cookies, AML statement, risk disclosure, complaints and fees, all live, all reachable without a login.

4. Fix prominence, not just presence. Check that mandated disclosures are reachable within one click from the pages clients use, and meet contrast and reading-order criteria.

5. Implement the territorial controls you claim. One restricted-jurisdictions list, referenced by the notice, the terms, the onboarding form and your campaign targeting.

6. Get written sign-off and freeze the site. Compliance signs off a dated snapshot. Any change between sign-off and decision goes through the same review.

How WSA Builds Licence-Ready Crypto Exchange Websites

WSA designs and builds websites for regulated fintech: brokers, payment firms and crypto exchanges. That specialisation changes how we structure a build, because compliance requirements arrive as design constraints rather than as a legal review at the end.

Three decisions do most of the work.

Disclosures live in the CMS, not in the design. Fees, risk warnings, restricted countries, entity details and asset whitepaper links become Framer CMS collections. Compliance updates the text and the change goes live everywhere it is referenced, without a developer and without a redeploy. This is the difference between a disclosure you can maintain and one that quietly goes stale.

Regulated and non-regulated services get separate routes. Distinct sections, distinct visual treatment, and an acknowledgement step on the boundary, so the separation ESMA expects is structural rather than a paragraph in your terms.

Prominence is designed and tested. Mandated disclosures are placed against contrast and reading-order criteria, then checked on mobile, where most "prominent" placements stop being prominent.

If you are earlier in the process and still deciding on structure and stack, our guide to how to build a crypto exchange website covers the ground before compliance becomes the binding constraint. No agency can promise approval, and no website design substitutes for legal advice. What a well-structured site does is remove a category of avoidable questions from your assessment.

Conclusion

A crypto exchange licence and a compliant website are assessed together, whether or not your application form says so. The pages a supervisor opens are the ones you probably built first and reviewed last, and the fix is not more legal copy. It is structure: one source for every disclosure, accurate status wording, separate routes for regulated and non-regulated services, and territorial controls that match what your terms already claim.

Treat the website as a controlled document from the moment you start drafting the file, and the VASP website requirements stop being a scramble in week eleven of your assessment.

If you want your site mapped against your filing before you submit, talk to WSA.

FAQ

Do crypto regulators actually review the exchange website?

Yes. Assessment teams routinely open the applicant's public website to verify what the firm tells the market against what it tells the regulator. The website is not usually a listed submission item, which is exactly why it gets overlooked, but it is the cheapest verification tool a supervisor has. Where a site claims a regulatory status the applicant does not hold, names an entity that is not the applicant, or advertises services outside the application's scope, the result is a request for information and a delay. Some regimes go further and put explicit obligations on the site itself: MiCA, for example, requires specific disclosures to be published in a prominent place on the website.

What disclosures does MiCA require on-site?

MiCA Article 66 places four obligations on the website of a crypto-asset service provider. Information to clients and prospective clients must be fair, clear and not misleading, and marketing communications must be identified as such. The provider must warn clients of the risks of crypto-asset transactions and provide hyperlinks to the relevant whitepapers. Policies on pricing, costs and fees must be publicly available in a prominent place on the website. And information on the principal adverse climate and environmental impacts of each crypto-asset's consensus mechanism must also be published in a prominent website location. ESMA has separately stated that regulated and non-regulated activities should sit in separate sections of the site, with regulatory status clearly visible rather than buried in terms and conditions.

Can I list tokens or show fees before the licence is granted?

You can publish information; you should not publish an offer. A fee schedule presented as corporate transparency reads differently from a fee table beside a "start trading" button, and a token page with a buy flow is a solicitation regardless of how the copy is worded. Before authorisation, the safe position is corporate content only: company details, technology, team, contact, and a clear statement of your application status. Live pricing, listing pages with trading actions, account-opening flows and referral incentives generally belong after approval. The line varies by jurisdiction, so confirm the specific position with your counsel for each market you plan to address.

Are geo-blocking and restricted-country notices mandatory?

There is rarely a rule that says "you must geo-block", but there is almost always an obligation not to solicit business you are not licensed to conduct, and the site is where that obligation bites. In practice you have three options: a restricted-country notice with a published jurisdictions list, gated onboarding that rejects restricted territories at sign-up, or a hard IP-level block. Gated onboarding plus a clear notice is the proportionate answer for most applicants. A hard block is the strongest evidence of control and the most costly, since it removes you from search visibility in those markets and blocks legitimate visitors. What matters most is consistency: the notice, the terms, the onboarding form and your ad targeting must all reference the same list.

Which legal pages must exist at the moment of filing?

At filing, the following should already be live and reachable without a login: terms of service naming the contracting entity and governing law; privacy policy and cookie policy with a working consent mechanism; an AML and KYC statement; a risk disclosure covering volatility and loss of capital; a complaints and dispute-resolution procedure with a stated response time; a public fees and costs policy; and a company page carrying the legal entity name, registration number and registered address. Add a restricted-jurisdictions page if your licence is territorially limited. If your application is pending, each of these should be worded for that stage rather than describing a status you do not yet hold.