Last updated: September 2026
AI sanctions screening agents review the hits that an institution's existing screening tool produces, leaving the screening itself to that tool. For each hit, the agent compares the list entry with the customer or payment data, shows which identifiers match, differ or are missing, and recommends clearing the hit as a false match or escalating it. Every possible true match, and every hit the data cannot resolve, goes to a person, and a person makes every decision to clear, block or reject.
The caution is deliberate, because a wrongly escalated false match costs analyst time while a wrongly cleared true match is a sanctions violation. This guide covers what an agent can and cannot do in sanctions alert review, how a false match is cleared, what the record of a cleared hit should contain, and what the Office of Foreign Assets Control (OFAC) and examiners expect of that record.
TL;DR
A sanctions screening agent reviews the hits from the screening tool you already use. It does not do the name matching, and it never clears, blocks, rejects or releases anything on its own.
Clearing a false match means comparing every identifier in the list entry with the data you hold (names and aliases, date and place of birth, nationality, ID numbers, addresses) and showing which alias produced the hit.
When the data needed to decide is missing, the agent should name the gap and recommend manual review while a request for information goes out.
A possible true match is always a person's decision. A confirmed match is blocked or rejected and reported to OFAC within 10 business days.
The record of a cleared hit should show the steps taken and the information relied on. OFAC does not confirm matches or false positives, so that record is the institution's evidence.
Evaluate an agent against your own past dispositions on two measures read separately: agreement on false matches, and critical misses, where the bar is none.
What does an AI agent do in sanctions screening?
An AI agent in sanctions screening reviews each hit the screening tool raises and recommends a disposition. The agent compares the hit with the list entry and with the customer or payment data, records which identifiers match, which differ and which are missing, and recommends either clearing the hit as a false match or escalating it. An analyst confirms or overrides every recommendation against that record.
A sanctions screening agent is conservative by design. It recommends clearing only when the record disqualifies the match, and it sends every possible true match, and every hit the available data cannot resolve, to a person. A person makes every clear, block and reject decision.
In the workflow, the agent comes after screening: the screening tool, working on the lists the institution licenses, still generates every hit, so the sanctions and watchlist screening layer that examiners already know stays in place. The agent's work is the review, which is where the time goes.
Hits, false matches and true matches
Hit (potential match): the screening tool's signal that a name or other detail in a customer record or payment resembles an entry on a sanctions list. Name screening is the matching step that creates hits in the first place.
False match (false positive): a hit on someone who is not the listed party. Clearing an OFAC false positive means showing, from the record, why the hit is not the listed party.
Likely match: a hit where several independent identifiers, such as name and date of birth, match the listing and nothing yet disqualifies it. OFAC's guidance sends a likely match to the institution's own procedures for likely matches, and those procedures should put it in front of a person.
True match: a hit on the listed party itself, which triggers the institution's procedures for blocking or rejecting.
Why does sanctions screening produce so many false matches?
Sanctions screening produces many false matches because name screening is built to catch any name that resembles a listed one, including aliases and alternative spellings. Common names and near spellings therefore raise sanctions screening alerts on people who are not the listed party. OFAC says as much in its guidance on assessing potential matches, updated in September 2026: "Many potential matches identified through screening are false positives."
The volume of false matches often comes from a small number of names. A BSA officer at a community bank described a single new customer whose name closely resembled a name on the OFAC list, and who generated a flood of alerts on their own. A trust and safety lead at an insurer described the repeat problem: "We get the same matches over and over again… if it's the same entry on the same sanctions list with the same individual repeatedly, then that is just a literal waste of time."
For some teams, the difficulty is review load. The insurer's trust and safety lead said the team's problem was its inability to discount repeat hits, which overloaded the team, rather than the accuracy of its matches. A senior AML compliance analyst at a fintech put the daily cost plainly: "I'm the one that clears them every day… It would be nice not to have to deal with that every single day."
Examiners expect a defined way through the volume of false hits. The OFAC section of the FFIEC's BSA/AML examination manual says a bank's policies, procedures and processes "should also address how it will determine whether an initial OFAC hit is a valid match or a false hit." It adds: "A high volume of false hits may indicate a need to review the bank's interdiction program."
How the lists behind screening are sourced, versioned and kept current is covered in a separate guide to OFAC and sanctions list management.
What does an agent do with a hit, and what does it not do?
An agent takes a hit the screening tool has already raised, prepares the review OFAC recommends step by step, and hands a person a recommendation with the evidence laid out. The agent does not do the name matching, and it does not clear, block or release anything on its own. In the sanctions screening process, the agent sits between the hit and the decision.
Keeping the screening layer in place is often the point. A BSA/AML/OFAC technology systems manager at a community bank said the bank would choose an established, plug-and-play screening vendor over a bespoke build, to ease examiners' concerns. An agent that works on top of that tool leaves the examined control untouched and takes on the review work around it.
OFAC's FAQ 5 recommends six steps for investigating a potential match. The table shows where an agent can prepare the work and where a person decides.
OFAC review step | What an agent can prepare | What a person decides |
|---|---|---|
1. Is the hit against an OFAC list, or a list kept by another agency or organization? | The list and entry that produced the hit | Which of the institution's procedures apply |
2. Does it involve a listed name, a targeted country, region or government, or another sanctions target? | The type of hit, the matching field and the alias | The classification, where it is unclear |
3. How good is the match? | Every identifier in the listing compared with the institution's data, each marked match, different or missing | Whether to confirm a recommendation to clear, or take over an escalated hit |
4. What are the next steps for a likely match? | The evidence so far, and a draft request for missing information | What happens next under the procedures for likely matches |
5. Block or reject? | Nothing beyond the evidence already gathered | Whether to block or reject |
6. Report and keep records | A record of each step and the information relied on | The report to OFAC and sign-off of the record |
Every decision in the last column belongs to a person, and the middle column is preparation.
Step 3, the comparison, is the step an agent can prepare most fully. Done this way, sanctions screening automation covers the preparation of each review, and the decision stays with a person. The same recommend-then-confirm pattern applies to transaction-monitoring alerts, covered in a separate guide to AML L1 alert automation.
How is a false match cleared?
A false match is cleared by comparing every detail in the list entry with what the institution knows about the customer or payment, and recording the result for each detail. OFAC's list entries can include full names, former names, known aliases, nationalities, passport, tax ID and national identification numbers, place and date of birth, business registration numbers and known addresses. The guidance states the method directly: "To verify or disqualify a potential match, compare all of the details in the OFAC listing with the information available to you about the data in your transaction or activity that led to the 'alert' or 'hit.'"
The number of details that agree decides the outcome. If very few details match, OFAC says, you may not have a valid match, and "if after you review available information, you can reasonably determine the match is not valid, then you may proceed with the transaction or activity." If several independent details match, such as name and date of birth for a person or name and location for an entity, the potential OFAC match can no longer be cleared at this step. It moves to the institution's procedures for likely matches.
A clearance that holds up follows five practices:
Show which alias produced the hit. A head of sanctions and AML compliance at a money transmitter said analysts need the matching alias highlighted, because a hit on one customer's name that points to a list entry filed under a completely different primary name looks like a broken system unless the alias is shown. OFAC classifies some aliases as weak aliases, which a screening tool may exclude as a risk-based decision, so the review should also say when a hit rests on one.
Mark every identifier. For each field in the listing, the record says match, different or missing. A missing field is neither a match nor a mismatch, and the record should say so.
Compare names part by part. Treating a full name as one string misses cases that a comparison of given names and family names catches. A shared given name with a different family name is weak evidence, and two names that look different as whole strings can still agree part by part.
Clear each match inside an alert. A global head of sanctions at a crypto firm described the rule the team works to: every individual match inside an alert is cleared before the alert can be approved as a false positive, and the disposition of each match is documented for audit.
Tie the clearance to the customer. A BSA/AML/OFAC technology systems manager at a community bank said that when a hit on a common name is cleared as a false positive, the bank wants later alerts suppressed for that customer, not for everyone who shares the name.
A prior clearance should also inform the next review. When a cleared entry returns for the same customer, the reviewer can check what has changed, including the list version, and build on the earlier work.
What should happen when the information needed to clear a hit is missing?
When the information needed to clear a hit is missing, the agent should name the specific gap and recommend manual review rather than force a disposition. A request for information then goes out, and the review runs again when the answer comes back. OFAC's guidance anticipates this step: verifying or disqualifying a potential match "may require gathering additional information from parties involved in the transaction or activity."
A senior AML compliance analyst at a fintech described the common case: a potential match flagged on date of birth where the customer record holds no date of birth, so the analyst has to find one from outside sources and work it out before the hit can be cleared or confirmed. An agent cannot clear that hit either, but it can say exactly which field is missing and what would settle it.
On payment hits, thin data is often the whole problem. A global regulatory and financial crime compliance director at a cross-border payments firm said of payments held on a screening hit: "With this information, everyone around the table can say, yes, it's not enough information… Not enough info to handle the hit to make a decision on the hit." The same director was blunt about the process of requesting more information: "The objective is helpful to get more info. But the whole process is not very helpful… the human being resources that we are allocating to this is not bringing lots of value."
Preparing the request for information is where an agent's help is least controversial: asking for exactly the missing identifier, then reconciling the answer against the listing when it arrives.
Conservatism has a visible cost. A head of sanctions and AML compliance at a money transmitter, reacting to an agent that had flagged conflicting evidence and recommended manual review, summed up the output: "But at the end of the day, it just says like, you know… you have to review it by yourself." On a sanctions hit that output is the right one, because a guess that clears a true match is a violation, while a recommendation to look again costs only time.
Why is a possible true match always a person's decision?
A possible true match is always a person's decision because the two ways to get a sanctions match wrong carry very different costs: escalating a false match costs analyst time, while clearing a true match is a sanctions violation that no saving in review time can offset.
The procedure in OFAC's FAQ 5 draws the same line. When multiple pieces of information in the listing match, such as name and date of birth, the review moves from evaluating the match to the institution's procedures for likely matches, and from there to the decision to block or reject. A BSA/AML/OFAC technology systems manager at a community bank described what a confirmed match means in practice: "If we have a watchlist alert and it's a true match, that's stop all things. We can't onboard this customer, we need to offboard this customer but pep, we don't have to."
A confirmed sanctions match is blocked or rejected, and the blocked property or rejected transaction is reported to OFAC within 10 business days. A hit on a politically exposed person leads to closer review of the customer, as this guide to PEP screening explains.
Speed still matters, because a customer is often waiting. A global head of sanctions at a crypto firm described a setup in which a screening hit restricts the customer's account straight away, so the customer cannot transact until an analyst confirms the hit is not a true match. That hold is a screening control, and a person lifts it. The agent's job is to put the evidence in front of that person sooner.
A compliance leader at a fintech stated the rule plainly: "This is always gonna be a human in the loop review. Nothing is gonna be automated without a human rubber stamping in and saying that we agree with this decision."
Some teams ask for more automation than a human sign-off on every hit. The community bank manager who preferred an established screening vendor also asked for the ability to close a hit automatically when the name clears the bank's minimum match threshold but the date of birth or address is clearly different. If an institution adopts a rule like that, it should be the institution's written policy for a defined queue, approved by the people accountable for sanctions compliance, with the evidence recorded for every hit the rule closes. That decision does not belong to an agent.
What should the record of a cleared hit contain?
The record of a cleared hit should show the steps taken to investigate the potential match and the information relied on to decide it was not valid. That is OFAC's own wording in FAQ 5, which says organizations "should keep complete, accurate records detailing the steps taken to investigate the potential match and the information relied upon to ultimately determine whether the potential match was valid," and adds that OFAC may request those records. OFAC also says it "does not confirm potential matches or false positives," so no one outside the institution signs the determination off.
A record built to that wording holds the following.
Record field | What it holds |
|---|---|
The hit | The list, entry and alias that produced the hit, and the list version or date |
Identifier comparison | Each identifier compared (name parts, date of birth, nationality, address, ID numbers) and its result: match, different or missing |
Information requested | Any request for further information, and what came back |
Recommendation | The agent's recommendation and the reasoning behind it |
Decision | The analyst's decision and rationale |
Sign-off | Who confirmed the decision, and when |
Escalation, where it applies | For a possible true match, the escalation and a person's decision to block or reject |
The rows follow the order of the review, so a later reader can retrace the clearance from the hit to the sign-off.
A sanctions and onboarding compliance QA lead at a regional bank described what audits usually find on the sanctions side: "The findings that we usually see on the sanctions front would be that the users typically forget to complete sanctions screening whether during onboarding or conducting a transaction or if they did conduct it, they clear it out with the wrong rationale." A structured record addresses the second failure directly. The same QA lead asked whether clearing rationales could come from a standard set of templates that the team could create and edit itself ahead of audit. Shared templates make one analyst's clearance read like another's.
Case management is where the record should sit, next to the alert and the decision, so a reviewer can find it. The record also has to last: since 12 March 2025, OFAC's recordkeeping rule (31 CFR 501.601) has required records of transactions subject to its regulations to be available for examination for at least 10 years, matching the 10-year statute of limitations for sanctions violations. Whatever an institution's own retention policy says about cleared hits, a clearance may need to make sense to someone reading it long after the analyst who wrote it has moved on.
How do you stop an agent inventing or misreading a match?
You stop an agent inventing or misreading a match by putting fixed checks around the model and by requiring every recommendation to cite the record. Deterministic checks before the model make sure the list entry and identifiers it reasons about are the real ones, and checks after the model test its output against them. A recommendation that cannot be tied to the list entry, the fields compared and the result for each is not a reason to clear.
An IT delivery manager at an asset manager described the architecture: "A lot of naive people over rely on the LLM… you need deterministic guardrails on the front. You need the LLM in the middle and you need deterministic guardrails on the back. And then you've got at least a shot at being consistent."
The IT delivery manager also described the failure case: an earlier pilot that dispositioned financial crime alerts with a prompt to a general-purpose language model, where nothing was auditable or explainable, the results were wrong, and the pilot was switched off after a short trial.
A Framework for OFAC Compliance Commitments, OFAC's 2019 guidance on sanctions compliance programs, lists screening software or filter faults among the root causes of sanctions compliance failures, including failing to include pertinent identifiers and failing to account for alternative spellings of prohibited parties. Each of those faults lets a true match through, which is the error that matters most.
OFAC's framework also sets a standard for technology in a sanctions control that applies to an agent as much as to the screening tool. Where information technology factors into internal controls, the organization should have "selected and calibrated the solutions in a manner that is appropriate to address the organization's risk profile and compliance needs," and should test them routinely to make sure they work.
How should you evaluate a screening agent before relying on it?
Evaluate a screening agent against your own past dispositions before relying on it: a backtest against historical screening alerts, then shadow mode on the live queue, then a readout. Read two measures separately. Agreement on false matches shows how much review time the agent could save. Critical misses, meaning true matches the agent would have recommended clearing, show whether the agent is safe to use at all, and the bar for critical misses is none.
The two measures, agreement on false matches and the count of critical misses, answer a question a VP of technology at a fintech raised about going live: "What's the process for us to get comfortable and take the AI agent review that is going to happen as is, or how are we going to even spot check some of these things… are we going to get additional early signals prior to launching this at a full scale?"
Next, read the disagreements between the agent and past dispositions, because an agreement rate on its own hides the most useful findings. Some disagreements are agent errors to fix. Others reflect information the analyst had and the alert did not, or practice nobody wrote down, such as hits an experienced analyst escalates because of how sensitive a particular list is, even though the written procedure would clear them.
Each kind of disagreement needs a decision before the agent goes live. Either the practice gets written into the procedure or the missing data gets to the agent; otherwise the agent is being scored against knowledge it was never given.
Validation belongs to the institution, even though the agent does not screen. A senior sanctions compliance officer at a regional bank, asked whether such a system would go through model risk management, said: "Even though you're not technically screening, you're still calling the system that is performing the screening, also doing the narrative and stuff like that for an analyst or somebody to make an ultimate decision." Expect the institution's own model risk or technology policy to bring a review layer like this into validation, and plan the evaluation so that it can serve as evidence for it.
What have regulators said about AI in sanctions screening?
Regulators have said little about AI in sanctions screening specifically. OFAC's most direct statement is still its September 2022 guidance on instant payments, which says OFAC "is aware of artificial intelligence tools and other innovative compliance solutions… which may enhance sanctions screening functions and reduce false positives." The same guidance says that "where appropriate, based on an institution's assessment of risk, OFAC encourages the use of such tools" to manage sanctions risks in instant payments.
As of September 2026, OFAC has issued no 2025 or 2026 guidance on AI or machine learning in sanctions screening. Treasury's March 2026 report to Congress on innovative technologies notes that "OFAC does not require companies to use any specific tool for sanctions screening," and it names data quality, governance and validation concerns as barriers to adopting AI tools.
Bank model risk guidance does not settle the question of AI in screening. The revised model risk guidance issued on 17 April 2026 (SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026) says that "generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." It adds that a bank's own risk management and governance practices should guide the controls for tools it does not cover. The agencies plan to issue a request for information on model risk management that considers banks' use of AI in particular; as of September 2026, it has not been issued.
In practice, the institution's own documented procedure is the standard an agent is held to. OFAC does not confirm matches or false positives, and no model risk standard names a screening agent, so the institution's own testing and human sign-off carry it.
How Oscilar approaches sanctions alert review
Oscilar's sanctions agent sits on top of the screening tool an institution already uses and reviews the hits that tool raises. The agent analyzes each hit, compares it against identifiers such as name, date of birth, nationality and address, and recommends a disposition with its reasoning written out. In the words of Oscilar's Agent Hub, the agent "works with your existing sanctions stack."
The agent is conservative by design. Where key attributes such as date of birth or address are missing, it flags the specific gap and recommends manual review rather than forcing a disposition. Oscilar's Agent Hub states that "agents never autonomously close or escalate alerts — every recommendation is reviewed and confirmed by a human analyst before any action is taken."
Oscilar keeps a full audit trail per decision with stored reasoning, and the platform is human-in-the-loop by design. Before an institution relies on the agent, the evaluation takes the shape described above: a backtest against the institution's historical alerts, followed by shadow mode on the live queue, with a readout at the end.
Oscilar's sanctions screening agent and its PEP and adverse media screening agent are each described in more detail on their own product pages.
Frequently asked questions
What does an AI agent do in sanctions screening?
An AI agent in sanctions screening reviews the hits a screening tool has already raised. For each hit, the agent compares the list entry with the customer or payment data, records which identifiers match, differ or are missing, and recommends clearing the hit as a false match or escalating it. An analyst confirms or overrides every recommendation, and every possible true match goes to a person.
Can an AI agent clear a sanctions screening alert on its own?
No. An AI agent should recommend clearing a sanctions screening alert only when the record disqualifies the match, and an analyst confirms the recommendation before anything happens. A wrongly cleared true match is a sanctions violation, so a person makes every clear, block and reject decision.
What should the record of a cleared sanctions alert contain?
The record of a cleared sanctions alert should contain the list, entry and alias that produced the hit, each identifier compared and whether it matched, differed or was missing, any information requested and received, the recommendation and its reasoning, and the analyst's decision, rationale and dated sign-off. That follows OFAC's FAQ 5, which asks for complete, accurate records of the steps taken to investigate a potential match and the information relied on. OFAC does not confirm matches or false positives, so the record is the institution's evidence that the determination was sound.
What should happen when the information needed to clear a match is missing?
When the information needed to clear a match is missing, the hit should go to manual review with the specific gap named, such as a missing date of birth or address. A request for information then goes to the customer or the parties to the payment, and the review runs again when the answer comes back. Forcing a disposition on incomplete data risks clearing a true match.
How should an institution evaluate a sanctions screening agent before relying on it?
An institution should evaluate a sanctions screening agent with a backtest against its own past screening dispositions, then shadow mode on the live queue, then a readout. The readout should report agreement on false matches and critical misses separately; a critical miss is a true match the agent would have recommended clearing, and the bar for those is none. The disagreements then show whether the procedure, the data or the agent needs to change.
A sanctions screening agent earns trust by showing its work: which identifiers matched, which did not, what was missing and why it recommends clearing. Anything short of that, and every possible true match, belongs with a person, and the record of each cleared hit has to hold up in a lookback. To see where sanctions alert review sits in a wider program, read about AML compliance for banks and AML for fintechs, or ask for a walkthrough against your own past screening dispositions.

Oscilar Team
The Oscilar Team is comprised of experts from many domains of risk operations. These articles express viewpoints and knowledge from a variety of sources and contributors across the organization.
DISCLAIMER
The content on this website is provided for informational purposes only and does not constitute legal, tax, financial, investment, or other professional advice. Any views or opinions expressed by quoted individuals, contributors, or third parties are solely their own and do not necessarily reflect the views of our organization.
Nothing herein should be construed as an endorsement, recommendation, or approval of any particular strategy, product, service, or viewpoint. Readers should consult their own qualified advisors before making any financial or investment decisions.
Oscilar makes no representations or warranties as to the accuracy, completeness, or timeliness of the information provided and disclaims any liability for any loss or damage arising from reliance on this content. This website may contain links to third-party websites, which Oscilar does not control or endorse.


