The Short Answer
You will not get false positives to zero. What works is three levers. Tune direction rules and thresholds to your actual business, govern the whitelist like the risk control it is. And route alerts by severity so senior hands touch the dangerous ones first. The goal is hours on high risk alerts, not an empty queue. The VASP compliance hub collects the related guides.
A system that never fires misses real cases; a system that fires on everything buries them. The answer is not a quieter engine but a better operated one: change a little, write it down, review on a schedule, measure whether it worked.
The three levels, with the discipline that keeps each one safe:
| Level | Lever | The discipline that keeps it safe |
|---|---|---|
| 1 | Tune direction rules and thresholds | One change at a time, each logged with its reason |
| 2 | Govern the whitelist | Written criteria, an owner, expiry, quarterly re-justification |
| 3 | Route by severity | A written routing table, before the queue is on fire |
This page is for teams whose monitoring already runs. If you are still wiring checks in, start with the transaction monitoring guide.
Why False Positives Are Structural
False positives are a cost of broad detection rules: missing a sanctioned payment can have serious consequences, while a false alert consumes analyst time. Wider rules can reduce missed-risk exposure but cannot guarantee zero omissions. The useful baseline is your own measured alert workload, not an unverified percentage or a fixed handling time.
The regulator's side supports this. The FATF's risk based approach for virtual asset businesses expects controls proportionate to risk: tuned rules, documented rationale, periodic review, not maximum firing on everything. Done with records, tuning is compliance working as designed.
Level 1: Tune Direction and Thresholds
Direction rules decide what your monitoring looks at; thresholds decide when it shouts. Tuning means fitting both to your business shape: customer mix, who you deal with, chains and assets. The same rule set on an exchange and a payments platform produces different noise, and the safety discipline is one change at a time, each logged with its reason.
Start by profiling the queue: group a month of alerts by what fired them. Most teams find a few rules making most of the noise, usually benign behavior that is merely unusual for the default set, a market maker's rhythm, a treasury sweep.
Then fit direction to business. Exchange flows involving known platform wallets or market makers may be ordinary only after their provenance and behaviour have been reviewed and found consistent with the business. Familiarity alone does not make a flow safe or a risk alert misconfigured. In payments, new addresses require risk assessment rather than automatic acceptance or rejection; use documented rules and bands matched to the business.
Threshold layering comes next. A single line between safe and suspicious produces noise at the boundary. Bands by amount and risk grade, narrow at high risk and tolerant at trivial amounts, produce a queue a human can triage, and each band documents its own rationale.
The safety discipline throughout: one change per review cycle, so cause and effect stay attributable, and a change log entry for every threshold moved, dated, initialed, with the reason. When an examiner asks why a rule was loosened, or when tuning goes wrong, the log answers.
For the related licensing and compliance guides, see the VASP compliance hub.
Level 2: Govern the Whitelist
A whitelist suppresses alerts on addresses you have checked and trust, and it is the fastest lever, which is why it needs governance more than enthusiasm. The standard: written criteria, an owner per entry, an expiry or review date, and a change trail. More whitelist is not more safety; a list that grows untended is a hole in the monitoring.
Inclusion criteria first, in writing. The defensible entries are the ones you checked yourself: internal wallets and treasury addresses, market makers whose identity and behavior you have confirmed, large partners with diligence files on record. "We see them every day" is not evidence; it is familiarity wearing diligence's coat.
Review cadence second. The other side changes: a market maker is acquired, an address rotates hands. Quarterly review of every entry, removal as the default for anything you cannot re-justify, keeps the list honest. Teams should review and remove temporary entries on their scheduled dates rather than leaving them indefinitely; this is a governance recommendation, not a claim that every product provides automatic expiry.
Governance trail third: who approved each entry, on what evidence, when. A whitelist incident with a trail is a control that had a bad day; one without a trail is a control that did not exist.
The honest statement of risk: yes, whitelisting can suppress a real case. That is the argument for the discipline around it. Entry criteria, expiry, review, trail. A governed whitelist is a precision instrument; an ungoverned one is a blind spot you built yourself.
Level 3: Route by Severity
The queue's problem is rarely the count of alerts; it is that they arrive as a line. Routing by severity turns the line into lanes: No Risk and Low alerts to automated or batched review, medium to human review in normal hours, high and critical to immediate action with escalation. Five grade levels, used as the routing table they are.
The routing table is a policy document, written before the queue is on fire: for each grade, who handles it, how fast, and what closes it. The grades come from the engine; the table is yours, and its quality decides whether senior analysts spend their day on critical alerts or on trivia.
Two principles fall out of the table. High risk does not wait: the institution may hold an unexecuted withdrawal for review when its policy and applicable law require it, on a short, tested escalation path. Low risk does not block: a trivial alert that can be batched and reviewed in aggregate should not be staffed like a case; that waste drowns the real ones.
The triage desk is where the table lives: one queue, sorted by severity, worked top down, each disposition recorded. That is what "risk based" looks like at 9 a.m. The alternative, first in first out, is how a two person team researches the fifteenth repeat on a known market maker while an odd deposit waits.
Measure and Review
Tuning without measurement is guessing with confidence. The honest loop: sample the queue monthly, judge each sampled alert by hand, and track your own ratio over time. Review the whitelist quarterly. Write the metric's definition into the policy so the number survives staff changes. Only numbers you generate yourself belong there.
The sample need not be heroic: a fixed slice of the month's alerts, judged by a named reviewer against a written standard, produces a trend line. That line tells you whether Level 1 changes helped, whether the whitelist absorbs the right traffic, and whether routing starves a lane.
Cadence binds it together. Monthly: queue composition, sample results, threshold change log review. Quarterly: full whitelist re-justification, routing table check against actual alert flow. Event driven: any missed case or incident triggers an immediate review of the rules involved, logged like any other change.
The measurement file is also the exam answer. When a supervisor asks how you know your monitoring works, the answer is a number you can defend, its definition in the policy, and the actions taken when it moved. United States expectations for money services businesses, published by FinCEN, are a fair template for what examiners read as evidence, and a risk based tuning record is exactly that category of artifact.
On tooling: this site's compliance line carries the three disciplines as features: an Alert Hub triage desk, direction rule tuning, and a managed whitelist. They carry the method; they do not replace it. The product detail is on the Phalcon Compliance page, the surrounding workflow is the transaction monitoring guide, and the family map is the VASP compliance hub.