At check issuance time, generate a positive pay issue record for each check containing at minimum the check number, issue date, payee name, and dollar amount; accumulate these records in a file formatted to your bank's specification (common formats include fixed-length text, delimited CSV, or XML)
Transmit the issue file to the bank via the bank's preferred channel — most treasury management systems use SFTP delivery to a bank-designated path, but some banks (including U.S. Bank) expose a REST API for programmatic issue file upload; upload the file promptly after check issuance, ideally same day, so the bank has the register before checks are presented
Monitor for exception reports: when a presented check does not match the issue file (mismatched amount, unknown check number, or payee mismatch if payee positive pay is enabled), the bank creates an exception item and notifies you via file delivery or API webhook within the exception decision window
Retrieve exception items via the bank's positive pay exceptions API or download the exceptions report file; for each exception, retrieve the check image to visually verify the item and determine whether to pay or return it
Submit your pay or return decision for each exception before the bank's daily decision cutoff — decisions received after the cutoff default to the bank's configured default action (typically return or pay depending on your agreement), which may not match your intent
Reconcile the paid check register periodically by comparing presented and cleared check data from the bank's prior-day report against your issue file; flag any discrepancies between issued and cleared amounts for fraud investigation
Known gotchas
Positive pay protects against altered or counterfeit checks only for items in the issue file — checks that were legitimately issued but not uploaded to the bank (e.g., manual checks or checks issued by a subsidiary without system integration) will appear as exceptions, causing unnecessary return of valid payments
Payee name matching in payee positive pay systems uses fuzzy matching that varies by bank implementation — minor name variations such as abbreviations, punctuation differences, or middle-name inclusion can produce false exceptions for valid checks, requiring operational review of every exception rather than automatic pay decisions
The exception decision window is typically several hours and is aligned to the bank's processing schedule; building an automated decision workflow that relies on real-time API polling may miss exceptions if the polling interval is too long or if the bank delivers exceptions in batch at a specific time
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp