What is positive pay? A guide from the bank's side

Positive pay is a fraud-prevention service in which a business customer tells its bank which checks it has written and which ACH debits it expects. The bank compares every item presented against that list. Items that match are paid. Items that don't match become exceptions, and the customer decides whether each one is paid or returned before a cutoff time. Anything the customer doesn't decide gets a pre-agreed default decision.

That's the whole idea. The detail is in the files, the timing and the people involved.

Why banks offer positive pay

Check fraud never went away. Mail theft, check washing (chemically removing the payee or amount and writing in new ones) and counterfeits printed from a stolen check's account and routing numbers are all common. A business that writes checks is exposed every time one goes in the mail.

Losses on forged and altered checks generally land on the paying bank under the Uniform Commercial Code, unless the customer's own negligence contributed. Positive pay changes the conversation. The customer supplies the data and makes the pay-or-return call on anything suspicious. Many treasury management agreements say a customer who declines positive pay accepts responsibility for losses it would have caught. For the bank it is both a fee-earning product and a loss-mitigation control.

How it works, day to day

1. The customer issues items. When the customer writes checks, its accounting or ERP system sends an issue file: account number, check number, amount, issue date, and often the payee name. Voided checks are reported too. For ACH, the customer sets up authorization rules saying which originators may debit which accounts, and within what limits.
2. Items are presented. Checks arrive in the bank's inclearings, most often as image cash letters from the Federal Reserve, correspondents or other banks, plus on-us items cashed or deposited at the bank itself. ACH debits arrive in the bank's ACH files.
3. Items are matched. A matching engine compares each presented check against the issue records: is there a check with this number on this account, is the amount the same, has it been voided or stopped, is it stale-dated, and (with payee positive pay) does the payee match? ACH debits are checked against the authorization rules.
4. Exceptions go to the customer. Anything that fails is shown to the customer, usually through an online banking or treasury portal, with the check image and the reason it was flagged.
5. The customer decides by the cutoff. Pay or return. The bank sets the cutoff early enough to still meet its own return deadlines. See exception processing and cutoff times.
6. Defaults and returns. Undecided items get the customer's default decision. The bank then returns the items marked for return through its normal check-return or ACH-return processing.

The kinds of positive pay

What the bank actually has to run

From the customer's side, positive pay is a file upload and a daily review screen. From the bank's side it's an operation with a lot of moving parts:

• Onboarding. Setting up the customer, its accounts and its users, and getting a test issue file in the right layout. Every customer's accounting system produces something slightly different.
• File handling. Receiving issue files by upload, SFTP or API; rejecting bad files cleanly; and spotting customers who have stopped sending files at all.
• The daily schedule. Loading presented items, running the match, notifying customers, enforcing the cutoff, applying defaults, and producing return files in time.
• Access and controls. Who at the customer can decide items, whether a second person must approve, and who at the bank can override. Examiners will ask about all of it. See what examiners look for.
• Teller and branch support. Checking a check presented for cash over the counter against the issue file before paying it.
• Billing and reporting. Monthly fees per account and per item, plus reporting on exceptions, decisions and timeliness.

Where positive pay programs break down

The technology rarely fails outright. The common problems are operational:

• Missing issue files. A customer changes accounting systems or loses the person who sent the file, and every check becomes a "not in file" exception. The customer then pays them all without looking.
• Defaults set to pay. A customer with a pay default who doesn't review exceptions has, in practice, no positive pay.
• No payee matching. A washed check keeps its original number and amount. Without payee matching, standard positive pay passes it.
• Over-broad ACH rules. Authorizing an originator with no amount limit, or blocking nothing, leaves the filter in place on paper only.
• Alert fatigue. Too many false exceptions train reviewers to approve everything.

A good platform helps with each of these: reporting on customers who haven't sent a file recently, flagging pay defaults, reading payees from images, and giving reviewers enough context to decide quickly.

How OpenClear approaches it

OpenClear is an open-source positive pay platform built for the bank's side of this work. It handles check, payee, reverse and ACH positive pay in one exception queue, lets tellers verify a check before cashing it, runs many banks and their business customers in a single installation, and keeps a signed, tamper-evident record of every decision. Its matching rules, file layouts and compliance mapping are all published, so you can read exactly what it does. You can try it in a sandbox bank in about a minute.