

Building effective financial crime detection requires more than just coverage. It demands precision, speed, and adaptability. As transaction volumes increase and typologies shift, detection rules must evolve to identify not only known patterns but also emerging behaviors that may signal risk.
Unit21’s rules engine is designed to meet that need. It supports three types of rules, each tailored for different levels of customization, complexity, and responsiveness. Whether you need out-of-the-box templates for common typologies or fully customized logic for unique risk models, the rules engine provides the flexibility to adapt to your organization’s requirements.
One of the latest additions is velocity rules. These rules focus on how quickly behavior changes, such as sudden spikes in deposits, rapid fund movement, or accelerated transaction counts. They are particularly effective in detecting fast-developing activity that might bypass traditional thresholds.
In this blog, we’ll walk through the core rule types available in Unit21 and then take a deeper look at velocity rules. We’ll explain how they work, where they deliver the most value, and how to implement them effectively.
Before diving into velocity rules, it's helpful to understand the foundation of Unit21’s detection framework. The platform supports three main types of rules: scenario rules, dynamic rules, and real-time rules. Each serves a distinct purpose depending on the level of flexibility and timing required.

Scenario rules are structured templates built around common financial crime typologies such as layering, structuring, or dormant activity. They follow a guided configuration model that makes them easy to deploy, even for non-technical users. Think of them as modular rules where you fill in the blanks to match your specific risk criteria. While they offer less customization than dynamic rules, they are ideal for quickly implementing industry-standard detection logic.

Dynamic rules offer full flexibility by allowing you to build logic using variables and trigger conditions. This rule type is designed for teams that want to combine behavioral trends, historical baselines, and entity-specific metrics. You can define exactly how variables should be calculated and when they should generate alerts. This includes the ability to layer in velocity logic, such as comparing recent transaction activity to longer-term averages. Importantly, dynamic rules are not limited to transactional data—they can also incorporate non-transactional events such as logins, PII updates, password changes, or any other system event. This allows compliance teams to capture a wider range of behaviors and build rules that reflect the full spectrum of user activity.

Real-time rules evaluate transactions or actions as they happen. These rules are ideal when you need to make immediate decisions such as blocking a transaction or requiring step-up authentication. They are optimized for low-latency performance and are triggered through Unit21’s real-time API endpoint. Use cases include login attempts from high-risk IP addresses or large transactions initiated by high-risk users.
Each rule type is designed to serve a specific purpose. Together, they give compliance teams the flexibility to detect known risks and adapt to emerging threats.
Not all rules in Unit21 are immediately active or alerting. Each rule goes through a specific status that determines its operational state. Understanding these statuses helps teams manage their rules confidently and ensures new logic is tested before going live.

Live rules are fully active. They continuously evaluate incoming data and generate alerts when their conditions are met. These rules are already validated and are part of your production detection logic.
Validating rules are in test mode. They run against historical data to help you assess whether the logic behaves as expected. This is a key step before activation. It allows teams to fine-tune thresholds, variables, or filters without impacting production alerts. These testing methods can also be used for A/B testing (above-the-line/below-the-line testing), enabling teams to compare different approaches and determine which logic is most effective before pushing to production.
Shadow rules are active but do not generate alerts. They silently evaluate live data on a schedule. This status is useful for testing how a new rule performs in a production-like environment without affecting alert volumes. It's a valuable tool for performance benchmarking, A/B testing, and rule refinement.
By using validating and shadow modes effectively, teams can deploy rules with greater confidence, reduce false positives, and improve overall model accuracy.
Velocity rules are a powerful extension of the rules framework in Unit21. They focus on detecting changes in the speed and volume of activity over time. These rules are designed to identify behavior that escalates quickly, which often signals risk before other patterns become visible.
Traditional rules often rely on fixed thresholds, such as flagging a transaction above a certain dollar amount. Velocity rules, on the other hand, focus on the rate and timing of activity. They allow you to ask questions like:
This type of logic helps uncover emerging risks that would otherwise fall below static thresholds.
Velocity rules are built using variables and trigger conditions in the rule builder. A variable could represent the total amount sent in the last three days or the number of transactions in the past week. Trigger conditions then compare these variables against historical baselines or other custom logic.
For example:

The result is a highly responsive detection rule that flags entities based on acceleration, not just volume.
Velocity rules are ideal for identifying:
They provide better context, reduce noise, and surface signals that are often early indicators of risk.
Velocity rules are most effective when applied to behaviors that change rapidly or deviate from established patterns. Below are some high-impact use cases where velocity-based detection adds value beyond standard thresholds.
Criminals often break large transactions into smaller ones to stay under reporting limits. Velocity rules help detect this by monitoring for rapid accumulation.
Example: Flag any entity that makes more than five deposits within 48 hours totaling over $9,500. This may indicate an attempt to avoid transaction monitoring thresholds.
A compromised account is often used quickly to extract funds. Velocity rules catch these early movements.
Example: Alert when an account logs in from a new device or IP and then sends more than three transactions above $2,000 within 30 minutes.
Accounts that suddenly reactivate with high-volume activity may indicate misuse, especially in synthetic or mule accounts.
Example: Detect entities that had no transactions for 90 days and then withdraw more than $10,000 within one day.
New instruments or wallets used for high-velocity transactions are a potential red flag, especially when seen for the first time.
Example: Trigger an alert if a newly added wallet conducts more than $15,000 in transactions within three days of creation.
High-speed fund movement between accounts or jurisdictions can signal layering or money mule activity.
Example: Identify users who send and receive funds through multiple channels, moving over 80 percent of received funds out within hours.
Velocity rules are powerful for identifying suspicious trends over time. But when paired with real-time rules, they enable both detection and immediate response. This combination is especially useful in fraud prevention and account protection scenarios.
Velocity rules are typically used for retrospective or scheduled evaluations. They reveal behavioral anomalies that develop across hours or days. Real-time rules, in contrast, evaluate events as they happen and can block or flag them instantly.
By using insights from velocity rules to inform real-time logic, teams can:
Let’s say a velocity rule identifies an entity that has initiated a spike in transfers over the last three days. You can use this signal to tighten controls via a real-time rule:
Real-Time Action: If a transaction is over $3,000 and the entity triggered a velocity rule alert in the last 72 hours, block the transaction or require step-up authentication.
This approach allows you to escalate your response based on the context of past behavior, not just the transaction itself.
Pairing velocity and real-time rules creates a layered defense that’s both proactive and responsive.
Implementing velocity rules in Unit21 is straightforward, especially if you're already using real-time rules. Here are a few quick steps to get started:
Velocity rules are highly adaptable and designed to evolve with your risk strategy.
Velocity rules give compliance teams a sharper lens for detecting fast-moving and unusual behavior. Whether you're targeting structuring, account takeovers, or rapid fund flows, these rules let you define logic that reflects both context and timing.
Combined with scenario templates and real-time responses, velocity rules complete a comprehensive detection strategy that adapts to both known and emerging threats.
If you're looking to upgrade your detection framework or explore velocity-based logic, now is a great time to start experimenting. The tools are flexible, powerful, and ready to deploy.

Gal Perelman is the Product Marketing Lead at Unit21, where she spearheads go-to-market strategies for AI-driven risk and compliance solutions. With over a decade of experience in the fintech and fraud sectors, she has led high-impact launches for products like Watchlist Screening and AI Rule Recommendations.
Previously, Gal held marketing leadership roles at Design Pickle, Sightfull, and Lusha. She holds a Master’s degree from American University and a Bachelor’s from UCLA, and is dedicated to helping banks and fintechs navigate complex regulatory landscapes through innovative technology.