Why Exception Handling in Payments Is Where the Fraud Losses Actually Sit

The queue is not slow. It is unsupervised.

Your payment operations team has a queue of items that did not go straight through. A wire over the sender's limit. An ACH file with a mismatched name. A payment that tripped a screening rule and needs someone to look at it before cutoff. The vendors pitching you this quarter all describe that queue the same way: as a productivity problem, measured in straight-through processing rates, solved by a platform that shrinks it.

That framing is accurate about cost and wrong about risk. Every control your bank has built lives in the automated path. Limits, screening, dual authorization, velocity rules: they are all encoded where the payment flows without anyone touching it. The exception path is where a person receives the transactions that failed those controls and decides, usually under a deadline, whether to let them through anyway.

Read that population description again. It is a list of payments that your own controls flagged, handed to a human with the authority to override the flag. That is exactly the population a fraudster is trying to create.

So the question worth asking about your exception queue is not how to make it smaller. It is whether the same controls apply on both sides of it. At the institutions we look at, they usually do not.

How big the unsupervised population is

This is not a rounding error at the edge of the operation. Backbase, which sells banking automation and so has every reason to make the number sound fixable, writes that most banks hit a ceiling around 60 percent straight-through processing. The rest falls into what it calls the operational whitespace, the space between systems where handoffs, exceptions and coordination live.

Take that at face value and roughly four in ten payments at a typical bank pass through a human hand somewhere. The vendor reads that as an efficiency opportunity. We read it as the share of your payment volume where your controls depend on a person choosing to apply them.

The threat pressure on that population is also not theoretical. The Association for Financial Professionals' 2026 Payments Fraud and Control Survey found that 76 percent of US organizations experienced attempted or actual payments fraud in 2025, and 74 percent were hit by business email compromise. The FBI's Internet Crime Complaint Center recorded 3,046,598,558 dollars in business email compromise losses across 24,768 complaints in 2025. Business email compromise is, almost by definition, an attack on the exception path. It does not try to beat your screening engine. It manufactures a reason for someone to make an exception to it.

Urgency is the attack, and the exception path is built for urgency

The mechanism is stated plainly by practitioners who work on disbursement controls: fraudsters exploit urgency, confusion and process gaps to bypass controls, and employees are more likely to override controls when a transaction appears urgent or unusual. The examples are the familiar ones. The urgent wire. The executive payment request. The vendor whose bank details changed this morning.

Now look at how an exception queue is designed. It exists to clear items before a cutoff. Its staff are measured on throughput and aging. The items in it are, by construction, unusual. And the escalation route for a stuck item usually runs upward, toward someone senior enough to approve it.

Every one of those design choices is reasonable on its own. Together they produce a workflow that rewards speed, normalizes the unusual, and routes the hardest decisions to whoever carries the most authority. A fraudster could not have specified a better environment.

The case that proves the point

The clearest public example is not a sophisticated external attack. It is Heartland Tri-State Bank, a roughly 139 million dollar agricultural lender in Elkhart, Kansas, which failed in July 2023.

The Federal Reserve's Office of Inspector General published its material loss review in February 2024. The CEO initiated ten wire transfers totalling about 47.1 million dollars of the bank's funds to a cryptocurrency platform, in what the report describes as an apparent pig butchering scheme. The Deposit Insurance Fund absorbed the loss.

What matters for this article is how the wires got out. Heartland had daily wire limits of 5 million dollars per sender, built into the wire system. In June 2023 the board tightened the limit to 3 million dollars and put a dual control requirement in place. The wires kept going. Three of the seven processed before the new policy exceeded the old limit. All three processed after it exceeded the new one, by as much as 5 million dollars. The chief financial officer and other employees approved them anyway.

Examiners had rated the bank's internal control policies adequate for its size in every review from 2017 through 2022. The controls existed. They were in the system. The OIG's finding is that employees circumvented the wire policy and daily limits, and that the CEO's dominance of the bank and his standing in the community made subordinates reluctant to question him.

Strip away the specifics and the pattern is general. The automated control worked. It stopped the payment. The loss happened at the moment a person was asked to override the stop, and the person being asked reported to the person asking. Dual control, once it was in place, did not help, because both controllers sat inside the same pressure.

Most exception-path losses are smaller and less dramatic than a bank failure. The structure is the same.

Why automating the queue can make this worse

Here is where we part company with most of the vendor pitches.

Shrinking the exception queue is a fine goal. The error is assuming that shrinking it reduces risk in proportion. It can do the opposite, for two reasons.

First, automation removes the easy exceptions. The name mismatch that was a typo, the file that failed on a formatting rule, the payment held because a reference field was blank. Those clear themselves once a better matching engine is in place. What remains in the queue is a smaller, denser population of genuinely strange items, which is to say a higher concentration of the ones someone engineered to be there.

Second, a smaller queue gets fewer people and less attention. The team working it shrinks with it. The second reviewer who used to glance at every override becomes a sampling process, or a monthly report. Your straight-through rate goes up on the dashboard, and the controls on the remaining human decisions get thinner at the same time the decisions themselves get riskier.

We have made a version of this argument about sequencing in what a community bank should automate last in digital onboarding. The throughput steps are safe to speed up. The decision steps are where speed has a direction. An override on a held payment is a decision step, whatever the workflow tool calls it.

The comparison nobody publishes

If you want to know whether this is your problem, there is one comparison that settles it: your fraud loss rate on payments that went straight through, against your loss rate on payments that passed through an exception or override.

We have not found a single institution that publishes it. Very few measure it internally, because loss events are usually coded by payment type and fraud typology, not by the path the payment took through operations. The information exists in your systems. It is rarely joined.

The regulators have already told you where they will look. The OCC's Payment Systems booklet in the Comptroller's Handbook instructs examiners to consider dual controls, segregation of duties, and whether personnel have the ability to override or circumvent controls. It then directs them to sample transactions that involved manual intervention, naming exception processing and overlimit stops explicitly, and to assess whether those manual controls are effective. An examiner is going to test the exception path. The question is whether you tested it first.

What separates a real answer from a queue-shrinking pitch

We are not going to hand over a control design here, because the right one depends on your volumes, your staffing, your core, and who in your building has override authority today. But there are a few questions that tell you quickly whether a vendor, or your own project team, is looking at the right problem.

Does the proposal describe what happens to the items that remain in the queue after automation, or only how many fewer there will be? A plan that ends at the straight-through rate has stopped at the easy half.

Who can override a hold, and does any control apply to that person that does not also depend on their seniority? If the answer to a stuck payment is always escalation, your control strength falls as the amount rises, which is backwards.

Is the dual control on the exception path genuinely independent, or are both approvers in the same reporting line, working the same cutoff? Two people under one deadline are one control with extra paperwork.

Can you produce the loss comparison above, even roughly, from last year's data? If not, that is the first project, and it costs almost nothing compared with the platform.

If some of this sounds like our broader argument about when AI is the wrong answer to an operations problem, it is. And the same dynamic shows up outside banking: our piece on the cost of exception handling in manufacturing describes the operational version of the same queue. In payments the exception carries a fraud cost as well as a labor one.

Where this stops being an article

An article can tell you that your exception path is where controls stop applying automatically. It cannot tell you where your own losses sit, whether your override authority matches your org chart or your risk appetite, or what the second reviewer on your wire desk actually does at 3:45 on a Friday.

Those answers sit in your payment logs, your loss data, and a few days of watching the queue being worked. If you are being asked to fund a payments automation program and you want a read on the exception path from someone who does not sell the platform, start a conversation with us. We will tell you where the unsupervised decisions are, and whether fixing them needs software at all.