OFAC Screening Is Not Optional and Your Fintech Probably Isn't Doing It Right

If your application moves money, processes payments or onboards customers, you need to screen against the OFAC SDN list. This isn't a suggestion. The Office of Foreign Assets Control can fine you $356,579 per violation and they don't care if you missed a match because your string comparison was case-sensitive.

I built an OFAC screening API because I kept seeing the same problem: companies either weren't screening at all, were doing naive exact-match lookups that miss obvious variations, or were paying enterprise vendors five figures a year for what amounts to fuzzy string matching against a publicly available XML file.

What most people get wrong

The SDN list is just XML. Treasury publishes it freely. The hard part isn't getting the data. The hard part is matching against it in a way that actually catches the people it's supposed to catch.

Here's an example. "Vladimir Vladimirovich PUTIN" is on the list. He also appears as "Vladimir PUTIN." If a customer enters "V. Putin" on your onboarding form and your system does an exact match, congratulations, you just cleared a sanctioned individual.

This is why you need multiple matching strategies working together:

• Jaro-Winkler similarity catches typos and transpositions
• Token-set matching handles reordered words ("BANK OF IRAN" vs "IRAN BANK")
• Phonetic matching catches different spellings of the same-sounding name
• Substring containment for partial queries

Each of these on its own misses things. Together they produce a confidence score that actually means something.

The DIY trap

I've talked to developers who say "we'll just download the XML and do our own matching." Sure, you can do that. Here's what you're signing up for:

• Parsing 18,000+ entries with multiple aliases per entry
• Handling name transliterations across scripts
• Updating the data every time Treasury publishes a change (which is frequent)
• Tuning match thresholds so you catch real hits without drowning your compliance team in false positives
• Documenting all of this for your auditors

Most teams get halfway through this list and realize they should have just used an API.

What good screening looks like

A screening call should take a name (and optionally a country, entity type or sanctions program filter) and return matches ranked by confidence. Each match should include the SDN entry details, the match score and which matching strategy flagged it.

Your compliance team needs to review anything above a certain threshold. The API should make it obvious what to review and what to ignore. If everything comes back as a 73% match, that's useless. You need clear tiers: exact match, strong match, partial match, weak match.

The system also needs to handle batch screening. If you're onboarding thousands of customers or processing payroll for a multinational, you can't make one API call at a time.

How I built it

The OFAC Screening API embeds the full SDN list locally and updates it regularly. No dependency on Treasury's servers at query time. Responses come back fast because there's no upstream call.

It uses weighted scoring across all four matching strategies I mentioned above. Results come back with a confidence tier and the full SDN entry details so your compliance team has everything they need to make a decision.

There's also an MCP server version if you're using AI assistants for compliance workflows. An agent can screen a list of names, review the results and flag the ones that need human attention.

The bottom line

OFAC screening is one of those things where the cost of getting it wrong is catastrophic and the cost of getting it right is pretty low. You don't need an enterprise contract. You need fuzzy matching, regular data updates and clear confidence scoring. That's it.

If you're not screening today, start. If you're doing exact-match only, fix it. The Treasury Department is not going to accept "our string comparison was case-sensitive" as a defense.