The Independent-Contact Rule for Vendor Bank Changes

Every reputable AP-fraud framework — the FBI's IC3 guidance, NACHA's fraud-monitoring language, and every social-engineering-endorsement condition in commercial cyber policies — says the same thing in slightly different words: an out-of-band verification uses a channel and a contact record that are independent of the request. If the request came in by email, you don't verify by replying to the email. If the request supplied a phone number, you don't call that phone number. If the request pointed to a “vendor self-service portal” link, you don't follow the link.

Instead, you use a contact record you already had — from before the request existed. That prior record is the independent contact.

The FBI's 2024 IC3 Report attributed $2.77 billion in adjusted losses to business email compromise (FBI IC3 2024 Internet Crime Report, p. 9) — the category that includes almost every fraudulent vendor bank-change request. The pattern behind those losses is remarkably consistent: the attacker's message included its own “please confirm here” contact path, and the firm used it.

Most fraudulent change requests arrive through a compromised vendor mailbox, a lookalike domain, or a reply-to header that redirects responses to a fraudster-controlled inbox. All three attacks have the same effect: you send a “just confirming” email back to what looks like the vendor, and the confirmation comes from the fraudster. The thread reads exactly like a legitimate conversation because both sides are talking to different halves of it.

That is not verification. It is one continuous fraudulent conversation with an extra step. To a claims adjuster reviewing the incident later, “we confirmed by email” is the phrase that gets the claim denied — because the policy required an independent channel, and email replies aren't independent when the request itself came from email.

The phone call has the same failure mode if the number you dial came from the request. Attackers include their own number so the callback lands with them.

An independent source is any record of the vendor's contact information that existed before the change request arrived. In a small bookkeeping firm running client AP, the usable sources are almost always some combination of:

• The vendor master file in the client's ledger (QuickBooks, Xero, Sage, etc.) as it stood before the change request.
• A prior invoice from that vendor — pull the header, footer, or remittance stub of a bill you paid three months ago.
• The vendor's signed engagement letter, contract, or W-9 in the client file.
• The vendor's real, publicly listed website — found through your own search, not clicked from the change request. Cross-check the domain against the domain on prior invoices.
• The client themselves, on the phone number you already use to contact the client (not a client email that may also be compromised).

Any one of those channels is independent. Two of them together are strong. The number in the change email is not independent no matter how professional the email looks.

The traps are the ones firms fall into most often:

• The number in the request email. Even if the signature block says “Direct line,” it is still inside the request.
• A reply to the request email. Same channel, same failure mode.
• A “vendor portal” link inside the request. The link is under the attacker's control.
• The number on a PDF attached to the request. Attachments are part of the request.
• A number from a Google search where the top result looks right. Attackers buy paid search results for common vendor names; verify the domain matches prior invoices before dialing.
• Contacting a different person “at the vendor” whose contact details also came from the request. The whole request is untrusted.

If you have to ask whether a source counts, it doesn't. The safe test: could this contact detail have been supplied by the attacker? If yes, use a different source.

The complication for firms running AP across many clients is that the vendor master file lives in each client's ledger, and the independent source has to be pulled per client. The vendor that emailed client A about “new bank details” may not be a vendor at client B, or may have a different contact record there.

The workable pattern is: for every bank-change request, pull the independent contact from that specific client's vendor file (or prior invoice inside that client's records), perform the callback on that number, and log the source of the number in the verification record. When an auditor or insurer later asks how you verified, “the number came from the July 2025 invoice in QuickBooks for [client]” is a defensible answer. “The number came from the change email” is not.

The multi-client vendor-verification workflow covers this in more depth.

Applying the rule is half the control. Documenting the application is the other half — and it is the half insurers and ODFI reviews increasingly focus on. On every bank-change verification, capture:

• The date and time of the verification call.
• The number you called and, in one line, where that number came from (“prior invoice, March 2025,” “vendor master file record predating change request,” “engagement letter dated 2024”).
• Who you spoke with at the vendor, and what they confirmed in their own words.
• Who approved the change on your side.

If the entries live in a tamper-evident log across all your clients, the record is portable — you hand it to a client, an auditor, or an insurer without reconstructing it.

For the end-to-end procedure, see how to verify a vendor bank account change, and use the free vendor bank-change verification template — it embeds the independent-contact rule in a one-page checklist and log sheet.