Transaction Monitoring Rules: 10 Fintech Examples

Transaction monitoring is where AML stops being a one-off check and becomes a daily job. Screening tells you who the customer is. Monitoring tells you what they are doing with the account, and whether that still makes sense.

The hard part is not writing rules. It is writing rules that find real cases without burying the team in alerts. Below are ten rules most fintech programs start with, why each one exists, and what to watch when tuning it.

Rules about how money moves

1. Rapid in and out. Funds arrive and most of the balance leaves within a short window, for example 80% out within 24 hours. This is the classic mule pattern: the account exists to pass money on, not to hold it. Tune the window to your product; a payroll wallet behaves differently from a savings app.

2. Many senders, one receiver. An account receives transfers from an unusual number of different people in a short period, especially people who have never paid this customer before. Collection accounts for scams look exactly like this.

3. One sender, many receivers. The reverse pattern: funds spread out from one account to many new beneficiaries. It often follows rule 2 a step later in the chain.

4. Structuring. Several transactions just below a reporting or review threshold, close together. One is normal. A series of near-threshold amounts in a day or a week is a reason to look.

5. Round amounts. A run of exact round numbers in and out. On its own it means little. Combined with rule 1 or 4, it adds weight.

Rules about the customer's profile

6. Activity out of line with the profile. A customer who declared a modest income or a student status suddenly moves volumes far above that level. This is the rule that ties monitoring back to onboarding data, so the profile has to be stored and kept current.

7. Dormant account wakes up. An account with little or no activity for months suddenly sees large or frequent transactions. Sold or rented accounts often behave like this.

8. Sudden change in pattern. A sharp jump compared with the customer's own history: transaction count, total value, or number of beneficiaries several times the usual monthly level.

Rules about counterparties and geography

9. New beneficiary, large transfer. A high-value transfer to a beneficiary added minutes or hours ago. This overlaps with fraud as much as AML, which is why it helps to run both on the same platform.

10. High-risk counterparties and jurisdictions. Transfers to or from counterparties that match a watchlist, or to jurisdictions your risk assessment marks as high risk. Screen the counterparty at the time of the transfer, not only the customer at onboarding.

How to keep the alert volume manageable

Score, then decide. Not every rule hit needs a person. Combine hits into a risk score per customer and route the highest-risk ones first. One weak signal rarely matters. Three on the same account in the same week usually do.

Segment your thresholds. A merchant account and a personal wallet should not share the same limits. Set thresholds per customer segment so one segment's normal does not flood the queue with false alerts from another.

Measure every rule. Track how many alerts each rule produces and how many turn into real cases. A rule that has not produced a single real case in three months needs tuning or retirement. A rule with a high hit rate might deserve a lower threshold.

Test before you switch on. Run new rules in observation mode against recent data before they create live alerts. You will see the volume they generate and the kind of cases they find before the team has to work them.

From alert to case

An alert is only useful if someone can act on it quickly. Each alert should open a case that shows the rule that fired, the transactions behind it, the customer's profile, and any linked accounts or devices. The analyst records a decision and the reasoning. When the pattern meets your reporting criteria, the case moves to compliance for the suspicious activity report decision.

Group alerts on the same customer into one case. Five alerts on one account in a week are one investigation, not five.

Where fraud and AML meet

Several of these rules, especially 1, 2, and 9, catch fraud victims and mule accounts at the same time. When fraud and AML run in separate tools, the fraud team sees a scam victim and the AML team sees an unusual account, and nobody connects them. Running both on the same customer and device records closes that gap.

Naiza supports full transaction monitoring with configurable AML rules, counterparty screening, CLEAR or ALERTED outcomes, cases, and SAR workflows, on the same platform as fraud decisions and device intelligence. The transaction monitoring entry covers the terminology, and our post on money mule account signals goes deeper on rules 1 to 3.