Article
Why Only 18% of Firms Continuously Revalidate Vendor Bank Details
New data from the 2026 Treasury Dragons / nsKnox Payment Fraud Index shows that 76% of organizations were hit by payment fraud in the past year, yet only 18% continuously revalidate supplier bank details, and 41% still send that data by email (nsKnox/Treasury Dragons, 2026). That gap between how confident finance teams feel about their vendor banking data and how rarely they recheck it is exactly where bank-change fraud gets through.
If you run AP for a services firm paying subcontractors and vendors by ACH, this is not a treasury-department problem you can skip past. You don't need a treasury function to have the gap. You need a habit of rechecking, and most AP teams don't have one.
What Did the 2026 Treasury Dragons/nsKnox Payment Fraud Index Find?
The index surveyed treasury and finance practitioners and found three things sitting on top of each other. First, 76% of organizations experienced payment fraud in the past year (nsKnox/Treasury Dragons, 2026). Second, 79% of respondents rated their confidence in their supplier banking information as high or very high, even though only 18% continuously revalidate those details (nsKnox/Treasury Dragons, 2026). Third, 41% of organizations still receive sensitive supplier or payment data by email, and only 39% always use a secure or encrypted channel for it (nsKnox/Treasury Dragons, 2026).
Put plainly: most finance teams check a vendor's bank account once, usually at onboarding, feel good about it, and never look again. That one-time check is also the control most AP teams at smaller firms already rely on, because it's the only one anyone taught them.
This tracks with a separate, independently-run survey. The Association for Financial Professionals' 2025 Payments Fraud and Control Survey found 79% of organizations were victims of payment fraud attacks or attempts in 2024, and business email compromise (BEC) was the number-one avenue cited by 63% of respondents (AFP, 2025). Two different surveys, same shape: fraud attempts are near-universal, and the control that would stop the most common version of it - a changed bank account - is the one teams skip.
Why Does a One-Time Vendor Check Stop Protecting You After Month One?
A bank account verified at onboarding only tells you the account was legitimate on the day you checked it. It tells you nothing about whether that account is still the right one six months later, after the vendor switched banks, after an employee's email got compromised, or after a fraudster sent a convincing "updated remittance details" email that looked exactly like every other vendor email you get.
This is the structural problem with "verify once, trust forever." Fraud doesn't happen on day one, when everyone is paying attention. It happens in month seven, on a recurring vendor you've paid forty times without incident, when a bank-change request arrives that looks completely routine. The nsKnox data shows that gap is now the norm rather than the exception: continuous revalidation sits at 18% while confidence sits at 79% (nsKnox/Treasury Dragons, 2026). Most teams are confident about a check they already stopped doing.
For a lean AP team, "continuous" doesn't have to mean a dedicated treasury tool. It means a trigger: any time a vendor's bank details change, on any invoice, that change gets independently confirmed before the payment goes out, not waved through because the vendor name and invoice format look familiar.
What Does Sending Bank Details by Email Actually Expose?
Email was built for messages, not for sensitive financial data, and it shows. When 41% of organizations still receive bank details by email and only 39% always use an encrypted or secure channel for it (nsKnox/Treasury Dragons, 2026), you have a point where the control and the attack surface are the same channel.
A fraudster who compromises (or spoofs) a vendor's email account doesn't need to breach your systems at all. They send a routine-looking note: new accountant, new bank, please update your records for the next payment. If the only verification step is "it came from the vendor's usual email address and the signature block looked right," there is nothing left to catch it. That is exactly how bank-change scams work, and it's the same mechanism behind the $67,000 fake invoice scam that cost one AP team a painful lesson in what "it looked legitimate" is worth.
The fix is not complicated, it's just rarely enforced: never accept a bank-detail change over the same channel the request arrived on. Confirm it through a second, independently-initiated channel, like a phone call to a known number on file, not one in the email.
How Do AI-Altered Invoices Defeat a Visual Bank-Detail Check?
A visual check asks: does this invoice look right? AI-generated and AI-edited invoices are built to pass exactly that test. They reproduce a vendor's logo, invoice numbering pattern, and formatting well enough that a reviewer scanning for anything "off" finds nothing. The only thing that changed is the bank account at the bottom, which is the one field a visual review is least likely to scrutinize line by line.
We've covered the mechanics of this in more detail in how AI-generated fake invoices are now passing AP review, but the short version matters here: once an attacker can clone the look of a real invoice, "does this look like a document we usually get from this vendor" stops being a meaningful control. What still works is checking the bank account itself against a source that isn't the document in front of you - a confirmed record of the vendor's verified account, independent of whatever the invoice claims this time.
This is also why agreement-level matching catches more than a glance at the PO. A rate card or SOW won't tell you the invoice is fraudulent on its own, but a payment workflow that already requires every line to trace back to a verified agreement and a verified payee has a natural checkpoint built in, instead of relying on a reviewer's eye for forged formatting.
What Does a Practical Revalidation Workflow Look Like for a Lean AP Team?
You don't need a treasury department to close most of this gap. You need three habits, applied consistently, every time:
- Verify at onboarding, through a channel the vendor didn't choose. Call a number you found independently, not one in their email signature.
- Treat every bank-detail change as a new verification event, regardless of how long you've paid that vendor or how routine the request looks.
- Separate the request from the confirmation. Whoever processes the change should not be the only person who confirms it; a second person or a second channel closes the loop.
For a firm paying a hundred invoices a month, this is a checklist a controller or senior AP person can run by hand: a shared log of verified accounts, a standing rule that no bank-detail change posts without a callback, and a second set of eyes before anything moves. It is tedious, but it is exactly the kind of tedious, repeatable work that is cheap to do consistently and expensive to skip.
Where this starts to strain is volume. Past roughly 200 invoices a month, manually tracking which vendors were last re-verified and when, on top of everything else AP already does, is where things slip - not because anyone got careless, but because there aren't enough hours in the week. That's the point to automate the check itself rather than add headcount to do it by hand; the goal is to absorb the extra verification work into the process before you need to hire for it, not to replace the person doing the reviewing. The approval still belongs to a human. What changes is whether the bank-account check happens every time or only when someone remembers.
Comparing Vendor Verification Approaches
| Approach | What it catches | What it misses | Effort required |
|---|---|---|---|
| One-time check at onboarding | Fraudulent vendor at setup | Any bank change after day one | Low, one-time |
| Periodic manual review (annual/ad hoc) | Some changes, if timed right | Mid-cycle bank-change scams, AI-cloned invoices | Moderate, recurring |
| Callback verification on every change | Email-based bank-change fraud | Nothing if consistently enforced | Moderate, ongoing discipline |
| Continuous, agreement-aware verification | Bank changes, payee mismatches, invoices tied to unverifiable agreements | Requires a defined process or tooling to run at volume | Higher upfront, lower per-invoice over time |
Only 18% of organizations currently operate at that fourth tier (nsKnox/Treasury Dragons, 2026), which is also why it's the tier the fraud data says matters most.
What Should a CFO Ask About Vendor Bank-Detail Verification?
A CFO doesn't need to run the callback script, but they should be able to answer three questions about their own AP process: When was the last time every active vendor's bank details were independently re-verified? What happens, specifically, when a vendor emails a bank-change request - is there a defined second-channel confirmation step, or does it depend on who's reviewing that day? And is there an audit trail showing who verified what, and when, if a regulator or auditor ever asks?
If those answers are vague, the exposure isn't hypothetical. It's the same gap 76% of organizations in the nsKnox data already experienced as real fraud, not a near miss (nsKnox/Treasury Dragons, 2026). An explainable, auditable record of every verification is the difference between telling the board "we check this" and being able to show exactly when and how.
FAQ: Vendor Bank-Detail Verification
What is vendor bank detail verification?
Vendor bank detail verification is the process of independently confirming that the bank account tied to a vendor payment belongs to that vendor, through a channel the vendor did not initiate, before money is sent.
How often should you revalidate vendor bank details?
Any time the bank details change, treat it as a new verification event, regardless of how long you've worked with the vendor. A recurring annual review is a reasonable baseline on top of that, but it does not replace checking every change as it happens.
What is a bank-change scam?
A bank-change scam is when a fraudster, often via a compromised or spoofed vendor email, requests that future payments go to a new bank account they control, relying on the fact that most AP teams accept such requests without independent confirmation.
Can AI-generated invoices pass a normal AP review?
Yes. AI tools can closely replicate a vendor's logo, formatting, and invoice numbering, which defeats a visual review focused on whether a document "looks right." Verifying the underlying bank account and agreement independently catches what a visual check misses, as covered in how AI-generated fake invoices are now passing AP review.
Does my firm need a treasury department to do this?
No. A documented callback-verification process, a log of confirmed vendor accounts, and a rule that no bank-detail change posts without independent confirmation covers most of the risk for a services firm, without dedicated treasury staff.
Next Step
The data is consistent: confidence in vendor banking information is high, continuous revalidation is rare, and that gap is where payment fraud gets through. Start by auditing how your firm currently handles bank-detail changes - not how it's supposed to work, how it actually works the next time a vendor emails new remittance instructions. For more on how fraud slips past AP review and what actually catches it, see the rest of the Quittance blog.