A complete guide to configuring, testing, and managing rules within the Flagright platform.

01 - Overview

Flagright's rules engine is the foundation of transaction monitoring. Rules define the conditions under which suspicious activity is detected, alerts are generated, and actions are triggered, either in real time or after the fact.

Two Paths for Creating Rules

Rules can be created in two ways, each with a different setup flow.

Path	How to Access	Setup Flow
Configure from Template	Templates tab → select a template → Configure	Step 1: Basic Details → Step 2: Standard Filters → Step 3: Rule Parameters
Create Custom Scenario	Templates tab → Create scenario	Step 1: Basic Details → Step 2: Rule is Hit When → Step 3: Alert Creation Details

Both paths produce a rule that appears in My Rules, where it can be activated as a live rule immediately, edited, tested with the Simulator, or deployed first as a Shadow rule to observe behaviour on real traffic before going live.

The My Rules Page

The My Rules page is the central hub for managing all configured rules. It displays each rule's ID, type, name, description, hit rate, assigned queue, execution mode, and active status. Rules are split across two tabs: Live rules and Shadow rules. From this page, rules can be edited, duplicated, deleted, enabled, or disabled using the action icons on each row. To deactivate a rule, click the Toggle button in the Status column for that rule.

The My Rules page showing Live rules and Shadow rules tabs, hit rate per rule, status toggle, and Edit / Duplicate / Delete actions.

Tab	Description
Live rules	Rules currently active and running against incoming transactions in real time or post-processing mode.
Shadow rules	Rules running in silent mode, evaluating live transactions and logging would-be alerts internally without surfacing them to analysts or taking any action. Used to safely observe how a rule behaves on real traffic before deploying it live.

Note: Shadow rules and the Simulator serve different purposes. Shadow rules run silently on future live transactions. The Simulator runs a rule against historical past transaction data. Use the Simulator to validate logic before deploying, and Shadow rules to observe behaviour on live traffic before fully activating. See Section 10 for full Simulator documentation.

Rule Categories

