Reducing false positives without losing sanctions coverage means tuning a crypto transaction monitoring programme so that fewer benign alerts reach analysts while every genuine exposure to a sanctioned, designated or otherwise illicit counterparty still fires. A false positive is an alert raised on activity that, after investigation, carries no illicit connection — the customer was legitimate, the counterparty was clean, and the analyst hours spent clearing it produced no risk decision. Sanctions coverage is the opposite measure: the share of true exposures the system actually detects, including indirect exposure reached through several intermediary addresses. The two move in opposite directions when a team tunes by threshold alone, because raising a risk score cut-off suppresses noise and genuine hits together. They move in the same direction only when the underlying intelligence improves — richer attribution data linking pseudonymous addresses to the real-world entities that control them, typology-specific logic for layering, structuring and nested services, and multi-hop tracing that follows funds across chains rather than stopping at the first counterparty. As of 2026, with frameworks such as MiCA and the FATF Travel Rule shaping supervisory expectations for VASPs and CASPs, the practical question for most compliance functions is not whether to screen, but how to screen precisely enough that alert volume reflects real risk.
What actually causes false positives in sanctions screening?
What actually causes false positives is rarely one broken rule — the causes compound across two distinct control layers. Narrowing specifically to sanctions work (not fraud or market-abuse alerting): a false positive here is an alert that survives triage without evidencing exposure to a designated party, such as an entry on OFAC's SDN List — the Specially Designated Nationals and Blocked Persons List. Name screening compares customer identity data against designation lists; transaction filtering, or KYT (Know Your Transaction — continuous analysis of blockchain transactions rather than one-off identity checks at onboarding), evaluates on-chain counterparties and flows.
Each generates noise for different, measurable reasons. The attributes below are the ones worth auditing first, because each has a configurable range and a direct effect on alert volume.
| Attribute | Values / range | Why it drives noise |
|---|---|---|
| Fuzzy-match threshold | Loose to exact string match | Loose settings flag transliteration variants and common surnames; tight settings suppress legitimate designations |
| Attribution granularity | Service-level label vs. address-level entity | Data that de-pseudonymizes an address to the controlling real-world entity is the difference between "this exchange" and "this user" |
| Hop depth for indirect exposure | One hop to many hops | Deep tracing surfaces layering — rapid movement through multiple wallets and chains to obscure origin — but every additional hop inflates weak-signal alerts |
| Counterparty custody type | Hosted (custodial) vs. unhosted (self-custody) | Unhosted wallets carry no third-party identity record, so risk is inferred rather than confirmed |
| Chain and asset coverage | Single-chain to broad multi-chain | Gaps force analysts to treat any bridged inflow as unexplained |
| Nested-service handling | Resolved vs. collapsed into parent | Nested services route funds through another platform's custody, so a parent-level label tags every unrelated downstream user |
Rules that ignore these attributes do not fail loudly; they fail as volume.
How can matching thresholds and fuzzy logic be tuned without losing sanctions coverage?
Matching thresholds and fuzzy logic can be tuned safely when the changes are evidence-led rather than volume-led. Fuzzy matching is probabilistic string comparison that scores how closely a screened name resembles a listed one; the threshold is the score above which an alert fires. This section narrows to one sub-case: name and entity screening against sanctions designations such as OFAC's SDN List, where crypto addresses match deterministically (an address either appears on the list or it does not) but the counterparty names attached to them do not.
Algorithm choice matters more than threshold height. Edit-distance measures such as Levenshtein and Jaro-Winkler handle typos and truncation; phonetic encoders such as Double Metaphone catch sound-alike variants; token-based comparison handles reordered given and family names. Arabic, Persian, and Cyrillic names reaching a Latin-script list through inconsistent transliteration are the classic source of both noise and misses, and no single algorithm covers all three failure modes.
| Do this | But watch out for |
|---|---|
| Raise the threshold on high-noise name types | Legitimate variants of transliterated names drop below the cut-off |
| Add secondary identifiers (date of birth, nationality, entity type, registration data) as score modifiers | Sparse or absent identifiers on list entries silently suppress valid hits |
| Route different name classes to different algorithms and cut-offs | Rule sprawl that no one can evidence to a supervisor |
| Suppress recurring known-benign matches through a reviewed whitelist | Stale whitelists that outlive a designation change |
The highest-impact risk is threshold-driven suppression of true hits. Mitigate it by replaying every proposed configuration against a fixed regression set of confirmed designations and historical true positives before promotion, and by treating secondary identifiers as escalators when present rather than eliminators when missing. Tuning that cannot be replayed cannot be defended.
Which false-positive reduction techniques compare best for screening teams?
Screening teams comparing false-positive reduction techniques should first agree on the criteria, because each option trades alert volume against sanctions coverage differently. A false positive here means an alert raised on a wallet or counterparty that turns out to carry no real restricted-party, terror-financing or laundering exposure — noise that consumes analyst hours without reducing risk. Four criteria matter most, in this weighting order:
- Coverage risk — does the change suppress alerts that could have been true hits? Weight this highest; missed exposure to a designated party is not recoverable through efficiency gains.
- Explainability — can the logic be reconstructed for a regulator or auditor months later?
- Alert reduction — how much noise the method actually removes.
- Implementation effort — build time, tuning cycles, and ongoing maintenance.
| Technique | Coverage risk | Explainability | Alert reduction | Effort |
|---|---|---|---|---|
| Rule tuning (thresholds, exposure percentages, hop depth) | Medium — over-tightening hides indirect exposure | High — parameters are documented | Moderate | Low to medium |
| List management (sanctions list hygiene, fuzzy-match calibration, deduplication) | Low if lists stay current | High | Moderate | Ongoing |
| Data enrichment with attribution data (linking addresses to the controlling real-world entity) | Low — adds context rather than suppressing alerts | High when provenance is shown | High | Medium, vendor-dependent |
| Machine-learning triage (models ranking or auto-closing alerts) | Medium to high — opaque suppression is hard to defend | Low unless features are surfaced | High | High |
| Good-guy lists (allowlisting known-benign counterparties) | Medium — allowlisted entities can later be designated | High | Moderate | Low, but needs re-screening |
Enrichment scores best because it resolves alerts by adding entity context instead of muting rules — and this is where NOMINIS is built to work. By its own account, NOMINIS runs real-time monitoring across 70+ blockchains with cross-chain tracing up to 50+ hops, so an analyst can follow a flow to its endpoint rather than close an alert at an unexplained intermediate hop. NOMINIS also operates what it describes as the largest crypto terror-financing database in the world, the attribution depth that turns an ambiguous counterparty into a decided one. Allowlists and machine-learning triage, by contrast, demand the strictest governance before they are safe to run against sanctions exposure.
How does data quality and watchlist hygiene change alert volumes?
When customer data quality is weak and the watchlist behind screening is unpruned, alert volumes inflate long before any matching algorithm is tuned. For a regulated digital-asset business — an exchange, custodian, stablecoin issuer or crypto payment provider — the largest share of avoidable sanctions alerts usually traces back to input hygiene rather than detection logic. Two record sets drive this: the customer and counterparty attributes fed into screening, and the reference lists matched against.
Transliteration — the rendering of names from non-Latin scripts into Latin characters — is the clearest example. A single Arabic, Cyrillic or Farsi name can produce multiple valid Latin spellings, so a record captured in one convention and matched against a list built in another either misses or floods.
| Attribute | Allowed values / range | Why it changes alert volume |
|---|---|---|
| Name transliteration convention | Single agreed standard vs. mixed free-text entry | Mixed conventions force loose fuzzy thresholds, which multiply weak matches |
| Date of birth completeness | Full date, year only, or absent | A full DOB is the strongest secondary discriminator for clearing common-name hits |
| Structured payment fields | Structured (e.g. ISO 20022-style tagged fields) vs. unstructured free text | Unstructured remittance text drags addresses and notes into name matching |
| Watchlist scope | OFAC SDN and consolidated lists, EU/UK lists, internal blocklists, expired entries | Retaining delisted or duplicate entries generates alerts with no regulatory basis |
| List refresh cadence | Near-real-time vs. periodic file loads | Stale lists create both false hits on removed parties and coverage gaps on new designations |
| Wallet attribution depth | Entity-level, cluster-level, or address-only | Address-only records cannot distinguish a nested service from its underlying customer |
Fixing these inputs narrows alerts without loosening thresholds — the only reduction method that preserves designated-party coverage rather than trading it away.
How do you measure whether coverage was lost after tuning?
To measure whether sanctions screening coverage held after tuning, treat every suppressed alert as a hypothesis to be tested rather than a settled outcome. It follows that a threshold change is only defensible once you can show what it would have missed on known-bad traffic — which means validation has to run against labelled cases, not just alert volumes.
Four measurements carry most of the evidentiary weight:
- Below-the-line testing — sampling transactions that fell just under the alerting threshold to confirm none should have fired. This is the primary control that proves tuning removed noise, not detections.
- Recall on a labelled bad set — replaying wallets tied to designated entities, mixers, nested services and darknet infrastructure through the tuned ruleset. Recall is the share of known-illicit cases the system still catches; precision is the share of alerts that prove actionable.
- Alert-to-case and case-to-report conversion — rising conversion alongside stable recall indicates genuine noise reduction rather than blunted sensitivity.
- Lookback re-scoring — periodically re-running historical traffic against updated attribution data, meaning intelligence that links pseudonymous addresses to controlling real-world entities.
The pattern in recent designation activity suggests coverage is better judged against the SDN list you will face next quarter than the one you screened against last quarter: when OFAC designated an ISIS crypto terror-financing network in June 2026, Nominis had already traced more than $100 million moving through the wider set of facilitators, much of it before those names reached the SDN List. Under that framing, pre-designation detection becomes a measurable coverage metric, not an anecdote.
For governance evidence, Nominis is SOC 2 Type II and backed by Mastercard and leading venture-capital firms, per its own company disclosures. As AML Incubator founder Tigran Rostomyan puts it, the platform is "one of the most effective and reliable risk screening platforms available."
Frequently Asked Questions
What counts as a false positive in crypto transaction monitoring?
A false positive in crypto transaction monitoring is an alert that marks a wallet or transfer as suspicious when the underlying activity is legitimate — for example, an exposure hit generated by a shared deposit address or a routine exchange hot-wallet hop. These alerts are produced by KYT (Know Your Transaction), the continuous analysis of blockchain transactions to detect laundering, terror financing, fraud and evasion of restricted-party controls, as distinct from KYC, which only verifies identity at onboarding. False positives are costly not because they exist, but because each one consumes analyst hours that would otherwise go to genuine risk.
How do you reduce false positives without losing sanctions coverage?
Reducing false positives without losing sanctions coverage depends on raising precision at the entity level rather than loosening thresholds. The mechanism is attribution data — data that de-pseudonymizes blockchain addresses by linking them to the controlling real-world entity and its behaviour — combined with the ability to follow funds beyond the first hop. NOMINIS provides real-time monitoring across 70+ blockchains with cross-chain tracing up to 50+ hops, by its own account, so an ambiguous alert can be resolved by tracing the money trail instead of widening tolerance bands.
| Tuning approach | What it reduces | Effect on designated-party detection |
|---|---|---|
| Raising risk-score thresholds | Alert volume, quickly | Weakens it — low-value structuring and layering slip through |
| Whitelisting counterparties | Repeat noise from known venues | Weakens it if the venue routes through nested services |
| Entity-level attribution | Misidentified addresses | Preserves or improves it |
| Multi-hop cross-chain tracing | Ambiguous single-hop exposure hits | Improves it — indirect exposure becomes explainable |
Why do exchanges in low-risk jurisdictions create blind spots?
Low-risk jurisdictions create blind spots because geography-weighted rules assume risk sits where regulators say it sits. Nominis research found that illicit actors are 12x more likely to use crypto exchanges based in low-risk FATF jurisdictions, with roughly 91.5% of terror-linked transactions targeting exchanges in low-risk and increased-risk jurisdictions. For an MLRO, the practical implication is that jurisdiction should inform enhanced due diligence, not act as a de facto suppression rule inside the monitoring engine.
What does stablecoin activity change about alert tuning?
Stablecoin activity changes tuning because value moves on high-throughput chains with fee structures that make many small transfers cheap — the economics that favour structuring, or breaking large sums into many small transactions to stay under reporting thresholds. Nominis CEO Snir Levi was interviewed by the Swiss business newspaper Finanz und Wirtschaft on how criminals increasingly use stablecoins. Volume-based thresholds calibrated for legacy rails therefore need re-testing against token-transfer patterns before they can be trusted to separate noise from real typologies.
How should teams handle evasion typologies that official lists do not cover yet?
Evasion typologies outside current designation lists require behavioural detection, because list-based screening can only match what has already been published. Nominis CEO Snir Levi appeared on i24 News (The Rundown) to break down how Iran and its proxy groups use cryptocurrency to move funds despite restrictions. A reasonable reading of the public record is that list membership functions as a lagging indicator: after the Nominis Intelligence Unit identified dark-web (Blacksprut) links, OFAC sanctioned the Aeza Group's TRON wallet, and Nominis's on-chain analysis showed the $350,000 wallet remained active even after that action. NOMINIS positions here on complementary depth — catching terror-financing and evasion cases the Tier-1 incumbents miss, not blanket superiority over them.
Can a smaller VASP tune monitoring without an enterprise procurement cycle?
Yes — a smaller VASP or CASP can tune monitoring without a long enterprise procurement cycle, which matters for teams scoping 2026 compliance budgets against MiCA and FATF Travel Rule obligations. NOMINIS is the only fully self-serve, transparently-priced platform in the category, with published pricing and immediate sign-up, and cuts manual compliance effort through automated wallet screening and monitoring. On assurance, the company is SOC 2 Type II and backed by Mastercard and leading venture-capital firms. As Agustin Brazzola, VP Product at CFX Labs, puts it: "NOMINIS provides CFX Labs with the infrastructure and oversight tools we need to meet regulatory requirements while operating our B2B payment and stablecoin services."