{"id":49636648,"url":"https://github.com/slowmist/crypto-aml-vendor-evaluation","last_synced_at":"2026-05-05T15:04:34.571Z","repository":{"id":348471055,"uuid":"1177455859","full_name":"slowmist/crypto-aml-vendor-evaluation","owner":"slowmist","description":"Crypto AML Vendor Evaluation Checklist \u0026 Implementation Guide（Crypto AML 供应商评估 Checklist 与执行指南）","archived":false,"fork":false,"pushed_at":"2026-04-01T08:52:50.000Z","size":1063,"stargazers_count":5,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-01T10:30:28.154Z","etag":null,"topics":["aml","anti-money-laundering","cryptocurrency","risk-detection"],"latest_commit_sha":null,"homepage":"https://kyt.slowmist.com","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/slowmist.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-10T03:24:58.000Z","updated_at":"2026-04-01T08:52:54.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/slowmist/crypto-aml-vendor-evaluation","commit_stats":null,"previous_names":["slowmist/crypto-aml-vendor-evaluation"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/slowmist/crypto-aml-vendor-evaluation","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slowmist%2Fcrypto-aml-vendor-evaluation","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slowmist%2Fcrypto-aml-vendor-evaluation/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slowmist%2Fcrypto-aml-vendor-evaluation/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slowmist%2Fcrypto-aml-vendor-evaluation/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/slowmist","download_url":"https://codeload.github.com/slowmist/crypto-aml-vendor-evaluation/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slowmist%2Fcrypto-aml-vendor-evaluation/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32654636,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-05T11:29:49.557Z","status":"ssl_error","status_checked_at":"2026-05-05T11:29:48.587Z","response_time":54,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aml","anti-money-laundering","cryptocurrency","risk-detection"],"created_at":"2026-05-05T15:04:28.685Z","updated_at":"2026-05-05T15:04:34.559Z","avatar_url":"https://github.com/slowmist.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Crypto AML Vendor Evaluation Checklist \u0026 Implementation Guide\n\n\n*Read this in other languages: [English](README.md), [简体中文](README_CN.md).*\n\nAs a threat intelligence company focused on blockchain ecosystem security, SlowMist has found through long-term hacker tracking and anti-money laundering (AML) practices that selecting the right AML vendor is not only critical for meeting compliance requirements, but also directly impacts an institution’s ability to manage illicit fund risks.\n\nBased on SlowMist’s accumulated threat intelligence and AML tracing experience, and with reference to requirements from the FATF, the Wolfsberg Group, and major jurisdictions (such as FinCEN, HKMA, and MAS), this guide aims to provide the industry with a Crypto AML vendor evaluation framework that balances compliance and real-world effectiveness.\n\n## 1. Evaluation Objectives\n\nEnsure that the vendor not only meets basic regulatory reporting requirements, but also possesses high-precision risk identification capabilities in complex adversarial scenarios (e.g., mixing, cross-chain transactions, and laundering attacks), achieving a balance between low false positives and low false negatives.\n\n---\n\n## 2. Core Capability Evaluation\n\n### 2.1 Sanctions \u0026 Blacklist Screening\n\n*Key focus: data timeliness, coverage, and the accuracy of fuzzy matching algorithms.*\n\n- [ ] **Coverage Scope**\n  - Does it cover major global sanctions lists (OFAC, UN, EU, UK HMT, DFAT, etc.)?\n  - Does it include crypto-related blacklists (e.g., OFAC-designated crypto addresses, hacker-related addresses, darknet addresses)?\n\n- [ ] **Update Frequency**\n  - Are lists updated in real time or at least daily?\n  - How quickly does the vendor respond to emergency sanctions events (e.g., geopolitical conflicts triggering urgent sanctions)?\n\n- [ ] **Matching Algorithms**\n  - Does it support fuzzy matching to handle misspellings, aliases, or variations?\n  - Can matching thresholds be adjusted to balance false positives?\n\n- [ ] **Clustering Capability**\n  - Can it identify associated addresses linked to sanctioned entities?\n\n---\n\n### 2.2 On-chain Transaction Monitoring\n\n*Key focus: accuracy of risk attribution and fund flow tracing capability.*\n\n- [ ] **Asset Coverage**\n  - Does it support major public blockchains (BTC, ETH, Solana, Tron, etc.) and Layer 2 networks?\n  - Does it support mainstream token standards (ERC-20, TRC-20, etc.)?\n\n- [ ] **Risk Scoring Model**\n  - Is it based on multi-dimensional analysis (direct risk vs. indirect/propagated risk)?\n  - Does it support hop-based analysis? (e.g., can it detect funds reaching a high-risk entity after multiple hops?)\n\n- [ ] **Entity Identification**\n  - What is the scale and quality of labeled entities (exchanges, mixers, darknet markets, ransomware, DeFi protocols, etc.)?\n  - How are labels updated? (manual intelligence vs. automated ingestion)\n\n- [ ] **DeFi \u0026 NFT Monitoring**\n  - Are there dedicated monitoring rules for DEXs, liquidity pools, and cross-chain bridges?\n  - Can it identify NFT-related laundering patterns (e.g., wash trading)?\n\n- [ ] **Rule Engine Flexibility**\n  - Can users define custom monitoring rules (e.g., single transaction \u003e 1 BTC AND from high-risk jurisdictions)?\n\n---\n\n### 2.3 Source \u0026 Destination of Funds Analysis\n\n- [ ] **Fund Tracing**\n  - Does it provide visualized fund flow graphs?\n  - Can it detect mixing behavior and layering patterns?  \n    *(Note: full de-anonymization is difficult, but detection capability is essential.)*\n\n- [ ] **Travel Rule Support**\n  - Does it support IVMS 101 standards?\n  - Does it integrate with major Travel Rule protocols (e.g., TRISA, Sygna, VerifyVASP)?\n\n---\n\n### 2.4 Continuous Monitoring \u0026 Automatic Re-screening\n\n*Key focus: retrospective risk recalculation when underlying data changes.*\n\n- [ ] **Trigger Mechanism**\n  - When an address’s associated entity label changes from “low risk” to “high risk/sanctioned,” can the system automatically recalculate historical transaction risk scores?\n  - After updates to underlying data sources or sanctions lists (e.g., OFAC), how quickly can the system re-scan affected historical data?\n\n- [ ] **Scope \u0026 Propagation Depth**\n  - Does re-screening propagate downstream (based on configurable hop levels) and trigger retrospective alerts?\n\n- [ ] **Alert Noise Reduction**\n  - Are retrospective alerts clearly distinguished from real-time alerts, or managed under separate case priorities?  \n    *(to avoid overwhelming normal alert workflows)*\n\n---\n\n### 2.5 Reporting \u0026 Case Management\n\n- [ ] **SAR/STR Assistance**\n  - Can it automatically generate transaction summaries required for Suspicious Activity Reports (SAR)?\n  - Do report formats comply with local regulators (e.g., FinCEN, JFIU)?\n\n- [ ] **Audit Trail**\n  - Are all system actions (alert handling, notes, whitelist changes) immutably logged?\n\n- [ ] **API Integration**\n  - Is the API documentation complete and clear?\n  - Can throughput (TPS) support peak business demand?\n\n---\n\n### 2.6 Data Privacy \u0026 Security\n\n- [ ] **Certifications**\n  - Does it hold certifications such as SOC 2 Type II, ISO 27001?\n\n- [ ] **Deployment Options**\n  - Does it support on-premise or private cloud deployment (for institutions with strict compliance requirements)?\n\n---\n\n## 3. Evaluation Methodology\n\nTo avoid relying solely on vendor demo environments, it is recommended to conduct a **POC (Proof of Concept)** using the following approach:\n\n---\n\n### Phase 1: Static Data Testing\n\n**Objective**: Evaluate database coverage and labeling accuracy.\n\n#### 1. Prepare Datasets\n\n##### (1) Known High-Risk Address Set\n\n*Used to evaluate the system’s ability to identify hackers, sanctioned entities, and illicit addresses.*\n\n**Example data sources:**\n\n- **Sanctions \u0026 Risk Entity Databases**\n  - OpenSanctions — CryptoWallet dataset  \n    https://www.opensanctions.org/search/?schema=CryptoWallet  \n\n- **Public Hack \u0026 Theft Address Repositories**\n  - Lazarus / Bluenoroff research  \n    https://github.com/tayvano/lazarus-bluenoroff-research/tree/main/hacks-and-thefts  \n  - ScamSniffer Scam Database  \n    https://github.com/scamsniffer/scam-database/tree/main/blacklist  \n\n---\n\n##### (2) Known Clean Address Set\n\n*Used to evaluate false positives (i.e., incorrectly flagged legitimate addresses).*\n\n**Example data sources:**\n\n- **Tagged CEX Addresses**\n  - Arkham Intelligence — CEX labels  \n    https://intel.arkm.com/tags/cex  \n\n- **Blockchain Explorer Labels**\n  - Exchange-tagged addresses (e.g., Etherscan)\n\n---\n\n##### (3) Grey Address Set\n\n*Used to evaluate detection of “risk tendency” rather than confirmed illicit activity.*\n\n**Typical categories:**\n\n- Gambling-related addresses  \n  https://etherscan.io/accounts/label/gambling  \n\n- High-risk exchanges or regulatory watchlist entities  \n\n- Mixer interaction addresses  \n\n---\n\n#### 2. Execute Testing\n\n- Import the above datasets into the vendor system.\n\n#### 3. Evaluation Metrics\n\n- **Recall**: How many high-risk addresses are correctly identified?\n- **False Positive Rate**: How many clean addresses are incorrectly flagged?\n\n---\n\n### Phase 2: Dynamic Transaction Monitoring Testing\n\n**Objective**: Evaluate rule engine flexibility and real-time performance.\n\n#### 1. Simulated Scenarios\n\n- **Scenario A: Structuring**\n  - Generate multiple transactions slightly below reporting thresholds within a short period.\n\n- **Scenario B: Mixer Interaction**\n  - Send small amounts to mixer contracts (e.g., Tornado Cash) and withdraw.\n\n- **Scenario C: Multi-hop Risk Propagation**\n  - High-risk address → intermediary A → intermediary B → your test address\n\n#### 2. Execute Testing\n\n- Conduct real transactions on testnet or mainnet.\n\n#### 3. Evaluation Metrics\n\n- **Alert Latency**: How long after confirmation is an alert triggered?\n- **Risk Propagation**: Can indirect risk in Scenario C be detected?\n\n---\n\n### Phase 3: API \u0026 Integration Testing\n\n**Objective**: Evaluate production readiness.\n\n- **Stress Testing**\n  - Simulate high-concurrency requests and observe latency and error rates.\n\n- **Failure Recovery**\n  - Simulate API interruptions and evaluate retry mechanisms and data consistency.\n\n---\n\n### Phase 4: Due Diligence\n\n- **Industry Reputation \u0026 Case Studies**\n  - Request 2–3 customer cases from similar business types or scales.\n\n- **Regulatory Engagement**\n  - Ask whether the vendor has direct cooperation with regulators  \n    *(this often indicates regulatory acceptance of their data)*\n\n---\n\n## 4. Sample Scoring Card\n\n| Evaluation Dimension | Weight | Vendor A Score (1–10) | Vendor B Score (1–10) | Notes |\n|---------------------|--------|----------------------|----------------------|-------|\n| **Data Quality** | 30% | | | Label accuracy, update speed |\n| **Feature Completeness** | 25% | | | Clustering, cross-chain tracing |\n| **Usability** | 15% | | | UI/UX, case workflow |\n| **Technical Performance** | 15% | | | API latency, stability |\n| **Cost** | 10% | | | Setup fees, API pricing |\n| **Support \u0026 Service** | 5% | | | Response time, training |\n| **Total** | **100%** | | | |\n\n---\n\n\u003e **Final Note**  \n\u003e While business models, regulatory requirements, and risk exposure vary significantly across institutions—and there is no single “best” solution—the underlying logic of risk control remains consistent.  \n\u003e  \n\u003e Based on SlowMist’s frontline threat intelligence and AML tracing experience, this evaluation framework is designed to help organizations identify AML vendors that not only meet compliance requirements, but also effectively defend against complex on-chain risks.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslowmist%2Fcrypto-aml-vendor-evaluation","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fslowmist%2Fcrypto-aml-vendor-evaluation","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslowmist%2Fcrypto-aml-vendor-evaluation/lists"}