Transaction monitoring: how to watch payments for fraud
Transaction monitoring is the continuous review of payments, logins and payouts to find activity that looks like fraud or money laundering. For payment fraud it runs in real time: each event is enriched with device, card and velocity context, scored, and then allowed, sent to review or blocked before money moves.
Updated · RiskCogs team
Key facts
- Fraud monitoring usually works in real time, before authorization; AML monitoring often reviews patterns after the fact.
- Velocity, meaning how often something repeats in a time window, is one of the strongest single fraud signals.
- Rules should be readable so analysts can explain why a payment was flagged.
- A risk score is a review signal, not proof of wrongdoing.
Fraud monitoring versus AML monitoring
Both look at transactions, but they answer different questions. Fraud monitoring asks whether this payment is likely unauthorised or abusive and must answer in milliseconds at checkout. AML monitoring asks whether a pattern of activity suggests laundering and usually feeds case work and regulatory reports. Many teams run both, with different owners and thresholds.
Signals to start with
- Velocity per card, device, IP, email and account.
- BIN context: card type, prepaid or virtual flags and issuing country.
- Mismatch between BIN country, IP country and billing country.
- Device and browser automation signals.
- Account age and history of successful payments.
- Amount compared with the customer’s usual basket.
How to roll out monitoring rules
- Write each rule in plain language with a clear owner.
- Run new rules in shadow mode and measure what they would have flagged.
- Check flagged payments against known chargebacks and good customers.
- Promote rules to review first, then to block only when precision is clear.
- Review rule performance monthly and retire rules that no longer catch fraud.
Monitoring decisions by score band
| Score | Decision | Typical action |
|---|---|---|
| Below 40 | Allow | Process normally |
| 40 to 69 | Review | Manual check or step-up authentication |
| 70 and above | Block | Decline and log the reason |
How RiskCogs supports transaction monitoring
RiskCogs returns a risk score for each event through POST /v1/risk-score, with the signals and rules that drove it. Scores below 40 map to allow, 40 to 69 to review and 70 or above to block.
Start on the free Shadow plan to see what your rules would have done on real traffic without affecting a single payment. RiskCogs sits next to your existing payment provider and does not process payments.
See what you would have blocked — free shadow modeFrequently asked questions
What is transaction monitoring in payments?
It is the ongoing review of payment events to spot fraud or money laundering. In fraud prevention each payment is checked in real time against rules and a risk score, so suspicious payments can be reviewed or declined before authorization instead of turning into chargebacks weeks later.
Is transaction monitoring the same as AML?
No. AML transaction monitoring looks for laundering patterns across accounts and time and supports reporting duties. Fraud transaction monitoring focuses on stopping unauthorised or abusive payments at the moment they happen. The data overlaps, but the goals, owners and response times are different.
How do I avoid blocking good customers?
Test every new rule in shadow mode before it affects real payments, send borderline scores to review rather than block, and compare flagged payments with known good customers. Tracking false positives per rule shows which rules need tuning or removal.
Sources and related reading
- FATF, International Standards on Combating Money Laundering (FATF Recommendations), public edition.
- European Banking Authority, Guidelines on fraud reporting under PSD2, public edition.
Measure first. Enforce when ready.
Run RiskCogs in shadow mode next to your existing payment setup and review the decisions before they affect a single customer.