Ongoing sanctions screening: how often to rescreen and what to screen

How often to rescreen customers against sanctions lists, what to screen beyond names, and a cadence that holds up under OFAC strict liability.

Screen every customer at onboarding, rescreen the whole customer base each time a sanctions list changes, and screen the parties and wallet addresses on every transaction before it settles. Scope covers individuals, businesses, beneficial owners, counterparties, and blockchain addresses. Batch rescreening on a fixed calendar leaves gaps of weeks, and OFAC liability is strict.

This article is general information, not legal advice. Sanctions obligations depend on where you operate and who your customers are, so confirm yours with counsel.

Key takeaways

  • Onboarding screening only proves a customer was clean on signup day. Lists keep changing after that.
  • The defensible baseline is rescreening on every list update plus screening at transaction time, before settlement.
  • Screen beneficial owners, not only business names. Under OFAC's 50 percent rule, an unlisted company can still be blocked.
  • Wallet addresses are sanctions identifiers in their own right, and OFAC says its address listings are not exhaustive.
  • Fuzzy matching catches spelling variants. Secondary identifiers and written decisions keep it from drowning the team.

Sanctions screening is one of the four parts of an automated risk monitoring program. This guide covers its two big decisions: how often to screen, and what to screen.

Why is a one-time sanctions check not enough?

Because sanctions lists change after the customer signs up, and OFAC liability does not depend on whether you knew. A customer cleared in January can be designated in March, and every payment after that date is exposed.

The Office of Foreign Assets Control (OFAC), part of the US Treasury, is direct about the standard. Its sanctions compliance guidance for the virtual currency industry says OFAC may impose civil penalties "based on a strict liability legal standard," meaning a US person can be held liable "even without having knowledge or reason to know" of the violation. OFAC weighs the facts of each case, but "we screened them at signup" does not make the payment legal.

The same guidance notes that the Specially Designated Nationals and Blocked Persons List (SDN List) "is frequently updated." OFAC posts each change on its Recent Actions page, and sanctions-related actions there often land several times a month.

So the question is not whether to rescreen. It's how fast you pick up a change, and what you rescreen when you do.

Which sanctions lists and watchlists should a fintech screen against?

At minimum, the OFAC lists for any business with a US nexus, plus the UN, EU, and UK lists wherever you or your customers operate. PEP and adverse media sources feed risk rating rather than blocking decisions.

ListWho it applies toWhy it mattersTypical screening trigger
OFAC SDN ListUS persons and transactions touching the US financial systemListed parties are blocked; dealing with them is prohibitedOnboarding, every list update, every transaction
OFAC non-SDN consolidated listsUS personsNarrower prohibitions on specific dealings, not full blockingOnboarding, every list update, every transaction
UN Security Council Consolidated ListUN member states, through national lawBase layer that many national lists implementOnboarding, every list update
EU consolidated financial sanctions listEU persons and business done in the EUAsset freezes and prohibitions across member statesOnboarding, every list update, every transaction
UK Sanctions ListUK persons and business done in the UKFinancial sanctions enforced by the Office of Financial Sanctions Implementation (OFSI)Onboarding, every list update, every transaction
Politically exposed person (PEP) databasesFirms following FATF Recommendation 12PEPs are allowed but need enhanced due diligenceOnboarding, periodic review, data change
Adverse mediaRisk-based, no single legal listEarly signal of fraud, corruption, or pending designationOnboarding, periodic review

Lists overlap but don't match, so a US-only screen is not enough for a business with EU customers. And PEP is not a sanctions category. A PEP match means more questions, as the FATF guidance on politically exposed persons lays out, not a refused payment.

How often should you rescreen customers against sanctions lists?

Rescreen the full customer base every time a list you rely on changes, and screen parties at transaction time before settlement. Fixed calendar batches, monthly or quarterly, are better than nothing and worse than both.

ApproachWhat it catchesWhat it missesRisk level
Onboarding onlyParties already listed at signupEvery designation after signupHigh
Periodic batch, quarterlyDesignations up to the last runUp to three months of new designations and the payments made in betweenHigh
Periodic batch, monthlyDesignations up to the last runUp to a month of new designationsMedium to high
On every list updateNew designations, across the whole base, as soon as the update is ingestedChanges on the customer side between updates, such as a new owner or walletLow to medium on its own
On every transactionParties and addresses at the moment money movesDormant customers who hold balances but don't transactLow to medium on its own
List update plus transaction plus data changeNew designations, new counterparties, and changed customer dataVery little, if matching is tunedLowest

The combination wins because each method covers the other's blind spot. List-update screening finds the customer who became a match while doing nothing. Transaction screening finds the new counterparty or wallet that was never in your customer base. Data-change screening catches the new beneficial owner who joined after KYB.

For stablecoin flows, transaction-time screening has to run before settlement. A confirmed on-chain transfer can't be reversed, so a match found afterward is a report, not a control.

What should you screen besides customer names?

Screen every party whose property or interest is in the payment: the customer, the people who own and control a business customer, the counterparty, and the wallet addresses involved. A name-only screen of the account holder misses most of the ways a sanctioned party actually shows up.

Individuals. Full legal name, plus date of birth, nationality, and address as secondary identifiers.

Businesses. Legal name, trade names, registration number, and registered address. Screen former names too.

Beneficial owners and controllers. OFAC's 50 percent rule guidance treats an entity as blocked when blocked persons own 50 percent or more of it, directly or indirectly, individually or in aggregate. The company's own name may appear on no list. Only screening the owners, as collected during KYB, catches it.

