Positive pay exception processing and cutoff times

A positive pay exception is a presented check or ACH debit that didn't match what the customer said to expect. Exception processing is everything between the mismatch and the money: telling the customer, giving them what they need to decide, recording a pay-or-return decision, applying a default when nobody decides, and getting the returns out in time.

The life of an exception

1. Raised. The matching engine flags the item with one or more reasons. A single check can be both an amount mismatch and stale-dated.
2. Notified. The customer's reviewers are told there's something to decide, usually by email or in the portal. During a large file load, one summary beats a hundred separate alerts.
3. Reviewed. The reviewer sees the check image, the matching issue record (or the authorization rule, for ACH), and why the item was flagged.
4. Decided. Pay or return. A return needs a reason, and for ACH the reason determines the return code.
5. Defaulted. Any item still undecided at the cutoff gets the customer's default decision.
6. Executed. The bank sends the decisions to its core and its return processing: check returns and ACH return entries.

Exception reasons

Most systems check in a fixed order, and some reasons end the check early. A stopped check is returned whatever else is true, and a check with no issue record can't be compared on amount or payee.

Setting cutoff times

The customer's cutoff is worked out backwards from the bank's own deadlines:

• Checks: a paying bank must return a check, or send notice of dishonor, before its midnight deadline: midnight of the banking day after the day it received the item. Regulation CC adds expeditious-return requirements.
• ACH: unauthorized debits to business accounts are usually returned as R29, which has a short window: generally the return must reach the originating bank by the opening of business on the second banking day after settlement.
• The bank's own processing: returns have to be built, checked and sent through the core, image exchange and ACH operator, each with its own processing windows.

The customer cutoff is commonly set for late morning or early afternoon on the day after presentment, leaving the bank's operations team time to process returns. A few practical points:

• Time zones. Express the cutoff in the bank's time zone, and show it to customers in theirs.
• Holidays. The cutoff follows banking days, not calendar days. A Friday presentment with a Monday holiday has a Tuesday cutoff.
• Reminders. A reminder two hours before the cutoff and another thirty minutes before reduces defaulted items more than any other single change.
• Late decisions. Decide in advance, and write down, what happens when a customer calls five minutes after the cutoff.

Default decisions

Every customer needs a default for undecided exceptions, chosen and documented at onboarding:

• Return all. The safest default for fraud. The risk is returning a legitimate check, such as payroll when the issue file was late, which is visible and embarrassing.
• Pay all. Convenient, but a customer who defaults to pay and doesn't review has no effective protection. The bank should know which customers are in this position, and some banks document that the customer accepted the risk.
• Decide by risk score. Some systems can apply the default by a fraud-risk score, paying low-risk items and returning high-risk ones. That's only defensible with a validated model and a clear record of why each item went the way it did.

Dual control and segregation of duties

Paying a suspicious item is a money-movement decision, so treat it like one. Common controls:

• Maker-checker: one person recommends a decision and a different person approves it.
• Separation of duties: the person who uploads issue files shouldn't be the one who decides the exceptions they create.
• Bank overrides: when bank staff decide on a customer's behalf, for example on a phone instruction, record who, when and on whose authority.

Metrics worth watching

• Exception rate per customer: a sudden jump usually means a file problem, not a fraud wave.
• Defaulted items: the share of exceptions nobody decided before the cutoff.
• Pay rate on exceptions: if customers pay nearly everything, rules are too tight or reviewers aren't looking.
• Days since last issue file, per active customer.
• Returns made late: should be zero, and investigated when they aren't.

How OpenClear processes exceptions

In OpenClear, every exception gets a decision deadline and notifications to the people who can decide it, with reminders before the cutoff (120 and 30 minutes by default). Each bank can require dual control: one user recommends and a different user approves, and the system enforces that they're different people. Each check's deadline is worked out from the day it was presented, in the bank's own banking days, so it never falls after the check's midnight deadline, and a decision sent late anyway is flagged. Decisions can be changed until the cut-off. Then they lock and are sent to the bank within a minute. If nobody decides by the deadline, the customer's default decision (pay or return) is applied, and an item is left alone when that can't be done safely, for example an ACH return with no default return reason.

A bank can turn on an advisory fraud-risk score. It comes from a logistic regression model trained only on decisions that bank's own people made (its first model only after 200 of them, and never on defaults applied at the deadline), chosen because a coefficient can answer "why was this flagged?". The score is shown beside the item and never decides it, and no default decision follows it. Every recommendation and decision is written to a hash-chained, signed action log. An ACH exception can be turned into an authorization rule from its detail page, so the same debit clears next time. See from exception to decision in the docs.