## 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

1. Freeze payments to the vendor on any bank-detail change request.
   Expected: No money moves during verification.
2. Call a known vendor contact using a number on file, not from the request.
   Expected: Out-of-band confirmation.
3. Require a second approver for the change.
   Expected: Dual control.
4. Send a micro-deposit and confirm receipt with the vendor.
   Expected: Proof the account is theirs.
5. 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