Wallet and transaction screening

Name screening tells a firm who its customers are; wallet screening tells it where their money comes from and goes to. On a public blockchain a single deposit can carry funds that left a designated address minutes earlier, and a single withdrawal can deliver value straight to one. This lesson covers how to screen addresses and transfers for sanctions exposure, how to set hop limits and thresholds, and what to do when designated funds actually arrive.

Two sources of address risk

Wallet screening draws on two different kinds of data.

List addresses are virtual asset addresses published by an authority as identifiers of a designated party. A match is binary and authoritative: the address belongs to someone the firm may not deal with.

Analytics-attributed exposure comes from blockchain analytics: clusters of addresses attributed to a designated person or service, and transaction tracing that measures how much of a transfer's value can be linked to them. It covers far more ground than lists, but it is probabilistic. Attribution can be wrong or out of date, and different tools can disagree. The IDFE-BA lessons Attribution and labeling and Evaluating cluster quality explain why; the lesson Blockchain analytics for compliance covers validating analytics output.

A sound program uses both: list addresses for certainty, analytics for reach, and a record of which source drove each decision.

Direct and indirect exposure

Direct exposure means the counterparty address of a transfer is itself a designated address or belongs to a designated cluster. Indirect exposure means the funds passed through one or more intermediate addresses between the designated source and the transfer. Analytics tools usually express indirect exposure as a share of the transfer's value and a number of hops, counted here as the intermediate addresses or entities between the designated source and the transfer. Tools count hops differently, so the firm's configuration should state its convention.

Indirect exposure weakens with distance and mixing. A deposit that received 80% of its value from a designated exchange one hop earlier is a very different case from one where 0.5% of the value is traceable to a designated mixer six hops back. How the share is computed also depends on the tracing method (see the IDFE-BA lesson Tracing funds forward and backward), so the method should be part of the firm's documented configuration.

Hop limits and thresholds

Rules turn exposure into actions. They must be calibrated to the firm's risk assessment and written down. An illustrative policy:

The percentages and hop counts above are examples, not standards. A firm sets them by testing against known cases, documents why, and reviews them as typologies change. A rule that alerts on any indirect exposure at any distance will drown analysts; one that ignores indirect exposure entirely will miss nested services and laundering one step removed from the list.

The following rule finds pending deposits that the policy says must be held:

-- Pending deposits with direct sanctions exposure or high indirect exposure
SELECT d.deposit_id, d.customer_id, d.txid, d.amount_usd,
       e.exposure_type, e.min_hops, e.sanctioned_share_pct, e.source
FROM deposits d
JOIN sanctions_exposure e
  ON e.txid = d.txid AND e.output_index = d.output_index
WHERE d.status = 'PENDING_CREDIT'
  AND (e.exposure_type = 'DIRECT'
       OR (e.min_hops <= 2 AND e.sanctioned_share_pct >= 10.0))
ORDER BY e.exposure_type, e.sanctioned_share_pct DESC;

The query joins each pending deposit to the exposure record produced by the analytics process, using the transaction ID and output index so that only the customer's own output is considered. It selects every direct case and every indirect case within two hops at or above 10% of value, and sorts direct cases first. The source column records whether a list address or an analytics attribution produced the exposure, which the analyst needs when deciding. On account-based chains the output index is replaced by a log or transfer index.

Pre- and post-transaction screening

The direction of a transfer decides what screening can achieve.

Outgoing transfers can be screened before they happen. The destination address is screened at the moment the customer submits the withdrawal and again just before broadcast, because lists can change in between. A match stops the transfer: once broadcast and confirmed, it cannot be recalled.

Incoming transfers cannot be refused at the protocol level. Funds arrive at the customer's deposit address whether the firm likes it or not. Screening therefore happens after arrival but before credit: the deposit stays in a pending state until screening clears it. Where a Travel Rule message arrives before the transfer, the originator data and source address can be screened in advance, and the firm can ask the originating VASP not to send.

Funds from a designated address: freeze and report

When a deposit arrives directly from a designated address, the instinct to "send it back" is wrong. Returning the funds would make assets available to a designated party, which is exactly what the prohibition forbids. The usual procedure is:

1. keep the deposit uncredited, or move it to a segregated wallet controlled by the firm and recorded as frozen;
2. restrict the customer account pending review;
3. confirm the match with the sanctions officer, recording the list entry or attribution, the txid and the amount;
4. report the frozen assets to the competent authority within the period its regime sets, and file a suspicious transaction report with the financial intelligence unit where there are grounds;
5. release or move the funds only on written instruction or license from the authority.

Not every deposit from a designated source makes the customer a wrongdoer. After high-profile designations, unknown parties have sent small amounts from designated addresses to well-known wallets, a practice called dusting. The dust itself is still frozen and reported, but the customer's account should be judged on the whole picture, not automatically closed.

A worked case

A retail customer, onboarded eight months ago with a modest trading history, receives a deposit of 2.4 ETH from an unhosted wallet. The exposure engine reports indirect exposure: 35% of the value is traceable, one hop back, to a cluster attributed to a designated exchange. Under the policy above this is a hold.

The analyst works through the case:

1. Check the source. The attribution comes from analytics, not a list address. The analyst checks the cluster's label history and finds it has been stable since before the designation, which supports the attribution.
2. Look at the intermediate wallet. It received funds from the designated cluster two hours before forwarding them to the customer, and has no other activity. That pattern points to a pass-through, not an unrelated third party.
3. Ask the customer. A request for information asks who sent the funds and why. The customer says a friend repaid a loan, but cannot explain the friend's use of the designated exchange.
4. Decide. The sanctions officer concludes that the funds are likely to be derived from a designated party's assets. The deposit stays frozen, the account is restricted, the freeze is reported to the competent authority, and a suspicious transaction report is filed.

Had the intermediate wallet been an established wallet with years of varied activity, and the designated share small, the same rule might have ended in release with enhanced monitoring. The record should show which facts tipped the decision.

Smart contracts as sanctioned objects

In August 2022 the United States designated the Tornado Cash mixer under its sanctions program, listing its smart contract addresses rather than a person or company. This raised new questions: whether code can be "property", whether interacting with an immutable contract is "dealing", and how to treat users who had funds in the pool. In November 2024 a US appeals court held that the immutable contracts were not property that could be blocked, and the designation was lifted on 21 March 2025.

The episode left three practical lessons. Screening must cover contract addresses, including router and pool contracts, and not only externally owned addresses. Withdrawals from a designated pool are direct exposure while the designation stands, even when the customer is the original depositor. And a delisting removes the sanctions prohibition but not the money-laundering risk: mixer exposure remains a high-risk indicator in monitoring and customer risk scoring.

Exam focus: list addresses versus analytics-attributed exposure and why both are needed; direct versus indirect exposure, hops and value share; designing and documenting hop-and-threshold rules; pre-transaction screening of withdrawals (screen at submission and before broadcast) versus screening deposits before credit; why funds from a designated address are frozen and reported, never returned; dusting; Tornado Cash as context for smart contracts as sanctioned objects and for the difference between delisting and residual risk.