> ## Documentation Index
> Fetch the complete documentation index at: https://sigma-docs.pastelhq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Rules

> Rules are predefined instructions used by Sigma AI to evaluate transactions. They determine whether a transaction should be flagged for manual review, automatically approved, or rejected, based on the specific conditions defined within each rule.

### What are Rules?

Rules are configurable conditions that tell Sigma how to evaluate a transaction. When a transaction matches the conditions in a rule, Sigma applies the action you defined: approve, flag for review, or reject.

Rules give you control over what Sigma flags and what it lets through. Without rules, Sigma uses its default AI model alone. With rules, you layer your own business logic on top, for example automatically rejecting crypto-related transactions or flagging all transfers above a certain amount regardless of the AI's confidence.

### Rule Components

Each rule has three parts:

**Conditions**: the criteria a transaction must meet to trigger the rule. You can combine multiple conditions using `AND` (all must match) or `OR` (any must match). Available condition fields include:

* Transaction amount (greater than, less than, between)
* Transaction type (deposit, withdrawal, transfer)
* Transaction channel (card, mobile, USSD, POS)
* Sender or receiver country
* Sender or receiver bank code
* Transaction hour or day of week
* Device ID, user ID, or account number
* Number of transactions in a time window (frequency)

**Action**: what Sigma does when the rule fires:

| Action    | Effect                                          |
| --------- | ----------------------------------------------- |
| `APPROVE` | Bypass further checks and allow the transaction |
| `REVIEW`  | Flag the transaction for manual investigation   |
| `REJECT`  | Block the transaction immediately               |

**Priority**: when multiple rules match a transaction, the rule with the highest priority takes effect. Set priority carefully: a high-priority `APPROVE` rule can override a lower-priority `REJECT`.

### How to Create a Rule

1. Log in to [Sigma](https://sigma.pastelhq.ai/)
2. Go to **Transaction Monitoring → Rules**
3. Click **Create Rule**
4. Choose to build from scratch or start from a template
5. Define your conditions, select an action, and set a priority
6. Save and activate the rule

Rules take effect immediately after activation.

### Common Rules

**Large transaction amounts**

Flag any single transaction that exceeds a defined amount threshold, especially if it is unusually high relative to the customer's typical behaviour.

*Example: REVIEW any transfer above ₦5,000,000*

***

**Transactions from high-risk countries**

Block or flag transactions where the sender or receiver country is a jurisdiction under international sanctions or on your institution's high-risk country list.

*Example: REJECT any transaction where `sender_country` is in `[IR, KP, SY]`*

***

**Frequent transfers to the same account**

Detect repeated transfers to the same beneficiary within a short time window, a common indicator of structuring or account takeover.

*Example: REVIEW when more than 5 transfers to the same `receiver_account_number` occur within 24 hours*

***

**Unusual transaction times**

Flag transactions executed outside normal business hours or at times inconsistent with the customer's known patterns.

*Example: REVIEW any transaction between midnight and 5am*

***

**Rapid successive transactions**

Identify bursts of activity from a single user that may indicate automated fraud or account compromise.

*Example: REVIEW when more than 10 transactions are submitted from the same `user_id` within 1 hour*

***

**High-value first transaction**

Flag when a new account's first transaction is unusually large, a pattern associated with newly created mule accounts.

*Example: REVIEW when `account_age_days` is less than 7 and `amount` is greater than ₦500,000*

***

**Failed transaction patterns**

Track users or devices with repeated failed attempts, which may signal credential stuffing or brute-force fraud.

*Example: REVIEW when more than 5 failed transactions occur from the same `device_id` in 30 minutes*

### Tuning Your Rules

Rules that are too broad generate false positives: legitimate transactions flagged for review, slowing operations and frustrating customers. Rules that are too narrow miss real fraud.

Start conservative:

* Begin with higher thresholds and tighten them as you observe your transaction patterns
* Monitor how often each rule fires and what percentage of flagged transactions turn out to be genuine fraud
* If a rule generates mostly false positives, raise its threshold or add an additional condition to narrow it
* Review your rules quarterly as transaction patterns and fraud tactics change over time

<Note>
  Start simple, monitor outcomes, and tune your rules over time to reduce false positives while staying secure.
</Note>