A positive pay file format is the layout a bank specifies for the issue file a business sends it: one row per check issued, carrying at least the account number, check number, amount and issue date, and for payee positive pay the payee name, with a code that marks a row as an issued or a voided check. There is no single public standard; each bank publishes its own specification, as fixed-width text, comma-separated values or another layout, and the business's accounting system produces the file to match. The format is the dull part. What matters is that the issue file is the business's own statement of what it wrote, so every positive pay decision afterwards rests on it: a row that is late, incomplete or wrong turns a genuine check into an exception, or lets an altered one through. Botminds' Positive Pay Exceptions reads every presented item against that row and shows the row beside the check, which is why it treats the file as evidence rather than as input.
Examples come from a fictional sample bank, Tessaly Community Bank, and its fictional clients. The rules and guidance are real and linked.
What is a positive pay file?
It is the list of checks a business has issued, sent to its bank so the bank can compare each presented check against it. The interagency check fraud booklet of 1999 described the usual case as a company that “transmits electronically to the financial institution a list of all checks it issued on a particular day” (Check Fraud: A Guide to Avoiding Losses). The FDIC's 2021 publication of the FFIEC authentication guidance describes positive pay in the same terms: electronic files from the business on every check it has issued, matched against the checks presented (FDIC FIL-55-2021).
The Federal Reserve's check fraud mitigation toolkit adds the detail a file designer needs: the list typically arrives daily and carries each check's number and amount, and often, though not always, its payee (FedPaymentsImprovement.org). That ‘often’ is the most important word in any positive pay file specification, because it decides whether the bank can compare the line thieves change most.
One client's issue file on the sample day
146
rows filed by one client, every one accepted
9:52AM
when the file arrived, against a 6:30 AM match
12
genuine checks raised as exceptions because the file was late
$38,740
the value of those twelve checks
What fields are in a positive pay file?
Six fields do the work, and each one powers a specific comparison. The row below is the sample client's issue row for check 10482, the check later presented altered; beside each field is what it lets the bank catch, and what goes wrong when it is missing or mistyped.
One issue row, annotated: what each field lets the bank catch, and what its absence costs
Account number
Row 1843041 •••• 7782
What it lets the bank catchTies the row to the account the check is drawn on
If missing or wrongThe row matches nothing; every check on the account becomes a no-issue exception
Check number
Row 18410482
What it lets the bank catchThe key the bank matches on, read from the encoded line
If missing or wrongA wrong number turns a genuine check into a no-issue exception and leaves a gap a counterfeit can use
Amount
Row 184$1,284.00
What it lets the bank catchCompared with the encoded amount on the presented check
If missing or wrongA keying error raises a genuine check as an amount mismatch; a missing amount cannot catch a raised one
Issue date
Row 184October 15, 2026
What it lets the bank catchLets the bank raise stale and post-dated checks
If missing or wrongNo stale or post-dated exceptions; a wrong date raises a genuine check
Payee name
Row 184Lakeshore Medical Supply
What it lets the bank catchCompared with the payee line read from the image (payee positive pay)
If missing or wrongA washed and rewritten payee matches the file and is paid
Issue or void
Row 184Issue
What it lets the bank catchTells the bank a check was cancelled before it was presented
If missing or wrongA voided check that turns up is paid like any other
The date field earns its place twice. Without it the bank cannot raise a check presented long after its date, the stale case, where the UCC frees a bank from any duty to pay an uncertified check once it is over six months old (UCC 4-404; the rule in full, and how a stale-date exception is decided, is in positive pay exception codes), and it cannot raise a check presented before the date the client gave it. With a mistyped date, the same field raises genuine checks: on the sample day an issue file dated a check November 14, 2026, 23 days after it was presented.
Does positive pay need the payee name?
Check positive pay does not; payee positive pay does, and the difference is large. A file without payees lets the bank compare only numbers, so a stolen check whose payee was washed and rewritten, with its number and amount untouched, matches the file and is paid. FinCEN's review of mail theft-related check fraud reports found the payee line was the section of a stolen check altered most often, ahead of the amount (FinCEN Financial Trend Analysis).
Sending payees has a cost in precision. The payee in the file has to be the name printed on the check, character for character, or every check to that vendor becomes a payee mismatch. The sample bank's rule lets a client register abbreviations and trade names it uses, so ‘LMS’ can match its supplier without loosening the rule for everyone. Check positive pay vs payee positive pay counts what the payee field catches and what it wrongly stops.
Fixed width or CSV: why every bank's layout differs
Because no regulator or network sets one. We found no public, rule-maker-issued standard for check positive pay issue files of the kind the Nacha Operating Rules set for ACH files, so each bank, or the system it runs, defines its own: field order, widths, date and amount formats, header and trailer rows, and the codes for issue and void. Accounting and enterprise resource planning systems carry export templates for many banks, which is why searches for a positive pay file format so often name a particular bank or system.
The details that make a file fail even when the fields are right
| Detail | What usually goes wrong | What it produces |
|---|---|---|
| Amount format | Decimal point included where the bank expects implied cents, or the reverse | Every amount off by a factor of 100: a whole file of mismatches |
| Date format | Month and day swapped, or two-digit years | Stale and post-dated exceptions on genuine checks |
| Leading zeros | Check or account numbers trimmed by a spreadsheet | No-issue exceptions: the numbers no longer match |
| Payee length | Long names cut at the bank's field width | Payee mismatches on genuine checks |
| Void code | Voids sent as negative amounts, or not sent at all | Voided checks paid when presented |
| File timing | Uploaded after the bank's match | Every check in the file raised as having no issue |
Check not on positive pay file: the late or missing row
A check that is not on the file is raised as a no-issue exception, and the client decides it before the cutoff; a common innocent cause is a file that arrived after the match. On the sample day Tarrowgate Industrial Supply filed 146 rows at 9:52 AM, three hours and 22 minutes after the 6:30 AM match. Every row was accepted, but twelve checks, numbers 7001 to 7012 and $38,740 in all, had already been presented against nothing.
Twelve exceptions, one cause: the issue file arrived after the match
The fix belongs in the client's process, not the bank's queue. A manual or replacement check written outside the accounting system is the other common cause, and it is the dangerous one: if the business routinely writes checks that never reach the file, its controller learns to approve no-issue exceptions without looking, and a counterfeit with a fresh number is approved the same way.
How to void a check in positive pay
Send a void row for it, before the replacement leaves the office, in the format the bank specifies; do not simply leave it out of the next file. A voided check that is presented later is one of the clearest signals a positive pay service gives: if the business cancelled it, someone else has it. Without the void row the bank sees an ordinary issued check, and pays it.
The timing matters. A void sent after the original check is presented arrives too late to stop it; a stop-payment order is the instrument for a check already in the mail that must not be paid, and it is a separate instruction with its own six-month life. A positive pay file is a list of what was issued, not a list of instructions.
A complete issue file against an incomplete one, field by field
A complete, timely file: Before the bank's match, every banking day checks are written
A late or incomplete file: After the match: every genuine check in it becomes an exception
A complete, timely file: Exactly as printed, with registered short names
A late or incomplete file: Missing: a washed payee matches and is paid
A complete, timely file: Present and correct
A late or incomplete file: Missing: no stale or post-dated exceptions; wrong: genuine checks raised
A complete, timely file: Sent before replacements leave the office
A late or incomplete file: Missing: a stolen voided check is paid
A complete, timely file: Added the day they are written
A late or incomplete file: Left out: the controller learns to approve no-issue exceptions blind
A complete, timely file: The check against the client's own row
A late or incomplete file: The check against memory
Securing the file: who can send it, and who can change it
Because the issue file decides what the bank pays, it is a target. A fraudulent row added to it makes a fraudulent check match, and no comparison downstream will object. The FFIEC's retail payment examination procedures ask examiners to check the controls over the electronic files commercial businesses send (FFIEC IT Handbook, Retail Payment Systems), and the FFIEC's 2021 authentication guidance expects extra controls on the client's own administrators, the users who can change digital banking settings (FDIC FIL-55-2021); who may upload an issue file is one of those settings, and the business banking administrator guide covers why that user is the one to watch.
Issue file controls for a business's accounts payable team
- Produce the file from the accounting system, never by hand
A hand-edited file is where a fraudulent row hides.
- Send it before the bank's match, every day checks are written
Agree the time with the bank and treat a late file as an incident.
- Include payees exactly as printed
And register short names and trade names with the bank once.
- Send voids before replacements leave
A voided check that turns up was stolen.
- Limit who can upload, and use dual control
One person prepares, another approves the upload.
- Reconcile the file with the check run
Count and total, every file, before it is sent.
- Read the bank's rejected-row messages the same day
A rejected row is a check that will come back as an exception.
The issue file as evidence, years later
Months or years after a check is paid or returned, the issue row is what shows whether the decision was right. A business has a year to report an alteration from the time its statement is made available (UCC 4-406(f)), and the bank that keeps paid items must keep them, or the capacity to furnish legible copies, for seven years (UCC 4-406(b)). Records required under the Bank Secrecy Act, including those behind a suspicious activity report, are kept for five years (31 CFR 1010.430(d)).
Every zone read against the issue row it rests on
That is why the solution never edits a client's issue file and keeps each row with the decision it supported: the file, the time it arrived, the row number and every field. When the client, the bank's auditor or an examiner asks why check 10482 was returned, the answer is on one screen: the row says $1,284.00 to Lakeshore Medical Supply, the image says $9,284.00 to Jordan K. Mills, and the two are drawn one over the other. Positive pay exception codes follows each kind of mismatch the row can expose to its decision.
Questions people ask
What does a positive pay file example look like?
One line per check: an account number, a check number, an amount, an issue date, and for payee positive pay a payee name, plus a code for issued or voided. In a comma-separated file a row might read account, 10482, 1284.00, 10152026, Lakeshore Medical Supply, I; the exact order, widths and formats are in the bank's own specification.
How often should a positive pay file be sent?
Every banking day on which checks are written, before the bank's match. A check presented before its row arrives is raised as an exception even though it is genuine, so a file sent after the match creates work for the client and the bank.
Can a positive pay file be corrected after it is sent?
Ask the bank whether it accepts a corrected or additional file, or edits in its portal; where it does, each correction should be controlled like the original upload. A correction does not change an exception already raised, which the client still decides before the cutoff.
Do ACH payments go in the positive pay file?
No. ACH positive pay runs on a separate list: the companies allowed to debit the account, by company ID, and usually a cap for each. The issue file covers checks only.
What happens if the positive pay file is rejected?
The bank has no issue data for that day's checks, so every one presented becomes a no-issue exception until a good file arrives. A bank should tell the client which rows were rejected and why, rather than dropping them silently; on the sample bank's screen a rejected row is always reported back.