Pre-Settlement Verification: The New AP Fraud Playbook

Most AP fraud programs are built on a quiet assumption that no longer holds: that there is time between when money leaves and when money is gone. There used to be. ACH gave you a day or two of working float where a sharp analyst could call the bank, freeze the credit, and recover the funds. Wire recalls were ugly but possible. Even a fraudulent check could be stopped between mailing and clearing.

That window has collapsed. Same-day ACH, instant payment rails, virtual card authorizations that settle in seconds. The recovery window on the fastest rails is approaching zero, and 79% of organizations experienced attempted or actual payments fraud in 2024 (Source: AFP 2025 Payments Fraud and Control Survey, https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/payments-fraud). The math has changed, but most fraud programs haven't.

Here is the uncomfortable conclusion. If your fraud controls activate after settlement, you don't have a fraud program. You have a recovery program. And on modern rails, recovery rates are trending toward zero.

The Frame: Every Payment Is an Authentication Event

The teams winning at fraud prevention right now have stopped trying to catch fraud. They've moved the entire control surface upstream of the payment run.

Think of it this way. When a consumer logs into their bank from a new device, the bank doesn't wait until money moves to flag the anomaly. It interrupts the session and asks for step-up authentication. That is the model AP needs to adopt. Every payment instruction is a session. Every new bank account, every change of remit-to, every first-time invoice from a vendor, every payment outside the normal envelope is an event that should trigger interruption, not monitoring.

