- General

How to Build a Sanctions Screening Process: A First-Timer’s Roadmap

How to Build a Sanctions Screening Process: A First-Timer’s Roadmap

The most common mistake people make when they first encounter sanctions screening is assuming it is a software purchase. They shop for a tool, connect it to their payment rails, and wait for the alerts to roll in. What they actually get is a noisy queue of false positives, a compliance team that stops trusting the system, and a regulator asking why a name that appeared on a list three months ago was never escalated. Screening is not a product you install. It is a process you operate, and the tool is only one part of it. If you are building this for the first time, the sequence below is the one that keeps you out of trouble.

Before the steps, one framing note. Sanctions screening is not the same thing as OFAC screening, even though the two are often used interchangeably in internal memos. Screening is the broader discipline of checking parties against multiple restricted-party lists, including but not limited to those maintained by the U.S. Treasury’s Office of Foreign Assets Control. OFAC screening is the specific application of that discipline to the SDN List and other OFAC-administered lists. Getting this distinction right matters because your process has to cover more than one list, and because regulators will ask you to explain your methodology. For a fuller breakdown of where the two overlap and where they diverge, ofacblockedfundslawyers’ guide to sanctions screening is a useful reference to keep alongside your build.

Step 1: Map Every Point Where a Restricted Party Could Enter Your Business

You cannot screen what you have not mapped. Before you evaluate a single vendor, sit down with operations, finance, legal, and anyone who touches onboarding and write out every moment a counterparty, beneficiary, director, or intermediary enters your records. That includes new customer onboarding, new vendor setup, incoming and outgoing wire transfers, trade finance documents, loan applications, insurance claims, and even inbound email from a prospect you have never met.

The goal is a list of screening triggers. Each trigger should have a clear owner and a clear moment in time: before the relationship is established, before the payment is released, or before the contract is signed. If you screen after money moves, you have already taken on the risk. First-time builders almost always under-map this step, then discover during an audit that a whole category of counterparties, often beneficial owners or guarantors, was never checked at all.

Write the map down. It becomes the backbone of your written policy, and it is the first document a regulator or an external auditor will ask to see.

Step 2: Decide What You Are Screening Against and How Often

Sanctions lists change constantly. Names are added, removed, and amended, and aliases accumulate over time. Your process needs to account for that movement, not just the state of the list on the day you signed the contract.

At minimum, you should be screening against the OFAC SDN List, OFAC’s Consolidated Sanctions List, and any other lists relevant to your jurisdiction and your counterparties, such as the EU consolidated list or the UK sanctions list. If you operate in multiple countries, your screening universe is the union of those regimes, and you screen against all of them for every party.

Frequency is the next decision. Onboarding screening is table stakes. Ongoing screening, sometimes called continuous or event-driven screening, is where most first-time programs fall short. A vendor who was clean at onboarding can be designated six months later. Decide now whether you will rescreen your entire book on a schedule, screen on every transaction, or both. Document the reasoning. A defensible rationale is worth more than an aggressive one you cannot explain.

Step 3: Match Your Screening Tool to Your Actual Risk Profile

There is no single best screening tool. There is only the tool that fits your volume, your data quality, and your risk appetite. A small advisory firm with fifty counterparties a month does not need the same configuration as a mid-sized bank processing thousands of payments a day.

When you evaluate vendors, ask four questions. First, how does the tool handle transliteration and name variants, particularly for Arabic, Cyrillic, and Chinese names? Second, how does it handle aliases and date of birth? Third, what is the false positive rate on a sample of your own historical data? Fourth, how does it document its match logic so you can explain it to a regulator?

That last question is the one people skip, and it is the one that hurts later. If you cannot explain why the tool flagged a name, you cannot defend the decision to close or escalate the alert. Insist on seeing the match rationale in the demo, not just the alert list.

Also decide how fuzzy you want the matching to be. Looser matching catches more true positives but buries your team in false positives. Tighter matching does the opposite. Most first-time programs start too loose, burn out their analysts, and then overcorrect. Start moderate, measure, and tune.

