KYC/AML in Web3 (Risk-Based CDD, KYT, Travel-Rule Concepts)

1) Why KYC and AML look different in Web3

Blockchains are transparent by default and pseudonymous by design. Everyone can see the movement of value, yet identities live off chain. That mix changes both the risk surface and the available controls. On the upside, you get rich, real-time telemetry that traditional finance rarely enjoys. You can quantify exposure to hacks and sanctioned entities with public evidence and track behavioral patterns across time. On the downside, if you treat an address as an identity you will drown in false positives or miss the human intent behind flows. The best programs combine disciplined data minimization with cryptography-aware tooling so that safety, privacy, and product velocity can coexist.

Another difference is operational tempo. Crypto markets run nonstop and cross chains, custodians, and jurisdictions in minutes. That speed forces compliance stacks to behave like any modern production system. Controls must be measurable, reproducible, and fail safe. Cases need clear SLAs. Vendors must be interchangeable. Playbooks must be exercised, not just documented. A rule that is correct on paper but impossible to operate at midnight on a Saturday is a broken rule.

2) A risk-based matrix that drives everything

A risk-based approach is the north star. Instead of one monolithic onboarding flow and one blunt monitoring threshold, you size your controls to the risk. A simple but powerful way to anchor risk is a matrix across four dimensions:

• Customer type: retail, high net worth, corporate, nonprofit, market maker, DAO treasury, or protocol foundation.
• Product exposure: custodial vs non-custodial, spot vs derivatives, staking or earn, leverage, and privacy features.
• Jurisdiction: where you are regulated, where the user resides, and where value flows.
• Asset and chain characteristics: stablecoins vs volatile tokens, L1 vs L2, bridge risk, admin keys, and oracle dependencies.

Score each dimension with simple, auditable logic. The matrix outputs a starting tier and a set of default limits and controls. It also defines when and how you refresh risk. As risk changes, controls evolve. The goal is principled consistency: similar customers and products get similar treatment, and deviations are explainable and logged.

3) CDD and KYC: tiers, verification, and refresh

Customer Due Diligence is not a form. It is a lifecycle. You collect information proportionate to risk, verify it, and keep it current as risk changes. The simplest structure is tiered onboarding.

Tiered onboarding

• Simplified due diligence: low limits and low risk. Capture minimal identity attributes and run sanctions and PEP screening. Good for trials and micropayments.
• Standard due diligence: add government ID, selfie or liveness, proof of address where required, and database checks. This is the default for most retail flows.
• Enhanced due diligence: for higher-risk or higher-limit cases. Request source of funds and, if relevant, source of wealth. Increase refresh frequency, add senior approval, and document the rationale carefully.

Entity customers

Onboard companies, funds, and foundations by verifying legal existence, collecting constitutional documents, identifying beneficial owners and controllers to relevant thresholds, understanding the nature of business, and verifying authorized signers. Record ownership charts and controller relationships so analysts are not reverse-engineering structures during a time-critical case.

Risk scoring and refresh

Assign a starting tier and a numeric risk score. Define refresh cadences by tier, plus event-driven triggers: change of residency, adverse media, sanctions list updates, unusual velocity, or large deviations from expected behavior. Track a risk delta over time so that you can explain movement between tiers. Refresh is not a one-size event; use step-up requests tailored to what changed.

Privacy-aware KYC

• Verifiable credentials: prefer credentials like “over 18,” “resident of X,” or “KYC-verified in last 12 months.” Store proofs and expiry, not raw documents.
• Selective disclosure: collect the exact attributes your rule requires. If permitted, purge raw scans after verification. Maintain a reproducible verification record without hoarding unnecessary personal data.
• Zero-knowledge proofs: in advanced setups, accept proofs of membership in an allowlist of verified identities, or proofs of non-membership in a denylist, without revealing identity.

Records and retention

Keep what you must — and no more. Store verification outcomes, analyst rationales, consent artifacts, and risk scores with immutable logs and strict access controls. Automate deletion at the end of retention windows and maintain an anonymized analytics copy only if your privacy posture allows and only when it cannot be re-identified.

4) Sanctions and PEP screening without the false-positive flood

Sanctions and PEP screening guardrails are essential but noisy when tuned poorly. Screen at onboarding and continuously. Handle transliteration and aliases, but do not accept black-box models you cannot explain. For every match decision, record why you cleared or escalated. Use multiple data sources for critical lists and cache results to avoid re-verifying unchanged identities. The goal is high precision at manageable volume, not theoretical recall that drowns analysts.

