Wallet screening for incoming stablecoin payments: what it checks, when it runs, and what to do on a hit

Wallet screening is the check an institution runs on a blockchain address before it accepts value from that address or sends value to it. The screen asks three questions: is the address itself on a sanctions list, has the address received or sent value to known illicit sources such as mixers, stolen funds or darknet markets, and does the address cluster with an entity the institution already knows or has already blocked. It runs before an incoming transfer is credited to a client and again before any outgoing transfer is signed, and each run leaves a record that an examiner can read. This article covers what the screen checks, when it runs, what counts as a hit, what must happen after one, and how to evidence the whole process.

What does a wallet address screen actually check?

The first check is a direct list match. The United States Treasury's Office of Foreign Assets Control began adding digital currency addresses as identifiers on Specially Designated Nationals entries in 2018, and other authorities have followed. A direct match means the specific address in front of the analyst appears on a list, and it is the simplest and rarest outcome. The second check is exposure analysis. The screening vendor traces the address's transaction history and reports the share of value that has passed, directly or through intermediate addresses, from categories such as mixing services, funds stolen in exchange hacks, darknet marketplaces, ransomware payment addresses, sanctioned exchanges, gambling services and fraud schemes. Each category is reported with a value share and a hop count.

The third check is clustering. Vendors group addresses that are controlled by the same entity using heuristics such as common spending behaviour and known deposit patterns, and label the cluster where they can, for example a named exchange, a named custodian or a service that has been identified in enforcement actions. A clean address that belongs to a cluster already blocked by the institution is not clean. The screen therefore returns three things per address: any list match, an exposure profile by category with hop depth and value share, and a cluster attribution with the vendor's confidence in it. The institution's policy decides what to do with each, and the vendor does not make that decision.

When should the screen run?

Three points in the flow, and the result at each point is recorded separately because the answer can change between them. The first is registration. When a client registers a counterparty address, whether a beneficiary wallet for payouts or a source wallet for receipts, the address is screened before it is added to the allow-list, and a hit stops the registration. The second is before acceptance. When an incoming transfer arrives at the institution's receiving address, the originating address is screened before the value is credited to the client's balance. The transfer has already landed on chain and cannot be refused, but the credit to the client can be withheld, which is the point at which the institution still has a choice.

The third is before release. Before an outgoing transfer is signed, the beneficiary address is screened again even if it was screened at registration, because list updates and new exposure can occur between the two events. Screening before signing rather than after broadcasting is the difference between a control and a report. Two further runs are good practice rather than mandatory: a periodic re-screen of the allow-list against updated lists, and a re-screen of a client's historic counterparties when the client's own risk rating rises. Where the platform screens at receipt of the payment instruction as well as before release, the pacs.008 is held with a pending status in the pacs.002 until the decision is made, and the originator sees a pending report rather than silence.

What counts as a hit, and what does not?

A screen without a written decision rule produces alerts, not decisions. The rule must be set before the first alert and must distinguish direct from indirect exposure. Direct exposure means the address transacted with the illicit source itself. Indirect exposure means value reached the address through one or more intermediate hops, which is common for any address that has interacted with a large exchange, because exchanges receive value from everyone. Treating all indirect exposure as a hit would block almost every address; ignoring it would let a structured chain of hops defeat the control.

• Any direct match against a sanctions list, or a cluster attributed to a sanctioned entity, is a hard hit and is blocked without analyst discretion.
• Direct exposure to stolen funds, ransomware or darknet categories above a low value share set in the policy is a hold for analyst review.
• Indirect exposure is scored against a hop depth and value share threshold written in the policy, for example exposure within a small number of hops above a stated percentage of received value, and only exposure above both thresholds becomes a hold.
• Exposure to a mixing service is treated on its own line, because the sanctions status of individual mixers has changed over time and the policy must say whether unlisted mixers are a hold or a note.
• A cluster attribution to a regulated exchange or custodian with high vendor confidence is a mitigating factor recorded on the case, not a reason to skip the other checks.
• A vendor confidence score below a stated floor means the finding is escalated to a senior analyst rather than automatically actioned.

The mixer line deserves care. Tornado Cash was designated by OFAC in August 2022 and removed from the list in March 2025 following litigation, so a rule that hard codes a specific service will be wrong at some point. The rule should reference the category and the current list, and the analyst record should show which list version was in force at the time of the decision.

The screen does not decide anything. It hands an analyst a fact pattern, and the policy decides. If the policy is not written down, the vendor's default settings have become the policy.

What must happen when a screen hits?

On a hard sanctions hit on an incoming transfer, the value is blocked. It is not credited to the client and it is not sent back to the originating address, because returning funds to a sanctioned person is itself a prohibited transaction. The blocked value sits in a segregated address under the institution's control, and a blocked property report is filed with OFAC within ten business days, which is the reporting requirement under OFAC's regulations. In Canada, a reporting entity that determines it holds property owned or controlled by a listed person must report to the RCMP and CSIS and, under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act, file a terrorist property report with FINTRAC. The client is told that the transfer is held; the client is not told why in a way that would constitute tipping off.

On a hold for exposure, the analyst works the case in the compliance workbench: reviews the exposure graph, requests source of funds information from the client where appropriate, checks whether the counterparty is a known and documented business relationship, and records a decision to release, reject or escalate. A second analyst approves any release. A rejection on an incoming transfer means the value is returned to the originator through a documented process, with the outgoing return itself screened, and the pacs.004 return references the original UETR. Where the pattern is suspicious, a suspicious activity report is filed with FinCEN within thirty calendar days of initial detection, or a suspicious transaction report with FINTRAC as soon as practicable, and the decision to file or not to file is itself recorded with reasons.

How do you evidence wallet screening for an examiner?

The examiner will pick transfers and ask to see the screen for each. The record per transfer must show the vendor used, the address screened, the timestamp, the list versions in force, the risk categories reported with hop depth and value share, the cluster attribution and confidence, the rule in the policy that fired or did not fire, the analyst's decision and reasons, the second approver on any release, and the filed reports where a hit led to one. The record must exist for clean results as well as hits, because the examiner's first question is whether screening ran on every transfer, and the second is what happened when it fired.

Beyond the per transfer record, the examiner asks for the policy with its thresholds and the date each threshold was set, the vendor due diligence file including coverage of the chains and tokens the institution settles on, the alert statistics by category and outcome, the quality assurance sample showing that decisions were reviewed, and the training record of the analysts. Retention is at least five years in both the United States and Canada. A platform that writes the screening result into a tamper evident audit trail against the UETR, alongside the pacs.002 status and the on chain hash, allows the whole file for one transfer to be produced from a single query rather than assembled from vendor exports and email.

Where StableNet fits

StableNet, built by SpendTheBits, settles cross border B2B payments in regulated stablecoins such as USDC and USDT on public blockchains, and wallet screening is built into the settlement flow rather than bolted on beside it. Addresses are screened at registration, before an incoming transfer is credited and before an outgoing transfer is released, and every result is written to a tamper evident audit trail against the UETR of the ISO 20022 instruction, so that the pacs.008, the pacs.002 status, any pacs.004 return, the on chain hash and the screening record for one payment sit together. Held items are worked in the compliance workbench with four eyes release, alongside KYT, sanctions and PEP screening and Travel Rule data in IVMS101 form. Customers keep custody of their wallets throughout. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.