Fraude na Alteração de Dados Bancários: Controlo de 3 Mãos

# Changing a Supplier's Bank Details: The Three-Hands Control That Stops the Wrong Payment

TL;DR: A supplier's bank-detail change request should never be approved by the person who received it, and it needs two distinct approvals from two different people — three hands in total — before the ERP will accept payments to the new account.

The attack doesn't need to hack anything

The cheapest way to redirect a supplier payment doesn't involve breaching a server. It involves an email.

The pattern, documented year after year by the FBI's Internet Crime Complaint Center (IC3), is called Business Email Compromise (BEC) — in one specific variant known as vendor email compromise, the attacker compromises or convincingly imitates a real supplier's mailbox and uses it to request that the operator or EPC contractor change the bank account for the next payment. In 2024 alone, IC3 received 21,442 BEC complaints, with reported losses of $2.77 billion — the second-highest loss total of any reported crime category, even though it wasn't the most frequently reported category by case count (FBI IC3, 2024 Annual Report). Between October 2013 and December 2023, cumulative identified BEC losses globally reached $55.5 billion (FBI IC3, PSA I-091124).

The mechanism is always the same, with minor staging variations:

1. The attacker registers a domain nearly identical to the real supplier's (one swapped letter, .co instead of .com), or actually compromises the supplier's mailbox.

2. Sends an email to the finance or accounts-payable team in an ordinary administrative tone — often citing a real invoice, a real contract number, a real contact name. "We've updated our bank. Please update our details for upcoming payments."

3. Attaches a letter on letterhead, with a stamp and signature, all visually convincing.

4. Asks that the change be applied before the next payment is due — manufacturing urgency.

There's no malware, no exploit, nothing an antivirus would flag. The attack exploits a process, not a technical vulnerability. Which is exactly why the right response isn't more network security — it's internal control over a single data field: the supplier's bank account number.

Why Angola carries an additional layer of risk

Outside Angola, when a payment lands in the wrong account, there is usually some interbank recall mechanism, however slow and unguaranteed. In Angola, legal analysis published by the law firm CAZOS on IBAN errors is blunt about this: transfers execute against the unique identifier (the IBAN) without verifying that the beneficiary's name matches the account, and the risk of error falls on whoever initiates the transfer. Under Law No. 40/20 (the Angolan Payment System Law), the sender's bank is only required to make reasonable efforts to recover the funds, in cooperation with the beneficiary's bank; according to that analysis there is no mandatory legal recall mechanism, and CAZOS is proposing that the BNA create a national 48-hour return mechanism for exactly this reason (CAZOS Advogados, "Os Perigos dos Erros no IBAN em Angola").

In other words: if money leaves for the wrong account, getting it back depends on the goodwill of the receiving bank and how fast you act — not on an automatic right. That changes the risk calculus. In a jurisdiction where reversal is uncertain, the only point where risk can genuinely be controlled is before the payment is instructed, not after. The National Bank of Angola (BNA) has already acknowledged the scale of the problem at the domestic payment-systems level, issuing Instrutivo (Instruction) No. 14/2023, of 23 October, which sets minimum information and strong-authentication requirements for fraud prevention within the Multicaixa system and the Instant Transfer System (PTI — "BNA estabelece novos requisitos para prevenção de fraude"). That instruction is addressed to payment service providers and how they authenticate their customers; changing a supplier's bank details inside the company's ERP is an earlier control point, and it sits with the paying company.

The three-hands control, spelled out without ambiguity

The principle that stops this type of fraud isn't new — it's the classic segregation-of-duties rule applied to one specific data field. Made concrete for supplier bank data, it works like this:

Hand 1 — Whoever requests the change does not approve it.

Any request to change a supplier's IBAN, bank, or account holder enters the system as a PENDING record, created by whoever received the request (typically someone in accounts payable or procurement). This person has no system permission to approve their own change. The ERP has to enforce this at the user-role level, not just as a written convention — if the same user account can create and approve the same record, the control doesn't exist; it only exists on paper.

Hand 2 — First approval, with out-of-band verification.

