Sanctions Screening in Zero-Knowledge: Proving You Are NOT a Bad Actor

Proving who you are is well-understood. You present a passport, sign a message, or show a credential.

Proving who you are not is significantly harder.

Yet, this is exactly what sanctions screening requires.

Every time a user interacts with a regulated crypto service—whether it's a centralized exchange, a fiat on-ramp, or a compliant DeFi protocol—the service asks a negative question:

"Are you a terrorist? Are you a money launderer? Are you on the OFAC SDN list?"

In the traditional financial industry, answering this question requires total surveillance. To prove you are not a bad actor, you must reveal exactly who you are, where you live, and who you transact with. The bank checks your identity against a global sanctions list and, if you are clean, allows the transaction.

But in Web3, this model breaks the fundamental promise of privacy. If every transaction requires public identification to prove innocence, we have simply rebuilt the existing banking system on a slower database.

This guide explores Sanctions Screening in Zero-Knowledge: Proving You Are NOT a Bad Actor.

It is a technical and operational deep dive into the "Non-Inclusion Problem."

We will explain how zero knowledge proofs allow users to cryptographically prove they are not on a list of sanctioned entities without revealing their identity. We will cover the architecture of compliance infrastructure, the challenge of false positives, and how financial institutions can meet AML regulations without turning compliance into surveillance.

Why Sanctions Screening is Different from KYC

Identity verification (KYC) and sanctions screening are often bundled together in the "Compliance" bucket, but they are fundamentally different mathematical problems.

The Inclusion vs. Non-Inclusion Problem

KYC is an inclusion problem. You want to prove that a user is who they say they are, and that they are included in a set of valid, real humans.

Sanctions screening is a non-inclusion problem. You want to prove that a user is not a member of a specific set of sanctioned actors.

Mathematically, proving non-membership in a large, dynamic set (like the OFAC list) is complex. In a privacy-preserving system, you cannot simply send your ID to the verifier to check against the list, because that reveals your identity. Instead, you must generate a proof locally that says: "My identity commitment is $C$, and $C$ is not present in the Merkle Tree of blocked identities $T$."

The Regulatory Pressure Cooker

Financial institutions and crypto asset service providers (CASPs) operate under intense regulatory scrutiny.

AML regulations (Anti-Money Laundering) and the Bank Secrecy Act require them to block transactions from sanctioned entities.

If a crypto compliance team fails to block a transfer to a known terrorist wallet, the penalties from regulatory bodies like OFAC or the Financial Action Task Force (FATF) can be existential.

This creates a culture of "when in doubt, block."

In a transparent system, this leads to massive over-collection of data.

In a privacy-preserving system, it creates a high bar for correctness: the zero knowledge proof must be airtight.

The Privacy Challenge

In traditional systems, screening is invisible to the user but highly visible to the bank. The bank sees everything.

In Web3, we want the user to retain control. We want to enable crypto transactions that are private from the public, yet compliant with the law.

