OFAC sanctions screening and what happens when a flagged transaction slips through.

A processor handled $2.1 billion annually. March 2024, a sanctioned wallet moved funds through their system. They had screening. The transaction went through anyway. Wells Notice arrived within three weeks.

Eighteen months of negotiation. $8.7 million settlement.

This wasn't a gap in technology. It was a gap in execution.

OFAC screening isn't optional if you touch U.S. dollars. It's also not automated. Most people think it is. They're wrong. If you're building payments infrastructure, you need to understand what screening actually requires, what it costs operationally, and most importantly, what it doesn't catch.

The regulation exists. Everyone agrees it exists. The problem is execution.

The SDN list and how it actually works

OFAC publishes lists. The Specially Designated Nationals list is the main one—about 9,000 names as of April 2026. There's also the Consolidated Non-SDN List, the Sectoral Sanctions Identification List, EU lists, UN lists. Each one is separate. Each one updates at different times.

When someone transacts on your platform, you need to match both sides against all these lists. That's the core requirement.

Simple, right? No.

Real-time screening happens as the transaction creates. You query the wallet address or account name against OFAC and allow or block instantly. Latency matters. Seriously. If your lookup takes 500 milliseconds, users abandon the transaction. If it takes 50 milliseconds, they don't notice it. Nobody wants their payment to feel slow.

Batch screening is different. You wait hours or days, collect transactions in a CSV, send to your vendor, get back a report. It's cheaper at volume. It's also reactive. The transaction already went through. You're just checking after the fact whether you broke the law.

Most companies do both. Real-time on the high-risk corridors. Iran, North Korea, stuff where designation is political and consistent. Batch on everything else. Some do both because regulations actually require redundancy.

Here's what nobody mentions. The lists change multiple times per day. Someone gets designated this morning. Your system doesn't know about it until your next list pull. If your list refresh is hourly, you're running a one-hour delay on new designations.

Comparing the vendors

Chainalysis, Elliptic, TRM Labs. Three companies. All different.

Chainalysis has the biggest crypto customer base. That means the most transaction history flowing through their system. Their API returns matches in under 200 milliseconds. They also do risk scoring for wallets that haven't been designated yet but have touched SDN wallets. Useful for catching laundering. Also creates more false positives.

Elliptic focuses harder on EU and UK lists. Better relationships with European regulators. Faster on SEPA stuff. Their matching is conservative, which means fewer wrong flags but possibly more actual risks that slip through. Pick your poison.

TRM Labs is in the middle. Not the fastest, not the slowest. Their strength is wallet clustering and behavioral analysis. They track money moving through chains and recognize patterns that don't appear on any official list. Useful if you're worried about sophisticated laundering. Overkill if you're just processing payments.

None of them are 100 percent accurate. The industry benchmark for false positives is 2 to 5 percent. Someone named "Ali Ahmed" gets flagged because "Ali Ahmed" is on the list. These aren't mistakes. They're inherent to name-matching at scale.

You'll review hundreds of these per month. Seriously. Thousands if you process volume.

The operational side nobody budgets for

A false positive means a customer's transaction gets blocked. They call support. Support doesn't know what to do. It escalates. Someone in compliance spends six hours verifying whether "Ali Ahmed" the customer is the same person as "Ali Ahmed" on the SDN list.

The transaction clears two days later.

The customer considers moving platforms.

Scale this. A processor handles 10,000 transactions daily. 3 percent false positive rate. That's 300 wrong blocks every single day. Even if your team fixes 99 percent of them correctly, you're creating friction at massive scale.

This is why vendor selection actually matters beyond just "which has the most data." Chainalysis has better integration with customer support software. Resolutions happen faster. Elliptic requires more manual work but starts with fewer false positives. TRM's pattern-based approach creates more friction upfront but catches more actual risk.

You need staff. A compliance analyst reviews maybe 25 false positives per day. If you're blocking 300 daily, you need 12 people minimum. That's $1.8 million annually before you even pay for the screening software.

Most startups don't budget for this. They hire 2 compliance people and wonder why they're overwhelmed within three months.

What actually fails

Two failure modes exist.

First, false negatives. A sanctioned transaction slips through because your screening didn't catch it. Second, you have screening but it's incomplete or misconfigured.

The processor I mentioned at the start was doing real-time screening at creation but not at settlement. The transaction was screened when initiated and passed. The OFAC list updated while the transaction was pending. When it settled four hours later, that wallet was newly designated.

They didn't re-screen at settlement.

OFAC penalties don't require proving intent. It doesn't matter that you had a system. The violation is the transaction itself. Gross negligence—you had screening but it obviously failed—that's $250,000 per violation. Willfully. You didn't care or deliberately bypassed it. That's $20 million or twice the transaction value.

The settlements usually land between $2 million and $15 million for a single incident involving a few transactions.

That processor had processed seventeen sanctioned transactions. Seventeen separate violations in OFAC's accounting.

How to actually build this

If you're building payment infrastructure, screening can't be an afterthought. It needs to be in the transaction engine itself.

Screen at multiple points. At initiation, at settlement, batch screening every 24 hours on everything. Redundancy costs money. It also catches when your primary system fails. And it will fail.

Log everything. Every API call, every result, every match, timestamps. Regulators will demand this. Your ability to prove you screened correctly is your only defense.

Use multiple vendors if the amount is high enough. Someone moving $500,000 through? Screen it twice. Two different vendors. If they disagree, escalate. This catches systematic errors in a single vendor's data.

Update your lists continuously. OFAC changes multiple times daily. Your system should pull lists at minimum hourly, ideally continuously. If you're updating once per day, you're running a full day behind.

Document false positives. Every single one. Track that you reviewed it, confirmed it wasn't a match, released the transaction. When regulators ask, you show a pattern of appropriate review.

The best compliance posture isn't zero false positives. That's impossible and probably means you're so aggressive that customers hate you. The best posture is zero false negatives—you don't miss actual sanctioned transactions—plus documented, systematic handling of false positives.

But here's the hard part. Even with all of this, a Wells Notice can still arrive. It happened to someone with screening, logging, multiple vendors, continuous updates. They did everything right. The regulator still showed up. You're never fully protected. You're just protecting yourself as well as possible.