Counterparties. The beneficiary of a payout or the sender of a payin, plus their bank or provider where you have it. A clean customer paying a listed supplier is still a prohibited dealing.

Wallet addresses. OFAC first listed digital currency addresses on SDN entries on November 28, 2018, for two Iran-based individuals. Its FAQ 562 says those address listings are "not likely to be exhaustive." Screen addresses against the list, then score their exposure to sanctioned actors through blockchain analytics. The crypto wallet compliance checklist covers address screening in more depth.

How does name matching work, and how do you clear a false match?

Fuzzy matching compares names by similarity, not exact spelling, and secondary identifiers decide whether a similar name is the same person. Exact matching is cheaper to run and misses too much.

Exact matching fails on transliteration (Mohammad, Mohammed, Muhammad), word order, dropped middle names, and alternate country spellings. OFAC's Framework for OFAC Compliance Commitments lists both failure modes among the root causes of past violations: screening software not updated for SDN List changes, and screens that did not account for alternative spellings, such as Habana for Havana.

Fuzzy matching fixes recall and creates noise. The fix for the noise is not a looser threshold. It's a second check before an alert reaches a person:

  • Date of birth or year of birth for individuals.
  • Nationality and country of residence.
  • Registration number and country of incorporation for entities.
  • Address, where the list entry carries one.

When an analyst clears a match, the record should say what matched, which list entry and list version, which identifiers were compared, the decision, who made it, and when. That record lets you suppress the same alert next time, but only while both the customer data and the list entry stay the same. If either changes, the pair goes back through the screen. A suppression that outlives its facts is how a real match gets waved through.

How do you design a sanctions screening workflow?

Define the scope, load the lists as events, screen on three triggers, and hold before settlement. The steps:

  1. Define the scope. Customers, owners and controllers, counterparties, and wallet addresses. Write it down; it is the first thing an examiner asks for.
  2. Pick the lists per jurisdiction. OFAC SDN and non-SDN lists for any US nexus, plus UN, EU, and UK lists where you or your customers operate.
  3. Load list updates as events. Ingest each change as soon as it's published, store the version, and alert when a load fails. A stale list is the quietest failure in this whole system.
  4. Rescreen the full base on every update. Every active customer, owner, and stored address against the new and changed entries.
  5. Screen at transaction time. Parties and addresses, before settlement. A possible match holds the payment while funds can still be stopped.
  6. Clear or escalate. Compare secondary identifiers, document the decision, and escalate anything unresolved to the compliance officer.
  7. Block, reject, and report. A confirmed match is blocked or rejected under OFAC rules and reported within the deadlines in OFAC's Reporting, Procedures and Penalties Regulations (31 CFR part 501). Returning funds to a blocked person is itself a prohibited dealing.

A sanctions hold is one of the transaction monitoring red flags a system scores before money moves.

What does a list-update match look like in practice?

Illustrative example. The names, dates, and amounts below are invented to show the mechanics.

A logistics company in Mexico passes KYB on January 12. It has two owners: one holds 60 percent, the other 40 percent. Neither owner, nor the company, is on any list. Clean.

On March 18, OFAC adds the 60 percent owner to the SDN List. The company's name appears nowhere in the update. Under the 50 percent rule, it is now blocked anyway.

With quarterly batch screening. The next run is April 1. Between March 18 and March 31, the company sends six payouts totaling USD 84,000. Each one is a dealing with a blocked entity, and the April run finds the match only after the money is gone.

With list-update screening. The March 18 update loads that afternoon. The rescreen matches the owner's name, then confirms on date of birth and nationality. Because owners are in scope, the match rolls up to the company. Its account is frozen and the payout queued for March 19 is held before settlement. Compliance confirms the match, blocks the funds, and files the report to OFAC.

Same customer, same list. The difference is when the screen ran and whether owners were in it.

What are the common sanctions screening mistakes?

Most failures come from screening too rarely or too little:

  1. Signup-only checks. The customer is screened once and never again. Every later designation is invisible.
  2. Ignoring beneficial owners. The business name is screened, the owners aren't, and the 50 percent rule goes unenforced.
  3. No wallet screening, or SDN-only address checks. OFAC itself says its address listings are incomplete.
  4. No record of cleared alerts. The match was cleared, but nobody can show why. To an examiner, an undocumented clearance looks like no review at all.
  5. No list update monitoring. The screening tool runs, but against a list version from weeks ago, and no one is alerted when a load fails.
  6. Permanent suppressions. A cleared match stays suppressed after the customer's data or the list entry changes.

How does BlindPay handle sanctions screening?

BlindPay runs KYC, KYB, sanctions screening, and transaction monitoring inside the API flow, before money moves. BlindPay is registered with FinCEN as a money services business, and its registrations are on the licenses page.

Customers are verified before their first transaction: KYC Standard is automated and takes about 60 seconds, while KYC Enhanced and KYB Standard are manual reviews that take 3 hours to 1 business day. Entities or individuals on OFAC, EU, UN, or other sanctions lists are not supported, per the prohibited activities list. Creating a customer or bank account in a prohibited country fails outright, with no override.

A sanctions or watchlist match on a payment is one of the documented compliance hold triggers. The payin or payout moves to on_hold for manual review. A hold can last up to 30 days: approval resumes the normal flow, and a timeout without a decision fails the transaction.

What to do next

Pull three facts from your current setup: the date of your last full-base rescreen, the list version it used, and whether owners and wallet addresses were in scope. If the rescreen ran on a calendar instead of on a list update, or owners weren't in it, fix that before anything else. Then sample 20 cleared matches and check that each one has a written reason.

Sources and further reading

This article is general information, not legal advice.

FAQ