Crypto AML monitoring rules need active tuning as transaction volume, counterparties, and risk policies shift. A default rule set that launches the team will silently over-alert or miss new patterns within weeks of going live. The power-user work happens in four places: the Risk Engine, behavioral templates, exposure thresholds, and the review cadence that keeps them honest. This guide covers four areas: Risk Engine configuration, behavioral template settings, exposure thresholds, and ongoing review. For the broader workflow, see Phalcon Compliance. This page is part of the AML Compliance Hub.
Beyond Defaults: Why Custom Rules Matter
A freshly deployed AML monitoring stack runs on the vendor's default rule kit. That kit is designed to be safe across the widest possible customer base, which means it is calibrated to nobody's specific risk profile. Three forces pull a default rule set out of shape within weeks of going live. Industry differences come first. An exchange, a DeFi protocol treasury, and a payment router have radically different counterparty populations, and a rule tuned for one will misfire on the others. Risk appetite comes second. Two teams in the same industry can disagree on whether a single mixer interaction is a reportable event or background noise. The rule set has to reflect that disagreement rather than override it. Volume comes third. A team screening a few hundred wallets per week experiences default thresholds differently from a team screening tens of thousands. The same false-positive rate produces different absolute alert counts.
The regulatory floor reinforces the point rather than resolving it. The FATF risk-based calibration expects a VASP to size its monitoring controls to assessed risk rather than leave a static default rule set in place, which makes calibration an ongoing obligation rather than a one-time setup. FinCEN's AML program rules make the same point from the US side. A monitoring stack has to match the institution's actual risk profile, not the vendor's shipping default. In practice, default rule kits are usually too coarse for an institution's counterparty mix, and teams tune thresholds and behavioral templates manually before alert volume becomes workable. The pattern is consistent across monitoring programs. The default kit is a starting baseline, never a steady state.
Risk Engine Configuration: The Five Tunable Dials
A Phalcon Compliance Risk Engine is a configurable rule built from five dials: Target type, Risk type, Trigger conditions, Risk level, and Notification channels. Every engine is applied globally by its target type, so an address engine screens every address submission and a transaction engine screens every transaction submission. The five dials map onto the questions a compliance officer asks when standing up a new rule.
| Dial | Options | What the dial decides |
|---|---|---|
| Target type | Address or Transaction | Whether the engine screens a wallet or a transaction |
| Risk type | Exposure or Behavioral | Whether the engine looks at who the counterparty is or how funds move |
| Trigger conditions | Thresholds, Risk Indicators, directions, hops | The exact condition set that fires an alert |
| Risk level | Critical down to No Risk | The severity stamped on every alert the engine raises |
| Notification channels | Email, Telegram, Lark, Webhook, Slack, Discord, PagerDuty | Where the alert lands and who has to act on it; channel availability is tiered - Email on all plans, Telegram and Lark added from Essential, the full set including Webhook on Scale and Enterprise |
Risk Levels are configurable per engine, ranked from Critical down through High, Medium, and Low to No Risk, and each organization defines what each level means against its own risk appetite. A large-value transfer rule can be Critical at one shop and High at another. Both are correct if the level assignment matches the internal escalation matrix. The discipline that matters is consistency. Once an organization defines what a High means for an Exposure hit versus a Behavioral hit, every engine should respect that mapping rather than leave level assignment to whoever last edited the rule.
Notification channels close the loop. A Critical alert that lands only in a shared inbox will be discovered late. Routing Critical and High alerts to Telegram or Lark channels the on-call analyst watches turns an engine into a working detection. Webhook pushes the same alert into a case management system, so the alert becomes a tracked item rather than a log entry. These dials all sit inside the broader crypto AML compliance platform. The engines wired up here are the same ones tuned in the crypto compliance software deployment timeline and rollout before advanced configuration takes over.
Behavioral Templates: Tuning the 3 Address and 2 Transaction Engines
The configurable surface that makes advanced crypto AML rule tuning possible inside Phalcon Compliance is the Behavioral Risk Engine, which ships three address-side behavioral templates and two transaction-side behavioral templates, each with thresholds a compliance officer can tune to match the institution's risk appetite. These five templates are the power-user's working surface, and almost every false-positive reduction campaign comes down to calibrating them.
The three address behavior templates catch distinct wallet-level patterns. One flags addresses whose transaction value exceeds typical user behavior, and the tuning question is where typical ends and suspicious begins for this specific customer base. One catches addresses that transact often, particularly in amounts just below an alert threshold, which is the classic smurfing and layering signature. One detects intermediaries that receive funds and move them on quickly, a pattern central to laundering flows. The two transaction behavior templates apply the same logic at the transfer level: one fires on a single transfer above the configured threshold, and one fires when funds land and depart inside a short window, indicating layering or evasion.
Threshold tuning is where power users spend most of their time. A large-value rule set too low fires on every whale customer and drowns the alert queue. Set too high and it misses the exact structuring pattern it was built to catch. The practical approach is to start from the default, read the alert volume over a representative week, and walk the threshold toward the point where alerts are dominated by genuinely suspicious activity. A high-frequency rule needs the same treatment on its count and amount-floor parameters, because the rule is only useful when the small-transaction floor excludes normal retail behavior. A rapid-transit rule needs its time window calibrated to the chain's block time and to the team's tolerance for fast-follow alerts.
Custom Risk Engine quota scales by tier: 3 on Screening Packages, 10 on Essential, 20 on Scale, and unlimited on Enterprise. The number of active engines a power user can keep tuned is gated by plan. A team that wants parallel threshold experiments, keeping a conservative engine and a tuned engine active side by side, needs to plan its engine quota around that workflow. Disabling an engine stops new alerts while already-triggered alerts remain in the Alert Hub, which makes it safe to experiment without losing the audit trail of what the old configuration caught.
Exposure Threshold Calibration
Where Behavioral engines look at how funds move, the Risk Exposure Engine looks at who a counterparty is and what it has touched. The Risk Exposure Engine ships three address-side exposure templates and three transaction-side exposure templates, and it evaluates Exposure Value and Exposure Percentage against configurable thresholds. Exposure Value is the USD total of assets that originated from, or ever interacted with, a designated risk source. Exposure Percentage is the tainted share of an address's total inflow or outflow value. Both are tunable per engine.
Risk Indicators used by Exposure engines span 17 categories, from Sanctioned and Terrorist Financing through Mixing, Dark Market, and FATF Grey List Jurisdiction. The power-user decision is which Risk Indicators each engine treats as in-scope and what exposure threshold trips an alert. An exchange with a permissive listing policy may scope an interaction-based engine to Sanctioned, Ransomware, and Mixing indicators with a low Exposure Percentage threshold, accepting a louder alert queue in exchange for coverage. A more conservative institution may add Dark Market and Drug Trafficking to the same engine and raise the threshold to keep alert volume workable. Neither configuration is wrong if it matches the documented risk appetite.
The interaction between Exposure Value and Exposure Percentage is where calibration gets subtle. A large address with a small Exposure Percentage can still carry a meaningful Exposure Value in absolute USD terms. A small address with a high Exposure Percentage can be a one-off burn wallet rather than a systemic risk. Power users typically pair the two, setting a floor on each, so that an alert only fires when both dimensions cross territory the team has agreed to investigate. Calibration is iterative. Once Monitor is enabled on a watched address, it re-analyzes that address on a dynamic schedule and raises an alert whenever risk status changes, without any manual re-screening. That means a threshold change propagates forward into live surveillance, so the tuning loop is short and the feedback is immediate.
Configure Advanced Rules on Phalcon Compliance
Default rules get a team to go-live. Tuned rules keep it there. Phalcon Compliance gives a compliance officer the five-dial Risk Engine, the Behavioral templates, and the Exposure thresholds needed to match a default kit to the institution's risk appetite. Configure advanced rules on Phalcon Compliance and walk the tuning loop on the team's own counterparty mix before the next regulator review.