AML for crypto: chains and labels

1) Why iGaming needs an onchain AML

• filtering of addresses and chains of origin (source of funds on-chain),
• early stop of high-risk transfers,
• evidence base for regulators/banks/providers.

2) Dictionary: labels, clusters, chains

Label (label/tag) - attribute of the address/cluster: exchange, service, "dark market," "multi-subscription wallet," "bridge," "mixer," "phishing wallet," "sanctioned subject," etc.
Clustering - combining addresses belonging to the same entity (co-spend/change/temporal heuristics).
Chain (path/trace) - a set of hops from the source to your address/wallet, indicating the amounts/shares of "dirty" funds.
KYT (Know Your Transaction) - scoring a specific transaction/address/chain by sets of labels and behavioral characteristics.

3) Label risk map (sample scale)

4) Typical risk patterns in chains

Peeling chain: long linear leads in small pieces from a large "dirty" pool.
Layering over bridges and L2: a fast multi-chain route with an attempt to break the trace.
Rapid in-out: deposit → almost instant output to a new high-risk address.
Cluster-hopping: Going through lots of wallets of the same type with no economic sense.

Mixer sandwich: in/out with mixers "sandwich."

Sanctions proximity: the connection of ≤ N-hops with sanctions clusters with a significant share of inherited funds.

5) KYT scoring and features (feature set)

Label risk score: weight by label type (sanctions> mixer> high-risk P2P>...).
Proximity: distance (hops) and proportion of contamination (taint%) in your transaction.
Behavioral: address lifetime, fan-in/fan-out, transactional frequency, round-amounts, typical amounts.
Counterparty quality: KYC-VASP/regulated exchanges vs unidentified.
Geo & time: risk regions, "time windows" after the incident (hacking/sanctions).
Entity graph: client's connections with previously flagged counterparties in your system.

Output: aggregated risk score 0-100 for transaction/address/chain.

6) Decision Matrix (RBA) for inbound/outbound

7) Travel Rule + KYT: How to Combine

Do pre-KYT before sending the Travel Rule to avoid sharing data on apparently prohibited routes.
If VASP↔VASP, store the IVMS101 messages together with the KYT report and the transaction hash reference.
Unhosted addresses: confirmation of ownership (signature/microtransfer), KYT before enrollment, limits and periodic verification of whitelist.

8) Processes: alert to case closure

1. Alert KYT → an auto case in the system.
2. Triage (L1): quick view of labels/proximity, matching with client profile.

3. Investigations (L2): detailed tracing, checking SoF/SoW, Travel Rule-responses, estimating "pollution share."

4. Solution: allow/partial release/hold/reject/escalate.
5. Documentation: data log, screenshots, provider reports (ID, timestamp, tag versions).
6. SAR/STR (if required by law).
7. Post-analysis: rule/model training, threshold updates.

SLA landmarks: auto-triage ≤ 5-15 c p95; L2-review ≤ 2-4 hours for High; regular cases ≤ 24 hours.

9) How to reduce false positive and not choke conversion

Contextual normalization: the labels "gambling service" are not equal to the default risk - take into account the license/geo/Travel Rule-response.
Time-decay: Reduce the weight of old events in the chain (unless there are fresh incidents).
Whitelist addresses/exchanges with periodic reverification and KYT thresholds.
Customer segments: good historical profile → below hold thresholds; new/High-risk → higher.
Feedback loop: mark the results (TP/FP/FN), calibrate scoring (Brier/PR curves).
Clear communication: clear reasons for hold and a checklist of documents → fewer tickets and disputes.

10) Data, privacy and storage

PII minimization: keep only what you need for AML/reporting; KYT Labels/Reports - PII Vault

Encryption at rest/transit, access separation (RBAC, need-to-know).
Versioning labels-Mark the source and version of the datum/model at the time of solution.
Retention: according to the law (often 5 + years); auto-expiration and audit deletions.
DSR: access/remediation/deletion processes (where applicable).

11) Metrics and OKR

Compliance/risk

KYT hit% (by label type), Reject/Hold rate, SAR-conversion.
Sanctions proximity incidents and reaction time.

Quality/accuracy

False Positive%, Precision/Recall for High-risk cases, Time-to-Decision p95.

Business/UX

Approval Rate after AML filters, Impact on Time-to-Finality, partial release share.
The proportion of calls to support for AML reasons and the average clarification time.

12) Anti-patterns

Rely only on "blacklists" without chain analysis and taint%.
Ignore bridges/L2 as a "mask" layer.
Auto-failures on any mixer label without context/share/time.
Not logging label versions and → sources cannot protect the solution.
Strict rules without RBA/thresholds → demolition of conversion and VIP experience.
Lack of idempotency and anti-duplicate in KYT webhooks → discrepancies and double locks.

13) Implementation checklist (short)

• KYT provider (s): network coverages, label accuracy, SLAs, versions/sources.
• Risk/Threshold Matrix (T1/T2/T3), proximity/taint% policy, and time-decay.
• Integration of Travel Rule (IVMS101) and unhosted policy (address confirmation).
• RBA-движок: allow/limits/hold/reject/escalate + partial release.
• Case-management: L1/L2/L3 roles, SAR/STR templates, bank/regulator reports.
• Whitelist/denylist with TTL, customer address book, proof of ownership.
• Logs/versioning: label source, model version, solution timestamp.
• Метрики: FP%, Time-to-Decision, SAR-conversion, Approval Rate post-AML.
• Command training (Risk/Compliance/Support), communication playbooks.
• Regular threshold reviews and retrospectives of lost/disputed cases.

14) Summary

An effective AML for crypto in iGaming is not a "magic address list," but a system: tags and clusters + chain tracing + KYT scoring + RBA solutions integrated with Travel Rule and SoF/EDD processes. With proper calibration, you mitigate regulatory and sanction risks by keeping conversion and payout rates at levels acceptable to businesses and partners.