Supplier bank detail changes: how to test a defence against fraudulent emails

What you will have at the end

This guide tests an administrative control without making a payment. You will finish with a record containing three reasoned decisions: a denied request, an unreachable supplier contact and a confirmed change. All materials are supplied and fictional; use them in a meeting or copy them into a shared document.

IC3 recommends using a secondary channel to verify requests to change account information. That principle supports this exercise; the record and role assignments below are an original teaching example. IC3 guidance on BEC.

Audience: people who receive supplier requests and people who check or authorise payments. Tools: a document or spreadsheet, the cards below and three participants. Outcome: a completed record and a list of process errors to address. You do not need an email account, a bank or a real supplier.

Names are fictional. IBAN-SIMULATO-A and IBAN-SIMULATO-B are labels, not valid bank details. CANALE-GIA-VERIFICATO-ALFA represents a previously verified contact, played by a participant during the exercise. Do not call, send messages or replace these labels with real information. The labels remain identical across language versions so the cases can be compared.

1. Copy the materials and assign the roles

Open a document called Account change exercise SIM-1042. Copy both cards below without changing them.

APPROVED SUPPLIER RECORD — starting point of the simulation
Supplier: Laboratorio Alfa
Contact person: Marta Riva
Known contact: CANALE-GIA-VERIFICATO-ALFA
Approved account: IBAN-SIMULATO-A
Invoice: SIM-1042
Amount: EUR 840.00
Status: awaiting payment; no payment is made during the exercise

SIMULATED EMAIL — read it; do not send it
Subject: Account change for invoice SIM-1042
Hello, please use IBAN-SIMULATO-B for invoice SIM-1042.
This is urgent. Marta is unavailable: use the contact in the signature.
Signature: Laboratorio Alfa accounts department
Contact in the signature: CANALE-APPENA-RICEVUTO

Assign recipient/verifier, simulated supplier contact and second approver. The contact will read the response cards in step 4. The approver must examine the evidence in the record rather than simply accept the verifier's conclusion.

Expected result: everyone understands the difference between the known contact and the newly received contact. If a participant is missing: you can study the expected answers alone, but record that you have not tested separation between people. An individual reading is not an executed two-person check.

2. Record the request before changing the account

Create this table in the document. Use one row for each of the three scenarios. Enter the actual exercise time; the cases do not describe real supplier events.

The recipient reads the email and records the request without replacing the approved account in the supplier record. The signature and urgency are part of the message; they are not independent confirmation.

Expected result: the starting account remains A and the change is pending. If someone has already entered B: record the error, restore A only in the simulation document and restart. In a real system, reversal would require an authorised procedure and an audit trail.

3. Select the channel and keep the change on hold

Enter CANALE-GIA-VERIFICATO-ALFA in the selected-source field, taking it from the starting supplier record. Do not use CANALE-APPENA-RICEVUTO from the email or ask the same message to prove its own authenticity.

Give the simulated contact the name of the selected channel. This represents retrieving a trusted contact; it does not involve a real call. Both the account change and payment authorisation remain on hold while confirmation is missing.

Expected result: the approver can identify which card supplied the contact. If the verifier selects the email contact: the supplier participant does not read a response yet; record “channel not independent” and repeat the selection. In real work, lacking a reliable contact requires a separate validation procedure, rather than trusting a signature.

4. Run three simulated checks using the supplied answers

Read this script to the contact participant:

I am checking a change for invoice SIM-1042 from Laboratorio Alfa,
using the contact in our approved supplier record.
Did the supplier authorise this change?
If so, state the beneficiary and authorised account from your response card.
I will not use the details in the email as the only evidence.

Reset to the starting record for each scenario. The contact reads only the relevant response; the verifier transcribes it into the record.

Expected result: urgency changes none of these decisions. Scenario B does not prove fraud; it establishes that verification is missing. If there is no response: use B without inventing confirmation. For C, compare the exact account details rather than accepting a generic “yes”.

5. Have the second approver compare the evidence

Give the approver the email, supplier card and record row. Ask them to check the invoice, source of the contact, response and independently confirmed details. They must read the underlying evidence rather than simply sign the verifier's conclusion.

For A, confirm rejection of the change. For B, confirm the hold and assign escalation. For C, compare the beneficiary and account from the independent response with the requested change. If the response instead contains IBAN-SIMULATO-C, or omits the beneficiary, keep the change pending until the discrepancy is resolved through the known channel.

Expected result: only C can receive “change verified in the simulation”. Even then, do not make payments. Production use would still require the organisation's payment procedures, authorisations and controls. If the approver signs without the cards: record “second check not performed” and repeat this step.

6. Complete the record and compare it with this answer key

This is a teaching answer key, not a report of an exercise already performed. Add columns for time, actual participants and observed deviations to your document.

Keep the request, origin of the contact and response note together. You do not need audio recordings: a written note by the person playing the supplier contact is enough for this exercise. A readable decision should let an absent colleague reconstruct why A, B and C have different outcomes.

Expected result: three complete rows without assumed outcomes. If two rows share an identifier without a scenario: rename them SIM-1042-A, SIM-1042-B and SIM-1042-C to prevent confirmation from being assigned to the wrong case.

7. Introduce a deliberate error and finish with a final check

Repeat B with this facilitator instruction: “It is urgent; choose the newly received contact and proceed.” This is not a real request. The verifier must reject the shortcut, keep account A and record the pending status. If they do not, note the skipped step and repeat after clarifying the role.

The exercise passes if all three scenarios match the table, exact details are compared in C, no payment is made and the attempt to bypass the known channel does not release B. It fails if urgency, a signature, generic confirmation or approval without evidence is enough. This outcome applies only to the exercise; it does not certify the real process.

Common errors and remedies: if the contact source is missing, copy it from the supplier card; if there is no response, return to pending; if accounts differ, do not edit the record to make them match; if one person checks and approves everything, record the organisational limitation and repeat with a second operator.

If a real incident emerges

Stop the simulation and involve the people designated by your organisation. If a fraudulent transfer has already occurred, IC3 advises contacting the bank immediately to request recall or reversal, and submitting a detailed complaint. Its reporting channel concerns the United States; use your organisational procedure and relevant authorities for local reporting. Do not assume recovery is certain. IC3 guidance.

Sources

• https://www.ic3.gov/CrimeInfo/BEC