Instant payments move fraud losses to a different clock
When value moves in seconds, a provider cannot rely on a review that starts tomorrow. Authentication, limits, confirmation and case handling have to intervene before or immediately after approval.
A card dispute can begin after settlement and still use an established chargeback process. An instant account transfer may become final within seconds. Fraud does not become inevitable, but the useful intervention window moves toward onboarding, authentication and the moment of approval.
The World Bank's 2026 paper on scaling instant payments in Africa includes consumer protection, governance and participation among the conditions for adoption. Those conditions meet inside a provider's risk register. Ordering that register by estimated loss can hide the operational problem. Order it by the last time someone can still act.
Before the account can send
Identity controls determine who opens an account and who can recover it later. A provider should separate documentary proof, device signals, contact ownership and behavioural evidence. No single check proves identity in every market, and stricter documentation can exclude legitimate users.
Fraudsters test recovery paths because a strong login has little value if a call-centre agent can reset it with weak evidence. Map enrolment, new-device registration, password reset, SIM change and account reactivation. Apply cooling periods or lower limits where a change raises risk, with a process for genuine emergencies.
Mule accounts receive stolen value and move it onward. Monitor rapid pass-through, many unrelated senders and account behaviour that changes after dormancy. A rule creates false positives, so the operations team needs review capacity and lawful grounds for restricting funds.
Onboarding metrics should include confirmed impersonation, accounts closed after review, customer abandonment and appeal outcomes. A low fraud rate achieved by rejecting many legitimate applicants isn't an inclusion success.
Before the customer approves
Social engineering often leaves authentication intact. The customer enters the code and presses send because a criminal has changed the story around the payment. Confirmation screens need enough information to interrupt that story.
Show the recipient name or verified merchant identity where scheme rules permit. Warn when a beneficiary is new, an amount departs from normal behaviour or the account changed security settings. A generic warning repeated on every payment becomes interface furniture.
Limits can vary by customer history, channel, beneficiary and recent account event. Publish customer-facing limits and give support staff a controlled way to handle legitimate exceptions. Criminals can use exception processes too, so an override needs evidence and a record.
A risk engine has milliseconds or seconds to decide. Its model and rules need tested fallback behaviour when data or a vendor service is unavailable. Allowing every transfer preserves uptime and removes a control. Blocking every transfer protects against fraud and creates a denial of service.
In the first minute
A customer may realise the deception immediately after sending. Give the app a visible report action linked to the transaction identifier. The provider can alert the recipient institution even if scheme finality prevents unilateral reversal.
The receiving institution needs a team and message format capable of acting. A free-text email to a general mailbox wastes the short period before money moves again. Shared fraud messages should identify transaction, reason, contact and legal basis for any requested hold.
Do not promise recovery. Funds may have left, and local law governs restraint and return. Promise acknowledgement, a case number and the next response time.
Providers can apply short, risk-based holds on certain incoming transfers only where rules and law allow. A broad hold would undermine instant availability. The scheme must define who bears loss or delay when a control stops a legitimate payment.
Before the day closes
Reconciliation can reveal duplicate processing, status mismatches and transfers accepted outside limits. Technical incidents and fraud incidents may overlap, but they need different evidence and customer treatment.
Link related reports across institutions. Five small complaints to five providers may point to one beneficiary. Data-sharing arrangements need purpose limits, security, retention rules and oversight. A fraud consortium isn't permission to circulate customer data without control.
Operations should preserve device, authentication, transaction and communication records. Retention has to meet legal requirements and avoid keeping sensitive data without need. Case staff need access controls and an audit trail.
Notify regulators and law enforcement under the applicable thresholds and timelines. A provider operating across countries should maintain a matrix rather than assuming its home rule applies to every incident.
After money has left
Recourse policy should distinguish unauthorised account access, authorised transfer scams, provider error and customer mistake. The facts and legal allocation differ. Calling every event “customer authorised” can ignore defective warnings or provider control failures. Refunding every event without investigation can attract abuse.
Publish the evidence considered and appeal route in customer terms. Decisions should be understandable without revealing detection rules. Track time to provisional answer, final answer and recovery.
Loss analysis needs a denominator. Fraud value by transaction value, case count by active customers and false-positive restrictions by reviewed alerts answer different questions. Keep attempted and realised loss separate.
The board should see which control failed and when action remained possible. A large recovered case may reveal better operations than a smaller unrecovered one; severity alone cannot rank the lesson.
Test the clock
Run exercises with the scheme operator and participating institutions. Start a simulated report at the customer channel, pass it through support, fraud operations and the receiving provider, then record elapsed time and missing data. Include nights and weekends if the rail runs then.
Review product changes before launch. Higher limits, alias payments and easier account recovery alter the intervention window. Revenue plans need the fraud staffing and customer-support cost attached.
Instant payment gives users certainty and releases cash faster. It also removes hours that older controls used for batch review. The risk register should show the minute at which each control stops being useful.
Sources
- World Bank, March 2026: Scaling Instant Payments in Africa