Rules

​

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: 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
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