A second person, with a distinct role (typically a procurement or finance-compliance lead), must confirm the request through a channel that is not the email that originated it. That means calling the phone number already on file for the supplier before the request arrived — never a number provided in the change message itself. Only after this confirmed phone verification does this person log the first approval in the system.

Hand 3 — Second approval, from a different person, with financial authority.

A third person — typically the financial controller or CFO, never the same person as Hand 2 — gives the second approval, reviewing the supplier's history (how long they've worked with the company, average invoiced value, whether there have been recent bank-detail changes) before confirming. Only once both distinct approvals are logged does the bank record move from PENDING to ACTIVE.

Three hands, three people, three system events with a timestamp and user recorded. None of them can be the same person as the other two.

The details that decide whether the control is real or theater

A few implementation details separate a genuine control from a cosmetic one:

A cooling-off period before the new IBAN can be used. Even after the second approval, the ERP should block the new IBAN from being used in a payment run for, say, 24 to 48 hours. That window gives time for an automatic notification — sent to the supplier's old email and phone, not the new ones — warning "your bank account was changed in our system; contact us immediately if this wasn't you." If the request was fraudulent, this is the safety net that can still catch it before the money leaves.
The previous bank record is never deleted, only superseded with history. This is essential for any later investigation or audit, and it's the same immutable-audit-trail principle we detail in the context of permissions and RBAC in an industrial ERP — see "Permissões que Não Mentem".
Segregation of duties has to live in the permissions engine, not in a PDF procedure. A written procedure saying "two people must approve" stops nothing if the system lets one person log in with two accounts, or lets an administrator temporarily disable the rule "to speed up" an urgent payment. Exceptions are exactly where fraud gets in.
The change-request trigger should be wired into the supplier qualification and master-data workflow, not be a loose form. If your procurement process already treats the supplier record as an object with history and workflow — as we describe regarding automating the purchase-to-invoice cycle — see "Procurement Automatizado em Angola" — a bank-detail change is just another state of that object, governed by the same approval rules.

A table for scoping the minimum design

Control element	No control (high risk)	Three-hands control
Who creates the request	Any user with access to the supplier record	Recorded as creator; no self-approval permission
Verification channel	Reply to the email received	Call to a number already on file before the request
Number of distinct approvers	0 or 1	2, mandatorily different from each other and from the creator
Immediate use of new IBAN	Yes, on the next payment run	Blocked during a 24-48h cooling-off period
Notification to supplier	None	Automatic, to old contact details, at time of change
Previous record	Overwritten	Preserved with full history

Where cybersecurity comes in, beyond the process control

The three-hands control fixes the business process. But how exposed a company actually is to this attack vector also depends on how easy it is, in practice, to compromise or convincingly impersonate a supplier's or an employee's mailbox — through targeted phishing, reused credentials, or the absence of multi-factor authentication on email accounts that handle payments. A security assessment covering specifically these entry points, not just firewalls and antivirus, is the natural complement to the ERP approval control; it's the kind of work that falls within the scope of Wise Hustlers' cybersecurity service.

FAQ

Does an email approval between two people already count as "two hands"?

No, if both approvals rely only on the content of the same received email, without verification through an independent channel. The strength of the control comes from out-of-band verification (Hand 2), not from the number of signatures on an email thread.

What if the supplier insists the change is urgent and there's no time for the cooling-off period?

A legitimate supplier accepts a 24-48 hour delay to confirm a bank account change. Pressure to skip verification is itself one of the most consistent signals described in IC3's BEC alerts and should be treated as a red flag, not a justification for bypassing the process.

Does this only apply to external suppliers, or also to employee bank-detail changes (payroll)?

The same three-hands principle applies to any change of destination account for recurring payments — including employee IBAN changes, a fraud vector also documented by the FBI IC3 in requests that imitate HR communications.

The ERP already has an invoice approval workflow. Isn't it enough to reuse the same flow for bank changes?

It shouldn't be the same flow. Invoice approval validates what should be paid; the bank-data control validates where it gets paid. These are different risks and, ideally, should have partially different approvers, so that compromising a single person isn't enough to redirect payment at either point.

Changing a Supplier's Bank Details: The Three-Hands Control That Stops the Wrong Payment