5) KYT and ongoing monitoring: from signals to cases

If KYC answers “who is the customer,” KYT answers “what is the money doing.” Crypto adds a superpower here: on-chain visibility. Combine on-chain context with your platform telemetry to detect risk early and act proportionately.

Data ingredients

• On-chain flows: deposits, withdrawals, swaps, bridges, and staking actions.
• Clustering and labels: provider labels for exchanges, mixers, darknet markets, ransomware, and sanctioned actors, plus your own internal wallet map.
• Behavioral signals: velocity patterns, peel chains, time since last activity, device change flags, and geolocation anomalies where permitted.
• Platform context: payment method reversals, login velocity, prior case outcomes, and account tenure.

Illustrative triggers

// Conceptual rules (examples; tune to policy)
if (tx.usd_value >= 10000 and risk.exposure_bps >= 500) flag("High value with risky exposure");
if (user.new_device and tx.to_privacy_pool and minutes_since_deposit <= 5) queueEDD("Velocity plus privacy pattern");
if (counterparty.label == "sanctioned" or hops_to_sanctioned <= 2) hold("Sanctions proximity");

Case management that analysts love

• Every alert forms a case with the full evidence trail: addresses, hops, screenshots, and relevant user context.
• Queues support priorities and SLAs with auto-escalation when timers breach.
• Templates accelerate customer comms for holds and extra information requests.
• Supervisor review gates freezes, closures, and suspicious activity reports.
• Outcomes feed back into rule tuning and model improvements with precision and recall dashboards.

6) Travel-Rule concepts and self-hosted wallets

Travel-Rule-style frameworks require certain originator and beneficiary data to accompany transfers between two regulated entities. The intent is traceability and screening, not public disclosure. Implementation varies by jurisdiction, but the moving parts are consistent.

Four building blocks

1. Counterparty discovery: determine whether the destination is hosted by a VASP or self-hosted. Use directories, signed ownership challenges, and deterministic tagging where possible.
2. Secure messaging: exchange minimal required fields over encrypted channels with signed acknowledgments and retry logic.
3. Decisioning: screen the data and verify consistency with the transfer. Accept, request correction, or decline per policy.
4. Record linkage: link the message and the on-chain transaction for audit and retention.

Self-hosted recipients

Where the recipient is self-custodied, many regimes prefer risk-based alternatives over full data exchange: proof-of-control challenges, micro-transfers, limits, cooling-off windows, and stepped verification. Write a clear acceptance policy with examples so analysts do not improvise under pressure.

7) Privacy-preserving compliance patterns

Privacy and compliance are not opposites. You can meet legal obligations while minimizing long-term data risk.

• Verifiable credentials and selective disclosure: accept attributes signed by a trusted issuer rather than storing documents. Keep proof artifacts and expiry, not raw scans.
• Zero-knowledge attestations: prove membership in a verified set or prove non-membership in a denylist without revealing identity. For certain policies, require cryptographic budget proofs instead of aggregate logs.
• Proof-of-control challenges: have users sign a message from destination addresses, or return a micro-transfer with a nonce to show control before high-risk withdrawals.
• Data minimization and lifecycle: collect only what you need, encrypt at rest, segregate personal data, and automate deletion at end of life. If analytics are required, keep an anonymized copy with safeguards that prevent re-identification.

8) Operating the program: org, vendors, playbooks

A thoughtful policy is day one. Execution is every day. Treat compliance like a mission-critical system.

Org and roles

• Compliance: policy design, oversight, regulator engagement, case quality reviews.
• Risk and analytics: rule tuning, model monitoring, back-testing, and pipeline reliability.
• Engineering: vendor integrations, policy engine, data security, and observability.
• Operations and support: customer communication for holds, escalations, and SLA ownership.
• Security: identity and access management, key custody, incident response, and tabletop exercises.

Vendor due diligence

For each vendor, document certifications, data residency, breach history, sub-processors, uptime, latency SLOs, and cost. Demand transparency for scoring models and maintain an exit plan. You will change vendors someday; make it easy.

Playbooks and runbooks

• Sanctions alert handling and escalation paths.
• Freeze and unfreeze criteria with customer messaging templates.
• Law-enforcement request handling: preservation vs production, approvers, and timelines.
• Incident response: hot wallet compromise, fraud spikes, partner outages.
• Travel-Rule messaging failures: retries, fallbacks, and orderly return of funds.

9) Edge cases and tricky scenarios

Privacy features

