---
title: "Ongoing sanctions screening: how often to rescreen and what to screen"
seoTitle: "Ongoing sanctions screening: how often to rescreen"
description: "How often to rescreen customers against sanctions lists, what to screen beyond names, and a cadence that holds up under OFAC strict liability."
date: "2026-10-01"
updated: "2026-10-01"
category: "compliance"
author: "BlindPay Team"
howto:
  name: "How to design an ongoing sanctions screening workflow"
  steps:
    - name: "Define the screening scope"
      text: "List every party you screen: individual customers, business customers, beneficial owners and controllers, payment counterparties, and the blockchain wallet addresses on both sides of each transfer."
    - name: "Pick the lists per jurisdiction"
      text: "Screen against the OFAC SDN and non-SDN consolidated lists, plus the UN, EU, and UK lists where you or your customers operate. Add PEP and adverse media sources for risk rating, not for blocking."
    - name: "Subscribe to list updates"
      text: "Ingest each list as soon as it changes, record the version you screened against, and alert when an update fails to load."
    - name: "Rescreen the whole base on every update"
      text: "When a list changes, rescreen every active customer, owner, and stored wallet address against the new entries, not only new signups."
    - name: "Screen at transaction time"
      text: "Before a payment settles, screen the parties and wallet addresses involved. A possible match holds the payment before funds move."
    - name: "Clear or escalate each match"
      text: "Compare secondary identifiers such as date of birth, nationality, and address. Document what matched, what was compared, the decision, who made it, and the list version."
    - name: "Block, reject, and report confirmed matches"
      text: "A confirmed match is blocked or rejected under OFAC rules and reported to OFAC within its deadlines. Do not return funds to a blocked person."
faq:
  - q: "How often should a fintech rescreen customers against sanctions lists?"
    a: "Every time a list it relies on changes, plus on every transaction before settlement. OFAC updates the SDN List frequently, often several times a month, so a quarterly or monthly batch leaves weeks in which a newly listed customer can still move money. Rescreen on customer data changes too, such as a new owner, address, or wallet."
  - q: "Is a sanctions check at onboarding enough?"
    a: "No. Onboarding screening proves the customer was clean on the day they signed up. Sanctions lists change after that, and OFAC applies a strict liability standard, so a payment to a person listed last week can be a violation even if your team never knew. Ongoing screening closes the gap between signup and every later payment."
  - q: "Do you need to screen blockchain wallet addresses for sanctions?"
    a: "Yes, if you move stablecoins or other digital assets. OFAC has added digital currency addresses to SDN List entries since November 2018, but says those listings are not likely to be exhaustive. Screen addresses against the list and use blockchain analytics to score exposure to sanctioned actors who were never listed by address."
  - q: "What is the OFAC 50 percent rule?"
    a: "It is OFAC guidance that treats an entity as blocked when one or more blocked persons own 50 percent or more of it, directly or indirectly, individually or in aggregate. The entity is blocked even when its own name appears on no list. That is why sanctions screening has to cover beneficial owners, not only the business name."
  - q: "What is the difference between sanctions screening and PEP screening?"
    a: "Sanctions screening looks for parties you are legally prohibited from dealing with, and a confirmed match stops the payment. PEP screening looks for politically exposed persons, who are allowed as customers but carry higher corruption risk. Under FATF Recommendation 12, a PEP match triggers enhanced due diligence, such as checking source of wealth, rather than a block."
  - q: "How do you reduce false positives in sanctions screening?"
    a: "Use fuzzy matching to catch spelling variants, then compare secondary identifiers before raising an alert: date of birth, nationality, country, address, or registration number. Record why each cleared match was cleared, and suppress the same match only while the customer data and the list entry stay unchanged. If either changes, screen again."
---

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](/resources/more/what-is-automated-risk-monitoring-fintech). 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](https://ofac.treasury.gov/media/913571/download?inline) 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](https://ofac.treasury.gov/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.

| List | Who it applies to | Why it matters | Typical screening trigger |
| --- | --- | --- | --- |
| OFAC SDN List | US persons and transactions touching the US financial system | Listed parties are blocked; dealing with them is prohibited | Onboarding, every list update, every transaction |
| OFAC non-SDN consolidated lists | US persons | Narrower prohibitions on specific dealings, not full blocking | Onboarding, every list update, every transaction |
| [UN Security Council Consolidated List](https://main.un.org/securitycouncil/en/content/un-sc-consolidated-list) | UN member states, through national law | Base layer that many national lists implement | Onboarding, every list update |
| [EU consolidated financial sanctions list](https://data.europa.eu/data/datasets/consolidated-list-of-persons-groups-and-entities-subject-to-eu-financial-sanctions) | EU persons and business done in the EU | Asset freezes and prohibitions across member states | Onboarding, every list update, every transaction |
| [UK Sanctions List](https://www.gov.uk/government/publications/the-uk-sanctions-list) | UK persons and business done in the UK | Financial sanctions enforced by the Office of Financial Sanctions Implementation (OFSI) | Onboarding, every list update, every transaction |
| Politically exposed person (PEP) databases | Firms following FATF Recommendation 12 | PEPs are allowed but need enhanced due diligence | Onboarding, periodic review, data change |
| Adverse media | Risk-based, no single legal list | Early signal of fraud, corruption, or pending designation | Onboarding, 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](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Peps-r12-r22.html) 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.

| Approach | What it catches | What it misses | Risk level |
| --- | --- | --- | --- |
| Onboarding only | Parties already listed at signup | Every designation after signup | High |
| Periodic batch, quarterly | Designations up to the last run | Up to three months of new designations and the payments made in between | High |
| Periodic batch, monthly | Designations up to the last run | Up to a month of new designations | Medium to high |
| On every list update | New designations, across the whole base, as soon as the update is ingested | Changes on the customer side between updates, such as a new owner or wallet | Low to medium on its own |
| On every transaction | Parties and addresses at the moment money moves | Dormant customers who hold balances but don't transact | Low to medium on its own |
| List update plus transaction plus data change | New designations, new counterparties, and changed customer data | Very little, if matching is tuned | Lowest |

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](/resources/more/are-stablecoin-payments-reversible), 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](https://ofac.treasury.gov/media/6186/download?inline) 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](/resources/more/what-is-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](https://ofac.treasury.gov/recent-actions/20181128) on SDN entries on November 28, 2018, for two Iran-based individuals. Its [FAQ 562](https://ofac.treasury.gov/faqs/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](/resources/more/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](https://ofac.treasury.gov/media/16331/download) 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](/resources/more/transaction-monitoring-red-flags-stablecoin-payments) 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](/licenses).

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](/docs/kb/prohibited-activities). 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](/docs/kb/cut-off-times). 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

- [OFAC: Sanctions compliance guidance for the virtual currency industry](https://ofac.treasury.gov/media/913571/download?inline)
- [OFAC: FAQ 562 on digital currency addresses](https://ofac.treasury.gov/faqs/562)
- [OFAC: Recent Actions](https://ofac.treasury.gov/recent-actions)
- [OFAC: Revised guidance on entities owned by blocked persons (50 percent rule)](https://ofac.treasury.gov/media/6186/download?inline)
- [OFAC: A Framework for OFAC Compliance Commitments](https://ofac.treasury.gov/media/16331/download)
- [FATF: Guidance on politically exposed persons (Recommendations 12 and 22)](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Peps-r12-r22.html)

*This article is general information, not legal advice.*