A vendor bank-account change is not routine master-data maintenance. It is a payment instruction that can redirect every future invoice to a different beneficiary. For accounts-payable teams making international supplier payments, the safest policy is simple: no payment detail changes become active until the request, the new beneficiary details, and the approval trail have each been verified independently.
The short answer: for a new or changed vendor bank account in the US, your payment rules should hold the first payment until three checks pass — an independent call-back to a contact on file, validation of the new beneficiary details against the supplier's verified records, and dual (maker-checker) approval after a cooling-off period. Because the rule lives on the vendor record in your payment platform or ERP, the hold is automatic rather than dependent on a busy approver. This page gives you the six-step workflow, the risk-tier model and the ERP configuration checklist that make the control auditable.
How payment rules block payments to a new or changed vendor account
Payment rules block a payment to a new or changed vendor bank account in the US by holding the first payout to the new details until the change passes independent verification. The hold is released only when all three checks clear:
1. Requester verified — the change was confirmed through a known channel (call-back to the number on file), not the email that requested it.
2. Beneficiary independently validated — the new account details match the supplier's verified records (not just the invoice or the request email).
3. Dual approval recorded — maker-checker approval plus the cooling-off period elapsed before release.
For US-based teams, encode this in your payment platform or ERP as a payment rule on the vendor record: first-payment hold = ON for any new or changed bank account. See the six-step workflow below, and the wider accounts payable processing workflow it sits inside.
This guide gives AP, treasury, procurement, and security teams a practical operating model. It focuses on the workflow after a supplier says, “Please update our bank details” - the moment when normal email processes are most vulnerable to business-email compromise and impersonation.
Quick answer: Route every bank-detail change through a controlled case, authenticate the requester using a known contact channel, independently validate the beneficiary data, enforce maker-checker approval, hold the first payment for review, and preserve evidence. A payment platform can automate routing and audit trails, but it must not replace the underlying ownership and escalation rules.
Why Vendor Bank Detail Changes Need Their Own Control
Invoice approval answers whether a business owes money. A bank-detail change answers where that money will go. Treating both as one checkbox creates a dangerous gap: a valid invoice can still be sent to a fraudulent account.
The risk rises in international operations because the supporting evidence varies by market, payment rails have different account formats, and time-zone pressure makes verbal checks tempting to skip. A strong process separates four decisions:
- Is this request genuinely from the supplier?
- Does the new account belong to the intended legal entity?
- Is the change appropriately authorized inside our company?
- Should the first payment be released without an exception review?
NIST's separation-of-duties principle is useful here: access and approvals should be designed so one person cannot request, activate, and pay a changed beneficiary without independent review. See NIST SP 800-53 Rev. 5 for the broader control framework.
Payment Rules for New or Changed Vendor Bank Accounts
Set the rule in the payment platform and ERP: a changed beneficiary remains on hold until independent verification, dual approval and the defined cooling-off review are complete. This control should apply to urgent payments as well as routine batches, with documented exception ownership.
The Six-Step Vendor Bank Account Change Workflow
1. Log the Request as a Case, Not an Email Thread
Create a case in the ERP, procurement system, or payment-operations queue. Capture the vendor ID, legal entity, requester email, original bank data, proposed bank data, payment corridor, change reason, timestamp, and attachments.
Do not let AP staff directly overwrite the vendor master from an email. The original message can be retained as evidence, but it is not proof of authorization.
2. Authenticate the Requester Through a Known Channel
Contact the supplier using a phone number or portal contact already held in the approved vendor record, not the number or link included in the change request. Ask the contact to confirm the change and the authorized signer.
For a supplier with a secure vendor portal, require the change to originate there and still perform a callback for high-value, first-time, or unusual changes. A reply from the same email thread is insufficient: compromised mailboxes can produce convincing replies.
3. Validate the Beneficiary Details Independently
Check format and ownership separately. Validate country-specific fields such as IBAN length, routing codes, account-name requirements, and currency eligibility. Where your bank or provider supports it, use beneficiary account verification before activating the record.
SWIFT's Payment Pre-validation service, for example, includes beneficiary account verification and payment-data validation. These checks help identify bad data early; they do not establish that the supplier requested the change. Your workflow still needs human authentication and approval.
4. Enforce Maker-Checker Approval
The person who enters the change must not be the person who approves it. For material vendors, require a second approver from treasury, procurement, or a designated controller. Approval should display both the old and new fields side by side, not merely a note that says “bank details updated.”
| Control point | Maker | Checker | Evidence |
|---|---|---|---|
| Create change case | AP analyst | - | Request and case ID |
| Verify supplier contact | Procurement or AP | Treasury / controller | Callback record |
| Enter new account | AP analyst | - | Field-level change log |
| Approve activation | - | Independent approver | Approval timestamp |
| Release first payment | Payments operator | Treasury reviewer | Payment review record |
5. Apply a First-Payment Safeguard
For a newly changed beneficiary, pause the first payment for enhanced review. The reviewer should compare the beneficiary, amount, invoice, currency, and destination country with expected supplier behavior. Flag changes that combine several risk signals: an urgent request, a new country, a different beneficiary name, unusual payment amount, or an override request.
This is not a reason to block legitimate suppliers indefinitely. Publish a service-level target, such as one business day for standard changes and expedited handling only with documented senior approval.
6. Notify, Monitor, and Preserve Evidence
Send a confirmation to the supplier's previously recorded contact, not only to the new requester's address. Keep a complete audit trail: the request, verification method, approvals, account validation result, activated fields, and first-payment outcome.
After activation, review the first settlement and reconcile it to the approved supplier record. SWIFT's Payment Controls describes real-time alerting or blocking of outlier payments; comparable rules in your payment stack can provide a useful final safety layer.
A Practical Risk-Tier Model
Not every change needs the same treatment. Risk-tiering lets teams keep routine operations moving without reducing control quality for sensitive cases.
| Change type | Minimum verification | Approval | First-payment rule |
|---|---|---|---|
| Same country, same legal entity | Known-channel confirmation + format check | Maker-checker | Standard monitoring |
| New account or new currency | Callback + account validation | Treasury or controller | Enhanced review |
| New country or beneficiary mismatch | Callback + documentary evidence + escalation | Controller and procurement | Hold pending investigation |
| Urgent executive-requested change | Same controls, no exception by email | Senior approver | Enhanced review |
The key policy is that urgency changes the staffing priority, not the evidence standard.
ERP and Payment Platform Configuration Checklist
A documented process fails if systems allow staff to bypass it. Configure controls where the work happens:
- Restrict vendor-master edit access to named roles.
- Require a case ID and reason code for every bank-field edit.
- Show old and new values in the approval screen.
- Route changes based on country, currency, vendor spend, and account-name mismatch.
- Prevent a user from both editing a vendor and releasing that vendor's payment.
- Add a temporary payment hold or review flag after a bank-detail change.
- Alert on multiple changes for one vendor or multiple vendors changing to the same account.
- Export immutable logs to the finance audit trail.
For implementation architecture, see our guide to ERP and accounting integrations for B2B payments. Teams processing many supplier payments should also use the batch-control patterns in Cross-Border Mass Payouts.
Common Failure Modes
“The email came from the supplier's real domain.” Domain appearance is not authentication. A compromised mailbox, lookalike domain, or forwarded chain can all appear credible.
“Procurement already approved the vendor.” Onboarding approval does not approve a new beneficiary account months later. The change is a new risk event.
“Our ERP has approval workflows.” Verify what the workflow approves. If it does not expose old-versus-new bank values, require independent ownership checks, and block payment release, it may only be documenting an unchecked edit.
“We cannot delay urgent international payments.” A short, properly staffed verification process is cheaper than a recovery attempt. Build an urgent lane with the same control requirements, not a bypass lane.
A 30-Day Implementation Plan
Days 1-7: Map the Current State
List every place vendor bank details can be edited, every role that can approve a change, and every payment system that consumes the master record. Sample the last 20 changes and identify where callback evidence or dual approval is missing.
Days 8-14: Define Policy and Ownership
Publish the risk tiers, acceptable verification channels, approval thresholds, and emergency escalation path. Assign a control owner in AP or treasury and a security partner for suspected compromise cases.
Days 15-21: Configure and Test
Implement role restrictions, maker-checker approval, case IDs, payment holds, and alerts. Test normal changes, high-risk changes, rejected changes, and attempts to bypass the workflow.
Days 22-30: Measure and Improve
Track change volume, average completion time, percent with callback evidence, exceptions, first-payment holds, and detected anomalies. Review the metrics monthly with AP, procurement, treasury, and security.
Frequently Asked Questions
How can payment rules block payments to a new or changed vendor account in the US?
Payment rules block the first payment to a new or changed vendor bank account by holding it in a pending state until the change is verified: an independent callback to the requester's known channel, validation of the new beneficiary details against supplier records, maker-checker approval, and a cooling-off period. In platforms like NetSuite, SAP, or a payment provider's vendor module, this is configured as a first-payment hold rule on the vendor record; the payment is released only when the hold conditions are cleared and the approver records evidence. Without such a rule, the first payment to changed details typically goes out on the normal cycle — which is exactly when diversion fraud succeeds.
Should every supplier bank change require a phone call?
Use a known-channel callback for new accounts, new currencies, high-value suppliers, unusual destination countries, and any suspicious request. Lower-risk changes can use a trusted portal plus independent validation when policy and local requirements allow it.
Can account verification replace supplier confirmation?
No. Account verification can validate beneficiary information or payment-data quality. It cannot prove that the authorized supplier contact requested the change.
Who should own vendor bank-detail controls?
AP usually owns the operational workflow; procurement owns supplier relationship context; treasury owns payment-release risk; security supports compromise investigations. One accountable owner should govern the policy and metrics.
How long should the first-payment hold last?
Until an independent reviewer completes the enhanced review. The policy should define a measurable service level rather than a fixed multi-day delay.
Build a Payment Operation That Is Hard to Divert
The best control is not a single fraud tool. It is a repeatable workflow that makes an unauthorized beneficiary change difficult to introduce, easy to detect, and impossible for one person to push through alone.
Use this process alongside the controls in our B2B payment fraud prevention guide and the operational practices in our international supplier payment terms guide. For global teams, a modern payment platform should provide the auditability and compliance context described in our payment compliance and KYC guide, plus the workflow enforcement that keeps verified supplier payments moving.