Business Email Compromise in South Africa: Stop Payment-Change Fraud

Business email compromise, or BEC, is payment and identity fraud carried through a trusted-looking business message. The safest response is not to become better at guessing whether an email “looks right”. Build a payment process in which an email can start a banking-detail change, but can never authorise it on its own.

If a supplier, executive or customer asks you to use a new beneficiary, stop the payment. Find a trusted number from your existing supplier record, contract or independently verified official source. Speak to an authorised contact, record the check and apply the required approval before money moves. Do not reply to the message or use the phone number printed inside it.

Email security still matters. A suitable business email hosting setup, multifactor authentication and domain authentication reduce risk. None of them proves that a bank-detail change is genuine.

What business email compromise looks like

BEC is often described as a hacked mailbox, but a convincing payment request can arrive in several ways. Your first response should not assume which one happened.

A familiar signature, invoice template, reply-chain history or writing style is context, not identity proof. An attacker using a real mailbox can inherit all of it. A lookalike-domain sender can also copy visible branding without accessing the genuine account.

Make every banking-detail change a controlled exception

Treat a new beneficiary, changed account number or unusual payment instruction as an exception to the normal invoice flow. The same rule should apply whether the request appears to come from a supplier, director, employee, attorney, estate agent or customer.

A small business may not have three finance staff. It can still avoid one-person control. For example, the bookkeeper records the request, the owner performs the trusted callback and the authorised banking user approves the beneficiary and payment. If one person must perform more than one step, require a documented owner review before release instead of quietly dropping the control.

Do not create an “urgent” bypass for executives. Urgency is the moment the control matters most. A real director or supplier can wait for the verification step, answer through a trusted channel or follow the exception process.

Red flags that should stop the payment

One weak signal does not prove fraud. One high-risk change is enough to pause and verify.

• new bank details, a new beneficiary or a request to split the payment;
• pressure to act immediately, keep the request secret or bypass a usual approver;
• a senior person making an unusual payment request while travelling or unavailable;
• a supplier contact changing at the same time as the bank details;
• a reply chain that suddenly changes sender domain, tone, payment timing or invoice attachment;
• an invoice layout, account holder, bank or payment reference that differs from the supplier record;
• a message that discourages a phone call or provides a new number for “verification”;
• deleted or missing mail, unexplained password resets, unknown forwarding, unfamiliar inbox rules or sign-ins your user cannot explain.

Do not reject a message only because of grammar, and do not accept it because the grammar is good. The deciding control is verification through a channel and contact record the suspicious message did not supply.

Technology reduces risk; it does not approve a payment

Multifactor authentication

Require MFA for email, especially for administrators, executives and anyone who handles invoices, supplier records or payments. Use the strongest option your platform supports and keep recovery methods controlled.

MFA is not a fraud guarantee. A stolen session, compromised recovery method, unsafe legacy access, malicious consent or a compromised supplier account can leave you facing a convincing message. Continue to verify banking changes even when both organisations use MFA.

Passwords, sessions and account recovery

Use unique credentials, a password manager where appropriate and separate administrator accounts from daily mail. Do not share one mailbox password across a team. Restrict who can reset finance and executive accounts, and make sure the recovery contacts are current.

When compromise is suspected, a password change alone may leave active sessions, added authentication methods, app access or forwarding in place. The authorised administrator or IT provider should follow the mail platform's current containment procedure from a trusted device.

Inbox rules, forwarding, delegates and access logs

Review visible and hidden inbox rules, external forwarding, delegates, connected applications, recovery methods and recent sign-ins. Look for unexplained changes around the first suspicious message, not only the moment the payment request was sent. Preserve the relevant records before normal retention or cleanup removes them.

SPF, DKIM and DMARC

SPF identifies authorised sending sources for a mail domain. DKIM adds a cryptographic signature that lets a receiving system check the signed message. DMARC checks alignment with the visible From domain, tells receivers how to handle failures and provides reporting.

Correctly configured records make direct spoofing of your own domain harder and improve visibility. They do not stop someone from using a compromised real mailbox or a separately registered lookalike domain. If you need the DNS layer in more detail, use the Allanux guide to how DNS SPF records work, then have the full SPF, DKIM and DMARC configuration reviewed for every legitimate sender.

