Fraud risk in a digital-payments business: what continuous monitoring catches.
When money moves in thousands of small transactions a day, sampling does not work. A note on the fraud patterns we look for, the data tests that find them, and how to report them without drowning the audit committee.
1. The old method does not scale.
The traditional fraud test in an internal audit was a sample. Pick forty payments, trace them to approvals and supporting documents, and extrapolate. That worked when a company made a few hundred payments a month through a bank and each one had a paper trail.
It does not work for a business that collects through UPI, pays out through a payment gateway, settles with hundreds of merchants or delivery partners, and processes refunds, cashbacks and chargebacks by the thousand. A sample of forty from two million transactions tells you almost nothing. The frauds that matter in these businesses are small, repeated and hidden inside volume.
The answer is not a bigger sample. It is the full population, tested continuously.
2. The patterns that recur.
Fraud in high-volume payment environments tends to follow a small number of patterns. Once an internal auditor knows the patterns, the data tests write themselves.
Refund and cashback abuse. Refunds processed to an account other than the one that paid. Multiple refunds against a single order. Cashbacks credited to accounts linked to the same device or the same bank account with different customer identities. Refunds approved by the same user who raised them.
Merchant and partner onboarding. Merchants with incomplete KYC who are settled anyway. The same bank account or PAN appearing across several "different" merchants. Merchants onboarded and settled within days, then dormant. Partners whose settlement bank account changed shortly before a spike in payouts.
Internal collusion. Employees with access to both the customer support tool and the payout system. Manual adjustments posted outside business hours. Adjustments just under the threshold that would require a second approval, repeated.
Chargeback and dispute manipulation. Disputes raised and closed by the same agent. Chargebacks accepted without evidence review. Disputes concentrated on a small set of customers or merchants.
Settlement and reconciliation gaps. Differences between the gateway settlement file, the bank statement and the ledger that are "parked" and never cleared. Suspense accounts that grow every month. Rounding differences that always go one way.
In a payments business the fraud is rarely one large transaction. It is the same small thing done four thousand times.
3. Building the tests.
Continuous monitoring is a set of queries that run on the full transaction population on a schedule, daily, weekly or monthly, with exceptions routed to a named reviewer. The tools do not need to be expensive. Most of the tests below run in SQL against a data warehouse, or in Python or even a well-built spreadsheet for smaller volumes.
Duplicate and near-duplicate detection. Same amount, same beneficiary, within a short window. Same invoice or order reference paid twice with a small change in formatting.
Threshold clustering. Count transactions in narrow bands just below each approval threshold. A spike at Rs 49,000 to Rs 49,999 when the second-approval limit is Rs 50,000 is not a coincidence.
Master-data linkage. Join merchant, vendor, employee and customer masters on bank account, PAN, mobile number, email and device identifier. Any match across categories is an exception to be explained.
Segregation of duties from the log, not the policy. Extract the user who created, approved and paid each transaction from system logs. Flag any transaction where two of the three are the same person.
Time and velocity. Transactions posted outside business hours, or by a user whose volume on a given day is several times their average.
Benford and digit tests. Useful as a screening tool on manual adjustments and expense claims, less so on system-generated transactions where amounts are formula-driven.
Reconciliation ageing. Age every unreconciled item between gateway, bank and ledger. Anything older than 30 days is reported by owner. Anything older than 90 days is reported to the audit committee.
Each test needs a documented rationale, a threshold, an owner for exceptions and an escalation route. Without those, a monitoring tool produces a list that nobody reads.
4. The legal and regulatory backdrop.
Fraud reporting in India has become less discretionary. Under section 143(12) of the Companies Act, 2013 the statutory auditor must report certain frauds to the audit committee or the Central Government, and CARO 2020 requires the auditor to report on frauds noticed or reported during the year, including whistle-blower complaints. Internal audit findings are frequently the source for both.
Payment businesses themselves sit under RBI's payment system regulations, including customer-protection and security directions, and under the Prevention of Money Laundering Act for KYC and suspicious-transaction reporting. Enforcement activity in the digital lending and payments space has increased, and a documented monitoring programme is a meaningful part of a company's response when a regulator asks what controls were in place.
5. Reporting without drowning the committee.
A continuous-monitoring programme can generate hundreds of exceptions a month. The audit committee should never see that list. It should see three things.
A one-page trend. Number of exceptions by test, this quarter against last, with the closure rate.
The material items. Any confirmed fraud, any exception above a stated monetary threshold, and any pattern that indicates a control has stopped working, each with the root cause and the fix.
The health of the programme. Which tests ran, which failed to run, which have no owner. A test that has not run for two months is itself a finding.
Management sees the detail. The committee sees whether the system is working.
This article is general in nature and does not constitute professional advice. Readers should seek specific advice before acting on any matter described here.
This website is meant for information purposes only. The contents are made available on a pull basis and are not intended to solicit work or advertise.
Frequently asked
Is continuous monitoring the same as internal audit?
No. Continuous monitoring is a management control that runs all the time. Internal audit tests whether that control is designed well and is operating, and performs its own independent analytics where needed. The two work together, but the monitoring programme should be owned by management, typically finance or risk, not by the internal auditor.
What data access does the internal auditor need?
Read access to the transaction tables, the user and access logs, the masters, and the settlement and bank files. Access should be granted formally, logged, and limited to the audit period. Where the data sits with a third-party gateway, the contract should provide for the company to obtain full transaction-level data on request.
Does this apply to a company that is not a payments company?
The patterns are most visible in payments businesses, but the same tests apply to any high-volume environment: e-commerce refunds, retail loyalty points, logistics partner payouts, or even a large manufacturer's expense-claim process. Wherever volume is high and individual amounts are small, sampling fails and population testing is the alternative.
