👉Our AI agents platform is now PCI DSS L1 certified!

sei
Compliance

OFAC Sanctions Screening with AI Agents: The SDN List, Fuzzy Matching, and the 50 Percent Rule

6 min read
Ramkumar Venkataraman
Share

Why Sanctions Screening Sits Differently From the Rest of the AML Stack

Most of a bank's AML program is risk-based, which is to say the duty is to design a reasonable program and to document why the calibration is reasonable. OFAC is different. The substantive prohibitions on dealing with blocked persons under the International Emergency Economic Powers Act and the Trading With the Enemy Act are strict-liability. A bank that processes a transaction for a name on the SDN list can be cited even if it did not know and even if the screening tool missed the hit. The risk-based piece, per OFAC's 2019 Framework for OFAC Compliance Commitments, is about how to design the program; it does not lower the underlying liability when a hit slips.

That asymmetry shapes how we build screening agents. The agent's job is not to look smart on the cleanly matching cases. It is to surface the messy ones, hold the bank's records together when an enforcement subpoena arrives, and never quietly close a hit that should have stayed open.

What the List Actually Looks Like at Ingestion

The screening surface is larger than the SDN list. It also covers the Sectoral Sanctions Identifications list, the Consolidated Sanctions List, the Non-SDN Menu-Based Sanctions list, the Foreign Sanctions Evaders list, and a handful of program-specific lists like the Palestinian Legislative Council list. OFAC publishes machine-readable formats and updates the lists on its own cadence, sometimes multiple times in a week, with Recent Actions as the canonical change feed.

The structural reality is that names on the lists carry aliases, transliteration variants, dates of birth that may be partial or estimated, identifiers from foreign passports, vessel IMO numbers, and cryptocurrency wallet addresses. The same person appears with multiple spellings. The same entity appears under multiple legal forms. The agent ingests the lists into a normalized internal store, preserves every alias and identifier as its own searchable record, and tags each record with the program it derives from and the date OFAC last updated it. We refuse to compress alias variants into a canonical name at ingestion because the variant the customer presents may be the one OFAC chose to publish.

Fuzzy Matching Is the Point of the Whole System

A pure-string match against the SDN list is the failure mode the system has to avoid. Sanctioned persons do not present using the exact spelling OFAC chose. Customers also do not present with consistent spellings of their own names. The agent has to find true hits in the space between those two distortions without burying the disposition team in false positives.

The matching layer we run combines algorithms by what they catch. Edit-distance metrics, including Levenshtein and Damerau-Levenshtein, catch misspellings and small ordering differences. Token-set similarity, including Jaccard on shingles and Sørensen-Dice, catches name reordering and middle-name presence. Phonetic encoders, including Metaphone and Beider-Morse, catch transliterations across writing systems. Date-of-birth proximity, identifier exact match, and country-of-issuance overlap raise the confidence on near matches and lower it where the secondary attributes disagree. The agent surfaces a composite score and the contributing signals, because a single number without the signal breakdown gives the disposition reviewer nothing to argue with.

The threshold the bank chooses is a risk-calibrated number, and OFAC's framework says the bank documents why it chose what it chose. We do not ship a threshold; we ship a tunable threshold with a documented testing harness that runs the bank's chosen number against a labeled set of true positives and labeled negatives and reports false-negative rate, false-positive rate, and the cost of a missed hit at the institution's volume. The bank picks the threshold and signs the calibration.

The 50 Percent Rule Forces Ownership Traversal

OFAC's 50 Percent Rule guidance, set out in the August 13, 2014 Revised Guidance on Entities Owned by Persons Whose Property and Interests in Property Are Blocked, says that any entity owned 50 percent or more, directly or indirectly, individually or in the aggregate, by one or more blocked persons is itself blocked, whether or not OFAC has placed it on the SDN list. The guidance also says that the indirect-ownership analysis is the bank's responsibility, not a thing the bank can wait for OFAC to publish.

For an AI agent, this is the part where pure name screening stops being enough. The agent has to traverse beneficial ownership for any new customer or counterparty, aggregate the chain, and apply the 50 percent test at each node. Where the bank has Customer Due Diligence Rule beneficial-ownership information already collected under 31 CFR 1010.230, the agent works from that store. Where the bank can lawfully query FinCEN's beneficial ownership reporting system for Corporate Transparency Act filings, that is another input subject to the access conditions in the rule and to current judicial status. Where neither is available, the agent records the gap and routes the counterparty for enhanced review rather than concluding that absence of evidence is evidence of absence. The 50 percent analysis is the place sanctions-screening programs most often fail quietly, because the name on the front of the relationship does not appear on the SDN list and no one looked at who actually owned the entity.