Category	Purpose	Typical Mode
AML	Detects typologies associated with making illicit funds appear legitimate. Common examples include: structuring (breaking transactions into smaller amounts to avoid reporting thresholds), layering (moving funds across multiple accounts or jurisdictions to obscure origin), money mule activity (accounts used to funnel illicit funds on behalf of criminal networks), round-tripping (funds sent out and returned in a different form), dormant account reactivation, unusual geographic activity, and transactions involving high-risk jurisdictions.	Post-processing
Fraud	Detects fraudulent transaction patterns to enable fund suspension or blocking before disbursement. Common typologies include: card testing (multiple low-value transactions probing a stolen card's validity), account takeover (sudden behavioural change indicating account compromise), authorised push payment (APP) fraud (customers deceived into authorising payments to fraudsters), first-party fraud, and social engineering scams.	Real-time
CTF	Counter-terrorism financing, focused on monitoring for funding flows linked to terrorist activity.	Real-time or Post-processing
Screening	Checks users and counterparties against sanctions, PEP, and adverse media lists.	Real-time

02 - Real-Time vs Post-Processing

Every rule must be configured as either real-time or post-processing. This determines when the rule is evaluated relative to the transaction and whether the platform can influence its outcome.

Real-Time (Synchronous)

The rule executes in real-time and the outcome, including whether the rule is hit and the associated action (Allow, Flag, Suspend, or Block), is returned in the API response payload before the transaction proceeds. Ideal for fraud prevention, sanctions screening, and any use case where an immediate response is required.

Post-Processing (Asynchronous)

The rule executes after the API response has already been returned. The outcome is not included in the API payload and is only available in the Console. Appropriate for AML use cases where the goal is to detect and investigate patterns after the fact, and where an immediate action on the transaction is not required.

Tip: Post-processing is well-suited for AML monitoring programmes where rules evaluate historical patterns, aggregated behaviour, and extended look-back windows. This type of detection logic is not time-sensitive and does not require a synchronous response.

Recommended Configuration by Action

Flagright recommends aligning execution mode with the rule's configured action.

Action	Recommended Mode	Reason
FLAG	Post-processing (Asynchronous)	Transaction can proceed with no immediate response needed. Running asynchronously allows the transaction to complete without waiting for the rule outcome.
SUSPEND	Real-time (Synchronous)	Transaction must be held pending review. The suspend instruction must be returned in the API response for the customer to act on it.
BLOCK	Real-time (Synchronous)	Transaction must be declined immediately. The block instruction must be returned in the API response before processing continues.

Factor	Real-Time (Synchronous)	Post-Processing (Asynchronous)
Transaction impact	Can suspend or block in flight	No impact. Transaction already processed.
API response	Action returned in API response payload	Outcome visible on Console only
Typical use case	Fraud prevention, card programs, sanctions screening	AML typology detection, pattern analysis
Alert creation	Always instant	Can be instant, weekly, or monthly
Recommended for	SUSPEND and BLOCK rules	FLAG rules

03 - Step 1: Basic Details

Step 1 is the same for both the template configure flow and the custom scenario builder. It defines how the rule is identified, categorized, and classified within the platform.

Step 1: Basic Details — rule name, description, rule nature (AML / Fraud / Screening / CTF), and optional rule labels.

Rule ID, Name & Description

Each rule is automatically assigned a unique Rule ID. The name and description are free-text fields customizable to match the customer's internal naming conventions.

Rule Nature

Classifies the rule by financial crime typology: AML, Fraud, Screening, or CTF. Ensures rules are correctly organized, filterable, and reportable within the platform.

Rule Type

Rule type defines what entity the rule evaluates and when it is executed. When configuring from a template, the rule type is inherited from the template and is not a configurable field. Most templates are Transaction type. When creating a custom scenario, the rule type is selected in Step 1.

Rule Type	What It Evaluates	When It Executes
Transaction	Transaction and user properties based on the defined rule logic.	Whenever a new transaction or transaction event occurs.
User	User properties based on the defined rule logic.	Whenever a new user or user event occurs. For ongoing screening, also executed for existing users.
Transaction screening	Transaction counterparty payment name details, bank name details, or transaction reference.	On each transaction event, checked against screening data.
Consumer user screening	Consumer user KYC details.	Checked against screening data on user creation and user events.
Business user screening	Business user KYC details including associated bank names, shareholders, and directors.	Checked against screening data on user creation and user events.
CRM user	CRM user properties linked to a user.	Executed when a linked CRM user is updated.
CRM ticket	CRM ticket properties linked to a user.	Executed when a linked CRM ticket is updated.

Rule Execution Mode

Sets whether the rule runs in real-time or post-processing. See Section 02 for a full explanation.

Rule Labels

Optional custom identifiers surfaced in the API response when the rule fires. Used to drive automated actions in the customer's own core systems.

Rule labels dropdown showing pre-configured options: RFI trigger, EDD trigger, KYC trigger, Unexpected behavior, and Illicit gains check.

Example: A customer assigns the label 'RFI_TRIGGER' to a rule. When it fires, their core system reads the label and automatically prompts the end user to provide proof of address, source of funds, or proof of income.

04 - Step 2: Standard Filters

Standard Filters is Step 2 of the template configure flow and is optional. It allows compliance teams to add segmentation and targeting logic to narrow which users and transactions the rule applies to. Filters are organized into five sub-tabs in the left sidebar: User details, Geography details, Transaction details, Historical transactions, and General.

User Details

Filters based on user profile attributes.

Filter	Description
User type	Scope the rule to All users, Consumer users only, or Business users only.
Target age range	Restricts the rule to users within a specified age range. From [value] To [value and above]. When users of a transaction fall within this range, the rule is run.
User creation age range	Filters by how long the user has been a customer. Calculated as NOW minus the user's createdTimestamp. Newer accounts are generally considered higher risk.
Whitelist users / Whitelist IDs	Specific user IDs added here are excluded from the rule entirely. The rule will not run for these users.
Target user IDs	If populated, the rule runs only for the specified user IDs. Used to apply specialized monitoring to a specific segment.

The User Details sub-tab showing User type (All/Consumer/Business), Target age range, and User creation age range filters with the 3-step Standard Filters flow visible at the top.

User Details continued: Whitelist IDs (exclude specific users), Target user IDs (run rule only for specific users), and Acquisition channels filter.

Acquisition Channel

Filters the rule to apply only to users acquired through specific channels. Useful for applying targeted monitoring to users originating from higher-risk acquisition sources.

Channel	Description
Organic	User signed up through unpaid, direct discovery of the platform.
Paid	User acquired through a paid marketing or advertising campaign.
Referral	User signed up via a referral from another user or partner.
Offline	User acquired through an offline process such as an in-branch visit or paper application.
Gathering	User acquired through an event or group-based onboarding activity.
Unknown	Acquisition channel is not specified or recorded.

Geography Details

Filters based on the user's geographical attributes. For business users, country fields filter based on shareholder and director attributes. For consumer users, they filter based on the individual user's attributes.

Filter	Description
Residence countries	Filters by country of residence. For business users: shareholder and director country of residence. For consumer users: the user's country of residence.
Nationality countries	Filters by nationality. For business users: shareholder and director nationality. For consumer users: the user's nationality.
Registration countries	Filters by the country in which the business is registered. Business users only.

The Geography Details sub-tab showing Residence countries, Nationality countries, and Registration countries filters. For business users, fields filter on shareholder and director attributes.

Transaction Details

Filters based on the attributes of the current (new) transaction being evaluated.

Filter	Description
Origin payment methods	Filters origin side of the transaction by payment method. Available options: ACH, CARD, IBAN, UPI, GENERIC BANK ACCOUNT, MPESA, SWIFT, WALLET, CHECK.
Destination payment methods	Filters destination side of the transaction by payment method. Same options as origin payment methods.
Target transaction types	Filters by transaction type. Available options: DEPOSIT, TRANSFER, EXTERNAL_PAYMENT, WITHDRAWAL, REFUND, OTHER.
Target transaction states	Filters by transaction lifecycle state. Available options: CREATED, PROCESSING, SENT, EXPIRED, DECLINED, SUSPENDED, REFUNDED, SUCCESSFUL. If not specified, all states are included.
Origin transaction countries	Filters by origin country inside the payment details.
Destination transaction countries	Filters by destination country inside the payment details.
Transaction amount range	Restricts the rule to transactions within a defined amount range. Configure currency, minimum amount, and maximum amount.
Product types	Filters transactions by product type (e.g. agriculture, instruments, software, furniture). Free-form text field. Currently one product type can be specified per rule.
Transaction tags	Filters by custom key-value tags attached to the transaction. Supports OR logic (any matching tag suffices) or AND logic (all specified tags must match).
Transaction time range	Filters transactions based on a specified time window, accounting for the configured time zone.

The Transaction Details sub-tab showing Payment Filters (methods, wallet types, card countries), transaction types, states, countries, and amount range for the current transaction.

Historical Transactions

Filters applied specifically to the historical transactions the rule looks back on when evaluating aggregated behaviour. These filters have no effect if the rule does not need to check historical transaction data.

Filter	Description
Payment methods	Filters which historical transactions to include by payment method. Options: ACH, CARD, IBAN, UPI, GENERIC BANK ACCOUNT, MPESA, SWIFT, WALLET, CHECK.
Target transaction types	Filters historical transactions by type. Options: DEPOSIT, TRANSFER, EXTERNAL_PAYMENT, WITHDRAWAL, REFUND, OTHER.
Target transaction states	Filters historical transactions by lifecycle state. Options: CREATED, PROCESSING, SENT, EXPIRED, DECLINED, SUSPENDED, REFUNDED, SUCCESSFUL.
Transaction countries	Filters historical transactions by origin and destination countries.
Transaction amount range	Restricts which historical transactions are included by amount. Configure currency, minimum amount, and maximum amount.
Transaction time range	Filters historical transactions to a specified time window.

The Historical Transactions sub-tab showing filters for payment methods, transaction types, states, countries, and amount range applied to historical look-back data.

Tip: Historical transaction filters are particularly useful for velocity and pattern-based rules. For example, a structuring rule might look back 30 days but only want to count successful transactions. The Historical transactions tab is where that state filter is applied to the look-back window.

General

Contains overarching rule behaviour settings that apply across all filter types.

Field	Description
ORIGIN	Only transactions data related to the origin user will be considered when evaluating the rule.
DESTINATION	Only transactions data related to the destination user will be considered when evaluating the rule.
Blank (both)	Leaving this field blank means the rule will run on both the origin user and the destination user.

The General sub-tab showing the User direction to check field: ORIGIN (origin user only), DESTINATION (destination user only), or blank (both users checked).

05 - Step 3: Rule Parameters

Rule Parameters is Step 3 of the template configure flow. It defines the condition threshold, the action triggered when the rule fires, and optional automated actions that execute in the background when an alert is created.

Step 3: Rule Parameters — CRA risk thresholds, transaction amount threshold configuration, and FLAG / SUSPEND / BLOCK action selection.

CRA Risk-Based Thresholds

Configures whether the rule applies the same logic to all users or adjusts based on each user's Customer Risk Assessment (CRA) risk level.

Setting	Behaviour
No (default)	Rule logic applies the same thresholds for all users irrespective of their CRA risk level.
Yes	Rule logic can be customized per CRA risk level, for example applying a lower transaction amount threshold for high-risk users.

Rule Logic

For template-based rules, the core rule condition is pre-defined by the template's detection pattern. The key parameter to configure is the threshold, such as the transaction amount at or above which the rule fires. The currency and threshold amount are set here.

Note: The rule logic in the template path is intentionally simplified. For fully custom IF/THEN logic using any data field and aggregation function, use the Scenario Builder (see Section 08).

Rule Actions

Defines the action Flagright returns in the API response when the rule fires. One action is selected per rule.

Note: When multiple rules are triggered by the same transaction, the most severe action takes precedence. Priority hierarchy: BLOCK > SUSPEND > FLAG.

Rule Action Aliases

The default action labels (FLAG, SUSPEND, BLOCK) can be replaced with custom aliases to match internal terminology. Aliases are configured in the Rules section under Settings and apply platform-wide.

Advanced Options

Expanded via the Show advanced filters button at the bottom of Step 3. When configured, these actions execute automatically whenever the rule fires, updating user records and sending communications without manual analyst intervention. If the same rule fires multiple times with different threshold instances, the status is updated to reflect the highest priority instance.

Rule actions (FLAG / SUSPEND / BLOCK) and Advanced options expanded — automated user status updates, KYC status updates, and Apply to other risk levels.

Automated Action	Description	Sample Use Case
Users to update	Selects which users are affected by the automated actions: All users on the transaction, Origin user only, or Destination user only.	A fraud rule targets only the sender, set to Origin so the destination user's record is not affected.
Update user state to	Automatically updates the user's account status when the rule fires. Requires a reason and optional description.	A high-risk transaction rule sets the user's state to Suspended pending investigation, preventing further transactions until an analyst reviews.
Update KYC status to	Automatically updates the user's KYC status. Requires a reason and optional description.	A structuring rule flags the user's KYC status as Requires review, triggering an enhanced due diligence process without manual intervention.
Update PEP status to	Automatically updates the user's PEP classification. Requires a PEP rank and category.	A rule detecting transactions with known government-linked counterparties automatically classifies the user as a PEP for ongoing enhanced monitoring.
Update Sanctions status to	Automatically updates the user's sanctions screening status.	A transaction to a sanctioned jurisdiction automatically marks the user's sanctions status as Hit, escalating the alert for compliance review.
Update Adverse Media status to	Automatically updates the user's adverse media screening status.	A rule detecting unusual transaction patterns linked to a news-flagged entity updates the user's adverse media status to Flagged.
Update tags to	Automatically adds or updates key-value tags on the user record when the rule fires.	A high-velocity rule adds a tag such as risk_flag: velocity to the user record, making the flag visible across other rules and analyst views without changing their formal status.
Add user to list	Automatically adds the user to a specified platform list such as a watchlist or blocklist. Lists can be configured with expiry windows, enabling time-limited list membership. For example, adding a customer to an 'EODD completed' whitelist with a 365-day expiry window. Once the entry expires, the customer falls out of the whitelist and periodic monitoring rules can surface them for re-review.	When a customer completes EODD, they are added to an 'EODD completed' whitelist with a 365-day expiry. When the entry expires, a periodic monitoring rule surfaces them for re-review automatically.
Request for information	Automatically sends an email to the user using a selected ticket template when the alert is created. A 'Requires confirmation before sending' option can be enabled to prompt an analyst to approve the email before it is sent.	A rule detecting a large outgoing transfer automatically sends an RFI email requesting proof of funds, without waiting for an analyst to trigger the outreach manually.

Tip: The Request for Information automation is powerful for reducing manual workload on high-volume rules. When a rule fires, the RFI email goes out automatically, allowing analysts to focus on reviewing responses rather than triggering outreach manually for every alert.

06 - Alert Creation Details

Alert Creation Details is Step 3 of the custom scenario builder flow, and is also accessible when editing any rule from My Rules. It defines how alerts are created, assigned, and managed once the rule triggers.

Step 3: Alert Creation Details — severity (P1-P4), alert created for, creation direction, interval, false positive check, assignment, stop-adding-transactions, queue, and checklist.

Alert Severity

Sets the priority level of alerts generated by this rule, from P1 (most severe) to P4 (lowest). Used by analysts to triage and prioritize their investigation queue.

Severity	Typical Use Case
P1	Sanctions hits, blocked or suspended payments, real-time fraud alerts requiring immediate action
P2	High-risk fraud alerts, payment suspension requiring prompt review
P3	Elevated AML signals requiring investigation within standard SLA windows
P4	Low-priority post-monitoring alerts, informational flags for record-keeping

Alert Creation Logic

When a rule is triggered by a user who has transacted with multiple counterparties, alert creation logic determines whether a single consolidated alert covering all counterparties is created, or a separate alert is created per counterparty for individual investigation. This setting is configured via the Alert creation logic dropdown in Step 1 Basic Details.

Option	Best For	Considerations
Single alert for all counterparties	Teams with fewer counterparties per client. Provides a comprehensive view of a client's network and reduces queue volume.	In consolidated views it can be harder to determine which counterparties have been cleared vs. which still need review.
Separate alert per counterparty	Teams with high volumes of counterparties per client. Easier to track individual counterparty review status and manage investigation workload.	Increases total alert volume in the queue. Best used for counterparty screening rules such as R-169.

Alert Creation Interval

Interval	When to Use
Instantly	Real-time fraud alerts, sanctions hits, and suspended or blocked payments. Any scenario requiring immediate analyst action.
Weekly	Post-monitoring rules where batching reduces alert volume and analyst workload.
Monthly	Behavioural rules where aggregating activity over time produces more meaningful alerts than individual flags.

Note: Batched intervals are only appropriate for post-processing rules. Real-time rules and any rule that may result in a suspended payment must always be set to Instantly.

Auto-Close Alert

When enabled, an alert automatically closes if all subsequent transactions for this rule return an Allow response after a Transaction Event. Most useful in screening scenarios where additional data resolves the potential match.

Alert Assigned To

Option	Description
None	Alert created in the queue with no assignment. The team picks up based on availability.
Account	Routed directly to a named analyst by their platform account.
Role	Distributed equally across all analysts in a given role.

Alert Created For

Specifies whether the alert subject is the customer's own user (User, identified by user ID) or the external counterparty (Payment details, matched on payment identifiers such as IBANs, account numbers, or card fingerprints).

Note: A payment identifier is a unique combination of account details specific to each payment method. The identifier is based on the payment method:

IBAN: BIC + IBAN
CARD: Card fingerprint
ACH: Routing number + account number
UPI: UPI ID
WALLET: Wallet ID
GENERIC BANK ACCOUNT: Account number, with account type and bank code included if provided
SWIFT: Account number + SWIFT code
MPESA: Business short code + phone number
CHECK: Check identifier + check number

Alert Creation Direction

Determines whether the alert is created for the sender, the receiver, or automatically determined based on the rule logic.

Default Alert Creation Status

Controls whether new alerts start in Open or Closed status. Closed is used for monitoring-only rules where alerts are for record-keeping only.

Stop Adding Transactions to Alert

Stops new transactions from being added to an alert once it reaches a specified status. Available statuses: Open, On hold, In review, In progress, Escalated, Re-opened.

Example: An analyst investigates a flagged user and escalates the alert based on three suspicious transactions. With this setting configured to stop at Escalated, no further transactions are added while the manager reviews. Without it, five more transactions could be appended before the manager opens the case, changing the scope of the investigation and potentially invalidating the analyst's original assessment.

Alert Queue

Assigns alerts from this rule to a specific case management queue, allowing different teams (AML, Fraud, Screening) to focus on their relevant workload.

Alert Investigation Checklist

A pre-defined checklist template attached to the rule. Guides analysts through required steps before a disposition decision is made on any alert generated by this rule.

Investigation checklists are created first in Settings (left navigation), under the Investigation checklist section. Once created, they appear as options when configuring a rule. A pre-defined checklist template can then be attached to the rule so that analysts follow a consistent process on every alert it generates.

User Rules evaluate user properties based on defined rule logic, and execute whenever a new user or user event occurs. Unlike Transaction rules which are triggered by payment activity, User rules can also be configured to run on a periodic schedule (daily, weekly, etc.) regardless of whether any transactions have occurred.

Ongoing sanctions screening: run daily against your entire active user base to catch newly sanctioned individuals who were clean at onboarding
Periodic EODD (Enhanced Ongoing Due Diligence): schedule a daily rule that checks for high-risk users not on an "EODD completed" whitelist, so overdue reviews surface automatically
KYC expiry monitoring: flag users whose identity documents are approaching expiry so remediation can happen before they lapse
Risk score changes: trigger a review when a user's CRA risk score changes, even if they haven't transacted recently
Business user screening: re-screen business users and their associated shareholders and directors against PEP and sanctions lists on a set schedule

07 - SLA Policies

SLA policies define the time limits within which an alert must be investigated and resolved. Configured per rule and typically tied to regulatory obligations. Financial institutions are required to report suspicious activity to Financial Intelligence Units (FIUs) within defined timeframes.

Created first in Settings (left navigation), where you define the policy name, type, time limit, working days, and which alert statuses the SLA applies to. Once created, they appear as options when configuring a rule in Alert Creation Details (Step 3). Up to 5 policies can be attached to a single rule.

Note: Examples of FIUs include FinCEN (United States) and FINTRAC (Canada). Common SLA windows include 30 days for standard AML investigations, with stricter timelines for sanctions-related alerts.

SLA Setting	Description
Duration	The investigation time window, e.g. 30 days, 5 days, 48 hours
Scope	Which role or stage the SLA applies to: analyst, manager/reviewer, or team
Max per rule	Up to 5 SLA policies per rule
Breach tracking	SLA status visible in case management, used to prioritize investigation workload

08 - Scenario Builder

The scenario builder allows compliance teams to create fully custom rules from scratch using any parameter in the Flagright data model. Accessed via the Create scenario button on the Templates page. It uses the same Step 1 (Basic Details) as the template path, but Step 2 is a full variable definition and logic builder, and Step 3 is Alert Creation Details.

Step 1: Variable Definition

Before building the rule logic, all variables the rule will reference must be defined. Clicking Add variable reveals four variable types.

The Variable definition section showing the Add variable dropdown with Entity variable and Aggregate variable options.

Variable Type	Description
Entity variable	References a specific attribute of an entity at a point in time. Select entity type (Transaction, User, or Linked entity), transaction direction (Origin, Destination, or Both), and the specific field. Transaction fields include: type, ID, timestamp, user IDs, state, amount details, currency, country, payment method details, and all other fields in the Flagright transaction schema.
Aggregate variable	Computes a value aggregated across multiple transactions over a defined look-back window. Aggregations can be performed not only per user but also across payment identifiers, names, addresses, IP addresses, and device IDs. Variable type: Transaction or User. Use Transaction to aggregate payment data; use User to aggregate user-level attributes. Check transactions for: User ID or Payment ID. Use Payment ID to track behaviour across multiple accounts sharing the same card, IBAN, or device. Sender / receiver scope: Sender, Receiver, or Both. Set to Sender to aggregate only outgoing volumes for structuring detection. Aggregate field: The specific field to compute over, e.g. transaction amount (to sum total outflow) or transaction ID (to count frequency). Aggregate function: Sum, Average, Count, Maximum, or Minimum. Use Count for velocity rules, Sum for volume thresholds, Average for behavioural baselines. Group by: Optional. Group by a field such as destination country to count how many distinct countries a user has sent funds to. Aggregate target: Time window or Last N transactions. Use Time for rolling windows (e.g. last 30 days); use Last N to evaluate the most recent batch regardless of timing. Include current transaction: Whether the triggering transaction counts toward the aggregation. Set to Yes when it should contribute to the threshold. Time from / Time to: Defines the look-back window. Enable Rolling basis to anchor the window to the exact transaction timestamp rather than midnight. Add filters: Optional. Narrows which historical transactions are included, e.g. filter to Successful state only so declined transactions do not inflate the total.
List variable	Checks whether an entity attribute matches a value in a configured list. For example, whether a transaction's origin country appears in a custom high-risk country list.

Note: The entity variable selector exposes the full Flagright data model. Any field in the transaction or user API schema, including custom fields passed via tags, can be referenced. Note: Aggregate variables can only be used to aggregate transaction parameters, not user parameters.

The Aggregate variable configuration form showing variable type, sender/receiver scope, aggregate field, aggregate function (e.g. Count), group by field, and time window settings.

Step 2: IF / THEN Rule Logic

Once variables are defined, rule logic is constructed using an IF/THEN structure. Each condition in the IF block specifies a Variable, an Operator, and a Value. Multiple conditions can be combined using Add condition (AND logic) or Add group (OR logic between groups).

The scenario builder showing defined variables (top bar) and the IF/THEN rule logic builder with Variable, Operator, Function, and Value fields, and Add condition / Add group controls.

The IF/THEN rule logic builder showing variable selection dropdown with entity and aggregate variable options available per CRA risk level tab.

String Functions

Within a condition row, the dropdown to the left of the variable field offers a Function option in addition to standard variable selection. The Concat string function allows up to three string fields to be combined into a single unified value before comparison. This is commonly used when data is captured across separate fields but needs to be evaluated as a whole.

Function	What It Does	Sample Use Case
Concat string	Combines up to three string fields into a single unified value before comparison.	Combine first name, middle name, and last name into a full name string, then check it against a sanctions list to avoid partial name mismatches.
String to number	Converts a text-stored numeric field into a number, enabling mathematical operators such as greater than, less than, and equal to.	Merchant Category Codes (MCC) may be stored as strings. Convert the MCC to a number to apply threshold logic, such as flagging transactions where the MCC falls within a specific range.
Number to string	Converts a numeric field into a string, enabling string operators such as contains or starts with.	Convert a numeric account number to a string to check whether it starts with a specific prefix associated with a known high-risk institution.
Stopwords	Removes common filler words from a string before comparison, improving match accuracy against lists.	Remove words such as Ltd, Inc, Bank, or The from a business name before checking it against a watchlist, so that “The First National Bank” can match “First National Bank.”

Example: A customer's name is stored across three fields: first name, middle name, and last name. Using Concat string, these are combined into a single full name value, which is then compared against a sanctions or VIP list using the In list operator. This ensures the rule evaluates the complete name rather than individual name segments.

Converting Between Types

Some data fields store numeric values as text strings, which prevents the use of mathematical operators (greater than, less than, equal to). The Function dropdown to the left of the Variable field also provides type conversion options to handle this.

Function	What It Does	When to Use
String to number	Converts a text-stored numeric field into a number, enabling mathematical operators.	When the field contains numeric data (e.g. Merchant Category Codes) stored as a string in the system.
Number to string	Converts a numeric field into a string, enabling string operators.	When you need to apply string operators (contains, starts with) to a field that is stored as a number.

Note: Tags are stored as strings by default. To apply mathematical operators to a tag value, select the tag variable, enter the specific key, click 'Add sub condition' for the tag's value field, then select 'number' from the dropdown before applying your operator.

Operators

Operators define how a variable value is compared to a threshold or match criteria. The available operators depend on the variable type being evaluated. Below is the full set of operators available in the rule builder.

Operator	Description
== (Equal to)	The variable value exactly equals the specified value.
!= (Not equal to)	The variable value does not equal the specified value.
>= (Greater than or equal to)	Numeric or time value is greater than or equal to the specified value.
<= (Less than or equal to)	Numeric or time value is less than or equal to the specified value.
> (Greater than)	Numeric or time value is greater than the specified value.
< (Less than)	Numeric or time value is less than the specified value.
between	A numeric or time value falls between two specified values (inclusive).
not between	A numeric or time value does not fall between two specified values.
is null	The value has not been provided in the payload.
is not null	The value has been provided in the payload.
is empty	The value is provided but contains zero characters.
is not empty	The value is provided and contains at least one character.
any in	The variable matches any value in a provided list of values.
not in	The variable does not match any value in a provided list of values.
any in (Lists)	The value belongs to one or more specified platform lists (whitelists or blacklists).
not in (Lists)	The value does not belong to one or more specified platform lists.
contains	A string value contains the specified keyword, phrase, or full value.
not contains	A string value does not contain the specified keyword, phrase, or full value.
starts with	A string value begins with the specified characters.
ends with	A string value ends with the specified characters.
equals	Checks if any of the provided string values are identical to the variable.
not equals	Checks if none of the provided string values are identical to the variable.
similar to	Checks if the variable value is similar to any provided string using Levenshtein distance. A fuzziness percentage is configured, e.g. at 40% fuzziness, 'John' matches 'Johnnie' (0% distance) but not 'Jonathan' (75% distance).
not similar to	Checks if the variable value is not similar to any of the provided strings.
similar to (words)	Breaks the value into individual words and checks each word against the parameter values. Returns true if any word matches.
not similar to (words)	Breaks the value into individual words. Returns true if none of the words match.
some	For a list of values (e.g. multiple tags), checks if some of the variable values match the comparison value(s).
all	For a list of values, checks if all variable values match the comparison value(s).
none	For a list of values, checks if none of the variable values match the comparison value(s).
count == / != / >= / <= / > / <	Checks if the count of variable values across all objects satisfies the specified numeric comparison.
count between / count not between	Checks if the count of variable values falls within or outside a specified range.
Row Match	Used with List variables for multifactor checks. Requires multiple conditions to match simultaneously within the same row of a list, e.g. both name AND IBAN must match the same entry.
matches regex	Checks if the variable value matches a specified regular expression pattern. Used for complex text pattern matching.

Note: The Row Match operator is specifically used with List variables when checking against multifactor lists. It requires that multiple conditions match simultaneously within the same row of the list. For example, both a name AND an IBAN must match the same entry in a blacklist, rather than either matching independently.

Using the Regex Operator

A regular expression (regex) is a search pattern that identifies, matches, or validates specific text patterns. In rule creation, the regex operator (Regex match / Not regex match) checks whether a field value conforms to a defined pattern. This is useful for validating data quality, detecting irregularities, or enforcing compliance formatting standards. Tools such as LLMs can help generate regex patterns for specific use cases.

Use Case	Regex Pattern	How It Works
Name validation: flag names with 4+ consecutive consonants (possible fake names)	[bcdfghjklmnpqrstvwxyzBCDFGHJKLMNPQRSTVWXYZ]{4,}	Apply Regex match to the counterparty name entity variable. Names like 'John Smith' pass; names with irregular consonant clusters fail.
Email validation: flag invalid email formats	^[\w.%+-]+@[\w.-]+\.[a-zA-Z]{2,}$	Apply Not regex match to the email field. Entries missing '@', domain, or extension are flagged.
Account number validation: flag numbers that are not 10-12 digits	^\d{10,12}$	Apply Not regex match to the account number field. Entries with letters or incorrect digit counts are flagged.

Tip: When building regex patterns for AML use cases, LLMs such as ChatGPT can generate the correct pattern from a plain-language description. For example: 'Write a regex that matches any string containing 4 or more consecutive consonants.'

Aggregate variable filters showing OR/AND logic combining time-based conditions with country lists — for example flagging transactions outside business hours to high-risk jurisdictions.

IP Address Resolution

Flagright automatically resolves IP addresses to their associated country, enabling geo-based rule logic. IP addresses are passed in the transaction payload using the originDeviceData or destinationDeviceData object, within the ipAddress parameter. Both IPv4 and IPv6 formats are supported. Once submitted, Flagright resolves the IP to an IP country and stores it alongside the transaction. This IP country is also visible in the Console transaction view.

Use Case	How to Build It
Block transactions from high-risk countries	Create a List variable pointing to a list of high-risk or prohibited IP countries. Use the any in (Lists) operator in the rule logic to match the current transaction's IP country against the list.
Detect new or unusual IP countries per user	Create an Aggregate variable collecting all unique IP countries from a user's past transactions. Create an Entity variable for the current transaction's IP country. Use 'not in' logic to trigger an alert if the current IP country is not among the user's historical IP countries, indicating a potential geographic anomaly or account compromise.

Tip: IP-based rules pair well with the R-87 (High risk IP address countries) and R-88 (Unexpected IP address for user) templates in the library, which implement these patterns as pre-configured starting points.

AIF Rule Builder

Available throughout Step 2 as a modal popup. Describe a monitoring scenario in plain natural language. The AI generates the corresponding variable definitions and rule condition logic automatically, including suggested examples such as 'Flag transactions where the amount exceeds the user's average over the last 90 days by more than 400%'. Takes a human-in-the-loop approach: the generated configuration is returned to the editor for review and adjustment before saving.

User-type rules can be configured to run on a periodic schedule (for example, daily) rather than being triggered solely by transaction or user events. This enables scheduled ongoing monitoring use cases where customers need to be evaluated at defined intervals regardless of transaction activity.

Example: Enhanced Ongoing Due Diligence (EODD): A periodic rule runs daily and checks for high-risk customers who are not on an 'EODD completed' whitelist. When EODD is completed for a customer, an automated action adds them to the whitelist with a 365-day expiry. Once the expiry passes, the customer falls out of the whitelist and the daily rule fires, surfacing them for re-review. This creates an automated, self-resetting EODD scheduling system entirely within the rules engine.

Multifactor Blacklists

The List variable type, combined with the Row Match operator, enables multifactor blacklist checks, blocking or flagging based on combinations of fields rather than single values. This prevents fraudsters from bypassing a check by altering one detail while keeping others the same.

Example: A custom blacklist is created with two columns: Name and IBAN. A rule checks incoming transactions using the Row Match operator, requiring both the counterparty name AND IBAN to match the same row in the blacklist simultaneously. A partial match on name alone does not trigger the rule. Both conditions must align.

09 - Rule Templates

The Templates tab contains a library of pre-built rule configurations covering the most common AML and fraud typologies. Templates can be searched using natural language and filtered by type. Each template is tagged with a type describing its detection pattern.

The Templates tab — natural language search bar, Create scenario button, and the full list of pre-built templates with rule type, description, typology, and Configure button.

Dynamic Rules

Dynamic rules automatically identify unusual patterns in customer transaction behaviour by comparing recent activity against historical baselines, using statistical analysis. Unlike standard templates where you set fixed thresholds, dynamic rules require zero manual configuration. The system learns from each customer's historical data and triggers when behaviour deviates significantly from their own established patterns.

When recent activity deviates by more than 2 standard deviations from the baseline period's patterns, the rule triggers an alert. This statistical threshold reduces false positives while maintaining sensitivity to genuine anomalies.

Rule	What It Detects	Recent Window	Baseline Window	Min. History Required
R-11: Transaction anomaly	Unusual changes in transaction volumes, specifically patterns falling outside normal statistical ranges.	Last 7 days	Last 30 days	30 days
R-12: Transaction frequency anomaly	Significant increases or decreases in transaction count.	Last 30 days	Last 90 days	90 days
R-25: Average transaction value spike	Sudden upward spikes in average transaction amounts. Only triggers on increases, not decreases.	Last 30 days	Last 90 days	90 days
R-26: Round-amount anomaly	Unusual increases in round-number transactions (e.g. $100, $500, $1,000), comparing the percentage of round amounts in recent activity against historical baseline. May indicate structuring.	Last 30 days	Last 90 days	90 days

Note: Dynamic rules require minimum transaction history to establish reliable baselines. For new customers with limited history, these rules will not trigger until sufficient data is available. R-11 requires 30 days minimum; R-12, R-25, and R-26 require 90 days.

Template Parameter Depth

Template parameters vary in depth depending on the detection pattern. The R-131 template (Transactions exceed past period), which detects unusual spikes in transaction volume relative to a historical comparison window, illustrates the level of configuration available across templates.

R-131 Rule Parameters showing the 3-step template flow, CRA risk thresholds (Yes selected enabling per-risk-level customization), Time period 1, Time period 2, and Multiplier threshold fields.

Parameter	Description
Time period 1	The recent time window measuring current activity (e.g. 7 days). Supports a Rolling basis option. When enabled, the window looks back from the exact time the rule fires rather than from 00:00 of the selected unit.
Time period 2	The earlier comparison window. Must be larger than time period 1, and time period 1 is excluded from it. Also supports rolling basis.
Multiplier threshold	The rule fires when transactions in time period 1 exceed transactions in time period 2 multiplied by this value. A multiplier of 3 means current activity must be more than three times the comparison period.
Minimum transactions in period 1	Optional floor. The rule will not fire unless at least this many transactions occurred in the recent window. Avoids false positives from users with very low absolute volumes.
Minimum transactions in period 2	Optional floor for the comparison period (with time period 1 excluded).
Initial transactions count threshold	Optional. The rule only executes once a user's cumulative transaction count reaches this value. Ensures the rule applies only to users with sufficient history to make the comparison meaningful.
Transaction direction (sender/receiver)	Controls which transactions are included for each side of the transaction: Sending only, Receiving only, All, or None.
Apply to other risk levels	Allows the same parameter configuration to be applied across multiple CRA risk levels in one action, reducing manual setup time.

Tip: These parameters illustrate how templates support precise calibration to reduce false positives. Minimum transaction floors and initial count thresholds in particular are important for ensuring rules only fire for users where the detection pattern is statistically meaningful.

10 - Simulator

The Simulator tests how a rule would have performed against historical transaction data before it is deployed live. Toggle it on from the My Rules page. Each rule then displays a Simulate button.

Tool	Data Used	Purpose
Simulator	Historical past transactions	Validate rule logic and calibrate thresholds against real historical data before deployment.
Shadow rules	Future live transactions (silent)	Observe rule behaviour on real incoming traffic without affecting the live environment.

Simulation Types

Type	Description
Automated sample	Simulates the rule for a random set of transactions or all transactions over the configured period. Best for broad validation across a representative cross-section of transaction history.
Manual sample	Simulates only for specific selected transactions or a specific user's transactions. Useful for testing against known cases.

Simulation Setup

Step 1 sets the simulation period (custom date range) and sample size (1,000 to 100,000 transactions). Step 2 mirrors the rule logic editor. The rule parameters can be modified here to test variations without affecting the live rule. The Duplicate tab allows multiple iterations to run side by side for comparison.

Tip: The recommended path for any new or significantly changed rule is: Simulator (validate on historical data) → Shadow rule (observe on live traffic) → Activate live.

After a simulation runs, the results window shows three metrics comparing the rule's performance Before and After the parameter changes tested in that iteration:

Delta of cases created: The change in the number of alerts that would have been generated. A positive delta means the new parameters produce more alerts; a negative delta means fewer. Use this to understand whether a threshold change increases or reduces your team's workload.
Delta of transactions hit: The change in the number of individual transactions that triggered the rule. A high number here relative to cases created indicates multiple transactions are being grouped into the same alert.
Delta of users hit: The change in the number of distinct users who would have been flagged. Compare this against the transactions hit to understand whether the rule is catching a broad user population or concentrating on a smaller set of high-frequency users.

The percentage shown alongside each metric indicates the magnitude of the change relative to the original rule's baseline. The bar charts show Before vs After side by side so you can visually assess the impact of your parameter changes before committing them to the live rule.

11 - Importing & Exporting Rules

Flagright's import and export functionality allows rules to be migrated between environments (for example, from sandbox to production) without recreating them manually. Both functions are accessed via the JSON icon in the top-right area of the My Rules table.

Exporting Rules

Go to Rules > My Rules in the source environment and select the export JSON icon. The Export rules modal displays all available rules. Select the rules to export and click Export. This downloads a .txt file containing the rule configurations.

Importing Rules

Go to Rules > My Rules in the destination environment and select the import JSON icon. Click Upload rules, then drag and drop or select the downloaded .txt file and click OK. Allow a few minutes for the rule logic to fully process and update in the new environment.

Post-Import Reconfiguration

Two items require manual reconfiguration after import, as they are environment-specific and will not transfer automatically.

Item	Why It Needs Reconfiguring	What to Do
List references	List IDs are unique to each environment. Rules that reference lists as variables will have broken references after import.	Migrate lists separately via the Lists section (Download and Import CSV), then update each rule to reference the correct list ID in the new environment.
SLA policies	SLA configurations are not carried over in the rule export.	Recreate the required SLA policies in the destination environment and reattach them to the imported rules.

Note: Before starting a migration, confirm that the number of CRA risk levels is the same in both the source and destination environments. A mismatch in risk level configuration may cause rule logic to apply incorrectly after import.

12 - Shadow Rules

Shadow rules run in parallel with live rules but do not create actual alerts or cases. Instead, they log hypothetical hit statistics, allowing compliance teams to observe how a rule would behave on real traffic before committing to it as a live rule. Shadow rules are a key tool for validating new rules and reducing the risk of misconfigurations.

Note: Shadow rules and the Simulator serve different purposes. The Simulator runs a rule against historical past transaction data for backtesting. Shadow rules run silently on future live transactions in real time, without generating alerts or affecting any transaction outcomes.

Setting Up a Shadow Rule

Shadow rules are configured through the same flow as live rules. Navigate to Rules and open the Templates section. Choose a template or use the scenario builder to configure a custom rule. Once all settings are finalized, click Done. A prompt will appear asking whether to deploy the rule as a Live rule or a Shadow rule. Select Shadow rule.

All shadow rules appear under My Rules in the Shadow rules tab. From there they can be edited, duplicated, deleted, enabled, or disabled at any time.

The Shadow rules tab in My Rules showing all configured shadow rules with hit rate, queue, timestamps, enabled toggle, and Edit / Duplicate / Delete actions.

Promoting a Shadow Rule to Live

When a shadow rule is ready to go live, open the rule by clicking its rule ID in My Rules. Click the Change to live rule button. The rule will immediately begin generating real alerts and cases and will appear under the Live rules tab.

Individual rule detail view showing the Change to live rule button alongside Edit rule, Simulate rule, Duplicate rule, and Delete rule actions.

Demoting a Live Rule to Shadow

An active live rule can be converted back to a shadow rule at any time. Open the rule by clicking its rule ID, then click Change to shadow rule. The rule will stop generating alerts and revert to silent monitoring mode.

Individual rule detail view for a live rule showing the Change to shadow rule option alongside other rule management actions.

Tip: The recommended deployment path for any new rule is: configure and test with the Simulator against historical data, then deploy as a Shadow rule to validate on live traffic, then promote to a Live rule once confident in its behaviour. On average, customers monitor shadow rules for approximately one week before promoting them to live.

13 - Template Parameter Reference

This section documents the configurable parameters for the most commonly deployed rule templates. Several parameters appear across multiple templates and are defined once here for reference.

Common Parameters Across Templates

Parameter	Description
Rule actions	Determines the action taken when the rule fires. Can be set differently per CRA risk level — for example, FLAG for low-risk users and BLOCK for high-risk users.
Apply to other risk levels	Copies the current parameter settings and rule action to one or more additional CRA risk levels in a single step, reducing manual configuration effort.
Time window	Defines the look-back period for historical analysis. Configured as a number of time units and a granularity (seconds, minutes, hours, days, weeks, months, years, or fiscal years).
Rolling basis	When enabled, the time window starts at the exact timestamp of the current transaction. When disabled, it starts at 00:00 of the configured time unit. Optional.
Sender direction to check	Controls which transactions are included based on the user's role as sender. Options: Sending (sender only), All (all transactions regardless of direction), None (exclude sender transactions).
Receiver direction to check	Controls which transactions are included based on the user's role as receiver. Options: Receiving (receiver only), All (all transactions), None (exclude receiver transactions).
Match payment method details (origin)	When enabled, the sender is identified by payment method details rather than user ID. Useful when the same payment details appear across multiple user accounts.
Match payment method details (destination)	When enabled, the receiver is identified by payment method details rather than user ID.

R-2: Transaction Amount Too High

Creates an alert when a user makes a transaction above a defined amount threshold. Useful for detecting unexpectedly large transactions relative to a customer's expected profile.

Parameter	Description
Transaction amount threshold	Set the currency and threshold amount. Multiple thresholds can be added for different currencies — one threshold per currency. If a duplicate currency is added, only the latest value is used.
Rule actions / Apply to other risk levels	See Common Parameters above.

R-7: Too Many Inbound Transactions Under Reporting Limit

Triggers when a user receives too many low-value inbound transactions within a defined amount range. Designed to detect structuring — deliberately keeping transactions below reporting thresholds.

Parameter	Description
Low transaction value	Set the currency, minimum value, and maximum value that define what counts as a 'low value' transaction. For example: USD $950 minimum, $1,000 maximum targets transactions just below the CTR reporting threshold.
Low-value transactions count threshold	The minimum number of qualifying low-value inbound transactions that must occur before the rule triggers an alert.
Rule actions / Apply to other risk levels	See Common Parameters above.

Example: Configured with: Low value range $950-$1,000 USD, count threshold 3, action FLAG. If a user receives 3 or more transactions between $950 and $1,000, an alert is triggered.

R-8: Too Many Outbound Transactions Under Reporting Limit

Same detection logic as R-7 but for outbound (sending) transactions. Triggers when a user sends too many low-value transactions within a defined amount range.

Parameter	Description
Low transaction value	Set the currency, minimum value, and maximum value defining 'low value' for outbound transactions.
Low-value transactions count threshold	The minimum number of qualifying low-value outbound transactions before the rule triggers.
Rule actions / Apply to other risk levels	See Common Parameters above.

Example: Configured with: Low value range $1,450-$1,500 USD, count threshold 30, action FLAG. If a user sends 30 or more transactions between $1,450 and $1,500, an alert is triggered.

R-9: Too Many Customers for a Single Counterparty

Creates an alert when more than a threshold number of different users transact with the same counterparty (payment identifier) within a time window. Detects fraudulent counterparties targeting multiple victims with a common scheme — for example, a single fraudulent bank account receiving funds from many deceived users.

Parameter	Description
Senders count threshold	The minimum number of distinct users that must transact with the same counterparty before the rule fires.
Time window	The look-back period over which the count is measured. See Common Parameters.
Rolling basis	See Common Parameters.
Rule actions / Apply to other risk levels	See Common Parameters.

Note: This rule checks transactions from different users to one payment identifier. Payments where the destination is a known user ID (rather than an external payment identifier) are excluded.

R-10: Too Many Counterparties for a Single Customer

Creates an alert when a single user transacts with more than a threshold number of distinct counterparties (payment identifiers) within a time window. Detects money mule accounts receiving funds from many different sources, or users being targeted by multiple deceptive counterparties.

Parameter	Description
Senders count threshold	The minimum number of distinct counterparties transacting with the same user before the rule fires.
Time window	The look-back period over which the count is measured. See Common Parameters.
Rolling basis	See Common Parameters.
Rule actions / Apply to other risk levels	See Common Parameters.

Note: This rule checks transactions from different payment identifiers to one user. Payments where the origin is a known user ID are excluded from the count.

R-30: High Velocity User

Identifies users who perform more than a threshold number of transactions within a specified time period. High transaction velocity can indicate money mule activity, acquiring fraud, or layering of funds.

Parameter	Description
Transactions count threshold	The minimum number of transactions a user must complete within the time window for the rule to trigger.
Time window	The look-back period. See Common Parameters.
Rolling basis	See Common Parameters.
Sender direction to check	See Common Parameters.
Receiver direction to check	See Common Parameters.
Match payment method details (origin/destination)	See Common Parameters.
Only check transactions from known users	When enabled, only transactions where the counterparty has a known user ID are included in the count.
Rule actions	See Common Parameters.

R-119: High Velocity Between the Same Parties

Identifies instances where the same sender and receiver are involved in more than a threshold number of transactions within a time window. Detects high-frequency activity between specific parties that may indicate layering, round-tripping, or coordinated fraud.

Parameter	Description
Transactions count threshold	The minimum number of transactions between the same parties within the time window to trigger the rule.
Time window	Supports granularities down to seconds, and includes a fiscal year option (1 Jan to 31 Dec, or 1 Apr to 31 Mar). See Common Parameters.
Rolling basis	See Common Parameters.
Match payment method details (origin/destination)	When enabled, parties are identified by payment details rather than user ID, allowing matching even when user IDs differ. Useful when multiple accounts share the same payment method (e.g. joint or company accounts). See Common Parameters.
Rule actions	See Common Parameters.

R-120: Average Transaction Amount Exceeds Past Period Average

Identifies users whose average transaction amount in a recent period has increased significantly compared to a historical reference period. Detects behavioral changes characterized by a substantial rise in transaction values.

Parameter	Description
Period 1 (number of days)	The recent comparison window. The rule evaluates the user's average transaction amount during this period.
Period 2 (number of days)	The historical reference window. Must be longer than Period 1. Used as the baseline average.
Rolling basis (per period)	Can be set independently for each period. See Common Parameters. Note: when rolling basis is enabled for both periods, ensure the start times align to avoid overlapping or skipping transactions.
Exclude Period 1 transactions from Period 2	When enabled, transactions from Period 1 are excluded from the Period 2 average calculation, ensuring a clean historical baseline.
Multiplier as percentage	The threshold for triggering the rule. For example, 200% means Period 1 average must be at least twice the Period 2 average. The rule fires when the increase meets or exceeds this percentage.
Currency code	All transactions in other currencies are converted to this currency before calculating averages.
Min/Max transaction count (Period 1 and Period 2)	Optional floors and ceilings on the number of transactions in each period. Used to exclude users with very low or very high transaction counts where the average may not be statistically meaningful.
Average amount threshold (Period 1)	Optional min/max values for the Period 1 average. Allows excluding cases where the absolute average falls outside a meaningful range.
Sender/Receiver direction to check	See Common Parameters.
Rule actions	See Common Parameters.

R-124: Too Many Round Transactions

Detects users whose transactions contain an unusually high proportion of round amounts (ending in .00). Frequent round-number transactions can indicate structuring or attempts to obscure the true nature of fund movements.

Parameter	Description
Threshold percentage limit	The percentage of a user's transactions (in a given direction within the time window) that must be round amounts to trigger the rule. For example, 80% means the rule fires when 80% or more of transactions are round amounts.
Initial transactions count threshold	The minimum number of transactions a user must have completed in a given direction before the rule applies. Ensures the percentage calculation is statistically meaningful.
Time window	See Common Parameters.
Rolling basis	See Common Parameters.
Sender/Receiver direction to check	See Common Parameters.
Rule actions / Apply to other risk levels	See Common Parameters.

R-126: High Volume Between Same Parties

Identifies when the cumulative transaction volume between the same sender and receiver exceeds a threshold within a time window. Unlike R-119 which counts transaction frequency, R-126 measures the total monetary volume. Detects high-value fund flows between specific parties that may indicate money laundering.

Parameter	Description
Transactions volume threshold	Set the currency and cumulative amount threshold. The rule fires when the total value of transactions between the same parties meets or exceeds this amount within the time window.
Transactions count threshold	A minimum number of transactions that must occur before the volume threshold is evaluated. For example, if set to 15, a cumulative volume breach reached in only 3 transactions will not trigger the rule.
Time window	See Common Parameters.
Rolling basis	See Common Parameters.
Match payment method details (origin/destination)	See Common Parameters.
Rule actions / Apply to other risk levels	See Common Parameters.

Transaction Monitoring