A vendor bank change should never be treated as a routine administrative update. It is a high-risk change to payment master data that can redirect a legitimate payment to an account controlled by a fraudster.
A secure vendor bank change process combines secure submission, independent account validation, callback verification, and dual approval. The new account should also remain on payment hold until the required checks are complete.
This is especially important because business email compromise can involve a genuine vendor mailbox or an existing email thread. The FBI and CISA recommend verifying payment changes through a known telephone number or another trusted channel instead of relying on the communication requesting the change.
For organizations looking to strengthen this process while reducing manual effort, automated vendor account validation can help verify account ownership and identify suspicious changes before payment.
Key Takeaways
• Treat every vendor bank change as a high-risk master-data event.
• Do not use ordinary email or spreadsheets as the source of truth.
• Combine account ownership validation with an independent callback.
• Separate request creation from approval and retain evidence for every decision.
Why Do Vendor Bank Changes Require Strong Controls?
Vendor bank changes require strong controls because they can change where money is sent without changing the invoice, purchase order, or supplier relationship.
A fraudulent request may contain accurate invoice numbers, familiar signatures, and a convincing explanation, such as a bank merger or internal restructuring. In a business email compromise attack, criminals may also use a genuine supplier mailbox or reply inside an existing email thread.
That makes traditional email reviews unreliable. The message may look authentic even though the bank details are fraudulent.
Trustpair’s guide to vendor email compromise explains why checking the sender is not enough when a supplier’s genuine mailbox has been compromised. The account itself must be verified independently.
The consequences of payment diversion can include financial loss, delayed deliveries, duplicate payments, difficult recovery efforts, supplier disputes, and audit findings. The control objective is therefore simple: no replacement bank account should become payment eligible until the organization has verified both the legitimacy of the request and the ownership of the destination account.
How Should a Secure Vendor Bank Change Process Work?
A secure process should follow a consistent sequence:
- The vendor submits the request through an approved channel.
- The request is checked for completeness.
- The new banking details are validated independently.
- A callback is completed when required.
- An independent reviewer approves or rejects the request.
- The account becomes eligible for payment only after approval.
This sequence separates the person submitting the change from the people validating and approving it.
Which Changes Should Be Covered?
The policy should apply to changes involving bank account numbers, routing numbers, ACH instructions, wire instructions, beneficiary names, payment addresses, bank countries, and payment currencies.
It should also cover related changes to vendor phone numbers, email addresses, and legal-entity information. A bank change that follows several other master-data changes deserves additional scrutiny.
Which Submission Channels Should Be Approved?
The preferred channel is an authenticated vendor portal or a controlled workflow connected to the vendor master-data process.
Ordinary email may notify a vendor that a request has been received, but it should not be used as the source of truth for updating the master record. Spreadsheet-based requests should also be rejected because they create outdated versions, unauthorized edits, and unclear ownership.
How Should Banking Details Be Captured Securely?
Banking details should be submitted through a secure form that identifies the vendor user, records the submission time, and preserves the original request.
The form should capture the vendor’s legal name, account holder name, financial institution, account number, routing number or other local identifier, bank country, payment currency, effective date, and reason for the change.
The workflow should prevent uncontrolled edits after submission. If the vendor needs to correct the request, the correction should create a new version rather than silently replacing the original.
How Should Sensitive Data Be Protected?
Full account numbers should be masked wherever complete visibility is unnecessary. Access should be role-based, and employees should only see the information required for their task.
Banking data should be encrypted in transit and at rest. The system should also record who viewed or changed sensitive information and prevent unnecessary downloads of full account details.
How Should Submitted Banking Details Be Validated?
Banking details should be validated in several layers. A format check can identify obvious mistakes, but it cannot prove that an account belongs to the vendor.
The validation process should assess the account format, financial institution, account ownership, existing vendor record, country, currency, and unusual changes.
Are Routing Number Checks Enough?
No. For U.S. accounts, an ABA routing number contains nine digits, including a check digit. This helps confirm that the number follows the expected format, but it does not establish account ownership.
The organization should also verify whether the account is associated with the vendor’s legal entity. Relevant information may include the account holder name, company registration data, financial institution, routing number, account number, and country.
Trustpair’s guidance on account validation services makes the same distinction: validating a routing number alone does not confirm that the account belongs to the intended vendor.
Which Changes Should Trigger Additional Review?
Additional review is appropriate when the request introduces a new financial institution, account holder name, country, currency, or contact detail. Multiple bank changes within a short period should also be investigated.
A new country is not automatically fraudulent. It may reflect an acquisition, treasury change, or legitimate banking arrangement. However, the business reason should be documented and independently confirmed.
When Should You Use a Manual Callback or Automated Validation?
Manual callbacks and automated validation should work together.
Automated validation is useful for routine checks, high transaction volumes, consistent decision-making, and continuous monitoring. Manual callbacks are most valuable when a request is unusual, incomplete, urgent, or high risk.
Trustpair’s article on vendor validation automation describes this layered approach: automated checks handle routine verification, while human review addresses exceptions and cases requiring additional confirmation.
| Control area | Manual workflow | Automated workflow |
|---|---|---|
| Submission | Email, spreadsheet, or manual form | Authenticated portal or integrated workflow |
| Validation | Employee performs individual checks | Rules and account checks run automatically |
| Callback | Often required for every change | Triggered for exceptions and high-risk cases |
| Processing time | Depends on staff and vendor availability | Near real-time for supported checks |
| Audit trail | Requires manual documentation | Captured throughout the workflow |
| Best use | Complex or exceptional cases | Routine volume and continuous monitoring |
Automation should reduce repetitive work without removing human judgment. An inconclusive result should be reviewed, not automatically approved.
How Do You Complete an Independent Callback?
An independent callback confirms that the vendor actually requested the change. It must use contact information that did not originate from the request.
Use a Trusted Phone Number
Use a number from the existing vendor master record, a previously verified contract, a trusted procurement contact, or another independently sourced record.
Never use the number included in the email, invoice, attachment, or signature associated with the bank change request. CISA specifically recommends using a known contact number rather than one provided in the electronic communication.
Ask the Vendor to State the Change
Do not read the new account information aloud and ask the vendor to confirm it. Instead, ask the representative to state the reason for the change, the new financial institution, the expected effective date, the account holder name, and the authorized contact responsible for the request.
This approach provides stronger confirmation because the representative must provide the information independently.
Record the Callback Outcome
The callback record should include the date and time, phone number used, source of the number, representative’s name and role, questions asked, information provided, and final result.
Trustpair’s guide to callback procedures provides additional recommendations for documenting phone-based verification before releasing payment.
Why Is Dual Approval Required Before Activation?
Dual approval prevents the person who creates a change from unilaterally activating it.
The requestor should submit the change and attach the validation evidence. An independent reviewer should assess the callback record, account ownership result, reason for the change, and any risk indicators.
The new account should become payment eligible only after approval. Rejected or incomplete requests should remain in a controlled queue rather than being repeatedly edited until they pass review.
Urgency should accelerate escalation, not eliminate the approval requirement.
What Should Happen When a Request Looks Suspicious?
A suspicious request should trigger an immediate payment hold and escalation.
The organization should prevent activation of the new account, notify finance or procurement leadership, and involve information security if vendor mailbox compromise is suspected. The original email, attachments, portal submission, validation results, callback notes, approval decision, and related payment records should be preserved.
If payment has already been sent, the organization should contact its bank immediately and follow its incident response process.
What Should the Audit Trail Include?
The audit trail should reconstruct the complete decision from the original vendor record to the final payment eligibility decision.
It should preserve the original banking details, submitted replacement details, requestor identity, submission time, validation results, account ownership evidence, callback outcome, reviewer identity, approval decision, and payment hold or release timestamps.
The audit log should capture before-and-after values rather than only the current record. Administrative actions, reopened requests, rejected changes, and changes to approval status should also be recorded.
Access to the audit log should be restricted and monitored separately from access to the vendor master record.
How Should Evidence and Retention Be Managed?
Retention requirements should reflect applicable regulations, contracts, internal policies, audit requirements, litigation needs, and risk level.
For ACH-related programs, organizations should align their process with applicable Nacha requirements. Nacha recommends confirming changes to payment instructions through a separate communication channel rather than relying on the original request.
Higher-risk records, including rejected, emergency, escalated, and fraud-related changes, may require stronger evidence handling and longer retention.
The retention policy should define what is preserved, how long it is retained, who can access it, and how records are protected from alteration.
How Should Banking Details Be Protected After Approval?
Approval does not end the control process. Banking information remains sensitive master data throughout the vendor lifecycle.
After approval, organizations should limit editing permissions, mask full account numbers, encrypt data, monitor related master-data changes, and review access rights regularly.
Monitoring should include changes to vendor phone numbers, email addresses, payment addresses, and legal-entity information. Fraudsters may change contact details first and banking details later.
How Should Urgent Requests Be Handled?
An urgent request should follow an expedited process, not a weaker one.
The request should include a documented business justification, confirmation from the business owner, an independent callback, dual approval from authorized reviewers, and a post-event review.
If payment must proceed before every check is complete, an authorized senior employee should explicitly accept the risk. The remaining validation steps should then be completed immediately.
How Can the Process Be Monitored Continuously?
Organizations should measure whether the process works in practice, not just whether a policy exists.
Useful metrics include callback completion rates, automated validation exceptions, rejected requests, emergency changes, approval-separation failures, repeated vendor changes, and records with incomplete evidence.
Internal audits should sample approved, rejected, and escalated requests to confirm that the request used the approved channel, account ownership was checked, the callback used an independent number, the reviewer was separate from the requestor, and payment eligibility remained blocked until approval.
A high approval rate is not necessarily a sign of a strong process. It may indicate that reviewers are approving changes without sufficiently challenging the evidence.
What Is the Practical Implementation Checklist?
Policy and Ownership
Define bank changes as high-risk master-data events, assign ownership to the vendor maintenance team, prohibit ordinary email and spreadsheets as intake channels, and document payment holds and escalation rules.
Intake and Validation
Use an authenticated portal, mask sensitive information, validate routing and account details, confirm account ownership, and flag unexpected country, currency, and account-holder changes.
Callback and Approval
Use a trusted phone number, ask the vendor to state the requested change, record the callback outcome, separate request creation from approval, and require approval before payment eligibility.
Audit and Monitoring
Capture user identities and timestamps, preserve before-and-after values, restrict audit-log access, review rejected and emergency changes, and test the process through internal audits.
Final Recommendations for Secure Vendor Bank Changes
The strongest secure vendor bank change process is layered. It does not depend on a single email, employee, or routing-number check.
Use secure intake to control where requests originate. Use automated validation to identify account and vendor inconsistencies. Use an independent callback to confirm the request with the supplier. Use dual approval to prevent unilateral activation. Finally, preserve the evidence so every decision can be reviewed.
For additional guidance, explore Trustpair’s resources on vendor fraud schemes and vendor validation automation.
The goal is not to make every bank change slow. It is to make high-risk changes visible, verifiable, and supported by evidence before money moves.