Virtual asset service providers should evaluate whether a provider can produce complete, accurate, and explainable data that supports transaction monitoring, screening, and reporting. The key test is not marketing claims but whether the underlying methodology is consistent enough to withstand regulatory scrutiny. If the data is noisy or incomplete, compliance teams may miss suspicious activity, file weak reports, or struggle to justify decisions to supervisors.
What “data quality” means for blockchain analytics in AML
For virtual asset service provider, blockchain analytics data quality is not just about whether a tool can label wallets or trace flows. It is about whether the data can support compliance decisions that are consistent, explainable, and defensible. A useful dataset should let analysts follow the path from raw on-chain activity to a monitoring alert, a screening result, or a suspicious activity report without relying on opaque vendor assertions.
That means the provider should test the data against the compliance use case, not against generic feature lists. In practice, the relevant question is whether the analytics output is reliable enough to support transaction monitoring, sanctions screening, wallet exposure assessment, and escalation decisions under real review conditions. If the same activity is interpreted differently across runs, regions, or entities, the dataset is weak even if the vendor market positioning sounds strong.
Quality also depends on coverage and explainability together. A dataset that is broad but poorly attributed can be hard to defend, while a dataset that is highly explainable but misses relevant chains, services, or typologies can create blind spots. For that reason, the best evaluation approach is to examine completeness, accuracy, timeliness, and the strength of the underlying methodology as a single compliance control problem.
How to assess methodology, coverage, and explainability
The first test is methodology transparency. A provider should be able to explain, at a level a compliance team can use, how clusters are formed, how risk labels are derived, what confidence levels mean, and how false positives and false negatives are handled. If the methodology cannot be described in operational terms, it will be difficult to justify in front of auditors or supervisors.
The second test is coverage against the provider’s actual risk profile. VASPs should verify whether the analytics data meaningfully covers the assets, chains, bridges, mixers, hosted services, cross-chain paths, and high-risk exposure patterns that matter to their business. Coverage gaps are especially serious when they affect typologies that drive alerting or customer due diligence, because an incomplete map can create a false sense of control.
The third test is explainability at the case level. Analysts should be able to understand why a wallet was flagged, what evidence supports the label, and what alternative explanations were considered. A compliant workflow depends on being able to defend not only the conclusion, but the reasoning chain behind it. For AML teams, that is often the difference between usable intelligence and a black-box indicator that cannot support a filing or escalation decision.
Independent validation matters here. A provider’s internal benchmarks are useful, but they should be tested against the VASP’s own known cases, sample populations, and alert history. External sources that set the regulatory and supervisory context include FATF Recommendations, AML and KYC Framework and FinCEN, which anchor the expectation that monitoring and reporting processes must be supportable, not merely automated.
What good evaluation looks like in practice
A serious evaluation process starts with test cases, not procurement demos. Compliance and investigations teams should sample known good, known bad, and ambiguous transactions, then check whether the analytics product reproduces the expected result consistently. The point is to see whether the data supports the provider’s own AML obligations under the conditions the VASP actually faces.
Good evaluation also checks for operational drift. Data quality can degrade when new chains are added, attribution sources change, service mappings become stale, or risk scoring logic is updated without clear release control. If the provider cannot show versioning, change history, and reproducible outputs, the VASP may be unable to explain why a case looked different last month than it does today.
For regulated firms operating across jurisdictions, it is also useful to compare the dataset’s assumptions with local AML guidance. For example, EBA AML/CFT Guidance is a practical reminder that firms need controls that support governance, case handling, and escalation, not just raw attribution scores. The evaluation should therefore ask whether the analytics product improves analyst judgement and supervisory defensibility, not only whether it produces a label.
Where the analytics output feeds screening or transaction monitoring, the provider should also document error handling. A high-volume false positive pattern can overwhelm investigators, while false negatives create silent exposure. Either problem can undermine the usefulness of the platform, but incomplete data is especially dangerous because it often looks clean until a review or examination exposes the gap.
Risk and Threat Considerations
Weak blockchain analytics data quality creates both compliance risk and abuse risk. If labels are incomplete or inconsistent, criminals can move through poorly covered assets or typologies with less chance of detection, while the VASP may still believe its monitoring is effective.
Failure mechanism: Incomplete attribution, stale clustering, poor coverage of cross-chain activity, or opaque scoring can cause transaction monitoring to miss suspicious flows or produce weak, hard-to-defend alerts.
Impact: The provider may fail to identify suspicious activity, file poor quality reports, or be unable to justify its decisions to supervisors, auditors, or investigators.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Data-quality evaluation is a vendor and control-risk decision for AML operations. |
| DE.CM-01 — Monitoring for Anomalies and Events | Blockchain analytics feeds transaction monitoring and alert generation. | |
| Recommendation — Define acceptance criteria for analytics quality and residual AML risk. Validate that analytics data improves anomaly detection coverage and consistency. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Explainable analytics must support reviewable evidence and defensible reporting. |
| SI-4 — System Monitoring | Analytics quality affects monitoring effectiveness, coverage, and drift detection. | |
| Recommendation — Retain traceable evidence behind flagged transactions and SAR decisions. Monitor for data drift and missing coverage in blockchain intelligence feeds. | ||
| SOC 2 (AICPA) | CC7.2 — Communicate Internal Control Deficiencies | Material data-quality weaknesses in compliance tooling must be escalated and remediated. |
| Recommendation — Escalate analytics defects that weaken AML monitoring or reporting controls. | ||
Practitioner Guidance
What to verify: Require the vendor to show how a sample alert was produced end to end, including inputs, logic, confidence, and change history. If the explanation cannot be replayed on demand, treat the data as unsuitable for high-stakes AML decisions.
Decision rule: If the analytics dataset cannot support consistent case outcomes on your own test set, do not accept marketing claims about coverage or intelligence quality. Prioritise reproducibility and supervisory defensibility over breadth of features.
What practitioners underestimate: The most common failure is not total absence of data, but data that is plausible enough to be trusted while still being too noisy, stale, or incomplete to support a robust compliance record.
Practitioner takeaway: Evaluate blockchain analytics the way a regulator or examiner would, by asking whether the data can survive challenge, reproduce the same conclusion, and support a defensible AML decision under scrutiny.
Related resources from NHI Mgmt Group
- How should security teams evaluate blockchain analytics data quality?
- How should compliance teams evaluate blockchain analytics providers?
- How should virtual asset service providers implement Travel Rule compliance across APAC jurisdictions with different licensing timelines?
- How should virtual asset service providers prepare for South Korea's stricter crypto compliance rules?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
