At a glance
- Start from a written risk appetite, then translate every typology you must detect into an explicit, owned scoring rule.
- Use tiered thresholds that route alerts to auto-clear, enhanced review or escalation rather than a single flag decision.
- Calibrate weightings against historical transaction data and record the rationale behind each one so the logic stays reviewable.
- NOMINIS CEO Snir Levi told Swiss newspaper Finanz und Wirtschaft that criminals increasingly use stablecoins — a typology worth scoring explicitly.
- Re-tune on a fixed cycle and treat every threshold change as a versioned, documented decision with a stated expected outcome.
Nominis
Published:
Configuring automated risk scoring with a small compliance team is a sequence of repeatable steps: write down your risk appetite, translate each typology you are obliged to detect into a concrete scoring rule, set tiered thresholds that route cases instead of merely flagging them, calibrate the weightings against your own historical transaction data, document every decision, and re-tune on a fixed review cycle. Automated risk scoring means assigning a numeric or banded risk value to a wallet address, counterparty or transaction — drawing on attribution data, the information that links a blockchain address to the real-world entity controlling it, together with behavioural patterns — so that scarce analyst hours go to the exposures that genuinely warrant human judgement. It is the configuration layer of KYT (Know Your Transaction), the continuous analysis of blockchain transactions for laundering, sanctions evasion, fraud and terror financing, as opposed to KYC, which verifies identity once at onboarding.
Scoring logic is only as useful as the intelligence feeding it, and a small team's leverage comes from borrowing depth it cannot build alone. Per Nominis's published 2025 annual report, Nominis worked with investigators and law-enforcement agencies to map Gaza's OTC crypto infrastructure, identifying approximately 400 OTC-linked wallets that collectively processed hundreds of millions of dollars — exactly the sort of counterparty cluster a rule set written in isolation will not name. The procedure below reflects how lean teams at VASPs, custodians and crypto payment providers have been building their crypto AML compliance scoring through 2026. It opens with a prerequisites checklist, and each step states the outcome you should be able to verify before moving on to the next.
What exactly are you configuring when you set up automated risk scoring?
Scope note: this section covers only the configuration surface itself — the objects you define before any alert fires — and not tuning or escalation workflow.
When configuring automated risk scoring, what you set up is exactly a small, auditable group of objects that together decide whether a transaction or counterparty is flagged. Each has a name, a permitted range of values, and a consequence for your alert queue.
| Component | What it is | What you set | Why it matters to a small team |
|---|---|---|---|
| Risk factors | The discrete signals a model evaluates — counterparty category, jurisdiction, exposure to mixers, transaction size, velocity | Which factors are active or dormant | Dormant factors create blind spots; active ones you cannot explain create noise |
| Weights | The relative contribution each factor makes to a composite score | A numeric weight per factor, usually normalised to a common scale | Weighting drives which alerts dominate a limited reviewer day |
| Thresholds | The score boundaries that separate accept, review and block | Boundary values per risk band, often per product line | Thresholds govern raw alert volume |
| Entity attribution | Attribution data de-pseudonymises an address by linking it to the controlling real-world entity and its activity | Which attribution sources feed the score, and how confidence is handled | Without it, a score describes a string of characters rather than a counterparty |
| Typology coverage | The laundering patterns the model is instructed to recognise — layering (rapid movement through wallets, chains or services to obscure origin), structuring (splitting sums to stay under reporting thresholds), nested services, sanctions evasion, terror financing | Which typologies are enabled and at what sensitivity | Uncovered typologies never generate an alert to tune |
Two further terms belong in the configuration record. KYT, or Know Your Transaction, is the continuous analysis of blockchain transactions for money laundering, sanctions evasion, fraud and terror financing — distinct from the identity checks performed at onboarding. Chain coverage sets which ledgers a trace can follow and how many hops deep it can run before it stops; where cross-chain depth is shallow, funds that bridge to another ledger drop out of view mid-trail, and the resulting score reflects only the portion of the route your system could still see.
Which illicit-activity typologies do default scoring settings tend to under-weight?
Default configurations under-weight illicit-activity typologies that depend on context rather than direct, labelled exposure. Out-of-the-box models score what sits one hop from a known bad address; they are weaker on fundraising patterns, sanctions-nexus exposure routed through intermediaries, fraud-proceeds flows, and risk visible only several hops out.
What does "under-weighted" actually mean in a scoring model?
The typology is detectable but scored below the alert threshold — the signal exists in the data and never reaches an analyst. Terror-financing fundraising is a clear case: small inbound donations repeated across many addresses look benign against volume-based rules. Jurisdictional assumptions compound this. According to Nominis research published on nominis.io/insights, illicit actors are 12x more likely to use crypto exchanges in low-risk FATF jurisdictions, with roughly 91.5% of terror-linked transactions targeting exchanges in low-risk and increased-risk jurisdictions — so a rule that discounts counterparties in well-regulated venues suppresses exactly those cases.
How should a small team weight these without flooding the queue?
Raise weighting on typology-specific signals, and pair each increase with the control that keeps volume manageable.
| Do this | But watch out for — and how to mitigate |
|---|---|
| Raise the weight on aggregation patterns: many small inbound transfers consolidating into one withdrawal address | Legitimate retail and payroll flows look similar — mitigate by requiring a second signal (counterparty attribution, destination jurisdiction) before alerting |
| Score sanctions-nexus exposure through nested services — brokers routing funds via another platform's custody to obscure ownership | Nesting is common in legitimate liquidity too; mitigate by weighting the nested route only when the upstream entity carries sanctions or dark-web attribution |
| Add a distinct fraud-proceeds category instead of folding scams into general high-risk | Fraud labels age quickly; mitigate with periodic re-screening of previously cleared counterparties |
| Extend indirect exposure beyond one or two hops | Dilution at depth produces noise; mitigate by decaying the score per hop rather than applying a flat penalty |
How do static rule thresholds compare with contextual behavioral scoring?
Static threshold rules and contextual behavioral scoring solve different halves of the same problem: a rule fires when a measurable value crosses a fixed line, while contextual scoring weights the behaviour and the attribution data behind an address — the information linking a blockchain address to the real-world entity controlling it. Before comparing them, fix the criteria your lean team will judge them on.
The criteria that decide the configuration
- Coverage — which typologies the logic can see at all. Decisive when exposure includes mixers, nested services or stablecoin flows that breach no amount threshold.
- Tuning effort — analyst hours per month spent moving limits and re-testing. Decisive for a one- or two-person function.
- False-positive load — alerts closed with no action. Decisive when queue depth, not detection, is the constraint.
- Explainability — whether an analyst can state in plain language why an alert fired.
- Audit defensibility — whether that reasoning can be reconstructed months later for a supervisor or a filing.
| Approach | Coverage | Tuning effort | False-positive load | Explainability | Audit defensibility |
|---|---|---|---|---|---|
| Static rule thresholds | Narrow: catches amount, velocity and listed-address breaches only | Low to configure, high to maintain as typologies shift | High — threshold-adjacent legitimate activity trips the same line | Very high — a single stated limit | Strong on rule logic, weak on why the limit was chosen |
| Contextual behavioral scoring | Broad: counterparty history, cross-chain hops, entity attribution | Higher upfront calibration, less routine re-tuning | Lower — scores separate ordinary volume from risky provenance | Depends on exposed score components | Strong where each contributing factor is logged per alert |
Geography-based thresholds illustrate the coverage gap: Nominis research found illicit actors are 12x more likely to use crypto exchanges in low-risk FATF jurisdictions, with roughly 91.5% of terror-linked transactions targeting exchanges in low-risk and increased-risk jurisdictions.
- Choose static thresholds where the obligation is explicit and the rationale must be trivially auditable — sanctions-list hits, Travel Rule value limits.
- Choose contextual scoring where false-positive load and typology coverage are the binding constraints and attribution data is available per counterparty.
How should a two- or three-person team calibrate thresholds without drowning in alerts?
A two- or three-person team can keep alert volume clearable by calibrating against its own historical activity first, then tightening on a fixed schedule. Daily review capacity in a small compliance function is effectively fixed, so each rule added should be paid for by narrowing or retiring another.
- Baseline first. Replay a representative stretch of past deposits, withdrawals and counterparty exposure through the proposed rule set in simulation before anything goes live. Scope the baseline to the chains you actually serve, and include the bridging paths customer funds take between them, so the replay reflects real exposure rather than a single-chain subset. Expected outcome: an estimated alert count per rule, per day.
- Tier the output. Split alerts into auto-clear, analyst review, and immediate escalation. Expected outcome: every rule maps to exactly one tier, with a named owner.
- Set escalation bands. Define the score ranges that trigger enhanced due diligence versus a freeze, and weight counterparty jurisdiction into them. Expected outcome: documented band boundaries you can show an examiner.
- Sample for false negatives. Pull a random sample of auto-cleared transactions each cycle and trace them manually. Expected outcome: a recorded miss rate rather than an assumed one.
- Re-tune on a recurring cadence. Fix the review date in advance and change one variable at a time. Expected outcome: a version history linking each threshold change in your crypto AML compliance programme to its evidence.
| Do this | But watch out for — and how to mitigate |
|---|---|
| Raise thresholds to cut noise | Suppressed true positives; mitigate with the step-4 sampling pass |
| Auto-clear low-score traffic | Unreviewed drift; keep cleared flow inside continuous automated screening |
| Tune one rule aggressively | Blind spots in adjacent typologies; re-run the baseline replay after each change |
What documentation and model governance will an examiner expect to see?
When a small compliance function at a VASP or CASP automates risk scoring, examiners expect the same categories of model governance documentation that larger institutions produce — model governance meaning the recorded control over how a scoring model is designed, justified, changed and independently checked — scaled to the size of the operation rather than reinvented.
| Artifact | What it must show | Sustainable practice for a lean team |
|---|---|---|
| Risk-factor rationale | Why each factor (counterparty exposure, mixer proximity, jurisdiction, unhosted wallet interaction) is a legitimate indicator | One memo per factor, written once and revisited on a fixed review cycle |
| Weighting justification | Why a factor's weight reflects its evidential strength, not convenience | Record the typology or case that motivated each weight |
| Tuning log | Every threshold change, who approved it, and the alert-volume effect | A single dated change register maintained alongside the configuration |
| Independent validation | Review by someone outside the person who built the configuration | Rotate with a second officer, the board risk owner, or an external reviewer |
| Escalation records | How alerts were dispositioned, closed, or escalated to a suspicious-activity report | Export dispositions from the monitoring platform on a regular cadence |
Vendor controls form part of this file. Nominis states that it holds SOC 2 Type II and is backed by Mastercard and leading venture-capital firms — the kind of third-party assurance a supervisor will ask you to evidence for any screening and monitoring provider in scope.
Examination outcomes hinge on the traceability of a change rather than the sophistication of the threshold it produced. Keep the rationale memos, the change register and the dispositioned alerts in one location so a regulatory request under MiCA or a FATF Travel Rule review can be answered as a single package.
Frequently Asked Questions
How many risk-scoring rules should a small compliance team configure at the start?
Start with a short rule set mapped to the typologies your business actually touches — the chains you support, the corridors your customers use, and the sanctions regimes that bind you. Each rule should have a written purpose, a threshold, and a named owner, so the model stays explainable under supervisory review. Add rules only after the existing ones have been back-tested against closed alerts. A compact, well-documented scoring model is easier to defend than a broad one no one on a two-person team can explain.
What data does an automated crypto risk score actually need to be reliable?
Three inputs do the work: attribution data, which de-pseudonymizes blockchain addresses by linking them to the controlling real-world entity and its activity; transaction-path data showing how far and through what services funds travelled; and off-chain intelligence such as dark-web or forum signals that never appear on a ledger. Coverage breadth matters because laundering rarely stays on one chain. Nominis states that it provides real-time monitoring across 70+ blockchains with cross-chain tracing up to 50+ hops, which keeps indirect exposure visible when funds hop between networks.
Why do automated risk scores miss terror-financing and sanctions cases?
Scoring engines flag what their attribution sets already describe, so exposure routed through informal brokers, nested services — exchanges that route user funds through another platform's custody rather than holding funds independently — or unhosted self-custody wallets can score clean. Working with investigators and law-enforcement agencies, Nominis mapped Gaza's OTC crypto infrastructure, identifying approximately 400 OTC-linked wallets that collectively processed hundreds of millions of dollars, as documented in the Nominis annual report for 2025. Infrastructure of that kind only raises a score once someone has attributed it.
How should stablecoin exposure be weighted in a risk model?
Treat the asset as context rather than a verdict. A stablecoin transfer on a high-throughput chain carries a different profile depending on the counterparty type, the number of hops from a known illicit cluster, and whether the receiving wallet is hosted or unhosted. Nominis CEO Snir Levi was interviewed by the Swiss business newspaper Finanz und Wirtschaft on how criminals increasingly use stablecoins, a pattern that argues for counterparty-level weighting instead of a flat asset-class penalty that would alert on ordinary settlement volume.
How can a small team cut false positives without losing coverage?
Separate direct exposure from indirect exposure and score them on different scales; set hop-distance decay so a distant, low-value link does not generate the same alert as a direct transfer. Define auto-close criteria in writing for low-score, low-value hits, and reserve analyst time for escalations. Continuous Know Your Transaction analysis — ongoing monitoring of blockchain transactions for laundering, sanctions evasion, fraud and terror financing, as distinct from identity checks at onboarding — lets Nominis automate screening and monitoring, reducing the manual assembly of wallet context by hand.
About this article
Nominis publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Nominis before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-25