This requires a shift from "Server-Side Screening" (where the bank checks the list) to "Client-Side Proving" (where the user proves they aren't on the list).

The Threat Model: How Bad Actors Evade Detection

To design a robust system, we must understand the adversary. Sanctioned actors are highly motivated to evade detection.

The Shell Game

Sophisticated actors, such as state-sponsored hackers, do not simply use a wallet tagged "Bad Guy."

They use:

Intermediaries: Sending funds through thousands of fresh wallets (peeling chains) to distance criminal proceeds from the source.
Mixers: Using privacy tools to break the on-chain link.
Stolen Identities: Buying "KYC'd" accounts on the dark web to bypass identity verification.

Name Variations and Fuzzy Matching

Sanctions lists are messy. They contain names, aliases, and sometimes wallet addresses.

A bad actor might use a slightly different spelling of their name to bypass exact-match filters.

Traditional transaction monitoring systems use "fuzzy matching" to catch this.

In zero knowledge, fuzzy matching is incredibly hard. ZK circuits are precise; they prove $A \neq B$. They struggle to prove "A is not similar to B."

This is a core challenge in deploying zero knowledge proofs for sanctions screening: handling the ambiguity of real-world data.

The Speed of Money

Illicit flows move fast. A hack happens, and the funds move across five chains in minutes.

Sanctions lists update slowly.

A robust compliance framework needs real-time updates. If a wallet is added to the SDN list at 10:00 AM, a transaction at 10:01 AM must be blocked.

Static lists or outdated Merkle Trees create a window of opportunity for terrorist financing and money laundering.

Sanctions Regulations and Sanctions Lists: What Gets Published

Before we build the ZK circuit, we must understand the data source. Sanctions regulations dictate who is on the list, but they don't provide a clean JSON API.

Who Publishes the Lists?

OFAC (US): Publishes the SDN List (Specially Designated Nationals). This is the global baseline for most financial institutions.
UN Security Council: Publishes global lists related to terrorist financing and proliferation.
EU/UK Lists: Specific to European jurisdictions.
Other Countries: Many nations maintain their own local lists.

For a global crypto compliance strategy, you cannot just check one list. You must check an aggregate set.

Address-Based vs. Identity-Based Screening

There are two types of sanctions screening in crypto:

Address-Based: Checking if the wallet address itself is sanctioned (e.g., the Lazarus Group's known BTC address).
Identity-Based: Checking if the owner of the wallet is a sanctioned person (e.g., checking "John Doe" against the SDN list).

ZK Non-Inclusion works differently for each. For address-based, the set is public addresses. For identity-based, the set is personal identifiers (Names, DOBS, National IDs).

Sophisticated compliance frameworks use both.

The Data Normalization Pipeline

Raw lists are messy. A builder needs a pipeline:

Ingest: Pull data from relevant authorities and commercial providers (Chainalysis, TRM, Elliptic).
Normalize: Convert names to a standard format (canonicalization) and wallet addresses to checksummed hex.
Commit: Build the cryptographic accumulator or Merkle Tree from this clean dataset.
Publish: Post the new "Sanctions Root" on-chain.

Sanctions Takeaway: The quality of your ZK proof depends entirely on the freshness and accuracy of this upstream data pipeline.

Compliance Infrastructure for List Ingestion

Building the "Oracle" that feeds the sanctions list to the smart contract is critical. This is the boring, unsexy part of compliance infrastructure that fails audits if ignored.

The Cryptographic Set Build

You cannot check the OFAC website inside a ZK circuit. You need a cryptographic representation of the list.

Merkle Tree: Good for updating, but proofs grow with list size.
Sparse Merkle Tree: Efficient for non-inclusion (proving an empty leaf exists).
Accumulators: (RSA/Boneh-Lynn-Shacham) Constant size proofs, but harder to update.

Your compliance infrastructure must compute this set every time the list changes (daily or hourly).

Versioning and Roots

Every time the list updates, the Root changes.

Transactions must reference a specific list_version.

Policy: "Transactions must use a Sanctions Root no older than 24 hours."
Mechanism: The smart contract stores a history of valid Roots.

If a user generates a proof against Root A, but the list updates to Root B before the transaction mines, the transaction might fail.

Compliance efforts must balance security (fresh lists) with UX (transaction stability).

Audit Trails for Regulators

Regulatory oversight requires you to prove which list you checked.

Your system must log:

"Transaction 0x123 validated against Sanctions Root 0xABC."
"Root 0xABC corresponded to OFAC List Version [Date]."

This links the on-chain math back to the legal requirement.

Non-Inclusion Proofs: The Technical Implementation

How do we actually build the "Not in Set" proof?

Merkle Non-Membership Patterns

In a sorted Merkle Tree (where leaves are ordered by value), proving non-membership is proving that your value $X$ falls between two existing leaves $A$ and $B$.

Logic: If $A$ and $B$ are adjacent in the tree, and $A < X < B$, then $X$ cannot exist in the tree.
Circuit Input: User provides $X$ (private), and the Merkle Path to $A$ and $B$ (public list data).
Circuit Output: True/False.

Address-Based Screening

This is the simplest implementation.

Set: All sanctioned wallet addresses.
User Input: Their wallet address.
Privacy: The user proves their address is not in the set.
Limitation: A bad actor can just generate a new wallet. Address-based screening is a game of whack-a-mole.

Identity-Based Screening

This is stronger but harder.

Set: Hash of (Name + DOB + Nationality) for all sanctioned persons.
User Input: Their verified credential containing (Name + DOB + Nationality).
Privacy: The user proves their identity attributes do not match any hash in the set.
Advantage: A sanctioned person cannot just create a new wallet; their bio-data remains sanctioned. This effectively stops sanctioned actors from hopping wallets.

Keeping Lists Current: Updates and Revocation

A static list is a non-compliant list. Compliance standards demand timeliness.

The Update Cycle

Trigger: OFAC adds a name.
Processing: The Screening Provider updates the tree.
Propagation: The new Root is pushed to the blockchain via a light client or oracle.
Client Sync: The user's wallet fetches the new sibling path needed for the proof.

Revocation at Scale

If a user is added to the list, their ability to generate a valid non-inclusion proof must die instantly.

Because the proof is mathematically derived from the current list, updating the Root automatically revokes access for the newly sanctioned address.

They literally cannot compute a valid path anymore.

This is a powerful feature of ZK compliance frameworks: revocation is enforced by math, not by a server admin flipping a switch.

Staying Agile

Crypto compliance teams need to stay agile. Lists change, regulations change, and algorithms change. Your tech stack should allow you to swap the underlying set structure (e.g., moving from Merkle Trees to Verkle Trees) without breaking the user experience.

Transaction Monitoring in the Digital Age

Transaction monitoring is a pillar of AML regulations. In a transparent world, this means tracing coin flows. In a private world, it changes.

Risk Assessment Without Surveillance

We move from monitoring the content of the transaction to monitoring the attributes of the participants.

Instead of scanning every transfer for illicit flows, we ensure that every participant has passed a recent risk assessment.

Risk Based Approach: High-value transactions require a proof against a stricter list (e.g., Global + Local lists). Low-value transactions might only check the UN list.
Signals: We can still monitor metadata. Is an account generating proofs at superhuman speed? Is the account interacting with high-risk contracts?

Monitoring Suspicious Transactions

Suspicious transactions are not just about who you pay; they are about behavior.

Financial institutions can require users to generate a "Compliance Proof" that attaches metadata (like country of origin) to the transaction in encrypted form.

This allows law enforcement agencies (with a warrant) to investigate suspicious activities without exposing all user data to the public.

Combating Financial Crime

ZK screening is a potent tool against financial crime. By making it impossible for sanctioned entities to interact with compliant pools, we shrink the liquidity available for money laundering.

We stop criminal proceeds from entering the clean economy.

False Positives: Dispute Workflows and Resolution

False positives are the bane of sanctions screening.

If your name is "David Smith," you might flag on a watchlist.

In a decentralized system, who do you call to get unblocked?

The "Step-Up" Review

We need a graduated flow that respects user privacy.

Initial Deny: The ZK circuit flags a potential match (fuzzy logic).
Escalation: The user requests a manual review.
Selective Disclosure: The user shares more data (e.g., Passport Number) with a trusted compliance provider via an encrypted channel.
Resolution: The provider confirms "This David Smith is not the terrorist David Smith."
Allowlist Credential: The provider issues a temporary "Exemption Token."

Audit Defensibility

This resolution must be logged.

Log: "Match flagged on [Date]. Resolved via Passport Check. Status: Cleared."
Privacy: The log does not contain the passport scan, just the result.

This provides compliant evidence for auditors while maintaining data minimization.

User Control

The user must be in control. They choose whether to escalate and share data.

If they prefer financial privacy over the transaction, they can walk away.

This empowers users control over their own sensitive information and customer information.

Access Control and Sensitive Information

Who holds the keys to the list?

Access control is vital for the compliance infrastructure.

Separation of Duties

The engineers managing the ZK circuits should not have access to the raw sanctions list mapping if it contains sensitive intelligence.

The Compliance Officer should not have write-access to the smart contract Roots.

Roles must be strictly defined.

Logging That Survives Scrutiny

Regulatory scrutiny is increasing.

Logs must be immutable and timestamped.

Good Log: "User 0x... checked against List v55. Result: Pass."
Bad Log: "John Doe (IP 1.2.3.4) checked against List v55."

Do not log sensitive information or customer information that isn't required.

Minimizing data reduces the risk of leaks and protects user privacy.

Operational Model for CASPs and Financial Institutions

For financial institutions entering digital assets, the operational model is key.

Who Runs What?

Screening Provider: (e.g., Chainalysis, TRM, Elliptic) Maintains the list, updates the Merkle Tree, handles the fuzzy matching logic.
CASP / Financial Institution: Integrates the API, defines the risk assessment policy (e.g., "Block high risk," "Flag medium risk").
Auditors: Verify the code and the process.

This ecosystem allows banks to use compliance standards they are comfortable with, adapted for crypto transactions.

Implementation Checklist

For builders implementing sanctions screening, follow this checklist:

List Versioning: Ensure every proof includes the list_version to prevent replay attacks with old lists.
Proof Scoping: Bind the proof to the specific transaction_hash or contract_address to prevent reusing a valid proof for a forbidden transaction.
Logging Minimisation: Do not log the user's inputs to the ZK circuit. Log only the output (Pass/Fail) and the metadata.
Break-Glass Access: Define a procedure for law enforcement access if a warrant is presented (e.g., View Keys).
False Positive Workflow: Build the UI for users to challenge a denial. Don't just show "Error."
Vendor Risk Controls: Verify your screening provider's uptime and data accuracy.
Stay Agile: Design the system to handle new sanctions regulations or changes in compliance standards.

Frequently Asked Questions (FAQ)

How does this fit with AML regulations?

AML regulations require risk-based controls to prevent money laundering. ZK sanctions screening satisfies the "Screening" component of AML by cryptographically ensuring no funds move to/from sanctioned entities. It supports a risk based approach by allowing different proof rigors for different transaction sizes.

Can ZK screening work for digital assets and crypto transactions?

Yes. It is specifically designed for digital assets. By embedding the check into the smart contract or wallet, it makes compliance native to the crypto transaction itself, rather than an external check.

How do you handle false positives?

Through a "step-up" process. If the automated ZK check fails (or flags a potential match), the user can perform a selective disclosure of specific attributes (like DOB or Country of Residence) to a trusted verifier to clear the match.

What does transaction monitoring look like without surveillance?

It focuses on "Compliance Verification" rather than "Activity Tracking." Instead of watching where the money goes, you verify that every participant in the flow is authorized. You monitor the validity of the proofs, not the content of the spend.

Is this compliant with the Bank Secrecy Act?

The BSA requires financial institutions to assist government agencies in detecting and preventing money laundering. By maintaining robust, auditable records of screening (even if the underlying identity is private from the public), institutions can fulfill their reporting obligations (SARs) when suspicious activity is detected, often using View Keys for specific investigations.

Does this eliminate the need for centralized compliance teams?

No. It changes their job. Instead of manual review of every transaction, they focus on managing the sanctions list, resolving false positives, and auditing the compliance infrastructure.

Conclusion

Sanctions compliance is a non-inclusion problem.

It asks the negative question: "Are you not a bad actor?"

Zero knowledge proofs offer the only path to answer this question without destroying the open, permissionless nature of Web3.

By proving "Not in List" cryptographically, we can stop illicit flows, block terrorist financing, and satisfy regulatory oversight—all while protecting the innocent user from mass surveillance.

We have solved Screening.

But what about the Transfer?

When you send money to another exchange, the law requires you to send the user's identity data with the money.

This is the "Travel Rule."

How do we do that without putting PII on the blockchain?

The Travel Rule Solved: Exchanging Compliance Data Without Doxing Users