Build a monitoring rule and get it approved

FlowSentry's guided rule builder lets you write a monitoring rule without code. You describe what to watch, set conditions and thresholds by point and click, see the rule written back to you as a sentence, and backtest it against history. Nothing goes live until a different person approves it. In this tutorial you will build a rule that flags customers who receive many mobile-money transfers from different senders in a short time — a common sign of a mule account.

Before you start

• Author: Analyst, Senior analyst, MLRO or Deputy MLRO role.
• Approver: MLRO, Deputy MLRO or Administrator role — a different person from the author — with a second factor enrolled for step-up.
• Look in the Rule library (/monitoring/rules) first. A built-in scenario may already cover the pattern, and tuning it is often better than writing a new rule.

Step 1: Start the rule

1. Open Monitoring › Create rule (/monitoring/rules/new).
2. Under "How do you want to start?", choose one of:
   • Describe it in plain English — for example, "flag customers receiving more than 8 mobile transfers from different people in 12 hours". The AI drafts the rule; you review every part before anything is saved, and Notes from the AI draft explain its assumptions.
   • Or start from a built-in scenario — copies the scenario as a starting point.
   • Start from a blank rule — you choose everything yourself.

For this tutorial, start from a blank rule.

Step 2: Basics

1. Give the rule a clear Name, such as "Mule fan-in — many senders to one wallet".
2. Pick the Typology (for example, money mules). Suggest from typology can propose sensible defaults.
3. Choose the Severity (Low, Medium, High or Critical) and, if your institution uses it, the Score weight.

Step 3: What to watch

1. Select the Transaction types the rule looks at (for example, wallet credits) and the Channels (for example, mobile money).
2. Under Add up activity for, choose how to group transactions: per customer, per account or per counterparty.
3. Set the window: Over a window of 12 hours.

Step 4: Conditions

1. Add a condition: "number of transactions ≥" and type a value such as 8.
2. Add a second: "number of distinct senders ≥" or "total amount ≥" — whatever describes the pattern.
3. Optionally restrict a condition to some transactions only (for example, amounts below a threshold).
4. Combine conditions with All of (every condition must hold) or Any of.

Step 5: Thresholds

Every number you typed becomes a named threshold — a parameter your institution can tune later without rewriting the rule. On Thresholds, check each one's name, value and currency. Money thresholds can carry calibrations for other base currencies.

Set the Cool-off (hours) under After an alert so one sustained pattern raises one alert rather than dozens.

Note: Never hard-wire a figure that may differ between institutions or change over time. Thresholds exist so that tuning is a governed parameter change, not a new rule.

Step 6: Review and test

1. Read the sentence describing the rule. If it does not say what you meant, go back and fix the step.
2. Fix anything flagged. Until then you see "Fix the problems above to submit."
3. Run the backtest. FlowSentry replays stored transactions through your unsaved rule exactly as the live engine would and shows Projected alerts, distinct subjects and an estimate of false positives based on past decisions. "The rule would have stayed silent over this window." means it raised nothing.
4. Adjust thresholds until the projected volume is workable and the alerts look meaningful.

Step 7: Save or submit

• Save draft keeps your work; only you can see a draft.
• Submit for approval saves this version and sends it to a second person. The rule shows as Awaiting approval in the library and appears in the approver's My approvals inbox and notifications.

You can withdraw a submitted rule until it is decided.

Step 8: The approver decides

1. The approver opens the rule from My approvals (/approvals/inbox) or the rule library.
2. They read In plain English, the scope, window, conditions and thresholds, and the backtest. Compare shows the difference from the previous version.
3. They select Approve and complete step-up, or Reject with a reason that the author will see.

The author sees "Waiting for a second person. You cannot approve your own change." — FlowSentry blocks self-approval on the server, whatever roles you hold.

Once approved, the version is Active and the engine starts evaluating it. Earlier versions remain in the version history.

Tuning a built-in scenario instead

Open a built-in rule in the library and select Tune. The wizard opens on it; change a threshold, review, backtest and submit. Once approved, your version replaces the built-in for your institution only — other institutions keep the built-in. Retiring your version later brings the built-in back. See Switch a built-in scenario off or back on.

After go-live

• Watch Rule performance (/monitoring/performance) for alert volumes and outcomes.
• Use Backtest (/monitoring/backtest) on saved rules when someone asks why a rule is noisy.
• Advanced users can open Advanced › Edit as JSON, but every change still follows the same approval.

Related

• Rules without code: the guided rule builder
• Analyst guide
• Key concepts