How Positive-Pay Algorithms Detect Cheque Fraud: Issued-Item Files, Serial Numbers, Amount Matching, Payee Matching, Exceptions and Pay/Return Decisions

Quick answer: Positive Pay is a business cheque-control process in which a company tells its bank which cheques it legitimately issued. When a cheque is later presented for payment, the bank compares the presented item with the company’s issued-item record—commonly using account, cheque/serial number and amount, and in enhanced versions the payee name. Items that do not match are placed into an exception queue. The company or bank then reviews the exception and makes a governed pay or return decision before the applicable cut-off. The algorithm therefore converts cheque fraud detection into a data-matching and exception-management problem rather than relying only on visual inspection after money has left.

Positive Pay asks a simple but powerful question before a business cheque is honoured: “Did the company tell us it issued this exact item?”

Safety boundary: this article explains defensive cheque controls. It intentionally does not provide techniques for altering cheques, defeating payee recognition, predicting bank thresholds or bypassing exception controls.

Why this belongs in mathematics and algorithms

Positive Pay uses exact-key matching, string comparison, image/data extraction, exception classification, deadlines, default decisions and reconciliation. It is also a clear example of asymmetric automation: straightforward matches can pass automatically, while uncertainty is deliberately routed to a smaller human-review queue.

The OCC’s check-fraud guide describes Positive Pay as a process in which a company electronically transmits a list of issued cheques to its financial institution; the bank verifies presented cheques against the list and investigates items that do not match. See OCC — Check Fraud: A Guide to Avoiding Losses.

1. The issued-item file is the expected-state ledger

When a company issues a cheque, its treasury or accounting system creates an authorised record. A simplified record can contain:

• bank account;
• cheque number/serial number;
• issue date;
• amount;
• payee name where payee matching is used;
• void/stop state;
• optional internal invoice or payment reference.

The company sends those records to the bank. The bank now has an expected set:

I = {all authorised cheque records not yet legitimately cleared or voided}.

2. Presented cheques become observed records

When a cheque is presented, the bank observes fields such as:

• payor account;
• cheque/serial number;
• amount;
• presentment date;
• cheque image;
• payee text where available;
• routing and clearing metadata.

Positive Pay compares observed record P with the authorised issue file I.

Basic rule:

if key fields match an open issued record → normal processing; otherwise → exception.

3. Serial/check-number matching catches unissued items

Suppose the business issued cheques 100501 through 100520. A cheque numbered 100600 arrives for payment and there is no matching issue record.

The simplest Positive Pay engine flags:

presented serial ∉ authorised open serials.

That does not prove fraud. The company may have failed to upload a legitimate issue. It does prove that the bank’s presentment state and the company’s authorised-issue state disagree and require resolution.

4. Amount matching catches altered or mis-recorded items

Suppose cheque 100510 was reported as S$2,500 but is presented for S$25,000.

Rule:

presented amount ≠ issued amount → amount exception.

Current bank APIs expose this idea explicitly. J.P. Morgan’s 2026 check-fraud protection API returns Positive Pay exceptions containing cheque number, amount, payee and exception reasons such as altered amount, then accepts pay or return decisions. See J.P. Morgan — Check Fraud Protection API.

5. Payee Positive Pay adds name comparison

Basic Positive Pay can still miss a cheque whose serial and amount are unchanged but whose payee was altered. Payee Positive Pay adds the payee name from the issue file to the comparison.

Conceptually:

match = account + cheque number + amount + payee evidence.

Bank implementations may extract payee text from cheque images and compare it with the issue record. Names create OCR and formatting uncertainty, so payee matching often needs normalisation and exception review rather than blindly treating text as exact.

6. Payee matching is an entity-resolution problem

Consider these two strings:

• ABC INDUSTRIAL SUPPLIES PTE LTD
• ABC INDUSTRIAL SUPPLIES

They may be a legitimate match. By contrast:

• ABC INDUSTRIAL SUPPLIES PTE LTD
• ABG INDUSTRIAL SUPPLIES PTE LTD

