The compliance technology stack

No crypto business can run its program by hand: transfers settle in minutes, customers onboard remotely, and the evidence lives on public ledgers and in partner systems. The technology stack therefore is the control framework in practice, and its weaknesses become compliance failures. This lesson explains the components, how to choose and integrate them without favoring any vendor, and how to keep their data and models under control.

The building blocks

A typical stack has six components. Some firms buy each one, others combine bought tools with in-house builds.

Transaction monitoring rules usually run on the data platform or inside the analytics or case tool; wherever they run, they depend on the same data. FATF's report Opportunities and Challenges of New Technologies for AML/CFT (July 2021) and its Guidance on Digital Identity (March 2020) describe the benefits and the conditions: governance, explainability and human oversight.

Build, buy or combine

Few firms build everything or buy everything. The choice turns on a few questions:

A common pattern is to buy identity verification, list data, analytics attribution and Travel Rule connectivity, and to build the data platform, the monitoring scenarios that rely on the firm's own data, and the decision logic that combines all the signals. Whatever is built in-house needs the same documentation, testing and change control as a vendor tool.

Selecting tools

Selection should start from the risk assessment and the control framework, not from a demonstration. Write down which controls the tool must perform, then score candidates against criteria such as:

• coverage: chains, tokens and bridges you support or plan to support; list sources; countries and document types;
• accuracy: false-positive and false-negative rates measured on your own data;
• explainability: whether every score or match comes with the reason and the source behind it;
• latency and availability: response times compatible with pre-transaction checks, and service levels;
• configurability: thresholds, rules and workflows you can change under your own change control;
• audit trail: full history of inputs, versions, decisions and user actions;
• security and data protection: independent assurance reports, certification such as ISO/IEC 27001, data location, encryption;
• exit: export of all data and history in a usable format if you leave.

A proof of concept with your own data is the strongest evidence. Feed a screening tool known list entries with spelling variants and see what it finds. Give two analytics sources the same 500 addresses, including your own test deposits, and measure where they disagree; disagreement is common and tells you where a second source or manual review is needed (on why attribution varies, see the IDFE-BA lesson Evaluating cluster quality).

Vendor due diligence and contracts

A tool that performs a control on your behalf is a third-party arrangement, and the rules in the lesson Building the compliance function apply: the firm keeps responsibility. Due diligence covers the vendor's ownership and financial health, its security and resilience, its own compliance with sanctions and data protection rules, its subcontractors, and where its data comes from. For analytics and screening data, ask how labels and list entries are sourced, how often they are updated, and how errors are corrected.

The contract should give audit and information rights, service levels with remedies, notice of material changes to models or data sources, breach notification, data ownership and return, and a tested exit plan. Concentration matters too: if one outage stops onboarding, screening and monitoring at once, plan a fallback.

Integration and the decision path

Where a control sits in the process decides whether it prevents or merely detects. Pre-transaction wallet screening and Travel Rule checks must run before a withdrawal is signed and broadcast; once a transfer is on chain it cannot be recalled. Each preventive control needs a defined failure mode: fail closed (hold the transaction when the tool is unavailable) for high-risk checks, or fail open with later review only where the risk assessment accepts it. Other integration rules: one customer identifier shared by every system, synchronized clocks in UTC, and retries that never create duplicate alerts or messages. Changes to the stack, from a new chain to a vendor's model update, go through testing in a non-production environment and sign-off by compliance before release, because a broken integration can disable a control without anyone noticing.

Every automated decision should leave a record that explains itself:

{
  "event": "withdrawal_decision",
  "withdrawal_id": "WD-2026-0918-00417",
  "customer_id": "C-88213",
  "asset": "USDC", "amount": "12500.00", "destination": "0xA1b2…9F",
  "screening": { "list_match": false, "list_version": "2026-09-18T06:00Z" },
  "analytics": { "entity_type": "VASP", "risk_score": 22,
                 "source": "provider-1", "label_date": "2026-09-02" },
  "travel_rule": { "required": true, "protocol": "TRP",
                   "status": "ACCEPTED", "payload_hash": "e91c…40ab" },
  "decision": "RELEASE", "rule_set": "WD-POLICY v4.2",
  "decided_at": "2026-09-18T10:42:07Z"
}

The record stores the inputs and their versions, not just the outcome: which list version was screened, which analytics source labeled the destination and when, whether the Travel Rule message was accepted, and which rule set made the decision. With it, an investigator or examiner can reconstruct months later why the transfer was released, even after lists, labels and rules have changed. The hash proves which message was sent without copying personal data into every log.

Data platform and lineage

Monitoring, management information and reports to authorities are only as reliable as the data beneath them. Data lineage documents where each figure comes from and every transformation on the way. The Basel Committee's Principles for effective risk data aggregation and risk reporting (BCBS 239, January 2013), written for large banks, set out expectations that suit any compliance data platform: accuracy, completeness, timeliness and adaptability, under clear governance.

Practical controls include:

• completeness reconciliations, for example the count of withdrawals in the ledger against the count screened and the count monitored each day;
• monitoring of data feeds, with alerts when a source stops or its volume drops sharply;
• a data dictionary and owners for each critical field;
• role-based access, logging of who viewed or changed records, and retention for at least five years;
• tamper-evident storage for decisions and evidence.

A monitoring scenario that silently missed a new chain for three months is a typical finding; the reconciliation is the control that would have caught it.

Model risk

Many stack components are models: fuzzy-matching algorithms, customer risk scores, analytics risk scores and machine-learning alert ranking. Each can be wrong, become outdated or be misused. Keep a model inventory with owner, purpose, inputs, version and last validation; validate before use and periodically; and control every change. When an investigator disagrees with a vendor label or score, the override should be recorded with its reason and evidence, reported back to the vendor, and counted: a rising override rate is an early sign that a model no longer fits your business. Vendor models remain your models: you need enough documentation and test results to explain their outputs to a supervisor. Frameworks such as the NIST AI Risk Management Framework (AI RMF 1.0, January 2023) and ISO/IEC 42001:2023 on AI management systems help structure governance. Tuning and validation methods are covered in the lesson Tuning, metrics and model governance.

Exam focus: the six components of the stack and the typical failure of each; selection criteria (coverage, accuracy, explainability, latency, configurability, audit trail, security, exit) and testing them with a proof of concept on your own data; vendor due diligence and contract terms, with responsibility staying with the firm; why pre-transaction controls must run before broadcast, and fail-closed versus fail-open; what a self-explaining decision record contains; data lineage, completeness reconciliations and BCBS 239 principles; model inventory and validation, including vendor models.