Step 4: Write the Escalation and Disposition Rules Before You Go Live

An alert is not a decision. It is a prompt for a decision. Your process needs a written rule for what happens when a name matches, and that rule needs to be specific enough that two different analysts would reach the same conclusion on the same alert.

A workable structure looks like this. Tier one: the alert is a clear false positive, such as a common name with no other matching identifiers. Document the reasoning and close. Tier two: the alert has partial matches on name and one other identifier. Escalate to a senior reviewer, request additional documentation from the counterparty, and hold the transaction. Tier three: the alert is a strong match or involves a party on a list with no exceptions. Escalate immediately to legal, freeze the transaction, and do not tip off the counterparty.

The freeze-and-do-not-tip-off rule is critical. Sanctions rules generally prohibit dealing with blocked persons and prohibit telling them they have been flagged. If your team is not trained on this, they will make a well-intentioned phone call that creates a much bigger problem. Put the rule in writing and train on it.

You also need a rule for how long alerts can sit before they are resolved. A queue with no service level is a queue that grows until it becomes a finding. Pick a target, such as 48 hours for tier one and same-day for tier three, and track it.

Step 5: Train the Humans Who Actually Touch the Alerts

The best-configured system in the world will fail if the people reviewing alerts do not understand what they are looking at. Training is not a one-time onboarding video. It is a recurring exercise that covers the current list landscape, your internal escalation rules, and real examples from your own alert queue.

Cover at least four things. First, what sanctions are and why they matter, in plain language. Second, how to read a match rationale and identify which identifiers actually matter. Third, how to document a disposition so that someone reading it six months later understands the reasoning. Fourth, when to stop and call legal rather than deciding on their own.

Document the training. Attendance logs, materials, and dates. Regulators do not just ask whether you trained; they ask you to prove it.

One more point on people: make sure someone owns the process end to end. Shared ownership is the same as no ownership. Name a person, give them the authority to freeze transactions, and give them a path to legal when they need it.

Step 6: Test, Document, and Improve on a Schedule

A screening program that is never tested is a program that is assumed to work. Assumptions are not defenses. Build a testing cadence into your calendar from day one.

At least quarterly, run a sample of your historical counterparties against the current lists and see whether your live process would have caught them. At least annually, review your list coverage, your match thresholds, and your escalation rules against what you have actually seen in the queue. If your false positive rate is climbing, your thresholds are wrong. If your false negatives are appearing in testing, your matching is too tight.

Keep records of every test, every threshold change, and the reason for it. This is the paper trail that turns a good process into a defensible one. It is also the raw material for your annual policy refresh.

Finally, build a relationship with sanctions counsel before you need it. The moment a strong match appears, you will want someone who already knows your program to help you decide whether to block, reject, or file a report. Bringing counsel in cold during a live alert is slower and more expensive than having them review your process once a year.

Your Closing Checklist

Before you consider your first sanctions screening build finished, walk through this list and confirm each item is done, not planned.

  • Every counterparty entry point is mapped, with a named owner and a screening moment.
  • Your screening universe covers OFAC lists and every other regime relevant to your business.
  • Onboarding screening and ongoing screening are both live, with a documented frequency.
  • Your tool’s match logic can be explained and exported for audit purposes.
  • Escalation tiers are written, with clear freeze and no-tip-off rules.
  • Alert resolution targets are set and tracked.
  • Analysts are trained, and the training is documented.
  • One person owns the process end to end.
  • Testing runs on a schedule, and results are recorded.
  • Sanctions counsel has reviewed the program at least once.

If you can check every box, you have something more valuable than a screening tool. You have a process that can survive an alert, an audit, and a change in the lists. That is the difference between buying software and building compliance, and it is the difference that matters when someone asks you to explain how a restricted party got through.

Leave a Reply

Your email address will not be published. Required fields are marked *