could be OCR noise or a materially different payee. The engine can normalise common suffixes and punctuation, but uncertain cases should remain exceptions rather than be “corrected” automatically.

7. An exception queue concentrates human attention

Suppose a business issued 5,000 cheques and 4,970 match exactly. Positive Pay does not ask treasury staff to review all 5,000. It routes the 30 mismatches into an exception queue.

Useful exception fields include:

• exception type;
• account;
• check number;
• issued amount;
• presented amount;
• issued payee;
• observed payee;
• cheque image;
• decision deadline;
• default decision;
• analyst decision and reason.

Automation therefore reduces the search space without pretending exceptions can always be resolved mathematically.

8. Decision deadlines are part of the control

Cheque return rights operate inside time limits. A business cannot review an exception indefinitely.

Modern Positive Pay systems therefore attach an exception cut-off time. J.P. Morgan’s current API, for example, exposes the exception cut-off timestamp alongside the exception and decision status.

The decision engine needs:

time remaining = cut-off timestamp − current timestamp.

Exceptions approaching cut-off deserve higher operational priority than equally suspicious items with more time remaining.

9. Default decision is a policy state, not an afterthought

What happens if the customer does not respond before the decision deadline? Depending on the service agreement, an exception can default to Pay or Return.

The system must store that policy explicitly. Otherwise a missed deadline can become an unexplained financial decision.

A safe architecture records:

• configured default;
• deadline;
• whether user decision arrived in time;
• final bank action;
• reason/audit trail.

10. Reverse Positive Pay reverses who performs the comparison

In traditional Positive Pay, the company sends the issue file first and the bank compares presentments against it.

In Reverse Positive Pay, the bank sends presented-cheque information to the company, which compares the items with its own records and instructs the bank whether to pay or return exceptions.

The OCC describes this reversed workflow in its check-fraud guide. Federal Reserve Check Services also offers a Corporate Payor Report described as a Reverse Positive Pay option, giving corporate customers check detail and images early enough to identify potential fraud and meet return timeframes. See Federal Reserve Financial Services — FedPayments Reporter.

11. Images add evidence but not certainty

An exception reviewer can compare the cheque image with the accounting record:

• payee line;
• amount in words and numbers;
• cheque stock;
• signature;
• endorsement;
• visible alterations.

But an image should complement structured issue data rather than replace it. A convincing counterfeit can look visually plausible while failing the issue-file comparison.

12. Voids and stop payments must update the expected set

If a company voids cheque 100510 after uploading it, the Positive Pay state should change from:

issued/open → voided/not payable.

A presented item can then be flagged even though the serial and amount match the original issue file.

This is why issue-file management is a state machine rather than a static spreadsheet.

13. Stale cheques create another rule layer

The OCC Positive Pay example includes stale-dated cheques among items a bank may reject or investigate. A business can therefore include issue date and ageing rules in the exception logic.

But stale-date treatment depends on law, cheque type and bank agreement. The algorithm should not assume that every old cheque is automatically invalid.

14. Treasury Check Verification shows the same data-control principle

The US Treasury Check Verification System is not the same product as corporate Positive Pay, but it illustrates the same defensive concept: compare a presented cheque with authoritative issue data.

The Treasury system lets financial institutions verify Treasury cheque information using routing-transit information, cheque number and amount; its API can also provide payee information for eligible checks. Treasury explicitly warns that verification data assist fraud detection but do not by themselves prove a physical cheque is genuine or properly payable. See Treasury Check Verification System.

This is an excellent model-limit lesson: matching issue data is strong evidence, not magical proof.

15. Duplicate decisions need idempotency

Suppose a treasury system submits RETURN for an exception, times out before receiving confirmation and retries. Without idempotency, the second request can conflict with the already-processed decision.

Current J.P. Morgan Positive Pay APIs use idempotency keys for decision submission and return a conflict if an already-processed exception is re-decisioned after the idempotency window.

This connects to How Payment-Idempotency Algorithms Prevent Duplicate Money Movement.

16. Positive Pay cannot detect every cheque fraud

A control based on serial, amount and payee can miss fraud outside those data fields. It also depends on the company uploading correct issue records promptly.

