The inbox was the pretext, not the control failure

A controller sees an invoice from a known supplier. The thread looks familiar. The signature block is right. The bank account has changed, and the explanation fits the month. The control failure is not that the message arrived. It is that the changed payment instruction becomes usable payment data before ownership is proven.

The wire goes out cleanly. The bank portal shows no error. The approval log is complete.

That is why business email compromise is hard to discuss inside finance teams. The visible failure is the payment. The attack usually happened earlier, when the organization decided that an instruction could be trusted.

The loss happens at acceptance

Business email compromise is often treated as an email security problem. For a CFO or controller, that frame is too narrow.

The criminal may enter through email. The loss usually occurs inside the payment workflow, when an altered instruction is accepted as normal work.

The control gap sits between identity and transaction trust. Knowing that a vendor exists does not prove that the bank account belongs to that vendor. Recognizing a sender's name does not prove that the instruction is valid. A second approval does not help much if both approvers are looking at the same unverified account data.

The dollar loss is only the first problem. Treasury calls the bank. AP stops payments. IT reviews mail logs. Legal asks what must be preserved. Executives want a timeline. The controller reconstructs who saw what, when, and under which policy.

Then the quieter damage starts. The person who approved the payment may keep the job and still lose authority. Routine payments draw new scrutiny. A founder starts approving ordinary payables. Trust shrinks, and the work gets slower.

The attack chain looks like ordinary work

The attack works because each step can resemble a task finance already performs. That is the point.

1. Observation. The criminal learns who can request a payment change, who can update the vendor record, and how the company communicates. Prior invoice traffic, public information, and a compromised mailbox can all help build the script.
2. Pretext. The criminal creates a reason for action. A supplier has changed banks. A law firm sends revised trust account instructions. A landlord updates wiring details before closing. The story is plain because plain stories pass.
3. Instruction change. The payment detail changes. The beneficiary account, routing number, remittance contact, or payment timing is altered. This is the heart of the event.
4. Acceptance. The finance workflow absorbs the change. AP updates the record. Treasury releases the wire. The payment rail works as designed.

The fourth step deserves the most attention. A compromised mailbox is serious, but finance teams often do not see it. They do see vendor onboarding, bank changes, invoice approval, payment release, and audit evidence. Those are finance-controlled moments.

Business email compromise succeeds when a communication channel is treated as proof. Email is a delivery channel. A PDF is a format. A phone call is a conversation. None of them, by itself, proves that the named business owns the receiving account.

The familiar controls can arrive too late

Dual approval can fail because it reviews the payment after the false instruction has entered the system. Two people can approve the same bad account number.

Callbacks can fail when the number used for verification comes from the same email, invoice, or PDF that carried the fraud. Even when the number is correct, teams sometimes call the person requesting the change, rather than a contact established before the request.

Vendor master controls can fail when the bank change process is lighter than onboarding. A company may require tax forms and internal approvals at setup, then accept a later account change with fewer checks because the vendor is already known.

Training helps people notice weak signals. It should not be treated as the control. A careful employee can still be deceived by a plausible request sent at the right time.

Segregation of duties can fail when each person relies on the same evidence packet. Different hands touched the transaction, but nobody independently verified the instruction.

The problem is not that these controls are useless. The problem is placement. They govern movement. They do not always prove that the instruction belongs to the counterparty.

Controls belong before the account becomes payable

The strongest control sits before a bank account enters the vendor record or a wire template. After that, the false instruction has already become operational truth.

• Separate vendor identity from account trust. Confirming that a company exists is not the same as confirming that the payment account belongs to that company.
• Treat bank changes as high-risk events. A change to payment instructions should trigger step-up review even when the invoice amount is ordinary.
• Use known-source callbacks. If a callback is required, use a contact source established before the change request. Do not use the number inside the new instruction packet.
• Preserve the evidence. Keep a record of who requested the change, what was checked, which source supported the decision, and when approval occurred.
• Set thresholds by exposure. Controls should reflect payment size, counterparty risk, payment speed, and the cost of delay.
• Watch the handoff. The riskiest point is often the move from request to vendor master update. That is where a false instruction becomes payable data.

Coffr's role is limited to that pre-payment space. It is designed for the exchange and verification of payment instructions before money moves. It is not a payment rail, bank portal, inbox monitor, or recovery service.

For a Coffr walkthrough, start with one recent bank-change file and the evidence behind it. That is where the control either held or became paperwork.

Before the next account becomes payable, require evidence that the instruction belongs to the counterparty you intend to pay. Approval should come after that proof, not in place of it.