Least privilege around supplier and payment data

Limit who can create suppliers, edit beneficiaries, approve payments and export supplier or customer data. Remove access when roles change. Keep payment and email administration rights out of normal user accounts where the platform allows it. A mailbox control cannot compensate for unrestricted access to the supplier master or banking platform.

When you are setting up email hosting on your own domain, decide these owners before adding every mailbox: who manages DNS, who administers accounts, who can reset access, who reviews logs and who receives an internal fraud escalation.

Use a role map before pressure arrives

If the request is suspicious but money has not moved

1. Stop the beneficiary change and payment. Do not reply, forward the suspect message casually or call a number inside it.
2. Contact the supposed sender through a trusted channel. Use the supplier master, contract or independently verified official number.
3. Alert the finance and incident owners. They need to protect other pending payments and related supplier records.
4. Preserve the original message. Keep the full message and headers where available, the attachment, timestamps and the actions already taken.
5. Escalate possible mailbox compromise. The authorised email administrator or IT provider should contain and investigate the affected environment.
6. Check for related requests. Review other unpaid invoices, beneficiary changes and messages involving the same parties without deleting evidence.

If the message proves genuine, complete the normal verification and approval record. A false alarm is cheaper than a payment released because someone was worried about inconveniencing a supplier or director.

If money has moved: run the first-hour actions in parallel

Do not spend the first hour debating who clicked what. Start the bank, account and evidence work immediately. Fast reporting may help, but no one should promise that a payment will be stopped, recalled or recovered.

The South African Police Service directs suspected online-scam fraud to the nearest police station, while YIMA provides a current scam-reporting route. Use current official guidance when the incident happens; do not rely on an old phone number copied into an internal document.

Secure the mailbox without destroying the evidence

The exact steps depend on the mail platform. An authorised administrator should use the provider's current compromised-account procedure and record every change. Common containment work includes:

• resetting the credential from a trusted device;
• revoking active sessions or tokens where the platform supports it;
• reviewing and removing unrecognised MFA methods and recovery details;
• checking forwarding, inbox rules, delegates, app passwords and connected applications;
• reviewing sign-in and mailbox audit records for affected users and time periods;
• checking the user's device for compromise before normal access resumes;
• warning affected contacts through a separate trusted channel if false messages were sent;
• securing other accounts if the same password or recovery route was reused.

Preserve original messages and headers rather than relying only on screenshots. Keep access records, rule changes, payment references, call notes and a timeline of containment actions. Restrict the evidence to authorised people and follow professional guidance on retention and disclosure.

POPIA: assess the facts, not the label

A suspicious payment email is not automatically a POPIA security compromise. A real mailbox intrusion can, however, expose names, contact details, invoices, identity information, correspondence or other personal information.

Escalate the facts promptly to the organisation's Information Officer or deputy. They should assess whether personal information was affected and follow the Information Regulator's current security-compromise guidance. The Regulator's fact sheet says responsible parties should report a security compromise as soon as they are reasonably sure it occurred, and that reporting now uses the eServices portal. Do not invent a universal hour-based deadline, wait for a full forensic investigation where the official test is already met, or assume every unverified BEC attempt is reportable.

Where the facts are unclear or sensitive, obtain current professional legal and regulatory advice. Allanux Web does not provide legal, forensic, banking-recovery or regulatory-notification services.

Test the process before a real request arrives

A useful exercise is short and operational. Give the team a mock request to change a supplier's bank details, then watch what happens:

• Does the recipient know where to report it?
• Can the verifier find a trusted contact without using the message?
• Can one person change a supplier and approve the payment?
• Does the payment approver see the callback evidence?
• Can IT revoke access and review rules, forwarding and logs?
• Does the incident owner have official bank and reporting routes?
• Does the Information Officer receive enough facts to assess the POPIA position?

Repeat the exercise after a material staffing, banking, supplier-master or email-platform change. Fix the slow or ambiguous steps while no money is at risk. The best control is one the team can follow when month-end is busy and the supposed director is “unavailable”.