Wallet screening and crypto risk

Screen a blockchain address for on-chain exposure - sanctions, illicit sources, and high-risk counterparties - either coupled to a transaction or on demand.

Written by Didit Support · Updated 19 August 2026

#What it tells you

123

1. Installed rules are the ones currently deciding your transactions.
2. Library rules are ready-made starting points you can install.
3. Create rule builds one from scratch - for example, block above a risk score.

Screening a person against sanctions lists and screening a crypto address are different problems. A name-based screen asks whether the individual is listed. Wallet screening asks where the money has been: whether the address has exposure to sanctioned entities, illicit services, mixers, or other high-risk counterparties, traced through on-chain activity.

You get back a risk score and severity, plus breakdowns of source of funds and destination of funds - the categories of counterparty the address has received from and sent to.

#Coupled or on demand

Two ways to use it:

• Transaction-coupled. The address is screened as part of evaluating a transaction, so the rules can act on the result in the same pass.
• On demand. Screen an address on its own - before accepting a deposit, when onboarding a wallet, or while investigating a pattern after the fact.

#Direction matters

Whether an address is the sender or the receiver changes what the risk means, and it can change what the analytics provider returns for source and destination exposure. An inbound transfer from a high-risk source is a different problem from an outbound transfer to one, and your rules should usually treat them differently rather than applying one threshold to both.

#Bring your own provider key

If you already hold a contract with a blockchain-analytics provider, you can plug your own key in and pay $0.02 per lookup instead of $0.15 - Didit does the routing and normalisation, and the lookup runs on your provider account.

The providers available in the console Marketplace are listed there; which ones fit your existing contracts is worth checking before you assume. See wallet screening.

#Chain and token coverage

Coverage depends on the analytics provider behind the lookup, not on Didit, and it varies by chain and token standard. If you need a specific chain - and this comes up most for the less-covered ones - confirm it against the provider rather than assuming a major chain implies its token standards.

#Enabling it

Wallet screening is enabled per organization. If the console shows it as unavailable, ask support to confirm the state of your account rather than debugging your integration - it's frequently an account-level switch rather than anything in your code.

#Reading risk levels honestly

Two traps worth naming:

• UNKNOWN is not LOW. An unknown risk level means there wasn't enough data to assess the address - a brand-new wallet with no history, for instance. Treating that as low risk is a decision you should make deliberately, not by accident of mapping.
• A risk score is exposure, not guilt. An address that received funds two hops from a mixer is not necessarily its owner's fault. Score-based rules should reflect how many hops and what proportion, which is what the source-of-funds breakdown is for.

#Not the same as Travel Rule

Wallet screening tells you about risk. Travel Rule is a separate obligation about exchanging originator and beneficiary information with the counterparty institution. They often apply to the same transfer and are billed separately. See Travel Rule.

#What it costs

When a Travel Rule transfer needs a wallet lookup to identify the counterparty institution, that lookup is billed once at the screening rate - never twice when crypto monitoring already screened the same address on the same transaction.