Graduated controls work better than blanket bans. For first-time privacy withdrawals, require step-up verification and proof-of-control, then apply conservative limits and a cooling-off window. Over time, adapt limits to the user’s history.

Bridges and cross-chain hops

Maintain labels for major bridges and watch for chain-hop typologies after hacks. Ensure your KYT view is multi-chain and correlates bridge deposit and mint events with redemptions and burns. Remember that chain context changes risk signals and fee behaviors.

Stablecoins

Create a stablecoin acceptance policy with de-peg response, issuer monitoring, and wind-down steps. When a de-peg starts, automatic position reductions and user warnings buy you time to investigate. Publish the policy to reduce user confusion during stress.

NFTs and collectibles

One-off art is low risk, but fractionalization and packaged revenue shares can look like investments. State your listing criteria and monitor wash trading and self-dealing. Be explicit about prohibited behaviors in your terms.

Staking and earn

Be clear whether you act as an agent or principal. Disclose slashing and lockups. Monitor for money mule behavior such as rapid deposit to yield and quick withdrawal to third parties. Use Travel-Rule signals for staked asset redemptions where relevant.

10) Policy as code and explainable decisions

Human language policies drift; code enforces. Expose a policy engine where compliance can change thresholds without redeploying the app. Every decision should be reproducible and explainable.

RULE: WITHDRAWAL_TO_PRIVACY_DEST
IF user.tier < TIER_ENHANCED
   AND dest.privacy_flag == TRUE
THEN
   REQUIRE step_up_kyc
   REQUIRE proof_of_control
   LIMIT daily_amount <= 2500 USD
   HOLD if first_use == TRUE for 24h
LOG decision { rule_version, inputs_summary, outcome }

Version and sign your rules. When you change a limit, stamp the rule version onto every decision so you can later show why the system behaved as it did. This habit turns tense audits into straightforward walk-throughs.

11) Metrics, model risk, and reporting

What gets measured gets improved. Establish dashboards and a monthly review rhythm. Track alert precision, recall, false positives, time to clear, sanctions exposure, and Travel-Rule delivery success. For models, watch drift, fairness, and stability. Back-test changes before pushing them to production, and keep a change log with owners and approvals.

For the board and supervisors, prepare a one-page summary that shows your top risks, your trend lines, and the last three improvements shipped. Regulators do not expect perfection; they expect a program that learns and iterates.

12) A 90-day implementation roadmap

Days 0–15: Foundations

• Draft your risk assessment across products, customers, jurisdictions, and assets.
• Define tiers and per-tier onboarding flows with consent and privacy notices.
• Select initial vendors for identity, screening, analytics, Travel-Rule messaging, and case management.
• Write version 0.1 of policies and procedures with named owners.

Days 16–45: Build and integrate

• Integrate identity verification and sanctions screening. Cache results and record rationales.
• Implement baseline KYT rules and label your internal wallets. Add a simple case queue with SLAs.
• Enable a minimal Travel-Rule path for VASP to VASP transfers and test retries and fallbacks.
• Ship first customer comms templates for holds and requests for information.

Days 46–75: Tune and harden

• Back-test rules on historical data; tune thresholds to raise precision and cut noise.
• Instrument metrics dashboards and alert budgets. Document change logs.
• Train analysts and support; run shadow drills with real cases.

Days 76–90: Privacy and resilience

• Pilot verifiable credentials for a subset of users and add proof-of-control for self-hosted withdrawals above a threshold.
• Run tabletop exercises: sanctions hit, chain exploit exposure, Travel-Rule outage.
• Refresh the risk register and finalize a remediation plan with owners and dates.

Quick check

1. What is the difference between KYC and KYT, and why do you need both?
2. Name two triggers for enhanced due diligence and describe the extra evidence you would seek.
3. What problem do Travel-Rule frameworks solve, and how do you handle self-hosted recipients?

Go deeper

• Concepts: sanctions and PEP program design, beneficial ownership for DAOs and foundations, typologies for mixers and bridges, and suspicious activity report drafting.
• Design patterns: verifiable-credential onboarding, zero-knowledge membership proofs for allowlisted pools, policy-gated smart wallets for prohibited destinations, and cryptographic proof-of-reserves with liabilities context.
• Operations: red-team tabletop exercises, model-risk governance for analytics, board-level KPI dashboards, and cross-border Travel-Rule interoperability strategies.

Next up: how different regions approach crypto regulation and supervision.

Next: Regulatory Approaches Worldwide →