vendor bank account change: fraud verification steps
Verifies vendor bank account changes to prevent payment fraud. Use when a vendor requests new payment details. Not for new vendor onboarding.
TL;DR
Fake bank-detail changes are the classic AP fraud: a convincing email redirects payments to the attacker. Verify every change through a second channel: call a known vendor contact (not a number from the request), require dual approval, and send a micro-deposit or penny test before the first real payment. Never change bank details from an email alone.
Steps
- Freeze payments to the vendor on any bank-detail change request.
Expected: No money moves during verification.
- Call a known vendor contact using a number on file, not from the request.
Expected: Out-of-band confirmation.
- Require a second approver for the change.
Expected: Dual control.
- Send a micro-deposit and confirm receipt with the vendor.
Expected: Proof the account is theirs.
- Log the change with who verified and how.
Expected: An audit trail.
When to use
- Bank detail change requests
- New remittance instructions
- Vendor email compromises suspected
When not to use
- New vendor setup (different flow)
- Address changes (lower risk, still verify)
- Payment method changes without new details
Compatibility
ERP-agnostic; process control, not software-specific.
Variant phrasings
vendor bank change fraud
verify new vendor bank account
BEC AP fraud prevention
Root cause
Business email compromise targets AP specifically because the payoff is a redirected payment. The email looks perfect; only out-of-band verification breaks the attack.
Edge cases
- Urgency language ('pay today or penalties') is a red flag, not a reason to skip verification
- Some vendors change banks legitimately during M&A; the process is the same
- Test deposits need the vendor to confirm; build the wait into SLAs
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Gmhq868965ii2fcWajI-aw