What Wallet Screening Checks — Two Distinct Layers
Wallet screening is not a single check but two overlapping verification processes that serve different purposes. The first is sanctions screening: the wallet address is checked against official sanctions lists — OFAC SDN, EU Consolidated, UN, and national lists — to determine whether the address itself has been formally designated as a blocked entity. This check is binary: an address on a sanctions list must be blocked; an address not on any list passes this layer.
The second is blockchain analytics risk scoring: the wallet address is submitted to a risk intelligence database that analyses the address's transaction history and connections to known risk-associated addresses. This produces a risk score representing the proportion of the address's funds that can be traced — through direct connections or chains of transactions — to high-risk sources such as darknet markets, ransomware wallets, mixing services, or exchange hacks. This is a probabilistic assessment, not a sanctions designation, and it provides a risk gradient rather than a binary pass/fail.
When Screening Occurs in the Payment Flow
Timing of wallet screening affects both its effectiveness and its operational impact. The two primary points at which gateways screen are:
● Pre-payment invoice creation screening: When a customer provides a 'refund address' or when a known counterparty address is associated with an account, screening occurs before any payment is requested. This is most relevant in contexts where the customer's wallet address is known before the transaction begins.
● Post-detection incoming payment screening: When an incoming transaction is detected to a gateway monitoring address, the sending wallet address is screened before the merchant's account is credited. This is the primary operative screening point for most payment gateway workflows — the customer's sending address is extracted from the blockchain transaction data and screened as soon as the payment is detected in the mempool.
A third timing point — periodic re-screening of existing customer wallet addresses — is relevant for ongoing relationships where a customer's wallet may come into contact with risk-associated addresses after initial screening. Gateways with periodic re-screening can catch risk changes in existing customer wallets rather than relying solely on onboarding-time or transaction-time checks.
Risk Score Thresholds and Transaction Handling
|
Risk Score Range |
Typical Interpretation |
Gateway Action |
|
0–15% |
Low risk — standard clean wallet history |
Auto-approve and process |
|
15–30% |
Moderate risk — some indirect exposure |
Process with enhanced monitoring flag |
|
30–60% |
Elevated risk — meaningful exposure to high-risk sources |
Hold for compliance review; request source of funds |
|
60–80% |
High risk — significant direct or indirect exposure |
Block pending manual review; likely rejection |
|
80–100% |
Critical risk — direct connection to sanctioned or criminal wallets |
Block transaction; freeze pending compliance action; SAR consideration |
Screening Coverage Across Networks — Quality Differences
Blockchain analytics coverage — the depth and accuracy of risk attribution databases — varies significantly across different blockchain networks. Bitcoin and Ethereum have the most comprehensive coverage: years of analytical work by Chainalysis, Elliptic, and TRM Labs have built attribution databases that classify the majority of active Bitcoin and Ethereum addresses. Tron has growing coverage but is less complete, meaning that some high-risk wallets on TRC-20 that would be flagged on Ethereum may not be identified. Privacy coins like Monero are largely opaque to standard analytics tools due to their cryptographic privacy features.
Gateways should maintain documented analytics coverage standards per supported network and disclose to merchants which networks have full analytics coverage versus limited coverage. Accepting payments on a network with limited analytics coverage does not mean the compliance requirement is waived — it means the gateway must apply compensating controls such as lower per-transaction limits, enhanced customer verification, or restricted merchant category acceptance for that network.
Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.