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.
| What you see | What may have happened | Why the distinction matters |
|---|---|---|
| A message arrives from the person's real address and fits an existing conversation | Their mailbox or active session may be compromised | The attacker may know invoice amounts, timing and writing style; checking only the visible address will not protect the payment |
| The display name looks right but the actual sender address does not | The From address or display name may be spoofed | Email authentication and filtering may help, but the payment process still needs independent verification |
| The domain differs by one letter, word or ending | A lookalike domain may be impersonating the business | The lookalike can send mail through its own correctly configured domain; a pass result for that domain does not make it your supplier |
| Your own mailbox looks normal, but a supplier or customer receives false instructions from a real account | The other organisation may be compromised | Your password reset cannot contain their environment; both organisations need trusted-channel contact and their own incident owner |
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.
| Step | Required action | Evidence to retain |
|---|---|---|
| 1. Pause | Do not change the beneficiary or release the payment from the email alone | The request, invoice, date, time and payment due date |
| 2. Source the contact independently | Use the supplier master, signed contract or a separately verified official source — not the email, attachment or reply signature | Where the trusted number came from |
| 3. Speak to an authorised person | Confirm the change with a known contact or a person whose authority can be established through the trusted channel | Name, role, number used, date and time |
| 4. Verify the exact change | Read back the supplier name, account holder, bank, account number and effective date; resolve any mismatch before proceeding | Old details, proposed details and the confirmation result |
| 5. Apply supporting checks | Use an available bank account-verification service where appropriate, but do not let it replace the trusted callback | Verification result and any limitation or mismatch |
| 6. Separate duties | Where practical, keep the person who edits the supplier record separate from the person who verifies it and the person who releases payment | Who created, checked and approved the change |
| 7. Record the exception | Keep a change log and attach the verification record to the supplier or payment record | A complete audit trail, including rejected attempts |
| 8. Release only after approval | Apply the organisation's amount, first-payment and beneficiary-change approval rules before payment | Final approver, payment reference, amount and time |
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
| Role | Before an incident | When a suspicious request appears |
|---|---|---|
| Request recipient | Know the red flags and trusted reporting route | Pause, preserve the message and alert the finance owner without replying |
| Supplier-record owner | Maintain trusted contact details and a change log | Freeze the proposed change until independent verification is complete |
| Independent verifier | Know who is authorised at key suppliers | Call a known number, confirm exact details and record the result |
| Payment approver | Enforce approval limits and exception rules | Refuse release until the verification evidence is attached and complete |
| Email/IT administrator | Maintain MFA, logging, account recovery and least privilege | Contain affected accounts and sessions, preserve logs and review rules, delegates and app access |
| Information Officer or deputy | Maintain the organisation's POPIA incident path | Assess whether personal information was affected and apply current Regulator guidance |
| Business incident owner | Keep bank, insurer, legal and law-enforcement escalation details from official sources | Coordinate facts, decisions, counterparties and updates without promising recovery |
If the request is suspicious but money has not moved
- Stop the beneficiary change and payment. Do not reply, forward the suspect message casually or call a number inside it.
- Contact the supposed sender through a trusted channel. Use the supplier master, contract or independently verified official number.
- Alert the finance and incident owners. They need to protect other pending payments and related supplier records.
- Preserve the original message. Keep the full message and headers where available, the attachment, timestamps and the actions already taken.
- Escalate possible mailbox compromise. The authorised email administrator or IT provider should contain and investigate the affected environment.
- 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.
| Priority | Action | What to have ready |
|---|---|---|
| Bank | Contact your bank immediately through its official fraud channel and follow its current instructions | Payment reference, amount, date/time, beneficiary details, account used and authorised contact |
| Internal control | Stop related payments and freeze unverified supplier or beneficiary changes | Open invoices, scheduled payments and users with edit/approval access |
| Email/identity | Ask the authorised administrator or IT provider to contain affected accounts and sessions | Affected addresses, first known sign, recent sign-ins, rules, forwarding, delegates, recovery methods and app access |
| Evidence | Preserve original messages, headers, invoices, rules, access records and payment evidence | A timeline with who observed, approved, changed and reported each action |
| Counterparties | Contact affected suppliers or customers through trusted channels and establish which side may be compromised | Known contacts, affected threads, invoices and confirmed facts only |
| Authorities and advisers | Report suspected fraud through the appropriate current South African channels and involve legal, insurance or specialist advisers where the facts require them | Bank reference, transaction evidence, preserved communications and a factual incident timeline |
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”.
