Positive pay software is the system a bank uses to receive its business clients' issue files and ACH authorization lists, match every presented check and debit against them, show each exception to the client and the bank's analysts, and turn their decisions into pay or return instructions before the paying bank's midnight deadline. Every such system matches. What separates them is what happens after the match: what the person deciding is shown, whether the image is read for washing, whether the deadline is protected, and what evidence is left behind. Those are measurable, and the fairest measurement is a replay of the bank's own closed month, whose outcomes are already known. Botminds' Positive Pay Exceptions is agent software for the decision layer, and this guide shows how to test it, or anything else, before a client sees it.
Screens come from a fictional sample bank, Tessaly Community Bank; its clients and staff are fictional. Rules and guidance are real and linked.
What a month of exceptions looks like at the sample bank
95
exceptions on one sample day, from 28,460 presented items
1,180
business clients with positive pay
16.5min
estimated per exception by hand, against 2.2 with the agents
98%
design target for exceptions decided by a named person before the cutoff
What positive pay software has to do, from issue file to return
Seven jobs, and a pilot should test all seven, because a weakness in any one shows up as a paid fraud, a missed deadline or a client who stops trusting the service. The examiners look at the edges too: the FFIEC's retail payment examination procedures ask whether an institution uses positive pay and “Whether the logical access controls over the electronic files sent by commercial businesses are adequately controlled” (FFIEC IT Handbook, Retail Payment Systems).
Seven jobs of positive pay software, and how a pilot tests each
| Job | What good looks like | How the pilot tests it |
|---|---|---|
| Take in issue files and ACH authorizations | Every row accepted or rejected with a reason the client sees; nothing silently dropped; files from controlled senders only | Feed the month's real files, including the late and malformed ones |
| Match presented items | Field by field, with the tolerance and payee rule the agreement states | Compare its exceptions with the month's actual exceptions, item by item |
| Explain each exception | Both images, the issue row, the fields that moved in a sentence, the client's history | Score the sentence against the known answer |
| Read the image for alteration | Signs with the evidence and a confidence; a person below the threshold | Count signs on known alterations and on genuine checks |
| Put the decision with the right person | The client inside its window; the bank only where the agreement says; maker-checker on bank actions | Replay the month's decisions and check who could have made each |
| Protect the deadlines | The client cutoff, the midnight deadline and the Regulation CC return test on one clock | Replay timestamps; count returns that would have been late |
| Keep the evidence | Who decided what, when, why and on what, exportable for an examiner | Ask for one decision's full trail from the replay, unaided |
Why a demonstration on the vendor's checks proves little
A demonstration item was chosen to be found. Its payee was changed in a way the tool reads well, its image is clean, and its client's history is short and tidy. A real month is none of those things: images vary in quality, payees are handwritten, issue files arrive late, and many exceptions are not fraud at all. A tool that finds every planted alteration but also raises signs on a fifth of genuine checks teaches analysts to ignore its signs.
The bank's closed month fixes all of that at once. The outcomes are known: which exceptions were paid, which returned, which defaulted, and which paid items came back later as claims. And the month's exceptions carry the bank's own mix of clients, check stock and image quality. Check positive pay vs payee positive pay shows the smaller version of the same idea: a seeded test of ten checks whose truth is known.
Can you test positive pay software on past exceptions?
Yes, and it is the most informative test available, because the bank already knows the right answer for almost every item. Pull a closed month: the presented items with both images, every client's issue files and authorization lists as they stood that day, every exception with its decision, decider, time and reason, and every claim or recredit on those items since. Hide the outcomes from the tool and from whoever operates it, run the month through, and score the result against the key.
What to pull from the closed month before the replay
- Every presented item, with front and back images
Including the ones that matched: the tool must not raise exceptions where there were none.
- Each client's issue files and ACH authorizations as filed, with arrival times
A late file in the real month must be late in the replay.
- Every exception with its decision, decider, time and reason
The key the replay is scored against.
- Every claim, recredit or alteration report on those items since
These are the misses: items paid that should not have been.
- The agreement terms in force: cutoff, default, tolerance, payee rule
Replay under production settings, not looser ones.
- The bank's return and referral logs for the month
To test the deadline and the evidence measures.
The pilot scorecard: six numbers that decide it
Six measures cover what matters, and each has a pass line the bank should set before the replay, not after. Writing the line down first is what makes the pilot a test rather than a demonstration with numbers attached.
The pilot scorecard: six measures, how to compute each, and why it matters
1
Minutes to a decision-ready exception
How: From the match to the moment the decider has both images, the issue row, the fields that moved and the history
Why: The client's window is fixed; every minute spent finding things is a minute not spent deciding
2
Moved fields named correctly
How: Share of the month's exceptions where the stated difference matches the known answer
Why: A wrong sentence is worse than no sentence: the client trusts it
3
Known alterations raised with a sign
How: Of the month's returned alterations and later recredits, how many carried a washing or red-flag sign
Why: This is what a field match cannot do, and the reason to buy anything new
4
Genuine checks given a sign
How: Share of paid, never-disputed checks on which the tool raised a sign
Why: Signs on good checks train people to ignore signs
5
Returns inside both deadlines
How: Replayed timestamps against the midnight deadline and Regulation CC's 2 p.m. second-business-day test
Why: A late return is a paid item, whatever the decision
6
Decisions with complete evidence
How: Share with both images, the issue row, reason code, decider, checker and the clause applied
Why: The examiner's question is why, not whether
Measures three and four have to be read together. A tool can raise a sign on every check and score perfectly on known alterations; it is the share of genuine checks given a sign that shows whether the signs mean anything. The sample bank's rule that two or more signs open a fraud referral makes the second number expensive if it is high: every false sign pair is an investigator's afternoon.
The exceptions that matter most: paid, then recredited
The most valuable items in the replay are the ones the bank got wrong. An exception paid in the closed month and reported later as an alteration is the case the software is being bought for, and a month that has none should be widened until it has some. FinCEN's analysis of mail theft-related check fraud found altered checks were the largest share of reports, about 44% (FinCEN Financial Trend Analysis), so these are the items the replay most needs.
They arrive late by design. A business has to examine its statement with reasonable promptness, and may report an alteration any time within a year of the statement before the claim is barred (UCC 4-406(c) and (f)). That is why the replay month should be at least four weeks old: the first statement cycle's reports will have come in. Score these items on one question. Would the decider, shown what the tool showed, have had a reason to return it?
A four-week pilot, before any client sees it
Four weeks is enough to replay one month and shadow another, without a client seeing anything new. The shadow week matters as much as the replay: analysts decide as they do today, and the tool runs beside them, so the bank learns what the tool would have changed on live items without risking a single decision.
Four weeks from a closed month to a decision, with no client exposed
- Pull the month, set pass linesweek 1
- Blind replay and scoringweek 2
- Shadow on live itemsweek 3
- Review with ops, fraud, auditweek 4
Who attends week 4 matters. Treasury operations will judge the minutes and the sentences. The fraud unit will judge the signs and the referrals. Internal audit should be asked one question: given one decision from the replay and nothing else, can it reconstruct who decided, on what evidence, under which clause, and who checked?
Positive pay API and files: what the software must sit beside
Positive pay software does not replace item processing, the image archive or the digital banking platform; it reads from them and writes back decisions. A pilot should prove each connection with the bank's real systems in the shadow week, because an integration that fails at 6:41 AM on a live morning costs the clients minutes of their window.
The client side matters as much. Businesses send issue files from their accounting systems, by upload, by file transfer, or by API where the bank offers one, and an API that accepts a check the moment it is written removes the late-file problem altogether. The files are also a target: a fraudulent row added to an issue file makes a fraudulent check match, which is why the FFIEC asks about controls over them and why the client's administrator rights and dual control over the file are worth testing. The positive pay file format guide covers the fields and their controls.
One written rule book, versioned, with the regulation behind every clause
Model risk: what the 2026 guidance covers, and what it leaves to you
Less than many banks expect. The revised interagency model risk guidance of April 2026, which replaced SR 11-7, states that generative and agentic AI models are outside its scope, and the agencies said they plan a request for information on banks' use of AI, including agentic AI (OCC Bulletin 2026-13; Federal Reserve SR 26-2). The guidance also says it is expected to be most relevant to banking organizations with more than $30 billion in assets.
That leaves a bank to show, on its own evidence, that the tool does what it claims and that people stay in charge of what moves money. The replay is that evidence. It measures the tool against known outcomes on the bank's own items, records the version that produced each result, and shows which decisions only a person could take. A pilot report that says what was measured, against which pass lines, by whom, is the document a model risk team, an examiner and an internal auditor will each ask for.
Where Positive Pay Exceptions fits, and where it does not
The solution is the decision layer: it matches, reads, explains, reminds and prepares, and named people decide, check and send. Six agents do the reading and preparing, and three rules are locked: no agent decides pay or return, no agent dispatches an instruction, and no agent files a report. It works with item processing and the image archive, the issue files and ACH authorizations, the payments hub, the digital banking platform where clients decide, the core banking system and fraud case management.
Who did what, when, why, and what they were looking at
It is not item processing, and it does not decide what the bank charges or which clients get the service. It cannot stop a stolen check deposited unaltered in an account opened in the payee's name, because nothing on that check differs from the file. And it is only as good as the issue files it is given: a client that files late or without payees gets a weaker service, which the replay will show. Read the pilot report with those limits in mind; positive pay service: twelve questions before you choose a provider turns them into questions for any provider.
The desk the pilot is trying to change
Questions people ask
What is positive pay exception management?
The work after the match: showing each exception to the person who decides it, getting a decision with a reason before the cutoff, applying the agreement's default where nobody decides, and sending returns before the midnight deadline. It is where most of the time and most of the risk sit, because the match itself is mechanical.
Is there positive pay software for businesses rather than banks?
Businesses mostly use their bank's positive pay through its digital banking platform, sending issue files from their accounting system and deciding exceptions in the bank's portal. Some treasury and accounting software can generate the issue file in the bank's layout. The matching and the decision deadline stay with the bank.
What is a positive pay platform?
Usually the bank-side system that runs the whole service: file intake, matching, the client decision screens, defaults and the return file. A platform can be bought whole, or a bank can keep its existing matching and add a decision layer on top, which is where Positive Pay Exceptions sits.
How long should a positive pay software pilot take?
About four weeks is enough for one replayed month and one shadow week, if the data can be pulled in the first week. The replay month should be at least four weeks past its end so that the first statement cycle's alteration reports are in the key.
What will an examiner ask about positive pay software?
Whether the bank uses positive pay and how the files clients send are controlled, according to the FFIEC's retail payment procedures; and, for any decision, who made it and why. Records required under the Bank Secrecy Act are kept for five years (31 CFR 1010.430(d)), so the evidence behind a referral needs to outlive the software contract.