This is not a theoretical reframe. Among firms that catch fraud before settlement, 86% use step-up authentication for high-risk transactions (Source: PYMNTS Intelligence/Plaid Data Book: How Bank-Linked Verification Cuts AR Payment Risk, https://www.pymnts.com/study/data-book-how-bank-linked-verification-cuts-ar-payment-risk/). The teams that have closed the loop on AP fraud did it by treating verification as the control, and the payment run as the consequence of that control passing.

The shift sounds subtle. Operationally it changes everything.

Why Detect-and-Recover Was Always a Story About Float

Detect-and-recover only worked because of float. Float was the unintentional fraud control buried inside slow payment rails. You could afford to monitor for anomalies after a payment because the payment hadn't really gone anywhere yet.

Faster rails removed the float. They didn't remove the fraud. So now every dollar of speed improvement on the rail side has to be matched by a dollar of control moved upstream, or the net result is a leak.

Two regulatory signals confirm this is now industry consensus. Phase Two of Nacha's Risk Management Topics rules took effect June 19, 2026 (Source: Nacha, https://www.nacha.org/rules/risk-management-topics), and under those rules, receiving institutions must establish risk-based processes to identify ACH credit entries suspected of being unauthorized or authorized under false pretenses (Source: Nacha, https://www.nacha.org/rules/risk-management-topics). Read that carefully. The obligation is not to catch fraud after the fact. It is to identify suspected fraud at the point of entry. The regulator is telling the entire rail to push controls upstream.

The teams still building detection dashboards on top of cleared payments are solving last decade's problem.

What Upstream Actually Means: The Four Gates

Pre-settlement verification is not one control. It is a sequence of four gates, each one designed to interrupt the payment before it becomes a payment.

Gate one: vendor identity at onboarding. Before a row exists in the vendor master, the entity behind it has to be verified against an independent source. Bank account ownership confirmation, business registration check, beneficial owner match. Not a self-attested W-9 and a callback to the number the vendor provided. That's not verification, that's theater.

Gate two: change-of-instruction as a re-authentication event. Any modification to bank account, remit-to, or payment method should drop the vendor back into a verification state, not just trigger a notification email. The classic business email compromise attack lives in this gate. It works because most AP shops treat a bank change as a data update instead of a security event.

Gate three: payment-level pattern matching at authorization. Before the payment file is released, every line gets scored against expected behavior. New payee, unusual amount, off-cycle timing, mismatch between PO and remit. The score doesn't generate an alert for later review. It generates an interrupt that blocks release until cleared.

Gate four: rail selection as a control. Not every payment should move on the same rail. High-risk, first-time, or anomalous payments should automatically route to rails with built-in verification surfaces, not to the fastest rail. This is where virtual card payments become a fraud control rather than just a cost optimization. A virtual card with single-use credentials, a transaction limit, and a defined merchant category code is functionally an authenticated payment instrument. The fraud envelope is bounded before the money moves.

Most AP teams have something at gate one. A few have something at gate three. Almost nobody has all four wired together as a single verification fabric.

The Stablecoin and Cross-Border Wildcards

Two adjacent trends are about to make this even less optional.

B2B stablecoin payments grew 733% last year to $226B in volume, the largest single use-case category ahead of remittances, retail, and consumer P2P (Source: Ramp, https://ramp.com/blog/stablecoin-payments-data). Settlement on stablecoin rails is final the moment the transaction is signed. There is no recall. There is no float. There is no recovery window to debate. If your AP team starts touching these rails without upstream verification in place, every payment is a one-shot bet.

The cross-border picture is similar. Effective November 14, 2026, financial institutions and corporates sending cross-border payments with addresses over Swift CBPR+ or key Payment Market Infrastructures must use hybrid or fully structured addresses (Source: Swift, https://www.swift.com/your-needs/banking/cross-border-payments-strategy/iso-20022-migration). Approximately 65% of Swift payment messages still contain unstructured addresses (Source: Swift, https://www.swift.com/your-needs/banking/cross-border-payments-strategy/iso-20022-migration), which means most corporates are about to discover their cross-border payments are getting rejected, delayed, or worse, allowed through with data quality that makes fraud screening impossible.

The pattern is the same in both cases. The rails are getting faster and more final. The data requirements are getting stricter. The room for downstream cleanup is disappearing.

Building the Verification Fabric

A pre-settlement verification program is not a tool purchase. It is a wiring exercise across systems that historically didn't talk to each other.

The minimum architecture has four pieces. A vendor master with verified, sourced identity attributes, not self-attested ones. A change-control workflow that treats edits as authentication events, with independent callback verification on bank changes. A payment-authorization layer that scores every line item against behavioral baselines before the file releases. And a rail selection engine that routes risk to instruments with built-in containment.

This is the architecture Finexio operates as AP payments as a service. Verified supplier identity at onboarding, change controls with out-of-band validation, payment-level scoring before release, and intelligent routing across rails including virtual card on the J.P. Morgan Chase issuing platform with Mastercard and Visa network coverage. Backed by Finexio Shield and its $2M fraud guarantee, because if we're wrong about a verification call, we hold the loss, not you.

The point isn't the product. The point is that this architecture exists because the old architecture, the one where AP runs payments and a separate fraud team reviews them after the fact, can no longer keep up with the rails.

What to Stop Doing

If you are running an AP fraud program today, three line items should come off the budget by next quarter.

Stop investing in post-settlement anomaly dashboards. They are useful for forensics, not for prevention. Reallocate to onboarding verification and change-of-instruction controls.

Stop treating bank account changes as data updates. They are the single highest-use attack vector in AP. Every change should require independent verification through a channel the requestor did not provide.

Stop measuring fraud program success by recovery rate. Recovery is the wrong metric on modern rails. The right metric is the percentage of suspicious payments interrupted before release, and the false positive rate on those interrupts. If you can't report those two numbers, you're flying blind.

FAQ

Q: Doesn't pre-settlement verification slow down payment runs?

Not if it's wired correctly. The verification work happens at vendor onboarding and at change-of-instruction events, which are off the payment run critical path. The payment-run scoring is automated and runs in seconds. The only payments that get slowed are the ones that should be slowed, which is the entire point.

Q: How is this different from positive pay or ACH filters?

Positive pay and ACH filters are bank-side controls that compare a payment to a list you provided. They catch errors in the payment file. They do not catch payments where the underlying vendor record was compromised before the file was built. Pre-settlement verification operates one layer up, on the integrity of the instruction itself.

Q: We already do vendor verification at onboarding. Isn't that enough?

Onboarding verification decays. A vendor verified two years ago whose bank account was changed last month through a compromised email is not a verified vendor anymore. The control has to operate continuously, with every change of instruction treated as a re-authentication event. One-time verification is a snapshot. Pre-settlement verification is a posture.

Move the Controls Upstream

The AP fraud conversation has been stuck on detection for a decade because the rails allowed it to be. They don't anymore. Faster, more final settlement has quietly turned every detect-and-recover program into a detect-and-absorb-the-loss program.

The teams getting this right have already moved. They've rebuilt their controls around the moment of authorization, not the moment of clearing. They treat every payment as a session that needs to authenticate. They route risk to rails with built-in containment. And they measure prevention, not recovery.

If you want to see what that architecture looks like wired together, with supplier verification, payment operations, and rail orchestration in a single fabric, Book a Consultation. We'll walk through your current verification gates and show you where the float you used to rely on has already disappeared.

Sources

- AFP 2025 Payments Fraud and Control Survey: https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/payments-fraud - PYMNTS Intelligence/Plaid Data Book: How Bank-Linked Verification Cuts AR Payment Risk: https://www.pymnts.com/study/data-book-how-bank-linked-verification-cuts-ar-payment-risk/ - Ramp, B2B Stablecoin Payments Analysis: https://ramp.com/blog/stablecoin-payments-data - Nacha, Risk Management Topics Rules: https://www.nacha.org/rules/risk-management-topics - Swift, ISO 20022 Migration and Structured Address Requirements: https://www.swift.com/your-needs/banking/cross-border-payments-strategy/iso-20022-migration