AI Risk Scoring for AML

Anti-money-laundering (AML) transaction monitoring has been a rules-based discipline for most of its history. A compliance team sits with a risk framework, a policy document and a monitoring platform; rules are coded; alerts are generated; analysts investigate; reports are filed. The model works, in the sense that it produces auditable output that supervisors accept. It also produces industry-level false-positive rates that are frequently cited as well above 90 per cent — meaning that the overwhelming share of analyst time is spent clearing alerts that were never going to be reportable. Against that backdrop, AI-driven risk scoring is positioned as the answer to a problem that rules-only systems have not solved.

This post sets out what AI risk scoring actually contributes to AML, where it is a good idea, where it is not, and how to design a system that a supervisor will accept. It is written for heads of compliance, MLROs, data scientists and engineering leaders at regulated fintechs, banks and VASPs who are evaluating AI-augmented monitoring and want a view that separates the genuine capability gains from the vendor marketing. It assumes a reader familiar with our broader KYC and AML infrastructure picture.

Rules are attractive because they are explicit. A rule fires when its conditions are met; the logic is transparent; the audit trail is clean. Rules also have structural limitations that have become more acute as financial crime patterns have evolved.

Rules encode known patterns, not unknown ones. A rule that flags transfers above a threshold catches only the structuring pattern the rule-writer imagined; it misses novel layering techniques, velocity patterns outside the rule's window and counterparty clustering that does not match the filter. Rules are also discrete where risk is continuous: a threshold at USD 10,000 produces false positives just above and false negatives just below. Individual transactions rarely look suspicious; it is the pattern across counterparties and across time that carries the signal, and writing rules that capture multi-dimensional patterns quickly becomes unmaintainable. A rules-only system responds to false positives by writing more rules to filter existing rules, which compounds maintenance without reducing analyst workload.

None of this means rules are obsolete. Regulatory thresholds — CTR thresholds, FATF Recommendation 16's USD 1,000 threshold for virtual asset transfers, sanctions list matching — are naturally rule-based and must remain so, because both the firm and the supervisor need a clean "the rule fired, the obligation arose" audit trail. The question is what sits alongside rules, not what replaces them.

AI risk scoring, in an AML context, is the use of machine-learning models to produce a continuous risk signal from customer and transaction data. The output is typically a score on a defined scale (commonly 0-100) attached to a customer, a transaction or an activity pattern. The score is not a decision; it is an input into the firm's risk framework that, together with rule outputs, analyst review and policy, produces decisions.

Several model families are in use. Supervised classifiers are trained on historical data labelled as suspicious or non-suspicious (usually using prior SAR or STR filings as labels). Anomaly-detection models are trained on normal customer behaviour and flag data points that deviate significantly. Graph-based models examine the relationships between accounts, counterparties and transactions, looking for structures characteristic of layering.

Each family has different failure modes. Supervised classifiers inherit the quality of their labels; a firm that has historically under-filed will train a classifier that under-files. Anomaly detectors flag unusual behaviour that may not be suspicious. Graph-based models require meaningful counterparty data that single-firm views often do not provide. A competent system combines several families with a meta-layer that reconciles outputs into a single score.

The most common objection to AI risk scoring in AML is explainability. A supervisor reviewing a firm's compliance posture will ask why a specific customer was rated high risk or why a specific transaction was escalated. The firm has to have an answer.

Explainability in this context does not mean reproducing the full weights of a gradient-boosted model or attaching a neural-network attribution map. It means that the firm can, for any customer or transaction, produce a short narrative of the features and signals that drove the score, in language a compliance analyst and a supervisor can follow. "The score was elevated because the customer's transaction velocity in the prior seven days was four standard deviations above their baseline, the counterparty cluster included three addresses associated with a prior high-risk case, and the geographic pattern was inconsistent with the stated source of funds." That level of explanation is achievable with tree-based models, attention-based summarisation and well-designed feature stores; it is effectively impossible with a monolithic deep-learning classifier trained on unstructured data.

The design implication is that model selection should weight interpretability alongside raw accuracy. A gradient-boosted decision tree with well-curated features frequently outperforms a deep model in AML not because the underlying learner is better, but because the feature-level explanations are tractable and the regulatory posture is stronger. Firms that optimise only on accuracy produce models that work in development and crumble at inspection.