Hit Disposition That Survives a Subpoena

A hit is not a violation; an unresolved or wrongly closed hit is the program risk. The agent triages each surfaced match, pulls the customer's identifying data, the SDN record details, and any beneficial-ownership findings into a single disposition record, drafts a candidate determination with the evidence behind it, and routes the file to a human reviewer with the authority to close or escalate. The agent does not close a true match on its own and does not file a blocking report on its own. Closure on a true hit is a regulator-facing event under 31 CFR 501.603 reporting and under the Reports Spreadsheet for blocked property, and the institution's name goes on it.

What the agent does own is the record. Every hit, including the ones the reviewer closes as false, sits in the disposition log with the score, the contributing signals, the reviewer, the timestamp, and the basis for closure. Regulators ask about false-positive disposition more often than people expect, because a program that calls everything a false positive is a program with the threshold set wrong or the disposition standard set low.

The Failure Mode We Engineer Against

The pattern OFAC enforcement releases describe again and again is the screening that ran clean because it was looking in the wrong place. A bank screens the named customer at onboarding and does not re-screen after the SDN list updates. A bank screens transactions through a domestic payment rail and not through the cross-border rail. A bank screens the payer but not the ultimate beneficial owner. A bank screens individuals and not the entities they own at fifty-one percent.

We make those failure modes structural rather than procedural. The agent re-screens the customer book against the lists on every published OFAC update rather than on a fixed cadence, because the lists move on their own schedule. The screening covers payer, payee, originator, beneficiary, and intermediaries on each transaction, and the agent flags any payment leg where one party went unscreened. Beneficial-ownership traversal runs on entity counterparties as a precondition for any new account or material transaction, and a gap in the ownership chain is a disposition event rather than an implied pass. Geographic screening on cross-border transactions checks the address fields and the originating country against country-program prohibitions, because a name-only screen does not catch a Cuba transaction routed by a person whose name is not on the SDN list.

Cryptocurrency and Identifier Screening

For institutions touching virtual assets, the agent screens digital currency addresses against OFAC's published SDN List crypto identifiers, which now appears on dozens of designation actions per year. Address screening is exact-match against the published wallet, plus heuristic checks against on-chain clustering where the institution has the data. The same disposition discipline applies: a hit is a person's call to close, not the agent's.

The OFAC File the Examiner Wants

OFAC examinations and enforcement actions are run against a written program, and the program is what the agent's records support. The artifacts we keep, per customer and per transaction in scope, include the lists screened against with their effective dates, the algorithms and threshold used, every hit surfaced with its score, the disposition with the reviewer's name and basis, the beneficial-ownership chain considered for entity counterparties, the re-screening events triggered by list updates, and the blocking and reporting filings made. The bank that can produce this in an afternoon for a sampled set is positioned to defend its program. The bank that cannot is reconstructing one.

The Trade-Off

A screening program that does all of this generates more hits than a string-match scan. The disposition team's workload goes up rather than down at first, because the system is now finding the matches the old configuration missed. The right read on that increase is that the bank was always carrying the risk; the agent is now showing it where. Over time the disposition load stabilizes, the false-positive rate drops as the threshold and the signals get tuned, and the bank ends up with a program defensible against the strict-liability question that OFAC reserves the right to ask. We build for the audit, because the alternative is to find out at a subpoena what the screening missed.

Ramkumar Venkataraman

Ramkumar Venkataraman

CTO & Co-Founder

BOOK A DEMO

Embed Sei AI in your workflows
Tell us about your operations. We'll show you how Sei handles borrower calls, processes loan documents, and monitors compliance for mortgage lenders and banks.
  • Deploy in weeks, not months
  • Trained on FDCPA, TCPA, TILA, UDAAP, and RESPA
  • SOC 2 Type II and PCI DSS L1 certified
  • Integrates with your LOS, CRM, and telephony

Please provide your full name so we know how to address you.

Tell us which company you represent so we can personalise our response.

Use your work email so we can connect you with the right specialist.

Choose the topics you’d like us to cover during the demo.

Complete the verification to submit the form.

sei

AI operations platform for mortgage lenders, servicers, and banks. Handle borrower calls, process loan documents, and monitor compliance.

Partners

Speechmatics

© 2026 Sei Software Technologies Inc. All rights reserved.