In January 2024, a finance employee at the engineering firm Arup joined a video call with the company's CFO and several colleagues. They asked for a series of confidential transfers. The employee made 15 of them, HK$200 million in total. Everyone on the call except the employee was a deepfake. Arup later confirmed that fake voices and images were used.
The banking systems weren't hacked. The approval process was.
The attack moved to the human layer
South Africa's banks see the same shift. SABRIC's 2024 crime statistics show digital banking fraud cases almost doubled, from 31,612 in 2023 to about 64,000 in 2024, making up 65.3% of reported incidents. SABRIC says these were the result of social engineering that exploited human error, rather than technical compromises of banking platforms. It also reported early voice deepfake scams impersonating people and bank officials.
When the weak point is a person being convinced, more security software on the payment rail doesn't help. The fix is to design processes, and the software that runs them, so that being convinced isn't enough.
Design rules for approvals that survive a perfect fake
1. Verify on a channel the attacker didn't choose
If a request arrives by email, video call or WhatsApp, confirm it somewhere else: a phone number already on file, the person's desk, a message in your internal chat. Never use contact details from the request itself. A deepfake can control the call it starts. It can't easily control a call you start to a number you already had.
2. No single person can move large amounts
Dual approval (the four-eyes principle) means one person requests and a different person approves. Build it into the system, not a policy document: the API should reject an approval from the same user who created the payment.
if (payment.createdBy === approver.id) {
throw new ForbiddenError("A payment can't be approved by the person who requested it.");
}
3. Slow down what's new or changed
New beneficiaries and changed bank details are where fraud lives. Add a cooling-off period before the first payment to a new account, and alert the account owner on every bank-detail change through a channel they already use.
4. Treat urgency and secrecy as signals
"Keep this confidential" and "it has to go today" are the oldest lines in the book, and deepfakes just deliver them better. Train people to see them as triggers for the verification step, and make that step quick, so following the process costs less than skipping it.
5. Log everything an investigator will ask for
Who requested, who approved, from which device and IP, and which verification step was completed. If something gets through, these logs are what let you stop the next transfer and help the bank trace the money.
Where engineers come in
Most of these controls are product decisions disguised as policy. Engineers decide whether the approve button checks for a second person, whether a changed bank account triggers an alert, and whether the audit log exists. Building those in is how a team turns "be careful" into a system that's careful by default.
