Payment anomaly monitoring: flag transactions that do not look like the business

Payment anomaly monitoring looks for transactions that differ from the company's normal patterns. A transfer can be properly authenticated and still be fraudulent if it is unusually large, sent to a new country or approved at a strange time, so behavioural controls can complement ordinary limits and MFA.

Build a baseline from normal payment behaviour

Useful dimensions include amount, beneficiary, payment type, currency, user, time of day, location and frequency.

Different teams can have very different normal patterns. Payroll, treasury and petty supplier payments should not share one simplistic threshold.

Flag unusual values relative to history

A £200,000 payment can be routine for property treasury and extraordinary for an office supplier. Compare with beneficiary and user history rather than one company-wide amount.

Sudden round amounts or repeated transactions just below approval thresholds can deserve review.

New and changed payees deserve stronger scrutiny

Combine anomaly monitoring with beneficiary whitelists and Confirmation of Payee where available.

A first payment to a new overseas account at 11pm should have a higher risk score than a normal monthly rent payment to a long-standing landlord.

Monitor unusual user behaviour

Login from a new device, out-of-hours beneficiary changes or a user approving far more payments than normal can indicate compromised credentials.

Behavioural alerts should trigger verification, not automatic accusation. Legitimate staff can work unusual hours during acquisitions or year end.

Define what happens after an alert

Low-risk anomalies can require a second approver; higher-risk events can be paused until finance verifies the beneficiary or transaction purpose.

Alert systems fail when staff receive warnings with no owner or escalation route.

Review false positives and confirmed fraud

Too many false alerts teach users to ignore the system. Adjust thresholds based on actual outcomes and business changes.

After fraud, feed the event back into rules. Monitoring should improve from the company's own incidents as well as generic fraud patterns.

Worked example: a finance user who normally approves UK supplier payments below £30,000 suddenly creates a £240,000 transfer to a new overseas beneficiary on Sunday evening. Password and MFA are correct, but the behaviour is sufficiently unusual to pause the payment for independent verification.

Use payment purpose and ERP data where possible. An unusual bank amount can be legitimate if it matches an approved acquisition completion or annual tax payment. Better context reduces false positives.

Keep monitoring independent from the user being monitored. A compromised administrator should not be able to disable alerts or erase logs without another control detecting the change.

Worked example: treasury normally sends monthly rent on the first working day and payroll on the 28th. A £900,000 payment on the 14th to a new beneficiary with no ERP invoice is anomalous even if the amount is within the CFO's limit. The monitoring process can hold it until finance identifies the acquisition or other legitimate purpose.

Use peer-group baselines where several subsidiaries behave differently. A construction entity can make many large supplier payments, while a holding company may make only tax and dividend transfers. One group-wide model would generate excessive false alerts.

Review payment sequences, not only individual transactions. A beneficiary change followed five minutes later by a large payment is more suspicious than either event viewed alone.

Keep anomaly alerts in the incident record even when cleared as legitimate. Historical false positives help tune the system and show auditors why thresholds changed.

Feed confirmed legitimate exceptions back into the model. An annual insurance premium or quarterly tax payment can look anomalous every time unless the system understands the recurring pattern.

Review alert effectiveness with finance and security together. Finance understands legitimate business events; security understands attack behaviour. One team alone can over-block or under-detect.

Use thresholds that reflect settlement urgency. A payroll anomaly may need immediate review before cut-off, while a low-value supplier anomaly can wait for the next morning. Alerts should prioritise both risk and how quickly the payment becomes irreversible.

Keep anomaly models aware of one-off corporate events. Acquisition closings, dividend payments and tax settlements can be unusually large but fully legitimate. Pre-registering approved events can reduce noise without disabling monitoring for the rest of the payment population.

Track alert-to-decision time. A control that notices a suspicious Faster Payment only after the bank has released it provides less protection than one integrated into the approval stage.

Use management reporting on alerts stopped before release, alerts cleared as legitimate and fraud confirmed. That shows whether the monitoring programme is actually reducing loss.

Document the decision on every material alert. A short note explaining why the payment was released creates accountability and useful training data for future monitoring changes.