Office of Foreign Assets Control Sanctions Screening Obligations for AI Payment Agents

On July 15, 2025, the Office of Foreign Assets Control settled with Interactive Brokers LLC for $11,832,136, covering 12,367 apparent violations. None of that changed the bill. That outcome traces back to one standard: OFAC enforces sanctions on a strict-liability basis, so an institution is liable for a prohibited transaction even without knowledge or intent. Ignorance that a counterparty was designated is not a defense.

OFAC sits inside the U.S. Department of the Treasury, not FinCEN and not the Department of Justice, and its authority comes from Treasury's mandate to enforce economic and trade sanctions. That authority reaches every financial transaction subject to U.S. jurisdiction, no matter which payment rail carries it. Civil penalties can reach $377,700 per violation, or twice the transaction value, whichever is greater, with penalties accruing per violation. A single misconfigured batch run becomes one liability event for every transaction inside it, and a screening gap at Interactive Brokers turned into an eight-figure settlement from thousands of individually small transactions this way.

Putting an AI agent in charge of executing those payments changes nothing about the math. Strict liability was written for a world of manual approvals and periodic reviews. It applies with the same force, and considerably less patience, to a world where an agent executes transactions continuously.

The three screening obligations that apply to every payment

OFAC's screening requirement is three separate layers, stacked on top of each other, and each one can generate its own violation independent of the other two.

The first layer is country-based: certain jurisdictions are subject to comprehensive sanctions programs, and transactions routed to or through them face severe restriction regardless of who the counterparty is. As of 2026, that list includes Cuba, Iran, North Korea, and the Crimea, Donetsk, and Luhansk regions of Ukraine. Some jurisdictions sit in a different category: sectoral and list-based restrictions rather than a comprehensive embargo, which means geography alone won't tell an agent whether a counterparty there is screenable or prohibited.

The second layer is the Specially Designated Nationals and Blocked Persons List: it names individuals, entities, and vessels whose assets are blocked, and U.S. persons can't transact with them. A payee who cleared screening at onboarding can be designated before the agent's next disbursement to that same payee fires.

The third layer is sectoral: restrictions aimed at specific industries, such as energy, finance, or defense, within countries that aren't under comprehensive embargo. Catching this layer requires understanding what a payee's business actually does, not just where it sits or what its name is. Missing this layer carries the same liability as missing an SDN match outright, and a system built only to check geography and match names is most likely to let it slip past.

These three obligations are cumulative. If any layer turns up a confirmed match, the funds have to go into an interest-bearing blocked account, and OFAC needs a blocking report within 10 business days. If a transaction is prohibited but not eligible for blocking, it still needs a rejection report within that same 10-business-day window. Screening failure isn't the end of the exposure. It triggers a mandatory reporting clock that starts running immediately.

Pre-Execution Screening on Real-Time Payment Rails

Timing is part of the compliance standard, not a detail around it. Processing a payment before the OFAC screen completes is itself a violation, even if that screen would have come back clean. A regulator asks whether the check ran before the money moved, not only whether the payment turned out to involve a sanctioned party.

That timing requirement collides directly with how modern payment rails work. OFAC's own guidance on instant payment systems acknowledges that batch screening poses real challenges for real-time rails, and it encourages institutions to adopt newer compliance technology rather than slow payments down to fit older screening methods. The agency is asking them to make screening fast enough to keep pace with the rails as they exist.

For an AI payment agent, this isn't a minor inefficiency to smooth out later. If an agent executes transactions at machine speed on real-time rails but a human checkpoint sits between the screening result and the execution step, it's architecturally non-compliant from the moment it goes live. No human reviewer can process alerts fast enough to keep that pre-execution requirement intact at the volumes these agents are built to handle. The rails dictate the speed. The speed dictates where the screening logic has to sit: inside the agent's execution path, running before the transaction fires, not alongside it or after it.

How agentic AI changes OFAC's authorization and traceability questions

Traditional payment compliance assumes a payment order traces back to an explicit instruction, either from an account holder or from a legally recognized agent acting on that holder's behalf. Agentic AI breaks that assumption cleanly. An agent operating under a broad mandate can execute a payment with no transaction-level instruction behind it, making authorization structural and mandate-based. That shift raises questions about traceability, consent, and liability, and existing payment frameworks weren't written to answer them.

For OFAC compliance, a regulator will ask directly why a screening check triggered, or failed to trigger, for this specific transaction. "The algorithm didn't flag it" answers nothing. It just restates the problem.

This is where the black box risk becomes concrete. Institutions sometimes market their compliance process as AI-driven while actually running a rules-based engine with cosmetic changes, a practice known as AI-washing. Institutions that do this risk overestimating what their own system can catch and relaxing oversight accordingly, and regulators tend to read that kind of misrepresentation as a signal about the institution's compliance culture overall, not as an isolated marketing exaggeration.

Liability when an AI agent fails a screening obligation

OFAC's institutional liability rule applies without modification to AI-driven systems. The bank or payment company that deployed the agent.

Enforcement history across the industry has already mapped out how these failures happen in practice: screening systems calibrated incorrectly so matches get missed, customer or transaction data that's incomplete enough to defeat accurate screening even when the model itself works fine, and automated processes left running without enough oversight for errors to get caught before they compound. None of these are exotic failure modes. They're the ordinary ways a screening system degrades when nobody is watching it closely enough.

