Do not begin with a score. Begin with the service boundary, transaction flow, responsibility map, and data limitations.
Define scope and ownership
State which entities, protocols, interfaces, APIs, chains, assets, client types, and review period are included. Name the assessment owner and each contributing team. Show excluded components and why they are outside scope. The document should let an independent reviewer understand the product without relying on marketing language.
Assess inherent risk
| Factor | Examples to examine |
|---|---|
| Customer | Retail, institutional, high-risk business, PEP, nested service, anonymous interaction |
| Geography | User, entity, counterparty, sanctioned exposure, weak supervision, conflict |
| Product | Swap, bridge, transfer, liquidity, issuance, staking, embedded API, recovery |
| Asset | Liquidity, privacy features, issuer, transfer restrictions, bridge and market risk |
| Transaction | Velocity, layering, chain hopping, unusual contract calls, high-risk exposure |
| Technology | Permissionless access, data gaps, smart-contract and admin-key dependencies |
Explain the causal link between each fact and the risk. Do not copy a sector risk statement without showing how it applies to this service. Add confidence levels where data is incomplete or volumes are too small to support a reliable conclusion.
Map controls to risks
For each control, record its owner, system, frequency, input data, decision logic, evidence, and failure path. “Blockchain analytics” is not enough. Specify which chains and transactions are covered, when screening happens, how risk indicators are interpreted, and what action can actually be taken.
- Customer and beneficial-owner due diligence
- Wallet, sanctions, and counterparty screening
- Transaction monitoring and case management
- Asset and geographic review
- Travel Rule classification and exceptions
- Enhanced due diligence, limits, holds, and escalation
- Security, access, vendor, and change controls
Test design and operation
Design testing asks whether the control could address the risk if performed as documented. Operating testing asks whether it actually worked. Use realistic scenarios, sample cases, inspect timestamps, reproduce decisions, and verify that failures reached trained reviewers. Rate design and operating effectiveness separately.
Explain residual risk
Residual risk is not a mechanical subtraction. A high-impact scenario can remain material even after likelihood is reduced, and several controls may depend on the same incomplete data. State why risk is acceptable, conditionally acceptable, or outside appetite. Link acceptance to an accountable decision maker, expiration, monitoring, and remediation.
Minimum evidence pack
Preserve the methodology, factor criteria, source data, control inventory, test results, assumptions, approvals, action plan, and prior versions. The assessment should drive launch conditions and resource allocation—not merely document a conclusion after the fact.
Use the complete dVASP AML/CFT risk assessment guide for a step-by-step methodology.