South Africa is racing into real time payments, PayShap IDs, instant EFTs, money that leaves in seconds. That is good for cash flow and great for crooks.
The hottest scam in the world right now is the authorised push payment (APP) fraud: criminals trick your team into paying their account. No malware, no Hollywood hacking. Just a believable voice or video, an urgent request and a finance clerk who wants to help.
In South Africa, when you press “send,” it’s usually your loss. The UK has rolled out a mandatory reimbursement regime that compels banks to repay most APP victims under clear rules. We have no equivalent in South Africa. Our rails may get faster, but our refunds do not.
Meanwhile, the fraudsters have upped their game. AI voice and video cloning is now cheap and convincing. Executives have been duped on multi-person video calls, cyber security leaders are reporting a dizzying rise in deepfake assisted scams.
SABRIC’s 2024 stats tell the tale, digital banking crime dominated incidents, with social engineering doing the heavy lifting. This is not a tech breach. It is a people and process breach at machine speed.
“Fine,” you say. “That is why we buy cyber insurance.” Not so fast. Most policies pay generously for data theft, recovery and certain liability risks, but authorised payments are another animal.
The small “funds protect” or similar add-on you skimmed at renewal often carries low limits and strict verification rules. Miss a documented call back, pay a new beneficiary too fast or approve over your internal threshold and you may just have voided your policy.
So what do proper internal payment risk controls look like?
The 20 safety pins
1. Freeze first pays.
Hold all new or changed beneficiaries for 48 to 72 hours and any payment above a board set threshold. If your bank cannot do it on instant rails, build the delay yourself. Speed is optional. Loss is not.
2. Kill ad hoc numbers.
Give verification only to pre-registered vendor contacts in your ERP. Any phone number in an email or WhatsApp is automatically treated as fraudulent.
3. Make dual control real.
Two people must approve. Nobody may override “in an emergency.” The only emergency is a fraudulent one.
4. Enforce account name checks.
Check whether the account holder’s name matches the supplier name on your records. No match, no money. Do not rely on someone “noticing”.
5. Stage a heist against yourself.
Run quarterly drills using AI voice/video clones of your execs. Break your own system before criminals do.
6. Align insurance with reality.
Raise your social engineering limits to a level that enforces proper risk mitigation. Make sure insurance policy warranties and conditions mirror your actual process, or fix the process to match your insurance requirements.
7. Pre-agree your recall route.
Do not waste time scrambling for your bank’s call centre number during a crisis. Know exactly who to call, what to say and what steps to follow, and practise these so your team reacts in minutes, not hours.
8. Senior contact voice check.
No new or changed beneficiary gets paid without speaking to a senior person at the vendor, pulled from your verified database. Call logged, checked and signed off by a senior company official, no exceptions.
9. Test payments.
Send a small test amount first. Independently confirm receipt with the verified contact. If something smells off, the loss is a rounding error, not a catastrophe.
10. Cooling off for changed accounts.
Treat any account change like a new supplier. Enforce a hard waiting period before the first big transfer. Crooks’ impatience often gives their game away; legitimate vendors understand.
11. Executive gatekeeper.
Large payments must include a callback escalation to an executive or board delegate. Deepfakes rarely survive a real conversation with a real executive.
12. Two channel verification.
Confirm any new or changed banking details through two independent channels, e.g. a voice call to a known number, and a pre-filed banking confirmation letter.
13. Lock geography.
Restrict payment authorisations to pre-approved IP ranges or devices. Any new location triggers step up authentication or a hard block.
14. Velocity tripwires.
Flag first-time payments over threshold, multiple new beneficiaries in short succession, or suspicious spikes. Fraud rings spread the damage, tripwires catch them early.
15. Name-ownership verification.
Where banks offer it, use confirmation of payee or the equivalent. Name mismatch = payment freeze.
16. Out of hours lock.
Block new or changed beneficiary payments outside business hours, unless a board member signs off. Friday at 16:29pm is the fraudster’s favourite time.
17. Escrow or split high values.
For first time large transactions, use escrow or break the sum up into instalments. This limits exposure and buys detection time.
18. Behavioural monitoring.
Use treasury or banking tools that flag deviations from your normal payment patterns (time, amount, frequency). Machines can catch what humans miss.
19. Lock the vendor master.
Limit who can edit vendor details. Every change must have dual or triple authorisation, be logged, and be reviewed by someone outside Accounts Payable.
20. Train your supply chain.
Run joint fraud simulations with key partners and suppliers. Your defence is only as strong as the weakest vendor who believes a fake email.
Final Thoughts
Boards, ask for a single page risk heat electronic payments map asap, including who can add a beneficiary, who can verify a change, what time locks exist, which call backs are recorded, what the sub-limit is, how long the “new beneficiary hold” is etc. If any answer is “we are not sure,” take immediate steps to become sure.
We are a country of fast “McGyver” workarounds. That is why so many of our businesses win. But you cannot “move fast” with money in 2025. The bad guys have a faster rail and your exact voice.
Build friction and backstops in key areas, analyse your risk thoroughly with a professional risk advisor, and buy cover that matches the process you will actually follow. And assume every urgent payment request is a risk pressure test performance, because it probably is.
Share
