Transaction monitoring for crypto businesses

Customer due diligence tells a firm who its customer is; transaction monitoring tells it whether the customer's activity still fits that picture. For a crypto business, monitoring is where most suspicious activity is actually found, and it is also where supervisors most often find programs that look complete on paper but detect little. This lesson explains how monitoring works across fiat and blockchain data, what "KYT" really covers, and how a simple scenario is built.

What monitoring is for

FATF Recommendation 10 requires ongoing due diligence, including scrutiny of transactions throughout the relationship to make sure they are consistent with what the firm knows of the customer, their business, risk profile and, where necessary, source of funds. Recommendation 20 requires a report to the financial intelligence unit when the firm suspects, or has reasonable grounds to suspect, that funds are the proceeds of crime or related to terrorist financing. Monitoring is the machinery between the two: it turns millions of events into a manageable number of questions that a person can answer.

Three related controls are often confused:

Screening is binary and list-driven (see the lesson Wallet and transaction screening). Monitoring is comparative: it looks at behavior over time, against the customer's profile, against peers and against typologies. The outputs of all three should land in the same case management system, because one customer can trigger all of them at once.

Two data worlds: fiat side and on-chain

A crypto business that touches fiat money has to monitor two very different streams.

The on-chain stream is richer than anything banks have: a compliance team can look at where deposited funds came from several transactions before they arrived, and where withdrawn funds went afterward. Its weakness is identity. An address is not a person, and attribution is probabilistic (see the lesson Blockchain analytics for compliance). The fiat stream has the opposite profile: strong identity, no visibility beyond the counterparty bank. The best detections combine the two, for example a crypto deposit with indirect exposure to a fraud cluster followed within hours by a fiat withdrawal to a newly added bank account.

Internal transfers matter too. Many platforms settle trades between customers on an internal ledger without touching the chain, so a monitoring program that reads only blockchain data will miss customer-to-customer movements, trading at a loss to pass value, and quick conversions between assets.

What KYT means and what it does not

KYT ("know your transaction") is a market term for screening crypto transfers against blockchain analytics: the address and its cluster are scored for exposure to risk categories such as darknet markets, scams, stolen funds, ransomware, sanctioned entities and mixers. It is valuable, and FATF's Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (October 2021) mentions blockchain analytics among the tools that can help assess risks and identify suspicious behavior.

KYT is not, on its own, a transaction monitoring program. It typically:

• scores each transfer by its counterparty's exposure, but does not know the customer's profile, occupation, expected volumes or history;
• does not see fiat activity, internal ledger movements, logins, device data or changes to account details;
• catches funds linked to known illicit clusters, but not a customer who launders clean-looking funds through unusual behavior;
• depends on labels that may be missing, stale or wrong.

A supervisor who asks "how do you monitor?" and hears "we use a KYT tool" will ask next how behavior is monitored, how the tool's thresholds were set and who validated them. A complete program uses analytics as one input among several.

Rules, scenarios and behavioral analytics

A scenario describes a typology in detectable terms; a rule is its implementation with parameters (thresholds, time windows, ratios) and a population it applies to. A scenario such as "rapid movement of funds" may have different parameters for retail customers, corporate customers and market makers. Grouping customers into segments with similar expected behavior is what keeps one threshold from flooding the queue for one group while missing activity in another.

Most mature programs are hybrid: rules for known typologies and regulatory expectations, analytics to rank alerts and find what rules miss. The lesson Tuning, metrics and model governance covers how each is tested.

Real time and batch

Timing follows the decision the firm needs to make.

• Pre-transaction (real time) checks run before a withdrawal is broadcast or a deposit is credited. They suit signals that justify stopping the transfer: a designated or high-risk destination, a withdrawal to a scam cluster, an account takeover pattern. Once a transaction is on-chain, it cannot be recalled.
• Post-transaction (near real time or batch) checks look at patterns over hours, days or months: structuring, rapid in-and-out, slowly changing behavior, network links between customers. They usually run in batches and raise alerts for investigation.

A useful design rule: anything that would make you refuse or hold a transfer must run before it; anything that needs a pattern runs after.

Joining customer data and blockchain data

Monitoring only works if each event can be tied to a customer and enriched. The core joins are:

1. Customer to address. Every deposit address the firm issues, and every withdrawal address a customer uses, is linked to a customer ID. Withdrawal addresses reused by several customers are a signal in their own right.
2. Transfer to analytics. Each transfer carries the counterparty's attributed entity, risk category and exposure, with the label source and date.
3. Transfer to Travel Rule data. Counterparty VASP and originator or beneficiary names (see the lesson Travel Rule data and messaging).
4. Transfer to customer profile. Segment, risk rating, expected activity and declared source of funds.
5. Prices. Every amount converted to a reference currency at the time of the transfer, from a recorded source, so thresholds apply consistently across assets.

Missing joins are a silent failure: an unpriced token, an address not mapped to a customer or an analytics call that timed out means a transfer that no rule ever evaluates. Monitoring the completeness of these joins is part of the program.

A simple rule in SQL

The rule below implements a "rapid in-and-out" scenario for retail customers: a crypto deposit of at least USD 5,000 equivalent followed, within 24 hours, by withdrawals totaling at least 80% of it.

-- Rapid in-and-out: a deposit of at least USD 5,000 equivalent,
-- then withdrawals of at least 80% of it within 24 hours
WITH pairs AS (
  SELECT d.customer_id, d.tx_id AS deposit_tx, d.usd_value AS deposit_usd,
         SUM(w.usd_value) AS out_usd, COUNT(w.tx_id) AS n_out,
         MAX(w.ts) - d.ts AS time_to_last_out
  FROM transfers d
  JOIN transfers w
    ON w.customer_id = d.customer_id AND w.direction = 'OUT'
   AND w.ts > d.ts AND w.ts <= d.ts + INTERVAL '24' HOUR
  WHERE d.direction = 'IN' AND d.usd_value >= 5000
  GROUP BY d.customer_id, d.tx_id, d.usd_value, d.ts
)
SELECT p.*, c.risk_rating, c.expected_monthly_usd
FROM pairs p
JOIN customers c ON c.customer_id = p.customer_id
WHERE p.out_usd >= 0.8 * p.deposit_usd
  AND c.segment = 'RETAIL';

The query joins the transfers table to itself: each qualifying deposit is paired with the same customer's withdrawals in the following 24 hours, and the withdrawals are summed. It then joins the customer table, keeps only the retail segment, and returns the risk rating and expected monthly volume so the analyst sees the profile beside the alert. The interval syntax differs between engines (some use a date-add function instead). In production, the 5,000 threshold, the 24-hour window and the 0.8 ratio would live in a parameter table with an owner and a change history, not in the code, so tuning decisions are recorded and testable.

Exam focus: monitoring as the R.10 ongoing-scrutiny duty that feeds R.20 reporting; the difference between screening, monitoring and Travel Rule checks; fiat-side versus on-chain data and why internal ledger transfers must be monitored; what KYT covers and its limits; scenarios, rules, parameters and segments, and rules versus behavioral analytics or hybrid designs; what must run pre-transaction versus in batch; the five core data joins and incomplete joins as a silent failure; reading a simple SQL rule and keeping parameters outside the code.