Failure can arise from:

• late or missing issue-file upload;
• wrong amount in the company’s own record;
• OCR error on payee;
• incorrect customer approval;
• compromised treasury credentials;
• fraud involving a genuinely issued cheque and legitimate data;
• missed deadline causing an unfavourable default action.

Positive Pay is one control layer, not a substitute for account security, segregation of duties and reconciliation.

17. Creative-work lens: the theatre guest list

Imagine a theatre admits only guests whose name and ticket number appear on tonight’s authorised list. Most guests pass immediately. A person with a mismatched ticket is not automatically a criminal; the item is routed to the box office for resolution.

Positive Pay works similarly: matching reduces friction, while mismatch concentrates review. Real cheque controls add amount, image, deadline and legal-return rules.

18. The Positive Pay algorithmic pipeline

1. Create authorised issue records when cheques are issued.
2. Transmit issue file securely to the bank.
3. Validate file completeness and acknowledgement.
4. Receive presented cheque data/image.
5. Match account and cheque/serial number.
6. Compare amount.
7. Compare payee where Payee Positive Pay is enabled.
8. Check void, stop and ageing state.
9. Route mismatches to the exception queue.
10. Attach image, reason and decision deadline.
11. Capture pay/return decision or apply governed default at cut-off.
12. Submit decision idempotently and capture acknowledgement.
13. Reconcile final paid/returned cheque with company ledger.
14. Analyse exception patterns and false positives.

19. Failure modes

• Missing issue record. Legitimate cheque becomes an exception because upload failed.
• Amount-only control. Payee alteration passes because serial and amount remain unchanged.
• OCR overconfidence. Payee text extraction error becomes an automatic return.
• Deadline blindness. Exception is identified correctly but reviewed too late.
• Wrong default. Unreviewed exceptions take a policy action nobody intended.
• Duplicate decision. Retry causes conflicting or repeated instructions.
• Void-state lag. Cancelled cheque remains authorised in the bank file.
• Positive-Pay absolutism. A matched cheque is assumed genuine despite other fraud evidence.

20. Diagnostics and falsifiers

• What percentage of presented cheques match automatically?
• Which field generates the most exceptions?
• How many legitimate items are exceptions because of late issue files?
• Does payee matching reduce altered-payee losses without overwhelming reviewers?
• How many exceptions miss the decision cut-off?
• Are default decisions consistent with policy and client configuration?
• Can every pay/return instruction be traced to an authorised user or default rule?
• Can paid items be reconciled back to the company’s issued-cheque ledger?

Suppose someone claims, “The cheque matched Positive Pay, so it cannot be fraudulent.” A falsifier is a fraud that uses a legitimately issued serial, amount and payee but changes another aspect or compromises the company’s own issue process. Matching proves consistency with the fields checked, not universal authenticity.

21. Verification and update triggers

• test missing and duplicate issue records;
• test serial, amount and payee mismatches;
• measure OCR/name-match false positives;
• test exception cut-off escalation;
• verify default decisions by account;
• test idempotent decision retries;
• reconcile paid/returned outcomes daily;
• update controls after cheque-format, clearing or fraud-pattern changes.

Research anchors

• OCC — Check Fraud: A Guide to Avoiding Losses.
• J.P. Morgan — current Positive Pay/Reverse Positive Pay API overview.
• Federal Reserve Financial Services — Corporate Payor/Reverse Positive Pay reports.
• US Treasury — Treasury Check Verification System.

The deeper lesson

Positive Pay is the mathematics of comparing what should exist with what actually arrived for payment. The company creates the authorised set. The bank observes presentments. Exact fields eliminate most uncertainty; payee comparison adds another layer; exceptions concentrate human judgement; deadlines turn judgement into action. A strong control therefore does not ask only, “Does the cheque look real?” It asks, “Did the company issue this exact economic item, do the observed fields agree with the authorised record, and what evidence supports the decision before the return window closes?”

Educational note: This article explains defensive cheque-fraud controls and public banking concepts. It does not provide methods for defeating Positive Pay or altering payment instruments.