Treat CDACE preparation as training in classification reasoning. For every topic — VASP standards, sanctions analytics, DeFi protocols, asset types — the work starts with a decision: what is this thing, and who controls it? Write out the definitional elements you are checking, apply them to short paper fact patterns, and score your own reasoning against a rubric. This turns a broad six-topic syllabus into a repeatable method you can reuse on any unfamiliar scenario the exam presents.
Anchor everything to the VASP definition before touching the obligations
The virtual asset service provider concept rests on a few elements: covered services, conducted as a business, for or on behalf of another person. Practice decomposing each element so obligations attach only after the definition is satisfied.
Break the definition into testable parts. Covered activity typically includes exchanging virtual assets for fiat or other virtual assets, transferring them, safekeeping or administering them, and participating in and providing financial services related to an issuer's offer or sale. Each part is a separate check: a company that only builds non-custodial software fails the safekeeping element; a hobbyist swapping their own assets fails the 'as a business' element. Write the elements as a checklist and practice running it against one-line descriptions of firms.
The elements do real work in exam-style facts. A hosted wallet provider holds customer keys and acts for customers, so the checklist catches it. A mining pool earns fees but does not transfer on behalf of a specific counterparty in the same sense. A decentralized exchange front-end that never touches custody raises harder questions the checklist is designed to surface rather than settle. The point is to see which elements are clearly met, which are clearly not, and which are genuinely contested — that final category is where careful reasoning earns its keep.
- Element 1: is a covered service being performed (exchange, transfer, custody, issuance-related services)?
- Element 2: is it conducted as a business rather than personally?
- Element 3: is it for or on behalf of another person?
- Output: clearly VASP, clearly not, or fact-dependent — and state which element is contested.
Travel Rule questions: identify your role before deciding what data must move
Travel Rule obligations attach to the institutions involved in ordering, transmitting, and receiving a transfer. Name your institution's role first — originator, beneficiary, or intermediary — because the required originator and beneficiary information flows depend on it.
Learn the role vocabulary precisely. The originator is the ordering institution on the sending side; the beneficiary institution is on the receiving side; intermediaries sit between them in routed transfers. The required information about the originator and beneficiary travels with the transfer, and the sequence of handoffs matters: a receiving institution evaluates information it obtains and decides on escalation when data is missing or inconsistent. Drills where you label roles in a multi-hop payment chain are more useful than rereading the rule text.
A compact scenario: your exchange initiates a customer withdrawal to another exchange's customer. A plausible mistake is assuming the data obligation belongs to 'the industry' generally and not analyzing your own position — leading you to neither transmit complete originator information nor check what you received. The better decision is a role analysis: you are the originator institution, so complete originator and beneficiary data must accompany the transfer, and you should have a process for when the counterparty's details are incomplete. Getting the role wrong changes which counterparty you chase and what you document.
Sanctions analytics: separate address screening, attribution, and exposure scoring
Chain analytics produces three distinct outputs: whether an address matches a listed or flagged one, who the address is attributed to, and how close an exposure is. Each output supports a different escalation decision, and conflating them produces either over-blocking or missed review.
Define the terms. Direct exposure means funds touch a flagged address or a counterparty itself is designated. Indirect exposure means a connection exists only through intermediated hops, common counterparties, or heuristically clustered addresses. Attribution assigns an address to an entity or cluster using heuristics such as common-input ownership and change-address patterns — always with a stated confidence level. Exposure scoring layers on distance and direction of funds. These are different claims with different evidentiary weight, and a sound compliance decision names which one it is relying on.
Practice a paper case: a customer deposit passes through a mixing service two hops before reaching your platform. A plausible mistake is treating any downstream connection to a mixer as equivalent to direct sanctioned exposure and freezing the account reflexively. The better decision is graduated: document the analytics output, note the hop distance and that mixers obscure rather than prove origin, and route to enhanced review or source-of-funds inquiry per your risk framework rather than to an automatic block. The classification — direct versus indirect — is what makes the response proportionate and defensible.
DeFi and DAOs: 'decentralized' is a question to investigate, not an answer
The analytical task is mapping control: who can upgrade contracts, pause functions, collect fees, or direct operations. Governance and administrative structures determine whether an identifiable accountable party exists behind a protocol.
Build a control-mapping vocabulary. Upgradeable contracts and admin keys or multisignature wallets indicate someone can alter protocol behavior. Governance tokens and on-chain voting indicate collective decision-making whose concentration matters — a handful of large holders behaves differently from broad distribution. Fee recipients, treasury addresses, and front-end operators are additional control surfaces even when the core contracts are immutable. Each item is a fact to identify in a scenario, not a conclusion to assume.
Compare two protocols on paper. Protocol A has immutable, non-upgradeable contracts, no fee switch, and no treasury — the control map is nearly empty. Protocol B has a timelocked admin multisig, a treasury paying auditors and marketers, and a polished front-end run by a company. A plausible mistake is dismissing B as 'fully decentralized' because the token votes. The better decision is to map B's controllers and assess whether its services are provided as a business on behalf of users — because the answer drives whether VASP-style obligations, sanctions responsibilities, and reporting expectations plausibly attach to identifiable parties.
Stablecoins, CBDCs, and tokenized securities: three different compliance logics
These asset types differ by issuer, value basis, and the holder's claim. The wrapper is tokenized; the underlying determines the regulatory lens, so identify the underlying first and let it dictate your questions.
A stablecoin is typically a private issuer's liability or reserve claim, so the compliance questions concentrate on reserve composition, redemption reliability, and disclosure. A CBDC is a central bank liability — a direct claim on the monetary authority — which shifts the analysis toward access models, privacy design, and intermediated distribution. A tokenized security is a traditional security represented on a ledger; the securities obligations of the underlying carry over intact, adding technology-layer questions about custody and transfer restrictions.
The exam-relevant skill is refusing to let surface similarity decide. A yield-bearing token, a bank-issued deposit token, and a tokenized bond can all move on the same chain with identical interfaces. A plausible mistake is classifying by technology or ticker aesthetics — treating anything on-chain as a crypto-asset question. The better decision is a two-step habit: establish the issuer and the holder's claim, then check which body of obligations the underlying invokes. Table 1 condenses the contrasts for quick self-testing.
| Feature | Stablecoin | CBDC | Tokenized security |
|---|---|---|---|
| Issuer | Private issuer or entity | Central bank / monetary authority | Issuer of the underlying security |
| Holder's claim | Claim on reserves or redemption right | Claim on the central bank | Rights of the underlying instrument |
| Primary compliance lens | Reserves, redemption, disclosure | Access model, privacy, distribution | Securities rules plus ledger custody |
| Key exam question | What backs it and can holders exit? | Who can hold it and through whom? | Which securities obligations carry over? |
Two worked scenarios with the reasoning written out
Work scenarios in a fixed order: classify the parties, classify the asset, identify the control map, then name the obligation. Watching where your reasoning jumps a step is the fastest way to improve.
Scenario A: a customer at VASP X withdraws to a self-custody wallet, and weeks later funds from that wallet arrive at VASP Y. A plausible mistake is treating the whole flow as a VASP-to-VASP transfer and demanding full travel-rule data from Y for a leg that ran through an unhosted wallet. The better decision splits the flow into segments: the X-to-wallet withdrawal is an unhosted transfer where the focus shifts to counterparty verification and source-of-funds analysis at deposit; the wallet-to-Y leg is inbound from self-custody, a distinct trigger. Why it matters: the segmenting decides which obligation, which escalation, and which documentation applies to each leg.
Scenario B: a lending protocol advertises community governance, but its contracts are upgradeable through a five-of-nine multisig controlled by the founding team, and the front-end is operated by a incorporated company charging fees. A plausible mistake is concluding no accountable party exists because votes occur on-chain. The better decision maps the controls — upgrade authority, treasury, fee-collecting operator — and evaluates whether identifiable parties provide financial services as a business. Why it matters: sanctions exposure, customer due diligence expectations, and incident response duties all presuppose someone to hold accountable, and that determination rests on the control map, not the marketing language.
A self-audit exercise, rubric, and adaptable study sequence
Run a weekly paper audit: write five short fact patterns, classify each on four dimensions, and score your reasoning against a rubric. Then sequence your preparation from definitions through mixed scenario sets.
The exercise: write five one-paragraph scenarios — a wallet vendor, a mixer-adjacent deposit, a governance-token protocol, a stablecoin redemption, a tokenized bond. For each, record four classifications: VASP status (with the contested element named), asset type, direct versus indirect exposure, and the control map. Expected observations: at least one scenario should land in 'fact-dependent' on VASP status; the mixer case should produce 'indirect' with a documented confidence level; the protocol case should surface at least two control surfaces. If everything classifies cleanly, your scenarios are too easy — rewrite one to be genuinely ambiguous.
A rubric and sequence make this sustainable. Score each scenario 0–2 per dimension: 0 means a label with no reasoning, 1 means reasoning with a missing element, 2 means complete element-by-element justification. A self-check milestone of consistently scoring 7–8 out of 8 across mixed scenarios signals reasoning fluency — a learning benchmark only, not a prediction of exam results. Then sequence: spend early weeks only on definitions and checklists; middle weeks on analytics drills and control mapping; later weeks on mixed timed scenario sets combining two or more dimensions per prompt.
- Readiness check 1: you can state the VASP elements from memory and name which element is contested in an ambiguous fact.
- Readiness check 2: given a transfer description, you can label originator, beneficiary, and intermediary roles without hesitation.
- Readiness check 3: you can distinguish direct from indirect exposure and state what documentation each warrants.
- Readiness check 4: given any protocol description, you can produce a control map with at least three candidate control surfaces.
- Readiness check 5: given a token, you can identify issuer and holder claim before naming any rule.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.