Payee positive pay

Payee positive pay is check positive pay with one more comparison: the payee name on the presented check must match the payee name in the customer's issue file. If it doesn't, the check becomes an exception for the customer to review, even when the check number and amount are exactly right.

Why the payee matters

Check washing is the most common way a stolen business check gets cashed. The fraudster removes the ink in the payee line, writes in a new name, and deposits the check, often through mobile deposit at another bank. They frequently leave the amount alone, because changing it is harder to do cleanly and is the first thing anyone checks.

Standard positive pay compares the account, check number and amount. On a washed check all three still match the issue file, so the check pays. The only thing that changed is the one thing standard positive pay doesn't look at.

What payee positive pay needs

1. The payee in the issue file. The customer's issue file must include the payee name. Most accounting systems can export it; some layouts allow two payee lines.
2. The payee from the check image. The presented check's payee isn't carried in the MICR line or in image cash letter data, so it has to be read from the image with optical character recognition (OCR). Printed payees on business checks read well. Handwritten ones are much harder.
3. A comparison that tolerates real-world names. "ACME Industrial Supply, Inc." in the file and "Acme Industrial Supply Inc" on the check are the same payee. An exact text comparison would make every check an exception.

How the matching works

Good payee matching normalizes both names first: case, punctuation, extra spaces, and common suffixes. It then measures how similar the two are instead of requiring them to be identical. A token-based similarity score handles reordered words ("Smith John" against "John Smith") and extra words ("Pay to the order of ..." left in by OCR).

The bank sets a threshold. Below it, the check is an exception. Setting the threshold is a trade-off:

• Too strict and minor OCR errors or abbreviations flood customers with false exceptions. Reviewers learn to click "pay" on everything, which is worse than no payee check at all.
• Too loose and a fraudster's name that shares a word with the real payee ("John Smith" against "John Smithers") slips through.

Watch the exception rate and the share of payee exceptions that customers pay after review. A high pay rate means the threshold is catching noise, not fraud.

Limits to be honest about

• Handwritten checks. General-purpose OCR struggles with handwriting. A business that writes checks by hand gets less from payee matching unless the OCR engine is built for it.
• OCR confidence. When OCR can't read the payee, the system should say so rather than guess. "Payee unreadable" and "payee doesn't match" are different situations for a reviewer.
• Added payees. Adding "or Jane Doe" after the real payee can survive a loose match. Reviewers should see the image, not just the score.
• Timing. OCR adds processing time between presentment and the customer's review window. It must finish well before the cutoff.

Payee positive pay at the teller line

When a check is cashed over the counter at the bank it's drawn on, the teller can check it against the issue file before paying it, including the payee. That catches the fraud before any money leaves, instead of in the next day's exceptions. It needs the positive pay system to answer a lookup in real time, not just in a nightly batch.

OpenClear answers that lookup. The bank's teller platform sends the check's account and check number, the amount and the payee as written, and OpenClear runs the same rules it runs in clearing. It answers "match" or the first problem, including "payee differs". When the customer gave a payee for the check, the teller platform must send one, or the check is declined. After the cash is paid, the platform records the check as cashed, so the same check presented anywhere later is caught as a duplicate. See the teller verification guide.

How OpenClear handles payee matching

OpenClear's check rules include a payee rule. When OCR has read a payee from the check image, OpenClear normalizes both names and compares them with a token-set similarity score. If the score falls below the bank's threshold, the item is flagged "payee mismatch", alongside any other reasons that apply. If OCR produced no payee, the rule doesn't fire, so a missing read is never reported as a mismatch.

The OCR engine is pluggable. The default is local Tesseract, which works for printed checks and trials but not for high-volume handwritten checks; that limitation is documented, and the provider can be swapped. Check images can be loaded individually, in bulk as a ZIP with a manifest, or straight from an X9.37 image cash letter. See OCR in the architecture docs.