When Australia's banks rolled out Confirmation of Payee, the pitch was simple: type in a BSB and account number, and the system tells you whether the name matches before you send money. It's a genuinely useful control, and the adoption numbers back that up — more than 140 million accounts were covered across 100 or more institutions within about a year of its July 2025 launch (source: Australian Payments Plus, 2026). For a consumer transferring rent to a new landlord, or a sole trader paying a supplier for the first time, that's a real reduction in a real risk.
It's also almost entirely beside the point for how a mid-sized or enterprise AP function actually pays its suppliers.
The control only runs where the fraud isn't
Confirmation of Payee checks a payee's name at the moment it's added or edited inside online banking — one payee, one screen, one human deciding whether to proceed. That's not how accounts payable teams pay two hundred suppliers on a Thursday. Payment runs go out as a single uploaded file — an ABA direct-entry file, or the ERP's equivalent batch export — and multiple banks have said plainly, in their own public FAQs, that CoP does not check payees included in a batch upload. New Zealand's equivalent, branded GetVerified by the NZ Banking Association, has the identical exclusion: the check runs when a payee is added or edited individually, not against a bulk file.
So the fraud that CoP is genuinely good at catching — someone manually keying in a dodgy account for a one-off transfer — is exactly the fraud that was never really the problem for a business AP team. The fraud that is the problem — a supplier's bank details changing between two payment runs, buried in a file of two hundred otherwise-legitimate line items — sails straight through, because nobody looks at line 147 of a batch file the way they'd look at a single online transfer.
Why this isn't a criticism of the banks
It's worth being fair here: Confirmation of Payee wasn't designed to solve this problem, and the banks aren't hiding that. It's a consumer and general business payments control, built to reduce a specific, well-understood category of fraud — the "wrong account" transfer, not the "right supplier, changed details" business email compromise. Layering a real-time name-check onto every line of a corporate batch file at scale is a genuinely different engineering problem, and not one Confirmation of Payee was ever scoped to solve. The Scams Prevention Framework Act, which places direct legal duties on banks, telcos and digital platforms to prevent and disrupt scams, is squarely aimed at that broader consumer-and-platform picture too — as it should be.
But that leaves a gap sitting exactly where a lot of business fraud actually happens: the supplier onboarding form, the "please update our new bank details" email, and the payment batch that goes out without anyone re-verifying that the account on file still belongs to the business it's supposed to.
What actually closes the gap
Closing it doesn't require replacing your bank's controls — it requires a control that operates where the banks' controls don't: at the point a supplier's bank details are first declared, again when they change, and again at the payment file itself, before it's uploaded. That's a different question from "does this name match this account" — it's "can this supplier prove they currently control this account," verified independently of whatever the invoice or email says.
This is the specific, narrow gap PayGuard is built to close — not a replacement for your bank's fraud controls, but the check that runs on the file before it ever reaches them.