Who made the request, and what is supposed to change?
A finance employee may receive a bank change from a supplier’s usual address with a credible company form. The address may belong to a compromised account. A valid approval account also leaves open whether the approver saw the final beneficiary or an earlier draft. The FBI’s Internet Crime Complaint Center (IC3) describes business email compromise (BEC), including unauthorized transfers induced from legitimate accounts, and recommends independent verification for changes to account details. FBI IC3 — Business Email Compromise[1]
In December 2024 the same agency warned about the use of AI-generated text, audio, and video in financial fraud. An unfamiliar tone or typo may prompt a check. Apply the control based on the state change requested, such as a new beneficiary, urgent payment, or contact change. An unresolved question about whether a message was synthetic is compatible with holding an unverified change. FBI IC3 — Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud[2]
A second channel loses value when it comes from the same request. A number in an attachment, a chat account supplied by email, and a button on a page may share a source. Use a supplier number verified during onboarding, an existing contact, an internal directory, or a managed approval system. After an inbound call, hang up and dial a known number. The displayed number alone is insufficient for approval.
Keep beneficiary and verification contact changes separate
Your supplier master contains the legal identity, approved bank account, and contacts relied on by future requests. If the bank and contact records change together and the new contact verifies the new bank account, the request supplies its own evidence. Start with the established channel. If it fails, apply a defined re-verification process, such as reaching the relevant office through a verified switchboard, consistent with your supplier policy.
The table gives examples for payment and access changes. Use your organization’s approval thresholds. New beneficiaries, master data changes, and resets of verification methods can affect multiple later transactions regardless of the amount.
| Request | Independent verification | Approver or verifier | Record |
|---|---|---|---|
| New or changed supplier bank details | Use existing contact or verified switchboard | Master data administrator and separate finance approver | Supplier and change IDs, old and new account references, channel and time |
| Change supplier contact or email | Use previous contact or approved supplier re-verification | Data administrator and supplier owner | Prior evidence, new verification, effective time |
| Urgent executive payment | Verify through an internal directory or approval system | Authorized payment approver and execution reviewer | Purpose, amount, beneficiary, approved version, outcome |
| Payment to existing beneficiary | Reconcile approved supplier against purchasing, receipt, and invoice information | Existing payment approver | Contract, invoice, payment request, review time |
| Finance account recovery or authenticator reset | Use verified internal support and access process | Identity verifier and account administrator | Actor, approval reference, authenticator and session outcome |
| New beneficiary with unreachable historical contacts | Use approved re-verification or new onboarding | Designated finance, purchasing, and supplier owners | Channel failure, replacement evidence, exception scope, pending checks |
Two signatures by the same employee are one independent check. Separate roles and test whether the application lets one account exercise both. Small teams need available deputies and a call order. The second reviewer should see payment details, previous and proposed values, purpose, and verification evidence.
If material transaction data changes after approval, route the new version for approval. Compare the payment system’s transaction ID and version with the values shown during approval. Bind the authorization to those values and check it immediately before execution. OWASP — Transaction Authorization Cheat Sheet[3]
Evidence connected from requirement to approval — Link requirements, tests, defect actions and approval records so teams judge quality consistently.
Rehearse two requests tied to the same fictional payment
A fictional manufacturer receives an email about a new bank account for a parts company, then a call apparently from its CEO asking to rush payment. The email says only the new number in the attachment can reach the supplier. Use invented records and exercise the approval process.
- Separate intake from payment. Register the bank change and check the payment and original beneficiary. Put an eligible pending payment on hold.
- Verify the supplier and executive independently. Use the supplier directory for the account and internal contacts for the executive. A positive result for one does not clear the other.
- Show the verified transaction. Tie purpose, amount, beneficiary, and documents to one version. If anything changes after approval, check the change record and source.
- Record the delay to legitimate work. Notify purchasing and finance when a known contact cannot be reached. Define which evidence releases a legitimate update.
- Escalate discrepancies to finance and security. Check the actual transaction, account activity, and other instructions. Move review out of the suspect thread.
Use variants with credible numbers, sender addresses, and attachments. Test a legitimate executive request and a genuine new supplier account as well. Measure how long checks take and whether a legitimate payment can resume. Define failures for both wrongful approval and a legitimate transaction that never clears.
Make the urgent approval path faster
When legitimate work is delayed repeatedly, staff may skip controls for urgent payments. Define the available people, approval scope, independent contacts, and which waiting periods can be shortened. If a new beneficiary cannot be confirmed at night, reschedule or consider a verified account where terms permit. Keep the temporary exception from changing supplier details for future work.
Record intake time, completion of verification, and posting of payment separately. Reasons such as supplier non-response, unavailable approvers, and inconsistent documents identify delays. If known contacts often fail, assign an owner and update cycle to the supplier directory.
| Exercise | Expected outcome | Change to consider if it fails |
|---|---|---|
| New account and contact arrive together | Verify through established channels and record distinct changes | Remove automated use of proposed contact as evidence |
| Sender resists verification and pressures staff | Contact deputy or hold and verify independently | Test emergency contacts and their availability |
| Amount or beneficiary changes after approval | Reject the prior approval and reapprove the changed version | Review approval binding and edit authority |
| Evidence confirms a legitimate transfer | Release the hold and resume the authorized path | Review hold queue, decision owner, and handoff |
When payment may have run already
If payment has not started, hold the relevant changes and check who edited the records. If it appears to have run or the result is unknown, ask finance and the financial institution through established channels about the existing transaction ID. Do not duplicate a payment while its outcome remains unknown. Assign reconciliation and a follow-up time if the ledger and provider disagree. Confirm what can be canceled or returned with the institution and your company procedure.
Preserve original messages, needed headers, timestamps, changes and approvals, and transaction IDs in restricted storage. Avoid spreading financial details. Suspected account compromise goes to security and operations for review of account activity, sessions, and authenticators. If a separate credential was exposed, follow the secret exposure response to revoke it and check where it was used.
Release holds according to normal payment controls and the available evidence. Document restoration of the beneficiary separately from reconciliation of payments sent while the change was effective. NIST incident response guidance[4] and the incident response runbook can help structure containment, action, recovery verification, and ownership.