Pushing the risk upstream through contract doesn't change where the regulatory liability lands. The UK's Competition and Markets Authority has taken the parallel position: a business stays responsible for its AI agents even when a third party designed or provided them. In the U.S., the direction of travel points the same way: a California statute now forecloses defendants from arguing that AI autonomously caused the harm in question, and a June 2026 presidential executive order directed the Department of Justice to prioritize enforcement of existing federal criminal statutes, including computer fraud, wire fraud, and identity fraud, against actors who use AI to illegally access computer systems or who use AI agents to access data later used for criminal purposes. Regulators are tightening institutional accountability for agent behavior, not loosening it.

A vendor's SOC 2 certification or a model's published accuracy numbers cannot function as a compliance shield. The paperwork has to originate from the institution deploying the agent, not from the vendor who built it.

What OFAC expects from a Sanctions Compliance Program when AI is doing the screening

OFAC tells every organization to build a risk-based Sanctions Compliance Program, and it has to be sized to that organization's own risk exposure, scale, and operations.

OFAC names five components as foundational to any defensible SCP, and all five apply in full once an AI agent is doing the screening. Senior leadership has to actively back and resource the program rather than hand the whole thing off to a technology team and move on. And training has to bring compliance staff to a level where they understand how the AI system works well enough to recognize when it's failing, even if they aren't the ones building the models.

OFAC's own framing treats technology as something that should boost efficiency without replacing human judgment, so the hybrid model, automation handling volume and humans handling judgment, is the actual expectation, not a cautious stopgap on the way to full automation. Regulators outside the U.S. are converging on the same standard. The UK's Financial Conduct Authority emphasizes explainability in AI compliance systems. If an institution operates across borders, it faces one consistent set of expectations, not a different rulebook in every jurisdiction.

The specific controls that make AI-driven payment screening defensible by design

Buying the right vendor platform and flipping on a feature doesn't make a screening program compliant. Compliance has to be engineered into the agent's execution logic from the design stage, because fixing it after the system is already in production is slower, more expensive, and legally riskier than building it right the first time.

The first control is a hard pre-execution gate. The screening check has to complete and return a clean result before the agent is allowed to execute the payment, not in parallel with execution, not as a sampled post-hoc review. That gate needs to run at onboarding and again immediately before every disbursement, since a payee who cleared months ago can be designated in the time since.

The second is real-time list currency. No screening model, however well built, performs reliably against stale or incomplete data.

The third is explainable decision logic. The institution should be able to say, for any transaction a reviewer pulls, which list was checked, what data was compared against it, what threshold applied, and what came out the other side.

The fourth is fuzzy matching with thresholds that are calibrated and tracked over time. The calibration goal is a system sensitive enough to catch designated parties and selective enough that the alerts it generates are ones a human team can genuinely work through.

The fifth is an escalation path with real human judgment in it. A kill-switch, the ability to halt the agent's payment authority immediately, has to be documented and tested, not just theoretically available.

The sixth is the audit trail tying all of this together. Blocking and rejection reports to OFAC, due within that 10-business-day window, should generate automatically from this record.

Engineering These Controls into Production AI Payment Systems

These controls aren't theoretical. Institutions actively deploying AI in financial crimes and payment compliance are converging on the same architecture: compliance logic embedded in the system, decisions that can be traced, and environments the institution itself governs, regardless of which underlying platform they've chosen.

FIS and Anthropic announced a partnership on May 4, 2026, and under it Anthropic's Applied AI team and forward-deployed engineers are embedded directly with FIS to co-design a Financial Crimes AI Agent. FIS is building this as an agent-first, governed environment: client data stays inside FIS-controlled infrastructure, and every decision the agent makes is traceable and auditable by design, not by retrofit.

What both deployments share shapes how reliably compliance decisions can be traced and governed, regardless of which vendor built them. Compliance logic sits inside the agent's operating environment, and it doesn't function as a filter bolted on downstream. Audit trails and traceability are treated as architectural requirements from the start, not as reporting features added once regulators ask for them. And the institution, not the AI provider, retains governance over the environment the agent runs in. Banks running agentic AI on their existing rails, rather than ripping out their infrastructure to adopt a new one, get a real advantage here: an agent with direct access to the institution's own transaction, payment, deposit, and customer data can screen against information that's richer and more current than what an agent pulling from aggregated third-party feeds would ever see.

Governance documentation required to survive an OFAC examination of an AI-driven payment program

A screening system can be engineered exactly right and still leave an institution exposed if the documentation behind it doesn't hold up. An OFAC examination asks an institution to demonstrate that its controls function as designed, not simply to assert that they do.

Model documentation needs to capture how the screening model was built, what data it was trained or calibrated against, what logic drives its match thresholds, and how those thresholds were set and approved, all written down before the agent ever goes live. Validation and back-testing records should show regular runs against historical data and known sanctions-evasion patterns, with dates, methodology, outcomes, and any remediation steps recorded each time. These models can't be set and left alone. Risk, customer bases, and geopolitics all shift, so each tuning decision needs its own record to show the institution is actively governing the system, not leaning passively on whatever a vendor configured at launch.

Escalation and resolution records should trace every alert the agent generated: how it was routed, who reviewed it, what was decided, and how long resolution took, complete enough to reconstruct the full path of any flagged transaction from start to finish. And governance artifacts need to spell out management accountability for the program, the actual scope of the agent's payment authority, the conditions under which that authority gets suspended, and the process for reviewing the program's risk calibration on a regular basis, alongside training records showing compliance staff understand the system's capabilities and limits well enough to catch a failure mode before a regulator has to point it out.

Complete documentation does more than satisfy an examiner's checklist. Institutions that build audit trails and governance records as part of the system's architecture, rather than adding them after the fact, can answer an OFAC inquiry in hours instead of weeks, and OFAC treats the completeness of that response as a mitigating factor in enforcement proceedings.