September 12, 2026

Screening Alert Adjudication: Learning From Past Decisions

Axle Team

Key takeaways

Screening alert adjudication generates the most valuable dataset in your sanctions program — and most institutions write it once for the auditor and never read it again.
The Wolfsberg Group treats risk-based alert-quality decisions, including suppression informed by past dispositions, as an ongoing obligation, not a one-time tuning exercise.
The bottleneck to learning from past decisions is almost never the matching engine. It's free-text disposition rationales that can't be queried, compared, or reused.
Suppression built on adjudication history needs the same governance as any screening rule: documented rationale, four-eyes approval, and independent testing.

What screening alert adjudication actually produces

Screening alert adjudication is the process of reviewing a screening hit — sanctions, PEP, or adverse media — and deciding with documented rationale whether it is a true match or a false positive. Programs improve adjudication by mining past dispositions: standardized rationale codes, entity-level suppression rules with governance, and consistency testing that replays historical alerts across analysts.

Every adjudication decision is two things at once. It's a compliance record — the evidence that a trained human looked at the hit and cleared it. And it's a data point — a labeled example of what a false positive looks like at your institution, on your customer base, against your lists. Most programs only ever use the first.

The Wolfsberg Group's Sanctions Screening Guidance is clear about what an alert is and isn't:

"The generation of an alert as a result of the process of screening is not, by itself, an indication of sanctions risk. It is the first step towards detecting a risk of sanctions exposure, which can be confirmed or discounted with additional information to evaluate whether the similarities in the text reveal a true sanctions match."
— Wolfsberg Group, Guidance on Sanctions Screening

If the alert is only the first step, then the adjudication — the confirming or discounting — is where the program's actual intelligence lives. Which raises the obvious question: why does that intelligence evaporate the moment the alert is closed?

Screening alert adjudication history is your most underused dataset

Ask any screening team about their repeat offenders. Every book has them: the customer whose name is two characters off a mid-tier SDN entry, the counterparty bank whose city matches a sanctioned region's alternate spelling, the payment reference that keeps tripping a keyword rule. The same analyst — or worse, a different analyst — clears the same entity-versus-list-entry pair for the fortieth time, reconstructing the same reasoning from scratch.

Wolfsberg's answer is that alert-quality decisions are supposed to be continuous, and explicitly include suppression informed by what you've already learned:

"Identifying and implementing risk based screening decisions, in order to maximise alert quality and minimise the number of low quality or irrelevant alerts, should be undertaken prior to the deployment of a new screening system and thereafter on an on-going basis."
— Wolfsberg Group, Guidance on Sanctions Screening

The same guidance lists suppression rules and "good guys" lists as legitimate tools for managing common false positives that would otherwise consume unnecessary manual review. The regulatory posture is not "re-review everything forever." It's "make risk-based decisions and be able to defend them." Past adjudications are the defense.

A workflow for learning from past screening decisions

Standardize disposition rationale at capture time. Replace free-text-only rationale with a constrained schema: which attribute broke the match (date of birth, nationality, entity type, geography, secondary identifier), what evidence was checked, and what would change the conclusion. Keep a free-text field for nuance — but never as the only record.
Mine for repeat pairs. Query closed alerts by customer-and-list-entry pair. Any pair adjudicated false-positive more than a handful of times on unchanged data is a suppression candidate.
Build suppression with governance, not convenience. Each suppression rule gets a documented rationale, four-eyes approval, an owner, and an expiry or re-review trigger — in particular, automatic re-review when the list entry or the customer record changes.
Consistency-test your analysts. Replay a sample of historical alerts through the current team. Divergent dispositions on identical facts are a training finding and a data-quality finding at once.
Feed outcomes into independent testing. Your testing function should validate not just that the engine generates expected alerts, but that suppression rules built from past decisions still hold against current list data.

OFAC's compliance framework backs the loop's last step — the program is expected to keep recalibrating against a moving environment:

"A comprehensive, independent, and objective testing or audit function within an SCP ensures that entities are aware of where and how their programs are performing and should be updated, enhanced, or recalibrated to account for a changing risk assessment or sanctions environment, as appropriate."
— OFAC, A Framework for OFAC Compliance Commitments

The same OFAC document's root-cause appendix lists screening software and filter faults — stale list data, missing identifiers, unhandled alternative spellings — among the recurring causes of apparent violations. That cuts both ways for adjudication history: suppression rules that aren't re-validated when lists update are exactly the kind of filter fault OFAC describes.

What to capture at adjudication time

Mismatched attribute (coded): Enables querying "all clears based on DOB mismatch" when a list entry gains a new DOB alias
Evidence source consulted: Distinguishes strong clears (documentary) from weak ones (name-shape judgment)
List entry version/date: Triggers re-review when the entry changes; protects suppressions from going stale
Analyst + reviewer identity: Makes consistency testing and four-eyes accountability possible
Would-change-conclusion note: Turns each decision into a standing instruction for the next occurrence

The practitioner's trap: rationales written for auditors, not for reuse

Here's the pattern we see over and over: institutions decide to "do something with adjudication data," then discover that five years of dispositions read like "Reviewed. Not a match. See attached." The record satisfied every audit it was written for — and it's nearly worthless as a learning input, because the reasoning lives in the analyst's head and the attachment, not in a queryable field. Retrofitting structure onto historical free text is a grinding, low-yield project. Capturing structure at decision time costs each analyst seconds. If you change only one thing after reading this, make it the rationale schema — it's the cheapest fix in screening and the one that unlocks everything else, including any future automation. Wolfsberg's expectation that the screening application let reviewers decide "based on the validity of that data and, thereafter, record relevant rationale" is the floor; recording rationale in a reusable shape is the version of that requirement that pays you back.

Where AI agents fit

An AI agent is, among other things, a way to make adjudication rationale consistent by construction. Axle's screening agent, Baley, adjudicates sanctions, PEP, and adverse media alerts with a structured, documented rationale on every decision — the same evidence trail a strong human analyst would leave, produced uniformly at volume. That uniformity is what makes the feedback loop above actually run: repeat-pair mining, suppression candidates, and consistency testing all assume decisions recorded the same way every time. Teams evaluating this should start with their screening alert workflow and, before any pilot, take an honest inventory of their adjudication data — the AI readiness playbook covers what that inventory should include.

FAQ

Can past adjudication decisions be used to auto-close screening alerts?

Only through governed mechanisms: suppression rules or match-exclusion logic with documented rationale, approval, and re-review triggers tied to list and customer data changes. Silently auto-closing on "we cleared this before" without those controls is the version examiners will fault — the prior clear may rest on data that has since changed.

How do regulators view suppression rules and "good guys" lists?

As legitimate risk-based tools — the Wolfsberg guidance names them explicitly — provided they are documented, approved, and independently tested. The scrutiny lands on maintenance: a suppression created in 2023 and never re-validated against 2026 list data is a filter fault, not a control.

What's the difference between alert triage and alert adjudication?

Triage sorts and routes alerts by priority and type; adjudication is the substantive decision on each alert — true match, false positive, or escalate — with recorded rationale. The learning loop described here runs on adjudication records, because those carry the reasoning; triage data alone tells you volume, not logic.

If your screening queue is full of alerts your team has already answered, see how Baley, Axle's sanctions screening agent, turns every adjudication into a structured, reusable decision record.

Screening Alert Adjudication: Learning From Past Decisions

More from the blog