Rule Examples
This guide walks through two complete, real-world rules built using the FraudShield Rule Builder. The examples are ordered by complexity - starting with a simple transactional rule before moving on to a more advanced historical rule that builds directly on the first.
If you are not yet familiar with the Rule Builder interface, read the Rule Builder guide first.
Example 1: High-Value Single Transaction
Many financial regulations require that transactions exceeding a set amount - commonly 10,000 - be reported to the relevant authority. This rule flags any single incoming deposit that meets or exceeds this threshold for immediate review.
Rule Details
| Field | Value |
|---|---|
| Name | High-value single transaction. |
| Risk Level | Medium. |
| Rule Group | General. |
| Risk Score | 25. |
| Regulatory Reporting | On. |
| Description | Flag any single incoming deposit meeting or exceeding 10,000 for immediate review and regulatory reporting. |
Rule Type
Select Transaction Only - a large deposit is suspicious in isolation and does not require historical context to be actionable. This also means the rule is evaluated instantly, with no additional query overhead.
Triggers
Set the Account Focus to Destination - the focus is the account receiving the funds, since the concern is large sums arriving into an account.
Add two condition rows joined by AND:
| Attribute | Operator | Value |
|---|---|---|
| Transaction Type | = | Deposit |
| Transaction Amount | >= | 10000 |
This rule is scoped to Deposit only, as the intent is to monitor large sums formally entering an account. Other incoming transaction types carry different risk profiles and are better handled by their own dedicated rules - this keeps the logic clean and avoids false positives. That said, this condition is fully flexible; if your requirements call for monitoring additional transaction types, multiple values can be added to the Transaction Type condition in the same way as Example 2.
The 10,000 threshold aligns with common regulatory reporting obligations, such as Currency Transaction Reports (CTRs), ensuring the rule captures any transaction that crosses the reporting threshold.
The resulting trigger expression is:
#{account} is {dest} AND #{trans_type} = {Deposit} AND #{amount} >= 10000
If both conditions are met, the rule immediately raises a case. Because this is a Transactional rule, there are no Queries or Result sections to configure.
A customer receives a single deposit of 14,500. The transaction type is Deposit and the amount exceeds 10,000, satisfying both trigger conditions. A medium-risk case is raised immediately and flagged for regulatory reporting.
Example 2: Structuring Under Reporting Thresholds
Structuring (also known as smurfing) is the practice of deliberately breaking up large transactions into smaller amounts to avoid triggering the reporting threshold set in Example 1. Because no single transaction is large enough to trigger that rule, a historical rule is needed to detect the pattern across multiple transactions over time.
Rule Details
| Field | Value |
|---|---|
| Name | Structuring under reporting thresholds. |
| Risk Level | High. |
| Rule Group | General. |
| Risk Score | 40. |
| Regulatory Reporting | On. |
| Description | Identify potential attempts to avoid reporting thresholds by making multiple smaller transactions. If the total count and combined sum reach the defined thresholds, raise a case for further investigation. |
Unlike a large deposit which may have an innocent explanation, a pattern of transactions specifically sized to stay under the reporting threshold is a strong indicator of deliberate evasion. Structuring is a criminal offence in many jurisdictions and is subject to mandatory reporting obligations such as Suspicious Transaction Reports (STRs) and Suspicious Matter Reports (SMRs) - hence the High risk rating and enabled Regulatory Reporting.
Rule Type
Select Historical - the behaviour only becomes visible when multiple transactions are examined together. No single transaction in a structuring pattern appears suspicious in isolation.
Triggers
Set the Account Focus to Destination - as with Example 1, the focus is the account receiving the funds.
Add a single condition row:
| Attribute | Operator | Value(s) |
|---|---|---|
| Transaction Type | = | ATM Deposit, Payment, Deposit, Transfer, Asset Sale |
In contrast to Example 1, this rule deliberately casts a wide net across incoming transaction types. A bad actor may mix methods - deposits, transfers, payments - to further obscure the pattern, so monitoring all common incoming types gives a more complete picture. Outgoing transaction types are excluded, as the rule only tracks funds arriving into the account.
The resulting trigger expression is:
#{account} is {dest} AND #{trans_type} = {ATMDeposit,Payment,Deposit,Transfer,AssetSale}
Query (Q1)
Add a query with the following configuration:
| Field | Value |
|---|---|
| Query Type | Transaction Count and Amount Sum. |
| Time Window | Past 7 day from Transaction time. |
| Account's Role | Destination. |
Apply the same transaction type condition as the Triggers:
| Attribute | Operator | Value(s) |
|---|---|---|
| Transaction Type | = | ATM Deposit, Payment, Deposit, Transfer, Asset Sale |
A 7-day window is wide enough to catch structured activity spread across several days, while remaining short enough to stay relevant to the current transaction. Mirroring the trigger conditions here is important - without them, the count and sum could include transaction types outside the scope of this rule, which would skew the result.
This query returns two output variables: Q1_count and Q1_sum.
QUERY COUNT({amount}), SUM({amount})
FROM DATA
PAST 7 day FROM transaction date
WHERE #{account} is {dest} AND #{trans_type} = {ATMDeposit,Payment,Deposit,Transfer,AssetSale}
Result
Add two conditions joined by AND:
| Variable | Operator | Value |
|---|---|---|
| Q1_count | >= | 3 |
| Q1_sum | >= | 10000 |
Requiring at least three transactions reduces the likelihood of a false positive - two transactions totalling 10,000 could easily be coincidental, whereas three or more suggests a more deliberate pattern. The 10,000 sum threshold directly mirrors the reporting threshold from Example 1, capturing cumulative activity that would have triggered that rule if conducted as a single transaction.
Q1_count >= 3 AND Q1_sum >= 10000
A customer makes three deposits over 6 days - 3,500, 3,200, and 4,100 - totalling 10,800. No individual transaction triggers the high-value rule from Example 1. However, when the third transaction is processed, Q1_count = 3 and Q1_sum = 10,800, satisfying both result conditions. A high-risk case is raised automatically and flagged for regulatory reporting.
Move on to Deploying Your Rule to learn how to activate your rules and make them live.