Blockchain transaction monitoring: blind spots and false positives
A signal about a suspicious operation arrives with a delay: a transaction is considered confirmed only after inclusion in a block, and rules trigger after the fact — when funds have already passed through two or three intermediate addresses.
The window between the first operation and notification is measured in tens of minutes, and during this time withdrawals can be split across wallets.
Some fund movement paths do not enter the analysis at all.
Internal smart contract transfers, operations via cross-chain bridges, movements within exchange wallets, and splitting into address clusters are visible only when analyzing the on-chain graph as a whole, rather than by subscribing to individual addresses.
A separate problem is false positives. Threshold rules from ready-made sets produce an avalanche of alerts: when nine out of ten signals are not confirmed, the duty officer stops reacting to the feed, and a real incident drowns among identical “checked” marks.
The cost of such an error is not a tired analyst, but a missed withdrawal of funds and claims from the regulator, who needs a reproducible trail for every check.
We build a framework in which rules describe your risk profile rather than come out of the box: risk-profile assessment of addresses, prioritization by amount and connections, separate scenarios for bridges and internal contract calls.
We consolidate findings from Chainalysis and our own checks into a single list with a transparent trigger threshold. How this closes the delay and blind spots — we break down below.
Streaming transaction monitoring: what changes in metrics
The effect of streaming monitoring is assessed by four values: delay from operation to signal, share of covered fund movement scenarios, number of false positives, and control downtime.
Before implementation, they are usually not measured — there is a daily export and manual review of addresses.
Reaction speed: from operation to signal
Analysis runs along two perimeters: the mempool gives a signal before an operation is included in a block, and block subscription gives a confirmed fact. The first is needed where an outgoing transfer can still be stopped, the second for analysis and reporting.
The path from operation to notification is reduced from hours to seconds, and for confirmed data — to one block interval.
Scenario coverage completeness
Address-based rules cover direct transfers to sanctions lists. The rest is caught by the graph layer: splitting of amounts, transit wallets, exchange for other assets, cross-bridge transitions, and return of funds through intermediate links.
Heuristics flag what is suspicious, the analyst confirms or removes the flag — coverage grows from tens to hundreds of scenarios, and every flag retains a trace of the fund path.
False positives are reduced not by the threshold but by weighted scoring: amount, frequency, counterparty novelty, proximity to a flagged cluster.
Control downtime is covered by node replicas and a degradation mode to rules without the graph — unavailability is measured in minutes, not days.
Each case goes into a card with the address, fund path, and analyst decision, so investigated incidents stop getting lost between shifts.
Chainalysis and similar tools set the industry benchmark for labeling — we use it as a reference, and build case storage around the customer’s access requirements.
Methods for detecting suspicious operations: comparison of approaches
No single method covers the task entirely — options are compared by reaction delay, depth of history, and scope of maintenance. Below are the alternatives that are actually chosen between.
| Option | When it fits | Limitations |
|---|---|---|
| Streaming analysis | Reaction at the moment an operation is included in a block: exchanges, payment gateways | Requires a stable event channel and in-house processing; a gap in the stream cannot be recovered |
| Periodic export | Reporting, post-factum incident investigation, historical archives | Verdict lags by hours, not suitable for blocking an operation |
| Node-level rules | Flagging or blocking addresses, thresholds by amount and frequency | Rule set grows and conflicts; bypassed by splitting amounts |
| External analytics service | Address labeling and risk scoring are needed without in-house expertise | Dependence on someone else’s model, request delay, limitations on history depth |
Node-level rules
The first filter: address checks against lists, thresholds by amount and frequency, and a ban on contracts without confirmed logic.
They trigger on the incoming stream and do not depend on external systems, but catch only the signs you described yourself — new schemes require manually adding rules.
External analytics services
They return address risk scoring and connections to already flagged clusters.
A request is made for each address, so in the stream it is supplemented with a cache of verdicts and asynchronous loading: the operation passes through node-level rules, and the assessment is refined by the service response. Divergence of verdicts is a reason for manual review, not automatic blocking.
In practice, perimeters are combined: streaming analysis as the main one, periodic export for reconciliation and reporting, external scoring as a refinement layer. Which of these you need depends on whether you block an operation or only flag it for investigation.
Implementation stages: from flow audit to handover of regulations
Transaction monitoring is not switched on all at once: too broad a rule set produces a stream of false signals, and analysts stop looking at the queue.
Therefore implementation proceeds in stages — from inventorying flows to regulations by which the service continues to work without us.
Audit of flows and current rules
First we record where the data comes from: network nodes, internal registries, exchange exports, external sources of risk labels. In parallel, we analyze what is already checked manually and why these checks trigger or miss what matters.
- Flow audit: sources, arrival frequency, field completeness, delay until an operation appears.
- Coverage scheme: which operations, addresses, and counterparties are under control, and which are outside the perimeter.
- Setup of data collection and analysis: a unified model, loading of gaps, integrity control.
- Detection scenarios: thresholds by volume and frequency, connections between addresses, deviations from the profile.
- Testing on historical data: running rules on past periods, measuring false signals.
- Access restriction: roles of analysts and the security service, action log, rights to edit rules.
- Handover of regulations: rule description, signal investigation procedure, escalation criteria, updates.
Testing on historical data
We run the rules on accumulated history and compare with completed investigations. This shows which threshold produces more false positives and which produces misses, and thresholds are tuned before being included in the working queue.
After handover, the customer’s team changes thresholds and adds scenarios independently — without contacting us.
Handover package: configurations, schemes, response regulations
The handover package is not a final report but working artifacts with which your team continues independently. Everything sits next to the rule code, is versioned, and is deployed according to instructions, not “from memory of the engineer” who has already left the project.
- Rule configurations: trigger thresholds, address lists, risk scoring weights — with change history and rollback to the previous version.
- Fund movement scheme: graph of address connections, entry/exit points, and service clusters, updated on a schedule.
- Access matrix: roles are tied to actions, not job titles.
- Response regulation: trigger levels, response times, who decides to suspend an operation, notification templates.
- Operational documentation: deployment, backup, recovery, rule update procedure.
- Test set: labeled historical operations on which a new rule is tested before being put into production.
Access matrix
An analyst sees operation cards and labeling, the duty officer can suspend a withdrawal, and an administrator changes thresholds and lists. A rule change goes into the log with author and reason — during incident investigation it is clear who weakened control and why.
Operational documentation
Instructions for deployment, list updates, and recovery after a failure, plus the procedure for investigating false positives. The document lives together with the rule code, so it does not diverge from the actual system state.
Implementation case: share of detected operations tripled
A digital asset exchange operator came with two disconnected control perimeters: rules in an analytics panel and scheduled exports into spreadsheets. Signs were added after investigation — a scheme entered the rules only after someone had already passed through it.
Initial state
A signal fell into a common chat, and the duty officer manually collected the transfer history of an address in network explorers, then spent just as much time on queries to label databases. The investigation queue by the end of the night shift grew faster than analysts could close it.
| Metric | Before | After |
|---|---|---|
| Share of detected operations | 29% | 87% |
| Time to signal | 55 min | 2 min |
| False positives per day | 140 | 22 |
| Incident investigations per analyst per shift | 24 | 6 |
What changed in the duty shift’s work
Rules and the risk model were placed in one queue: the former catch formal signs, the latter catch deviation of an address’s behavior from its own history, and feature labeling was aligned with FATF recommendations.
A connection graph several hops deep and an evidence base are attached to the signal card — transaction export, counterparty labels, history of prior touches. The analyst makes a decision from a ready picture rather than collecting data.
“The shift was drowning in routine: half the time went to data collection. Now the duty officer sees why the system raised a flag and closes the request with a clear justification.”
Customer assessment: the load on the duty shift decreased, incident investigation became predictable, and the share of detected operations tripled.
What to do if your own transaction control system is already running on the network?
A running transaction control system is not something you switch off for a new one.
It holds current processes and accumulated decisions, so integration starts with parallel operation: the same stream of operations is processed by both systems, the old one continues to flag and notify, the new one only counts and writes to a separate log. No signal is lost, and the impact on customers remains zero.
History preservation is handled by transferring accumulated logs as they are — with original labels, trigger reasons, and final operator decisions.
This provides material for running the new logic over the past: it shows where it would have found what the old one missed and where it would have triggered unnecessarily. Without such a run, comparison is blind.
Next is comparison of results in parallel mode. Discrepancies are analyzed by class: misses, false positives, threshold differences, different interpretations of the same signs.
In practice, discrepancies concentrate in several scenarios rather than being spread across the entire stream — these become the subject of rule reconciliation.
Rule reconciliation means that thresholds, address lists, and feature weights are aligned, duplicates are removed, and disputed rules remain in exactly one system with a clearly assigned owner.
Each change is versioned and rolled back independently; otherwise parallel operation becomes uncontrolled.
The gradual transition happens not all at once but by groups: by operation types or customer segments. Your own control system remains the main perimeter until the new one produces no fewer triggers with a lower share of false positives. Then the stream switches over, and the log remains unified — history is not broken at any stage.
Technical questions: false positives and data privacy
False positives are the main reason implemented monitoring gets switched off: the case queue grows faster than an analyst can investigate it, and with rough rules, splitting an amount into dozens of small transfers and transit through a chain of intermediate addresses slips through.
The working point is found by calibration on your operation history, not by substituting typical values.
How are trigger thresholds configured and what to do about noise?
The threshold is set separately for each rule: amount, number of operations per window, speed of fund movement along an address chain, share of incoming from high-risk addresses.
A trigger can be marked as false — the labels go into recalibration, the noise share decreases, and the threshold itself remains explainable to auditors.
What happens to data privacy and personal information?
Monitoring is built on public data: addresses, amounts, times, and operation hashes. Customer personal data remains in your perimeter and enters the risk model only as depersonalized features; deployment is inside your infrastructure, without exporting operations outside.
How are restrictive lists connected?
Lists are connected as a separate source: addresses are normalized to a unified form and updated on a schedule; inclusion in the list gives the maximum risk level regardless of amount. The log records which version of the list triggered the block.
Who gets access to data about suspicious operations?
Access is delimited by roles: an analyst sees the case and address connections, a manager sees the summary and investigation statuses. Opening an operation card is recorded, so it is always possible to reconstruct who viewed data and when.
Can a proprietary network be connected?
Monitoring is not tied to a single blockchain: for a new network, the data source and operation analysis rules are described, and then it works under the common risk model. A proprietary or private network is connected the same way — node access is sufficient.
Let’s discuss the task: what is needed for an assessment and plan
To return with an assessment and plan rather than generalities, we need to see how your transaction control is structured now.
The more specific the input data, the more accurately we determine the scope of work: which addresses and contracts are in the focus area, which events are considered suspicious, and who reacts to a rule trigger and how.
- List of networks and assets to be covered by monitoring, including test perimeters.
- Network access: own nodes or external data providers, access keys, read-only rights — we do not require transaction writing or signing.
- Current control processes: existing rules and trigger thresholds, who investigates alerts and what happens to them next.
- Description of suspicious scenarios: amount splitting, fan-out transfers, operations with addresses from sanctions lists, anomalies by time and frequency.
- Reporting requirements and history retention depth — from internal regulation to regulator requests.
- Where to send alerts: email, messenger, ticketing system, or your internal portal.
- Volumes: approximate number of transactions per day and history depth to load at start.
Describe the task as it is now — some data is usually clarified during the conversation, and that is normal. We will return with an assessment, stage plan, and a list of risks we see in your scheme.