Sample report

Compliance audit report

Licensing is a function of how the product is built. Each design choice, and the specific licence or duty it triggers in each market.

Download the original PDF

In short

Four technical design choices traced to the licences they trigger across the EU, UAE, Singapore and the US.
Custodial key handling, an in-house matching engine, a fee-sharing token and a company-settled fiat on-ramp each trigger a separate regime.
Half of those triggers are design choices rather than destiny. The cheapest licence is the one the architecture never needs.

This is an illustrative deliverable, not a record of a real engagement, and it is not legal advice. The subject, the Lumenswap Protocol, is fictional. The regimes named are real; how they apply to a real product depends on its facts and on local counsel.

Target markets

The team plans to serve the European Union, the United Arab Emirates, Singapore and, later, the United States. Every finding is mapped against those four, because a design that is unremarkable in one is licensable in another.

C-01. Custodial wallets hold user assets

The platform generates and stores users' private keys server-side; deposited assets sit in pooled wallets the company controls. Users never hold their own keys.

UAE: this is Custody Services under VARA's VA Activities framework, licensable in its own right and separate from exchange activity. EU: under MiCA this is the CASP service of custody and administration of crypto-assets on behalf of clients, requiring authorisation plus segregation and safekeeping duties. Singapore: a digital payment token custody service under the PSA.

Before launch: either obtain the custody authorisations in each market, or re-architect to non-custodial — user-held keys, or MPC where the user keeps a share — which removes this trigger entirely. The team scoped custody out of the EU launch and filed with VARA first.

C-02. In-app swaps against the company's own matching engine

Trades execute against an order book the company operates, not peer-to-peer smart contracts alone.

UAE: Exchange Services licence under VARA. EU: MiCA CASP service of operating a trading platform for crypto-assets. Singapore: PSA licensing for facilitating DPT exchange.

Before launch: sequence applications with the custody filings above, since both target the same regulators. Until granted, geo-restrict the affected markets at onboarding, not just at the marketing layer.

C-03. Token carries fee sharing and voting

The protocol token distributes a share of platform fees and votes on treasury spending.

EU: fee flow makes pure utility-token treatment hard to sustain under MiCA, and the whitepaper and notification duties attach either way. US: fee sharing is the classic profit-expectation limb of the Howey analysis, which makes the US the highest-risk market for this design.

Before launch: keep the US excluded. If US access matters commercially, the fee-sharing mechanic is what has to change, not the marketing.

C-04. Card on-ramp settles through the company account

Fiat from card purchases lands in the company's account before crypto is delivered, which makes the company an intermediary in the flow of customer funds.

US: state-by-state money transmission licensing. EU: e-money and payment services rules alongside MiCA. Everywhere: full AML and KYC programme obligations attach to this flow.

Before launch: route the fiat leg through a licensed payments partner so funds never touch company accounts, and verify in writing that the partner's licences actually cover this flow.

Feature to licence, market by market

The same table the engineering team reads and the legal team argues from. One row per design choice, one column per market.

Technical feature	EU (MiCA)	UAE (VARA)	Singapore (PSA)	US
Custodial wallets	CASP custody	Custody Services	DPT custody	State-level
Own matching engine	Trading platform	Exchange Services	DPT exchange	High risk
Fee-sharing token	Whitepaper duties	Issuance review	Case-by-case	Howey exposure
Card on-ramp	PSD2, e-money	Via partner	Via partner	Money transmission

The engineering alternative

Half of these triggers are design choices, not destiny. Non-custodial wallets remove C-01, routing swaps fully on-chain narrows C-02, and a partner-held fiat leg removes C-04.

This is why the compliance review runs alongside the technical audit rather than after it. The cheapest licence is the one your architecture never needs.

Launch readiness

Two complete, one in progress, one open. The open item is the one that depends on a third party, which is usually the one that slips.

Item	Status
VARA custody and exchange filings prepared	In progress
EU launch scoped to non-custodial features	Complete
US access excluded at onboarding	Complete
Payments partner licences verified in writing	Open

Questions

Is this legal advice?

No. We are engineers who map what your architecture triggers, and we name the regimes in general terms. How a regime applies to your specific facts is a question for licensed counsel in that jurisdiction, and the report is built to be handed straight to them.

We already have lawyers. Why do we need this?

Because your lawyers cannot read your codebase. The gap between what the product does and what the legal team believes it does is where licensing surprises live.

Can an architecture change really remove a licence requirement?

Sometimes, and legitimately. Non-custodial key handling removes custody obligations because there is nothing held; a licensed partner on the fiat leg removes payments obligations because the funds never arrive. The trigger is the behaviour, not the description.

The work behind this

Compliance and business logic audit

Every feature traced to the licence it triggers, in every market you plan to serve.

Proof of reserves

Independent verification that what you hold covers what you owe, published so users can verify it themselves.

Web3 and protocol audit

Line-by-line review of contracts, chain layer and upgrade paths, with proof-of-concept for every finding.