Vendor payment change fraud occurs when an attacker persuades an organization to redirect a legitimate supplier payment to an account controlled by the attacker. The request may come from a spoofed domain, a compromised vendor mailbox, a hijacked email thread, a fraudulent supplier portal update, or an impersonated executive. Because the invoice, relationship, names, and timing may all look genuine, ordinary invoice matching is not enough.
This guide explains how procurement, accounts payable, treasury, information security, and TPRM should prevent, detect, and respond to fraudulent vendor bank-account changes. The strongest control is simple: no payment instruction changes are trusted until independently verified through a previously established channel.
What Is Vendor Payment Change Fraud?
Vendor payment change fraud is a form of business email compromise and payment diversion. A criminal sends or alters a request to change a supplier’s bank account, beneficiary, payment method, remittance address, or contact details. The organization updates the vendor master or pays an invoice using the fraudulent instructions.
The attacker may compromise the supplier, the buyer, or neither. Common paths include:
- A lookalike domain that differs from the vendor’s real domain by one character.
- A compromised vendor mailbox used inside an existing invoice thread.
- A compromised employee mailbox with access to supplier and payment conversations.
- Malicious forwarding rules that copy or redirect billing messages.
- A fake portal, form, attachment, or phone call requesting new details.
- Social engineering that uses urgency, confidentiality, executive authority, or a claimed banking problem.
- Collusion or misuse by an insider with vendor-master access.
The FBI advises organizations to verify changes in account numbers or payment procedures with the requester and to use contact details obtained independently, not those supplied in the change request.
Why This Is A TPRM Issue
Finance owns payment execution, but TPRM has important context. It knows the supplier relationship, business owner, approved contacts, criticality, incidents, ownership changes, and contractual obligations. Procurement controls onboarding and commercial records. Information security investigates compromised identities and domains. No single function can manage the risk well alone.
TPRM should ensure that payment-change controls are built into vendor onboarding, contact governance, ongoing monitoring, incident handling, and offboarding. It should not become the team that approves bank accounts, but it should make sure the relationship record supports independent verification and escalation.
The Minimum Preventive Control
Every change to vendor payment instructions should require:
- A request submitted through an approved channel.
- Independent verification using a trusted contact already on file.
- Segregation between the requester, verifier, master-data changer, and payment approver.
- Evidence of the verification and approvals.
- A risk-based hold or enhanced review before the first payment to the new account.
Email alone is not independent verification, even when the message comes from the vendor’s normal mailbox. If that mailbox is compromised, replying to it only confirms the attacker’s request.
Control Design Across The Vendor Lifecycle
Vendor onboarding
Collect bank details through a controlled workflow rather than unstructured email. Record the vendor’s legal name, tax identifier, bank-account owner, approved finance contacts, independently sourced telephone number, domain, and business owner. Verify the initial account before use and restrict who can edit the supplier master.
Contracting
State how payment details may be changed and which channels are valid. Require prompt notification of compromised accounts, suspected fraud, ownership changes, and unauthorized instructions. Clarify that a requested change is not effective until the buyer completes verification.
Ongoing relationship management
Keep trusted contacts current. A stale contact list pushes staff toward the contact information supplied in a suspicious request. Revalidate contacts during renewal, material change, ownership change, and after personnel turnover.
Payment change
Route changes through a dedicated queue with maker-checker control. The verifier should call a known vendor representative using the number in the validated vendor record or independently confirm through an approved portal. Record who verified, when, through which channel, what was confirmed, and what supporting records were reviewed.
Offboarding
Disable vendor-master access, portal accounts, standing payment arrangements, and unused purchase-order routes. Retain the decision record and prevent a terminated supplier identity from being reactivated without a new onboarding check.
Red Flags That Require Enhanced Review
- Urgency, secrecy, or pressure to bypass the normal workflow.
- A last-minute bank change near an invoice due date.
- A new country, currency, beneficiary, or bank inconsistent with the contract.
- A beneficiary name that does not match the supplier’s legal entity.
- A free email address or a subtle change in the supplier’s domain.
- A request to communicate only by email or avoid a known contact.
- An attachment or link that replaces a normal portal process.
- A request split into smaller payments or routed through an intermediary.
- A bank account shared by unrelated suppliers.
- Changes to both contact details and bank details in the same request.
- A vendor ownership change, insolvency concern, or disputed invoice.
- A first payment immediately after a dormant supplier is reactivated.
A red flag does not prove fraud. It increases the evidence and approval needed before the change becomes effective.
A Practical Payment Change Workflow
1. Quarantine the request
Do not update the vendor master directly from the email or invoice. Capture the request in the controlled workflow, preserve the message and headers, and pause related payment when risk indicators are present.
2. Validate the supplier identity
Match the legal entity, contract, purchase order, tax identifier, business owner, and approved contacts. Investigate changes in domain, ownership, or beneficiary. A correct invoice number does not establish authenticity because attackers may have observed the real thread.
3. Verify out of band
Contact the supplier through a number or portal already validated before the request. Speak with an authorized representative and use a challenge based on relationship records that are not contained in the suspicious message. Do not use a number, link, or contact introduced by the change request.
4. Validate account ownership
Use available bank-account validation, beneficiary matching, confirmation-of-payee, tax, or supplier-verification services where appropriate. Treat a mismatch, unsupported intermediary, or unexplained country change as an escalation.
5. Apply dual approval
The individual entering the change should not be its final approver. High-value or unusual changes may require treasury, procurement, the business owner, or fraud specialists according to documented thresholds.
6. Control the first payment
Consider a waiting period, low-value test payment, enhanced approval, real-time monitoring, or confirmation after receipt. Do not announce a predictable control that attackers can easily imitate without considering how the verification itself will be secured.
7. Notify relevant owners
Tell the business owner and procurement that verified payment details changed. Unexpected objections can reveal a fraudulent or unauthorized request before funds are sent.
Evidence The Control Should Produce
- Original change request and preserved message headers.
- Supplier record used for trusted contact information.
- Name and role of the vendor representative contacted.
- Date, time, channel, and result of verification.
- Account-owner or beneficiary validation result.
- Maker, checker, and final approver records.
- Reason for any exception or urgent override.
- First-payment monitoring or confirmation.
- Security or fraud case reference when suspicious.
TPRM, Procurement, And Finance Responsibilities
| Function | Primary responsibility |
|---|---|
| Business owner | Confirms the relationship, expected invoice, and legitimate business change. |
| Procurement | Maintains supplier identity and commercial records; challenges changes inconsistent with the contract. |
| Accounts payable | Operates the controlled change process and invoice-payment checks. |
| Treasury | Approves or monitors high-risk payments and supports recall procedures. |
| TPRM | Maintains relationship context, vendor contacts, material-change triggers, and third-party incident coordination. |
| Information security | Investigates compromised accounts, domains, email rules, malware, and access. |
| Fraud or compliance | Defines detection rules, investigates suspected fraud, and supports reporting. |
| Legal | Advises on contractual, notification, recovery, and evidence issues. |
What To Do After A Suspected Fraudulent Payment
- Contact the financial institution immediately and request a hold, recall, or communication with the receiving bank.
- Activate the fraud and incident-response process; preserve emails, logs, approvals, call records, and payment details.
- Disable or secure compromised accounts, revoke sessions, review forwarding rules, and reset credentials.
- Contact the vendor using trusted information and coordinate containment.
- Identify related invoices, pending payments, changed master data, and other affected suppliers.
- Notify law enforcement, insurers, regulators, customers, or other parties when required and appropriate.
- Document the control failure and complete corrective actions before normal payment processing resumes.
Common Mistakes
Calling the number in the request
An attacker can control both the email and the supplied phone number. Use independently validated contact data.
Relying on invoice matching
A compromised mailbox gives attackers real invoice details. Match the invoice, but independently verify the payment destination.
Letting one employee make and approve the change
Segregation reduces error, insider misuse, and successful social engineering.
Ignoring small account changes
Attackers may test controls with a small payment before pursuing a larger amount.
Keeping trusted contacts only in email
A secure vendor record or approved portal is more reliable than searching old threads during an urgent request.
Analyst Takeaway
Vendor payment change fraud is controlled through verified identity, trusted channels, segregation of duties, and evidence. The critical rule is that the change request cannot validate itself. Procurement establishes supplier identity, finance controls master data and payment, TPRM supplies relationship context, and security investigates compromise. Together they create a process that remains reliable even when a legitimate mailbox has been taken over.
FAQ
Is replying to the vendor email enough verification?
No. The mailbox or thread may be compromised. Verify through a previously established contact number, approved portal, or other independent channel.
Who should approve a vendor bank-account change?
Use a maker-checker process. The approver should be independent from the person entering the change, with additional authority for unusual or high-value changes.
Should TPRM own the vendor master?
Usually no. Finance or procurement typically owns supplier-master controls. TPRM should ensure the relationship record, trusted contacts, material-change triggers, and incident process support those controls.
What is the first action after discovering a fraudulent transfer?
Contact the financial institution immediately to seek a hold or recall, then activate incident response and preserve evidence.
