Why blocking suspicious addresses breaks at scale
The first incident is usually closed manually: the address ends up on the blacklist after the funds have already left. While the list lives in a spreadsheet, every edit goes through a developer, and reviewing a request takes hours.
A manual blacklist handles the load while addresses number in the dozens—at hundreds, it becomes a bottleneck.
Then external risk-signal sources are connected: sanctions lists, analytics services, in-house heuristics based on wallet behavior. Each has its own format, confidence scale, and update rate, while consolidating them into a single decision remains with a human.
Incident response latency grows: the signal has already arrived, but a queue, approval, and deployment of changes stand between it and the block.
Circumvention of restrictions also breaks the logic of checks.
Funds are split, pass through intermediate addresses and exchange services—a direct lookup through the list does not see them, and blocking one address does not prevent the remainder from being withdrawn along the chain. The higher the stakes, the faster the scheme changes, and a static list stops keeping up with it.
At scale, the problem is not the absence of a list but the absence of a process: signal, risk assessment, automated decision, action log, and error review. That is why blocking suspicious addresses must work as a service with rules and metrics, not as a spreadsheet. Let's break down how this is addressed.
Operational effect: what changes in metrics after implementation
The key metric is the time from the first signal to the actual halt of withdrawal.
Before implementation, the signal went into the on-call queue, the on-call person manually checked the address against the database, and only then set a restriction: during that time, funds managed to pass through several intermediate wallets and leave the custodial perimeter.
A rule that links an address from the list with behavioral indicators—a fresh wallet, liquidity top-up, interaction with a mixing service—moves the account into "inbound only" mode automatically, and the gap between signal and block shrinks to seconds.
Precision of triggers is set by thresholds: a single name match does not block; the decision is made based on a combination of indicators, so the share of false restrictions drops, while real withdrawal attempts do not go through.
Coverage is wider than in manual mode—incoming, outgoing, and internal transfers between accounts are checked, not only amounts above a set limit.
A whole class of failures disappears: an incident in which withdrawal managed to occur before an analyst's decision.
The load on manual review changes as a result—automation closes typical triggers, and the specialist reviews only disputed cases where indicators contradict each other.
We calibrate thresholds using external risk data, including Chainalysis, and our own statistics: rules that generate noise are revised rather than accumulated.
Operating modes: manual rules, scoring, hybrid scheme
The detection and transaction-stopping mode is chosen not by how "smart" the model is, but by what matters more in your risk profile: response speed, explainability of the decision before review, or support effort. Below are three schemes and their limitations.
Static rules check an address against sanctions lists, an internal incident registry, and whitelists. The decision is deterministic: a match—the operation is stopped; no match—it proceeds.
The limitation is fundamental: the rule works only on known addresses, and a transfer is split into a chain of intermediate wallets before the address gets added to the list.
Behavioral scoring evaluates an address's connections, history, and transaction structure, so it catches unknown wallets by indirect indicators.
The decision here is probabilistic: thresholds and false-positive review are needed, and without explaining the indicators, a stop is hard to defend before a compliance review.
The hybrid scheme keeps rules as a hard barrier and applies scoring to the rest of the flow with configurable thresholds: below—pass, in the middle zone—manual review, above—automatic stop.
External databases such as Chainalysis are connected as an address reference, not as a ready-made policy.
| Mode | How it works | Strength | Limitation |
|---|---|---|---|
| Static rules | Matching against sanctions and internal lists | Instant response, decision is unambiguously explainable | Catches only known addresses, circumvention via a chain of transfers |
| Behavioral scoring | Evaluation of connections and transaction history by a model | Finds unknown addresses by indirect indicators | Requires a threshold and false-positive review |
| Hybrid scheme | Rules as a barrier, scoring on the rest of the flow | Combines speed and explainability | Requires regular retuning of weights and thresholds |
In practice, the mode is chosen by the cost of an error: where a miss is unacceptable, thresholds are tightened and the manual review zone is expanded.
How we implement blocking: from flow audit to handover of regulations
Blocking suspicious addresses is not a one-time list but a decision pipeline where every trigger has a reason, threshold, and owner.
We start with a flow audit: it is important to understand how many addresses and operations pass through control, with what delay, and what happens to the signal next.
- Flow audit. We record the volume of operations per day, bottlenecks, and the delay between a transaction and its assessment—this determines whether a separate review loop is needed.
- Risk source map. We consolidate sanctions lists, analytics service data, and internal incident reviews into a single map: each source has its own weight, update frequency, and cost of error.
- Logic configuration. We set thresholds, observation window, and reaction gradation—flag, send to manual review, or block. We separately define exceptions for treasury addresses so as not to stop our own operations.
- Historical data test. We run the rules on accumulated transactions and calculate the share of false positives and missed addresses. We adjust thresholds until the first drops and the second remains under control.
- Go-live. First, shadow mode: the system evaluates and writes a decision but does not block. After reconciliation with manual review, we enable real blocking and monitor the trigger flow daily.
- Handover of regulations. We provide documentation: logic design, response times to a trigger, appeal review procedure, list updates. After that, we review thresholds and sources—risks change.
What remains with you: configurations, access policies, regulations
Handover of the blocking system is not an archive with code but a working loop: your engineers can use it to spin up a test environment, reproduce rule behavior, and review an incident without us.
We record the package in your repository and documentation registry, with change history and an owner for each part.
- Rule configurations — risk model and trigger thresholds, profiles for production and test loops, procedure for rolling out a rule change and rolling back to the previous version.
- Integration scheme — connection points to analytics, nodes, and accounting systems, data exchange formats, behavior when an adjacent service is unavailable.
- Access policies — permission matrix: who proposes an address for blocking, who confirms the decision, who is authorized to lift the restriction.
- Operator roles — separation of duties for the on-call shift, analyst, and administrator, so that block confirmation does not depend on one person.
- System documentation — field and status reference, instructions for typical operations, diagram of how a decision flows from signal to enforcement.
- Appeal procedure — channel for receiving requests, response times, who makes the decision, how the restriction is lifted, and what goes into the log.
- Decision log — export of triggers and removals with grounds, so that the lawfulness of blocking is confirmed by data, not memory.
Before handover, we go through each item together with your team: we show where the artifact is stored, who owns it, and what to do if the configuration diverges from the documentation.
Case: how we reduced false blocks and response time
The client is a service with custodial storage and exchange, several thousand operations per day. Suspicious addresses were filtered by a single rule: a match with a sanctions or internal list meant manual stopping of the operation.
An analyst checked the address against open sources and Chainalysis logs, then an operator manually held the transaction—on average 40 minutes from signal to response.
Starting point
Every trigger went to manual review: 60-70 requests per week, more than a third false. Labels were applied without risk gradation, so a legitimate address that had once appeared in a transit chain received the same stop as an obvious mixer.
Disputed requests were handled by email, the response took up to three days, and some operations were canceled irrevocably.
What changed
We introduced a point-based risk assessment: an address receives weight based on independent indicators—direct match on a list, depth of connections, share of dirty volume, recency of connection. The threshold is divided into levels: monitoring, holding, blocking.
Holding is lifted automatically if the risk is not confirmed within a given window; blocking requires analyst confirmation, and every decision is written to an immutable log with justification.
Results
Incident response dropped from tens of minutes to 1-2 minutes—holding triggers at the transaction signing stage. The share of erroneous blocks fell from 34% to 5%: an address first goes into quarantine, where you can see which indicator affected it.
Manual review decreased almost threefold, and disputed requests became an order of magnitude fewer—the client sees the reason for holding and the time frame instead of a generic rejection wording.
How is a blacklist different from behavioral scoring?
A blacklist answers the question "we definitely know this address"—and therefore provides maximum explainability: a trigger references a specific entry in the list, not a guess.
The sources here are clear: regulatory and sanctions lists, addresses from incident reviews, confirmed wallets of seized funds.
The limitation is also predictable: an address that is not yet on the list will pass review, even if the funds left a wallet that was flagged last night.
Behavioral scoring works not with an identifier but with flow indicators: splitting an amount into parts, fan-out transfers to fresh addresses, short wallet lifespan, transit through already flagged clusters, a sharp change in geography.
Hence the coverage—unknown addresses are also monitored—but at the cost of false positives. An ordinary user with nonstandard activity may well look suspicious.
The choice of approach is a question of which error is more expensive in your scenario. For a payment acceptance service, a false block of an honest client costs trust and manual request review; for custodial storage, missing funds with a dirty history is more expensive.
Until the cost of both errors is fixed, the argument "list or scoring" remains a matter of taste.
In practice, the methods are combined into one scheme with different levels of reaction. A match with the list is a hard rule: block immediately, without thresholds.
Scoring provides a risk assessment, and that determines the action: pass, send to quarantine until review, request source-of-funds confirmation from the client, or reject.
Thresholds are calibrated on historical data so that the false-positive rate does not grow along with coverage.
A separate part of the scheme is the decision trail: which indicator triggered it, which analyst confirmed it, what was answered to the client, and how the address got into the list.
Without this, blocking turns into a black box, and every appeal becomes a manual search through logs. We assemble both layers together with the procedure for updating the list and reviewing disputed triggers.
Disputed cases and limitations: common technical questions
Disputed cases are inevitable: any risk scoring produces false positives. The question is not whether they will happen, but how long an address will remain under restriction and how quickly the request will be reviewed.
Therefore, the foundation is not a blacklist but a pipeline: signal → quarantine → review → removal or confirmation.
We outline the method's limitations upfront: the system sees on-chain behavior but does not know the reasons for a transfer, so the final decision on a disputed address remains with the analyst. If you already have your own address control deployed, we connect to it rather than replace it.
A legitimate address was stopped by mistake—what happens next?
First, quarantine, not a full stop: incoming transfers pass, outgoing are limited by a cap, and the client submits a request. Review follows the procedure—the analyst checks the signal sources, counterparty connections, and address history. Each removal refines the indicators, and the false-positive rate falls in subsequent periods.
Can an address be partially restricted instead of fully blocked?
Yes: freezing only outgoing transfers, a limit on amounts per period, stopping one route while others work, prohibiting interaction with a specific address cluster. Partial blocking leaves a legitimate user with access to the service and prevents withdrawal of funds. For medium-risk addresses, this is the default mode.
How does the loop behave under peak load?
Risk assessment runs asynchronously from operation intake: priority queues, recalculation only of affected addresses, verdict cache. At peak, the system degrades to recording signals—operations do not stop, and verdicts are calculated afterward.
We capture verdict latency and the share of deferred decisions as separate metrics so that degradation is visible before complaints.
Let's discuss the task: what to prepare for an accurate estimate
So that the project estimate is based on facts rather than assumptions, your free-form description is enough—no need to prepare formal requirements and documents.
The more precisely flows and current rules are defined, the less buffer we include in the work plan and the fewer edits surface at the start.
- Flow description: where addresses come from for review—client wallets, exchange deposits, payment acceptance gateways, internal transfers; daily volume and its peaks.
- Data sources for risk assessment: your own lists, external metrics providers, public registries, investigation materials—what is already connected and in what form the verdict arrives.
- Current rules: by which indicators an address is currently deemed suspicious and where this rule lives—in code, configuration, or in the head of the analyst manually processing the queue.
- Decision points: what happens to a transaction—blocking, quarantine, manual review, notification only; who lifts a block and on what grounds.
- Roles and access: who initiates, approves, and cancels a decision, what data must remain in the log for subsequent review.
- Integration boundaries: which systems must receive the verdict—processing, back office, client interface, regulatory reporting.
- Constraints: acceptable response latency in the flow, retention depth for decision history, system behavior when an external metrics provider is unavailable.
Once this is assembled, we come back with an estimate, a data flow diagram, and a phased work plan. Then we agree on priorities, launch order, and work start.