The email is not the incident
Business Email Compromise looks like an email problem.
That is why so many organisations misread it.
A fake supplier message arrives. A compromised mailbox sends a believable instruction. An executive appears to request an urgent payment. A finance team receives new bank details. A vendor record is changed. An invoice is approved. A payment batch is released. Money leaves.
The email matters.
But the email is not the whole incident.
The real incident is the conversion of a suspicious instruction into authorised business action.
That is where most BEC evidence fails. Organisations preserve the email, the invoice, the bank confirmation, and the workflow approval, then assume they have the incident file. They do not. They have fragments from the beginning and end of the fraud. The critical missing record sits in the middle: why did the organisation decide the instruction was real?
The FBI describes Business Email Compromise as one of the most financially damaging online crimes, and its 2024 IC3 report recorded more than $2.77 billion in reported BEC losses. The NCSC describes business payment fraud as criminals tricking organisations through tailored emails, including requests to pay into a different bank account. Those definitions are useful. They still do not answer the evidential question.
The deeper question is not whether the message was fake.
The deeper question is why the organisation’s own systems accepted it.
“BEC does not succeed because one email is convincing. It succeeds because the organisation’s own controls agree to behave as if the email is true.”
That is the evidence gap.
The real failure is trust conversion
Most businesses split BEC across several teams.
Cyber looks at spoofing, compromised accounts, headers, phishing, malware, MFA, and mailbox rules. Finance looks at invoice approval, supplier records, payment batches, bank release, and reconciliation. Procurement looks at vendor onboarding and supplier changes. Legal looks at liability, notification, privilege, recovery, and insurance. The board asks how the payment got through.
Everyone owns a piece.
Nobody owns the evidential chain.
That is why BEC is so destructive. It crosses the seam between communication, identity, authority, verification, approval, and money movement. Attackers do not need to defeat every control. They need to make the control environment behave as if the request is ordinary.
They use urgency, hierarchy, familiarity, supplier relationships, payment timing, end-of-month pressure, executive travel, tender deadlines, and ordinary reluctance to slow down a transaction that appears commercially normal.
Sometimes the fake invoice sounds like the supplier because the attacker has read the real conversation.
Sometimes the payment change arrives exactly when the accounts team expects one.
Sometimes a compromised mailbox watches correspondence until the right moment.
Sometimes a senior-person request is shaped to make verification feel disloyal.
The fraudster sends the instruction.
The business supplies the authority.
The missing record is payment authority
After a BEC incident, organisations often have proof that a payment happened.
That is not the same as proof that controls worked.
The missing record is the payment-authority record. It should answer one question: what made this instruction trustworthy enough to act on?
That record should connect the source request, supplier identity, bank-detail change, previous supplier data, independent verification, contact route, approver authority, exception logic, payment release, and decision boundary.
Most businesses cannot produce that record cleanly.
They can show an approval log. They can show that an authorised user clicked a button. They can show the invoice entered the payment run. They can show the supplier record was changed. They can show the bank transfer. Those facts matter, but they often prove only that the internal workflow executed.
They may not prove independent judgement.
A workflow approval may show that the fraud successfully entered the system and received a legitimate internal blessing. It may not show that anyone checked the thing that actually mattered.
Was the supplier change genuine?
Was the number used for callback independently sourced?
Was the person contacted actually authorised?
Was the request consistent with previous supplier behaviour?
Was the approver shown the risk signal?
Was the exception recorded?
Was the payment held pending independent confirmation?
If the evidence cannot answer those questions, the organisation should expect further challenge from banks, insurers, suppliers, auditors, boards, or investigators.
The invoice was fake. The approval was real. That is why the evidence matters.
The callback must escape the compromised channel
Most BEC guidance says organisations should verify payment requests through a second channel.
That is correct.
EviWrite framework
The BEC payment-evidence chain
A defensible BEC record connects the suspicious instruction to the internal decision pathway that changed supplier data, approved payment, released funds, and triggered recovery action.
01 Instruction
Preserve the email, message, invoice, attachment, account-change request, phone note, meeting record, or supplier communication that initiated the action.
02 Identity and source
Record whether the sender, domain, account, supplier, executive, phone number, bank details, and payment request were independently verified.
03 Authority
Show who had authority to change supplier records, approve the payment, override controls, release funds, or accept an exception.
04 Verification
Record the callback method, independent number source, person contacted, confirmation given, verification questions, and any discrepancy or uncertainty.
05 Payment pathway
Connect supplier-master change, invoice approval, payment batch, bank instruction, value date, release time, receiving account, recall attempt, insurer notice, and law-enforcement report.
06 Proof boundary
State what the record proves, what it merely supports, what was not checked, what remains unknown, and what should not be inferred from internal approval alone.
It is also incomplete.
A callback is only as strong as the evidence around it. The business needs to show what number was used, where the number came from, who made the call, who answered, what was confirmed, what was not confirmed, what documents or details were checked, whether there were discrepancies, and who decided the result was enough.
The weakest callback is the one made to the number supplied inside the suspicious email.
That is not independent verification. That is asking the attacker to confirm the attack.
“A callback made to the number inside the suspicious email is not a control. It is customer service for the attacker.”
A stronger callback uses a pre-existing trusted source: a verified supplier master record, contract file, official website, prior independently verified contact, or separate trusted channel. Even then, the evidence should preserve the route used and the result of the conversation.
The same applies to video calls, messaging apps, supplier portals, and meeting links. Attackers can compromise mailboxes, imitate writing styles, intercept real threads, create convincing domains, and exploit existing trust. The verification record must therefore prove more than “someone checked.”
It must show how the check escaped the compromised channel.
Supplier bank-detail changes are evidence events
A supplier bank-detail change should not be treated as routine administration.
It is one of the highest-risk evidence moments in the finance system.
The organisation should preserve the request, source channel, previous bank details, proposed new details, effective date, supplier identity check, independent callback, approver, exception path, payment hold, and confirmation record. It should also preserve the reason the change was accepted and the timing of the first payment after change.
Image transcript
Infographic transcript
The fake payment evidence chain
The infographic shows how a fraudulent instruction becomes a real payment when controls produce authority without preserving evidence.
- Stage one: impersonation — spoofed email, compromised mailbox, fake supplier request, executive instruction, invoice redirection, or altered bank details.
- Stage two: trust conversion — internal staff, workflow tools, supplier records, approval systems, and payment controls convert the request into authorised action.
- Stage three: evidence gap — missing independent callback, missing number source, missing authority boundary, missing supplier-change proof, missing exception rationale, and missing verification record.
- Stage four: recovery fight — bank recall, insurer claim, supplier dispute, law-enforcement report, board review, customer communication, and post-incident control remediation.
- EviWrite Evidential Mark — a small visible circled e with the words 'EviWrite Evidential Mark' appears in the bottom-right corner of the infographic.
Most organisations under-record this moment.
They treat the supplier master as an operational record: a place where data is updated so payment can continue. That is not enough. The supplier master is also a future evidence file. If money is diverted, the first question will be how the new bank details became trusted.
The supplier-change record should be harder to fake than the supplier-change request.
That requires separation. The person receiving the request should not be the only verification point. The new bank details should not become active merely because an email asked for them. The first payment after change should not move without heightened evidence. Emergency changes should create more proof, not less.
Fraud loves urgency because urgency makes weak evidence feel efficient.
A proper supplier-change record slows down only the dangerous part: the leap from communication to authority.
ERP approval is not independent verification
ERP systems, procurement workflows, finance platforms, email logs, security alerts, bank confirmations, and supplier-master histories can all generate useful records.
They are not proof of truth by themselves.
A workflow log may show that a step was completed by a named user. It may not show what the user saw, what they understood, what risk signal was available, what verification occurred, or whether the approval was based on genuine authority.
A supplier-master record may show that bank details changed. It may not show that the change was genuine.
A payment confirmation may show that funds were sent. It may not show recoverability, liability, policy cover, or control sufficiency.
This distinction matters after BEC.
The organisation may say the payment was approved according to process. The insurer, bank, auditor, supplier, or board may ask a different question: did the process verify the thing that mattered?
An approval process that does not force independent verification of new bank details is not a payment control. It is a payment conveyor belt with manners.
This is the control-theatre problem inside BEC. The system produces a respectable-looking trail. The trail shows that the wrong action moved through the right workflow. That may be administratively neat. It is evidentially weak.
If your payment trail only proves that your own workflow said yes, it proves the fraud entered the business with permission.
BEC exploits hierarchy, not just technology
BEC is often described as social engineering.
That phrase is accurate, but too shallow.
The attack exploits the hierarchy of the business. A junior finance employee may hesitate to challenge a CFO. A procurement manager may avoid annoying a key supplier. An accounts-payable team may not want to delay a time-sensitive payment. A project lead may not want to disrupt a closing date. A charity, school, publisher, agency, or public body may have thin staffing and a strong culture of helpfulness.
The attacker turns normal business behaviour into a control weakness.
BEC is not only about gullible people clicking bad emails. It is about organisations that reward speed, politeness, hierarchy, and commercial smoothness more consistently than they reward verification.
Weak payment records versus stronger BEC evidence
Where BEC evidence quietly collapses
Many organisations can show that a payment was approved. Fewer can show why a fraudulent instruction was trusted.
| Record type | What it may show | What it may not show | Stronger evidential posture |
|---|---|---|---|
| 01Suspicious email | What it may showThe apparent instruction, sender, attachment, wording, or payment request | What it may not showWhy the business accepted it, who verified it, or whether the channel was compromised | Stronger evidential posturePreserve the full instruction with headers, account context, supplier history, verification records, and decision trail |
| 02ERP approval log | What it may showThat a workflow step was completed by an authorised user | What it may not showWhether independent verification occurred or whether the approver saw the relevant risk | Stronger evidential postureLink approval to evidence reviewed, verification method, exception handling, authority boundary, and payment release |
| 03Callback note | What it may showThat someone claims a call was made | What it may not showWhether the number was independently sourced, who answered, what was confirmed, or whether the call proved anything | Stronger evidential postureRecord independent number source, caller, recipient, confirmation questions, outcome, timestamp, and proof limits |
| 04Supplier bank-detail change | What it may showThat vendor records were updated | What it may not showWhether the change request was genuine, authorised, verified, or linked to the correct supplier | Stronger evidential postureMaintain a supplier-change evidence record with source request, independent verification, approval, previous details, new details, and effective date |
| 05Bank transfer confirmation | What it may showThat funds were sent | What it may not showWhether the payment was authorised by a genuine business instruction or recoverable after fraud discovery | Stronger evidential postureConnect transfer evidence to recall action, bank contact, receiving account details, fraud report, insurer notice, and recovery timeline |
A finance team may know the policy.
The team may also know that slowing down a senior request creates friction.
That is why evidence design matters. A good control should make the right behaviour easier to defend. The employee who pauses a payment should have a record-backed process to stand on. The approver should see the evidence gap before approval. The system should require the independent number source, not merely a tick box saying “verified.”
Verification should not depend on personal courage.
It should be built into the payment evidence record.
After payment, timing becomes evidence
Once money moves, the recovery clock becomes evidence.
The organisation must show when the fraudulent instruction was received, when the payment was approved, when funds were released, when the fraud was discovered, when the bank was contacted, what recall request was made, what receiving account was identified, when law enforcement or fraud-reporting bodies were notified, and what instructions were received.
Timing can affect recovery prospects, insurer assessment, legal responsibility, bank action, and post-incident review.
The FBI advises victims of internet crime to notify all financial institutions involved in the relevant transactions, submit an IC3 complaint, contact the nearest FBI field office, and contact local law enforcement. The NCSC similarly advises organisations tricked into fraudulent payments to report internally and contact the bank directly using official details.
The evidence point is direct: speed must be recorded.
A business that waited two hours may still have acted reasonably. A business that cannot show when it discovered the fraud and when it contacted the bank has created a new problem.
The recovery trail should be preserved like the payment trail.
Bank contact. Call reference. Recall request. Fraud report. Account freeze attempt. Receiving bank details. Law-enforcement report. Insurer notice. Customer or supplier communication. Internal escalation. Board update. Remediation decision.
After payment, every hour becomes part of the file.
Insurance, supplier disputes, and recovery all depend on the chain
BEC creates classification problems.
Is the loss business email compromise? Funds transfer fraud? Social engineering fraud? Cybercrime? Computer fraud? Crime policy? Cyber policy? Invoice fraud? Supplier fraud? Employee error? Voluntary transfer? A sub-limited event? A policy exclusion?
Those distinctions can affect cover, limits, exclusions, notification duties, recovery expectations, cooperation obligations, and claim handling.
The evidence record needs to show not only that a loss occurred, but how the loss occurred. That means connecting the fraudulent communication to the internal action and the resulting payment. It also means showing policy-relevant facts: whether an account was compromised, whether credentials were used, whether systems were accessed, whether the instruction came from a spoofed domain, whether a supplier was impersonated, whether an employee released payment, whether verification controls were required, and whether those controls operated.
A weak claim says: we were tricked and lost money.
A stronger claim shows the pathway from deception to authority to transfer.
BEC can also create a second conflict. The business thought it paid the supplier. The supplier never received funds. The supplier still wants payment. The business says it acted on what appeared to be supplier instructions. The supplier says its genuine payment details never changed.
That dispute turns on evidence.
Practical checklist
Evidence to preserve before and after BEC
The useful BEC record is not the fake email alone. It is the chain showing how identity, authority, verification, approval, payment release, and recovery were handled.
- Original instruction.Preserve the email, full headers where available, attachment, invoice, reply chain, message record, caller note, payment request, or bank-detail change request.Shows what triggered the business action instead of relying on a later summary of the fraud.
- Identity context.Record who or what was being impersonated: supplier, customer, executive, employee, domain, mailbox, phone number, payment account, or previous relationship.Separates the apparent sender from the verified business identity.
- Supplier-change history.Preserve the vendor-master or supplier-record history showing previous details, proposed new details, who changed them, when, why, and under which approval route.Shows how a fake instruction became trusted payment data.
- Independent verification.Record the callback route, the independent source of the number or contact method, who made contact, who responded, what was confirmed, and what remained uncertain.Proves the check escaped the suspicious channel instead of asking the attacker to verify the attack.
- Authority and approval.Preserve approver identity, authority basis, segregation-of-duty checks, exception approvals, override reasons, payment hold decisions, and risk warnings shown to the approver.Shows whether approval was meaningful or just workflow theatre.
- Payment pathway.Connect invoice approval, supplier change, payment batch, bank instruction, value date, release time, receiving account, transfer confirmation, and payment reference.Links the fraudulent instruction to the actual movement of money.
- Discovery and recovery timeline.Record discovery time, bank contact time, recall request, fraud report, insurer notice, law-enforcement report, supplier or customer communications, and recovery outcome.Preserves the speed and quality of the response after money moved.
- Control-operation record.Separate the fake external instruction from the genuine internal actions that accepted it, including checks performed, checks missed, controls bypassed, exception reasons, and pressure points.Makes the review useful instead of reducing BEC to blame or phishing awareness.
- Proof boundary.State what the record proves, what it only supports, what was not checked, what remains unknown, and what should not be inferred from internal approval alone.Prevents the organisation from overclaiming recoverability, liability, insurance cover, or lawful authority.
Who controlled the compromised mailbox? Which party received the fake instruction? Who changed the bank details? What verification was required by contract? What route was used? Which contact details were trusted? Were payment terms altered? Did the supplier warn about fraud? Did the business follow its own controls? Did either side notice a changed domain, unusual wording, altered invoice format, new account name, or timing inconsistency?
This is where BEC stops being a cyber story and becomes a commercial evidence dispute.
The contract can define the supplier-payment protocol.
The evidence record must show whether it happened.
The evidence should exist before the attack
The best BEC evidence is not created after the loss.
It is built into the payment process before the attacker arrives.
That means treating certain events as evidence events: new supplier onboarding, supplier bank-detail change, high-value payment, first payment after change, urgent executive request, payment outside normal pattern, payment to new geography, payment to a new account name, exception approval, and payment release after failed verification.
Each event should create a record that survives outside the compromised channel.
The question is not whether the organisation has a policy. Most do. The question is whether the organisation can prove the policy operated in the specific payment.
That requires more than a tick box.
It requires independent contact-source evidence, previous and new payment-detail record, approval context, risk flag visibility, exception rationale, segregation-of-duty proof, payment hold or release record, and proof boundary.
Better email security helps. Phishing training helps. MFA helps. Bank controls help.
But BEC lives in the handoff between message and money.
The control record must live there too.
The attack begins in communication.
The loss happens in authority.
A practical BEC evidence protocol
A serious protocol is not complicated. It is disciplined.
- Treat every supplier bank-detail change, first payment after change, urgent executive payment request, and payment outside normal pattern as a high-risk evidence event.
- Require independent verification using a trusted contact source that did not arrive through the suspicious instruction.
- Preserve the source request, previous supplier details, proposed new details, contact-source evidence, verification outcome, approver, exception reason, payment release, bank confirmation, and proof boundary.
- Give finance staff explicit authority to pause payment without being punished for delaying convenience.
- Preserve recovery evidence immediately after discovery: bank contact, recall request, fraud report, insurer notice, law-enforcement report, supplier communication, and board escalation.
The EviWrite position is simple: a payment-control record should not merely show that a payment was processed. It should show why the organisation was entitled to trust the instruction at the moment authority was given.
That means preserving the evidence of identity, verification, approval, exception handling, payment release, recovery action, and proof limits as a structured record, not as scattered screenshots after the loss.
Public proof does not require exposing payment data
BEC records will often contain sensitive material: supplier details, bank accounts, email headers, employee names, legal advice, insurer communications, fraud reports, internal control findings, and recovery steps.
That does not mean the evidence cannot be structured.
Common mistakes
How businesses help BEC evidence fail
The biggest BEC evidence failures are not technical. They are control records that look respectable until someone asks what they actually verified.
- 01Treating the fake email as the incident instead of examining the internal authority chain that made the fake instruction executable.
- 02Calling a number supplied in the suspicious email, invoice, footer, or attachment and recording the call as independent verification.
- 03Failing to record the source of the trusted contact details used for verification.
- 04Treating ERP approval as proof of verification when it only proves that a workflow accepted the request.
- 05Changing supplier bank details without preserving the source request, previous details, independent confirmation, approval, and effective date.
- 06Allowing urgent, confidential, senior, or relationship-preserving requests to bypass the evidence standard.
- 07Preserving the payment record but not the decision record that allowed payment.
- 08Waiting until the bank, insurer, customer, supplier, or board asks for proof before building the incident file.
A serious evidential model separates private substance from proof layer. The private record preserves the sensitive material. The proof layer records existence, timing, status, chain, verification action, and evidence boundary without exposing payment details unnecessarily.
This matters after fraud.
The business may need to show an insurer, bank, auditor, supplier, regulator, board, or investigator that a record existed at a certain time, that a supplier-change evidence file was created, that callback verification was recorded, that payment release was linked to approval, or that recall action occurred promptly.
That can be done without making supplier bank details public.
Public proof does not mean public exposure.
It means the record can be checked without relying only on memory, screenshots, compromised inboxes, or internal confidence.
The future of BEC defence is evidence, not awareness
Most post-incident reviews ask how the email got through.
That question matters.
The better question is: how did the business turn that email into authority?
Which system accepted the instruction? Which person relied on it? Which control was supposed to challenge it? What evidence did the approver see? What independent source was used? What exception was created? Why was payment released? What record survived? What was missing?
That is the question that makes BEC less mysterious.
Awareness training will remain useful.
Email security will remain useful.
MFA will remain useful.
Bank controls will remain useful.
But none of them solves the deeper evidence problem alone.
BEC is a business-decision attack. It uses communication to corrupt authority. The defence must therefore record authority with the same seriousness that security teams record intrusion.
The organisation that can prove its payment controls worked, or prove exactly where they failed, is in a stronger position with banks, insurers, suppliers, auditors, boards, and investigators. The organisation that can only produce the fake email and the transfer receipt is already fighting from a weaker place.
The next serious payment-control standard will not be “did someone approve it?”
It will be “what evidence made approval reasonable?”
Do not wait until the money is gone.
Show why the payment was trusted before the money moves.