OpenClearWith standard positive pay, the customer sends the bank a list of checks it wrote, the bank compares, and the customer reviews only the mismatches. Reverse positive pay turns that around. Each day the bank sends the customer a file or report of every check presented against the account. The customer compares that list with its own records and tells the bank, before a cutoff, which checks to return. Checks the customer doesn't object to are paid.
Standard vs. reverse positive pay
| Standard positive pay | Reverse positive pay | |
|---|---|---|
| Who sends a file | Customer sends the bank an issue file | Bank sends the customer a presented-items file |
| Who matches | The bank's system | The customer, in its own system or by hand |
| What the customer reviews | Only the exceptions | Every presented check |
| Usual default | Pay or return, as the customer chose | Pay, unless the customer objects |
| Customer effort | Send a file after each check run; review exceptions | Reconcile the full list every day, inside the review window |
| Protection if nobody looks | The default decision still applies to mismatches | None; everything pays |
When reverse positive pay fits
Reverse positive pay suits customers who can't produce an issue file. Small businesses that write a handful of checks from a checkbook or a basic accounting package often fall into this group. It may also fit a customer whose own reconciliation system is stronger than what the bank offers. For the bank it's simpler to provide: there's no file layout to agree and no issue records to load.
Its weaknesses
- It depends on daily discipline. The customer has to reconcile every presented check every banking day, within a window of a few hours. Vacations, sick days and month-end crunches are when fraud gets through.
- The default is pay. If the customer doesn't respond, every item pays, including the fraudulent ones.
- Nobody checks the payee. Unless the customer looks at each image, a washed check whose number and amount match the checkbook is paid.
- Liability can shift. Many agreements put losses on a customer who received the report and didn't object. The customer may not realize how much responsibility it accepted.
A better option for small customers
The real obstacle for small customers is producing an issue file, not reviewing exceptions. If the bank's customer portal lets a business key in the few checks it writes, or upload a simple spreadsheet, then the business gets standard positive pay. The bank does the matching, mismatches come to the customer as exceptions, and a "return" default protects the customer on the days nobody looks.
OpenClear starts every customer on standard, exception-based positive pay for checks (with payee matching) and for ACH. Business customers can enter issued checks one at a time in the portal or upload them in almost any layout, including spreadsheets.
Reverse positive pay in OpenClear
For a customer that still can't send issued checks, the bank can put an account on reverse positive pay. Turning it on is a protected change that another bank administrator approves. Then:
- Every check presented on the account appears as an item marked to review. The customer returns the ones they don't recognize, and the rest are paid at the cut-off.
- A check with a real problem, such as a stop payment, a void or a duplicate, shows as that problem and follows the customer's default decision. It's never paid just because nobody looked.
- The customer can pay everything still to review in one step, and gets a reminder before the cut-off rather than an email per check.
- At a branch, a teller verifying a check on a reverse positive pay account is told the customer reviews each check, so it isn't cashed on the spot.
That closes the worst weakness of reverse positive pay, a silent default, while keeping it available for customers who need it.
Related: What is positive pay? · Positive pay file formats
Whether you're evaluating OpenClear or working through a positive pay project, get in touch.