TL;DR
Positive pay is a bank service that matches every check or ACH debit presented against a list of payments you authorized, holding anything that does not match so you can approve or reject it before money leaves the account. It is one of the most effective controls against check and ACH fraud. But it only works if the workflow behind it, submitting the issued-payments file, hitting the bank's daily deadline, and clearing exceptions in time, runs reliably. That workflow is where it usually fails.
Key Takeaways: Positive pay verifies outbound payments against an authorized list at the bank before they clear. Check positive pay covers checks; ACH positive pay covers electronic debits. It stops counterfeit and altered payments, but not vendor-impersonation fraud that tricks you into authorizing a bad payment in the first place. Its weak point is operational: the daily file, the submission cut-off, and time-boxed exception review. Miss the window and fraud clears or a real payment bounces.
What is positive pay?
Positive pay is a fraud-prevention service offered by banks that verifies outbound payments against a list of payments you have authorized, before those payments clear your account. You send the bank a file listing every payment you issued, and when an item is presented for payment, the bank checks it against your list. If it matches, it clears. If it does not, the bank holds it as an exception and asks you to approve or reject it before the money moves.
The name describes the logic: the bank only pays items that positively match your authorized list. Anything that does not match is held by default rather than paid. It is, in effect, a checkpoint on the way out of your account, catching payments you did not authorize before they become losses rather than after.
Positive pay matters because payment fraud remains stubbornly common. Check fraud in particular has proven durable even as check volumes decline, and it consistently ranks as one of the most common fraud methods businesses face. For any organization still issuing checks or originating ACH payments at volume, positive pay is one of the highest-leverage controls available, which is why it is widely considered a baseline treasury protection.
How positive pay works
The mechanics are consistent across banks and follow four steps.
Issue-file submission. Your treasury or AP team transmits a file to the bank listing every payment issued, with details like the check number, amount, date, and, for payee positive pay, the payee name. This is usually sent nightly or in batches through the day.
Presentment. A check or ACH debit is presented to the bank for payment, through clearing, a teller, or a deposit.
Match. The bank's system compares the presented item against your issued-payments file, checking the details align.
Exception or clear. A clean match clears normally. A mismatch is held as an exception, and the bank notifies you, giving you a window to approve or reject the item before final settlement.
That final step is the one that matters most, because a held exception is only protective if someone actually reviews and decides on it before the bank's cut-off.
Check positive pay vs ACH positive pay
Positive pay comes in variants that cover different payment rails, and it is worth knowing the difference.
Check positive pay is the original and most common form. It matches presented checks against your issued-check file to catch counterfeit, altered, or forged checks.
Payee positive pay is an add-on that also verifies the payee name, not just the check number and amount, catching cases where a legitimate check has had its payee altered.
ACH positive pay applies the same verification concept to electronic ACH debits, letting you control which originators can debit your account and flagging unauthorized electronic transactions. As fraud has shifted from checks toward ACH, ACH positive pay has become an increasingly necessary companion to the check version, and the strongest setups cover both rails under one workflow.
What positive pay does not do
Positive pay is powerful, but it protects against a specific category of fraud, and understanding its limits is essential to not over-relying on it.
Positive pay catches counterfeit and altered payments, items that do not match what you authorized. What it cannot catch is fraud that makes you authorize a bad payment in the first place. If a fraudster impersonates a vendor, convinces your AP team to change the vendor's banking details, and a legitimate-looking payment is then issued to the fraudulent account, positive pay sees a payment that matches your issued file and clears it. The control did its job; the fraud happened upstream, before the payment was ever authorized.
This is why positive pay is necessary but not sufficient. It defends the exit from your account, but the growing threat, business email compromise, vendor impersonation, and authorized-but-fraudulent payments, attacks the decision to pay, which happens earlier, inside your AP process. A complete defense pairs positive pay at the bank with strong controls upstream: verified vendor banking details, out-of-band confirmation of change requests, and dual approval.
The real weak point: the exception workflow
Here is the part the standard positive pay explanation understates. Positive pay's effectiveness does not rest on the matching itself, banks do that reliably. It rests on the operational workflow around it, and that workflow is where positive pay quietly fails.
Three operational realities determine whether positive pay actually protects you. The issued-payments file has to be accurate and complete; a payment missing from the file will be flagged as a false exception, and errors in the file create noise that buries real fraud. The file has to be submitted within the bank's daily window; miss the cut-off and legitimate payments can be rejected or, worse, the control operates on stale data. And exceptions have to be reviewed and decided before the bank's deadline; miss that window and the default action, which varies by setup, can mean a fraudulent item clears or a real payment is returned.
Each of these is a time-sensitive, detail-heavy task, and each is exactly the kind of work that slips when AP is busy. A missed submission window, an incomplete file, an exception that sat unreviewed past the cut-off, these are how a control that is technically in place still lets fraud through or disrupts legitimate payments. Positive pay is only as strong as the process feeding it, and that process is manual and deadline-bound at most companies.
Where automation fits
Because positive pay's weak point is the workflow rather than the matching, that is where automation delivers. The file generation, the submission timing, and above all the exception review are repetitive, time-boxed, and detail-sensitive, and they need to happen accurately every single day without fail.
Automation that can read payment data and reason about exceptions can keep the issued-payments file accurate and complete, ensure it is submitted within the bank's window, and, most importantly, work the exceptions, distinguishing a genuine mismatch that needs escalation from a benign discrepancy, so decisions happen before the deadline rather than after. That turns positive pay from a control that depends on someone remembering to work it into one that runs reliably.
But because this is a fraud control, the automation itself has to be trustworthy and transparent. An exception cleared incorrectly is a fraudulent payment approved, and an exception decision no one can explain is a control that will not stand up in an audit. Every action, why an item was submitted, why an exception was cleared or held, has to be explainable and produce a record. A system that resolves exceptions through logic no one can inspect does not strengthen the control; it adds a blind spot to it.
This is the frame Kognitos works on, with a clear boundary. Positive pay is a service your bank provides; Kognitos does not replace it. Kognitos is the reasoning-and-exception layer that operates the workflow around it, working alongside your ERP and AP systems to keep the issued-payments file accurate, meet the bank's submission windows, and review positive pay exceptions using deterministic, English-as-code logic so every decision is explainable and produces a complete audit trail. And because positive pay cannot see the upstream fraud that authorizes a bad payment in the first place, the same layer strengthens the controls before the payment, validating vendor banking changes and catching the invoice and vendor exceptions where authorized-but-fraudulent payments originate. The bank matches the payments; Kognitos makes sure the workflow that feeds the bank, and the controls before it, actually hold.
Getting started
If you already have positive pay, the question worth asking is not whether the control exists but whether the workflow behind it runs reliably every day: is the issued-payments file always accurate and on time, and are exceptions always reviewed before the bank's cut-off? Those operational gaps, not the matching, are where positive pay fails. And because it cannot catch fraud that happens before a payment is authorized, pair it with upstream controls on vendor banking changes and payment approvals.
For related fraud and payment controls, see our guides on vendor payment fraud and BEC controls, invoice fraud, and accounts payable automation. To see how deterministic AI runs the positive pay workflow and the controls around it with a full audit trail, book a demo or try the platform.
