The problem
An institution must detect and report potentially suspicious activity and must not process payments involving sanctioned parties, using inexact matching over incomplete data, without generating more alerts than it can competently investigate.
What makes it hard
- The rate of genuinely suspicious activity is very low relative to volume, so even a highly specific rule produces mostly false positives.
- Sanctions screening matches names, which are transliterated, abbreviated, reordered and shared; exact matching misses real hits and fuzzy matching floods the queue.
- Sanctions screening is a blocking control in the payment path while behavioural monitoring is retrospective, so they have incompatible latency budgets and cannot share a pipeline.
- Every threshold, rule and score is a documented decision about what will not be reviewed, and it will be examined.
- Investigator capacity is fixed in the short term, so raising sensitivity anywhere lowers effective coverage everywhere.
- Alert data is the most sensitive data in the institution and cannot be shown to the customer it concerns.
Components
How it fails
| Failure | How you notice | What bounds it |
|---|---|---|
| Alert volume exceeds review capacity, so the backlog ages and alerts are closed to clear the queue. | Queue age distribution, not queue depth. A rising 95th percentile time-to-first-review, and a rising share of closures with no investigative narrative attached. | Cap intake per rule and treat the cap as a risk decision requiring sign-off. Suppressing alerts by tuning is a governed change; suppressing them by not reading them is a finding. |
| A tuning change silently removes coverage of a typology. | Coverage tracked per typology rather than per rule, with a rule-to-typology map maintained alongside the rules. | Above-the-line and below-the-line testing on every threshold change - sample what the new threshold would have excluded and confirm nothing productive was in it. |
| Sanctions screening tuned for queue relief, so a genuine match is scored below threshold. | Re-screen the full customer and counterparty base against every list update and reconcile against prior decisions. Regression against a known-match test set on every configuration change. | Match thresholds are set by risk assessment, not by workload. Keep name screening deliberately over-inclusive and manage the volume in triage, where the decision is recorded. |
| Stale sanctions or watchlist data. | Age of the loaded list version against the publisher's current version, alarmed in minutes rather than checked daily. | Automated ingestion with a fail-closed posture - if the list cannot be refreshed, escalate rather than continue screening against yesterday's list. |
| The audit trail does not reconstruct the decision. | Pick a closed alert at random and attempt to reproduce it - the data as it was, the rule version, the score, who decided, on what basis, and when. | Version rules and thresholds as data with effective dates, snapshot the inputs that produced each alert, and make dispositions append-only. |
| Tipping off - the subject of a report learns of it through system behaviour. | Access review on case data, and a check that no customer-facing surface reflects alert or case state. | Physical separation of case data from customer-facing systems, role-based access with logging, and no shared identifiers that leak into support tooling. |
Obligations that attach
- FFIEC BSA/AML Examination Manual - suspicious activity monitoring, alert management, SAR decision making and documentation of the process end to end
- FFIEC BSA/AML Examination Manual Appendix S - key suspicious activity monitoring components
- FATF Recommendation 20 - reporting of suspicious transactions to the financial intelligence unit
- FATF Recommendation 11 - records on transactions retained for at least five years and sufficient to permit reconstruction of individual transactions
- FATF Recommendation 21 - tipping-off and confidentiality
- Interagency guidance on model risk management (SR 26-2, superseding SR 11-7 and SR 21-8) - validation, ongoing monitoring and outcomes analysis for monitoring models
- OFAC guidance on evaluating a potential match before acting on it
When not to use this
- The institution is not a regulated obliged entity and there is no reporting duty. Fraud detection has different objectives, different latency and a customer who can be told.
- Fraud loss prevention. Fraud optimises expected monetary loss and can accept false negatives; AML optimises detection of reportable activity and cannot. Sharing one alert queue for both produces the wrong triage priority for each.
- Where the underlying customer data is not fit to screen against. Name screening over records with no date of birth, no address and no identifier generates volume with no discriminating power, and data remediation is the cheaper project.
Almost every design decision in transaction monitoring is downstream of one arithmetic fact: the base rate of reportable activity is very low, and the population being screened is very large. A detector with excellent specificity, applied to a population where the positive rate is a small fraction of a percent, still produces an alert queue that is overwhelmingly composed of ordinary behaviour. That is not a flaw to be engineered away. It is the operating condition, and a system designed as if it were a flaw will fail in the specific way regulators look for.
The consequence for architecture is direct. The scarce resource is not compute or storage; it is qualified human attention. Every rule, every threshold and every scoring model is spending that resource, and the design question is not “how do we detect more” but “how do we spend a fixed review budget on the alerts most likely to be productive, and document why we spent it that way”.
Two systems, not one
The most common structural error is treating sanctions screening and behavioural monitoring as one pipeline. They share vocabulary and nothing else.
| Sanctions screening | Behavioural monitoring | |
|---|---|---|
| Position | Inline, blocking. The payment does not proceed until it clears | Retrospective, batch over a completed period |
| Latency budget | Milliseconds to a payment timeout | Hours to a day |
| Question asked | Is this party on a list, or owned by someone on it? | Is this pattern of activity inconsistent with what we know of this customer? |
| Input | Names, identifiers, addresses, countries in the message | Aggregated behaviour over rolling windows, plus customer risk profile |
| Failure of the control | A prohibited payment is processed. Not remediable after the fact | Activity that should have been reported is not |
| Correct disposition of a false positive | Release quickly, record the reasoning | Close with narrative, retain for the required period |
They need different data stores, different scaling behaviour, and different on-call expectations. An inline screening service that shares a database with a batch scoring job will eventually hold up payments because someone ran a large query. Separate the capacity, and treat the inline path with the operational discipline of a payment component, not of a compliance tool.
Screening is also not a one-time event. Lists change, and a customer who cleared last month may not clear against today’s list, so the same engine has to support re-screening the entire customer and counterparty base on every list update. That batch workload is the one that dominates screening infrastructure, not the inline path.
Why matching is inexact, and why that is not fixable
Sanctions screening compares names. Names arrive transliterated from other scripts, abbreviated, reordered, misspelled, with and without patronymics, and shared with large numbers of unrelated people. Exact matching therefore misses real targets, which is the failure that matters, so every practical implementation matches approximately.
OFAC’s own search tool illustrates the mechanics rather than prescribing them: it combines an edit-distance algorithm with a phonetic one, scores whole names and name parts separately, and returns the higher score (OFAC FAQ 249). Two things follow, and OFAC states both. First, a match score is a similarity measure, not a probability that you have a hit. Second, OFAC explicitly declines to recommend a threshold, on the grounds that users must set it from their own risk assessment and compliance practices (OFAC FAQ 250).
That second point is more important than it looks, because it puts the threshold decision (and its justification) on the institution. The evaluation of a hit is a structured process, not a score comparison: OFAC’s guidance walks through whether the entity type even matches, how much of the name matches, and whether the additional identifying data you hold is consistent with the list entry (OFAC FAQ 5). Screening is also not limited to listed names. Ownership structures matter: OFAC treats an entity owned 50 percent or more in the aggregate by blocked persons as blocked itself (OFAC FAQ 399), which means the screening input includes beneficial ownership data you may not have.
The architectural implication is that the screening engine must produce a reviewable artefact, not a verdict: the candidate list entry, the score, which algorithm produced it, and every attribute compared. An engine that returns only “hit” or “no hit” cannot support the review process the guidance describes, and it will be replaced within a year.
Where the alerts come from
Behavioural monitoring generates alerts from three layers, and mixing them into one undifferentiated queue destroys the information needed to triage.
Rules over aggregates. Structuring patterns, velocity, round-amount sequences, activity inconsistent with the stated purpose of the account, flows to or from higher-risk jurisdictions. These are explicable, testable and tunable, and they are what an examiner will ask to see mapped against the typologies the institution’s own risk assessment identified. The aggregates they run over - per-account velocity, counterparty concentration, deviation from a peer-group baseline - are time-series data, and computing them for the whole book nightly is the bulk of the compute.
Risk-profile changes. A customer whose risk rating moves, whose beneficial ownership changes, or whose declared activity no longer matches observed activity. These generate few alerts and they are disproportionately productive, because they carry context a transaction pattern does not.
Models. Scoring or anomaly detection layered over the rules, usually to rank and not to replace. This is where the governance obligation bites: a monitoring model is a model, and the interagency guidance expects validation covering conceptual soundness, ongoing monitoring and outcomes analysis including back-testing, performed with independence from development. The current guidance is SR 26-2, issued in April 2026, which supersedes and replaces SR 11-7 and the 2021 interagency statement on model risk management for BSA/AML systems (Federal Reserve, 2026). The practical reading has not changed: a scoring model that nobody can explain, whose performance nobody tracks, and whose overrides nobody analyses is a governance finding regardless of how well it performs.
Keep the layers separately identifiable on every alert. An investigator triaging a queue needs to know whether they are looking at a threshold breach, a profile change or a model score, because the first question they ask differs in each case.
Triage is the system
The queue between generation and reporting is where the design either works or does not, and it is usually the least engineered part.
The FFIEC manual describes what examiners do with it, and it is worth designing to that directly: examiners map out the process the institution follows to monitor for, identify, research and report suspicious activity, and then follow an alert through the entire process (FFIEC, BSA/AML Examination Manual). A single alert therefore has to be traceable end to end: generation, research, escalation, decision, filing or no-filing, and the reasoning at each step. Where it cannot be, the process is not demonstrable, whatever its actual quality.
That gives a concrete requirement list for the case system:
- Alerts are immutable; dispositions are appended. A closed alert that can be edited is not evidence. Reopening is a new event referencing the old one.
- The inputs are snapshotted. The customer risk rating, the aggregates and the rule version as they were when the alert fired. Reproducing an alert against today’s data proves nothing about the decision that was made.
- Rules and thresholds are versioned data with effective dates, so any alert can be joined to the exact configuration that produced it.
- A no-file decision is a first-class record with a narrative. The decision not to report is the one that gets examined, and “closed” with no reasoning is indistinguishable from “not read”.
- Continuing activity is tracked, so a subject with repeated alerts is escalated as a pattern instead of being triaged independently each time.
- Access is restricted and logged. Case data cannot be visible to customer-facing systems, and it cannot leak through shared identifiers into support tooling. Tipping-off is a distinct prohibition, not an aspect of general confidentiality.
Retention follows the record-keeping obligation rather than the storage budget. FATF requires records of transactions to be kept for at least five years following completion of the transaction, and to be sufficient to permit reconstruction of individual transactions; findings from examining unusual transactions are to be kept available for at least five years as well (FATF Recommendations, R.11 and the assessment methodology). Local law is frequently longer. Design the ledger of alerts and decisions to be queryable at that horizon, not merely restorable from an archive, because the requests that arrive are for specific accounts over specific periods.
Tuning is a governed change, not a performance fix
This is the point where engineering practice and regulatory expectation most often diverge. Raising a threshold to reduce queue depth is, in substance, a decision to stop reviewing a category of activity. Made deliberately, documented, and tested, it is legitimate risk management. Made as a capacity fix in a config commit, it is the finding an examiner is looking for.
The practice that satisfies both is straightforward and rarely automated:
| Test | Question it answers |
|---|---|
| Below-the-line testing | Of the activity the new threshold would exclude, was any of it productive? Sample it and review it as if it had alerted |
| Above-the-line testing | At the current threshold, what proportion of alerts are productive, per rule? A rule with no productive alerts over a long period is either mis-tuned or covering a typology you do not have |
| Typology coverage | With the change applied, is every typology in the risk assessment still covered by at least one rule? |
| Override analysis | Where investigators consistently disagree with the model, why? A high override rate is evidence the model needs work, not evidence the investigators are wrong |
Note that the last row is a direct import from model risk management, where override tracking and analysis is called out as a signal that the underlying model needs revision. It generalises well to rules.
What to put on the dashboard
Detection metrics are the ones people build first and the ones that say least. These four say more.
| Metric | What a bad reading tells you |
|---|---|
| Time to first review, 95th percentile, per queue | The control is degrading now. Rising queue age precedes every mass-closure incident |
| Productive alert rate per rule, trended | A rule falling towards zero is spending review budget for nothing; a rule spiking has an upstream data change behind it more often than a crime wave |
| Closures with no narrative, as a share of closures | The only direct measure of whether alerts are being read |
| Age of the loaded sanctions list version | Screening against a stale list is a control that is silently off |
The first and third of those are cultural metrics disguised as technical ones, and they are the pair worth watching most closely. A monitoring system fails long before it stops generating alerts; it fails when the alerts stop being read, and the only evidence of that is in the shape of the dispositions, not in the volume of the output.