Model quality depends overwhelmingly on training-data quality. Label quality matters most: models trained on prior SAR/STR filings inherit the filing patterns of the firm that produced the training set, so a firm that historically under-filed will train a model that under-files. Feature quality matters next: the feature pipeline has to be reliable across training and serving, because a feature computed differently at inference produces silent degradation. Distribution stability matters last: financial crime patterns and customer behaviour evolve, so a model trained on 2024 data will not hold its accuracy into 2026 without retraining and drift monitoring.

The feedback loop matters as well. Analyst decisions on AI-raised alerts — accepted, dismissed, escalated — are a strong signal for retraining. A system that captures these decisions produces improving performance; a system that treats analyst review as a black box decays silently.

A continuous risk score is only useful if the firm has a policy for what different score ranges mean. The policy should be explicit, tier-aware and jurisdiction-aware.

A typical policy assigns score bands to actions: scores below a floor receive no special treatment; scores in a middle band trigger enhanced monitoring but no analyst review; scores in a higher band trigger analyst review within a defined window; scores in a top band trigger immediate analyst review and a possible transaction hold. The band boundaries are configurable parameters, not constants in code.

The policy should also interact with the customer's KYC tier, as discussed in our pillar post. A score that would be routine for a fully verified institutional customer with a rich source-of-funds record may be concerning for a lightly verified customer. The effective threshold is a function of score and tier, not score alone.

Different jurisdictions will require different tuning. A corridor into a higher-risk geography may require lower thresholds for the same activity; a sector with elevated financial-crime exposure may require elevated thresholds across the board. Firms operating across multiple jurisdictions should be able to tune per-corridor without retraining the underlying model.

Vendors routinely claim that AI risk scoring reduces false positives by 50-80 per cent. Those numbers are true on the vendor's training and evaluation set. They may or may not be true on the firm's own data.

The honest evaluation is a parallel run. The AI system runs alongside the firm's existing rules-based monitoring for a period long enough to see multiple reporting cycles, including edge cases and seasonal variation. For each alert produced by either system, the analyst team reviews and disposes as they normally would. At the end of the parallel run, the firm compares the two systems on the metrics that matter: alerts per volume of activity, analyst time per alert, confirmed suspicious cases caught by each system, cases caught by one and not the other, time-to-filing.

A good AI system will produce meaningfully fewer alerts per volume, shorter analyst time per alert, and an overlap with rules that is high but not complete — where each system catches cases the other misses, and the combined system catches more than either alone. A mediocre system will produce similar false-positive rates dressed in different language. The parallel run distinguishes the two.

Firms should resist the temptation to run the evaluation only on cases where the AI system flagged. That produces a biased evaluation that confirms the vendor's marketing without telling the firm anything useful. The right evaluation runs on the full activity set and asks what each system did with it.

AI risk scoring does not sit as a separate product; it integrates into monitoring, case management and reporting. At the monitoring layer, the score is an input to alerting alongside rules: a regulatory-threshold transaction produces a rules alert regardless of score, and an AI-elevated score produces an alert even if no rule fired. At the case management layer, the score and its feature attribution become part of the case file so that a supervisor can see what the model said and how the analyst engaged with it. At the reporting layer, suspicious cases filed via goAML should capture the risk-scoring evidence where appropriate. Our broader compliance infrastructure carries this context end-to-end.

Several anti-patterns consistently produce weak AI risk scoring in production.

Over-automation: using the AI score to auto-close low-score alerts without review. This produces missed cases and removes the feedback loop that keeps the model honest.

Under-investment in features: treating the AI system as a black box that ingests raw transaction data. High-quality features — derived attributes that encode compliance knowledge — produce more accurate and more explainable models than raw data alone.

Vendor lock-in: committing to a single AI vendor without retaining the ability to evaluate alternatives. The field is moving; a vendor that was best-in-class eighteen months ago may not be today.

Absent drift monitoring: deploying a model and assuming it remains accurate. Production models without drift monitoring degrade silently.

Conflating AI with magic: expecting AI to solve problems that the firm's monitoring policy has not articulated. If the firm cannot state what it wants to detect, no model will detect it.

Bridge Intelligence operates AI-augmented risk scoring as part of its compliance infrastructure, integrated with KYC, Travel Rule and reporting. To discuss AI risk scoring design and evaluation for your stack, reach out through our contact page or explore the broader identity platform.