The problem
The client is a mid-size bank. Outgoing wires that miss a field, a sanctions-list timeout, or a beneficiary mismatch land in an exception queue. Analysts rebuild the file by hand from the payment system, the customer record, and the sanctions result. Most of those files are routine. The queue still set the pace of the desk, and a payment that should have left before noon left the next morning.
The operations lead did not want a model that approved wires. The ask was narrower: put the evidence in one place, name the exception reason in the bank's own code, and leave the release button where it already was, on a person's screen.
Why packaging, not auto-release
Release is the control. Once a payment leaves, the bank owns the recall. A faster package is valuable. A model that presses release to save the last click is a different risk, and the control owners had already said no to it. We treated that as a requirement, not a preference to revisit at the end.
Architecture
One package, three systems
For each exception the workflow pulls the payment instruction, the customer record as of that morning, and the sanctions or validation result that created the exception. The draft names which of those three is missing or mismatched. It does not invent a beneficiary detail that none of the three contain.
The bank's exception codes, not a new taxonomy
Analysts already work from a short list of reason codes. The assistant must use those codes. A free-text reason that does not map to a code goes back as incomplete, because downstream reporting is built on the code.
Low-risk is a rule the bank wrote
Same-hour packaging is limited to reason codes the operations and risk teams marked as low-risk and fully evidenced. Anything else, including a sanctions hit of any kind, is packaged but flagged for the existing senior path. The model does not decide that a hit is a false positive.
The release control stays put
The package opens in the payment system the desk already uses. The release action is the same control as before, with the same entitlements. There is no second button in the assistant.
Challenges and tradeoffs
- Beneficiary strings did not match across systems. The payment instruction and the customer record often differed by punctuation or a legal-entity suffix. A strict match marked too many files as mismatched. We normalized with the operations team and wrote the remaining true mismatches, the ones a person should see, into the evaluation set.
- A sanctions timeout is not a clear result. The first draft treated a timeout as no hit. That is the wrong way around. A timeout now keeps the file on the senior path until the screening service returns a result.
- Analysts skipped packages that hid the source screen. A summary with no link back to the payment system was unused. Every line in the package links to the screen it came from.
Results
During the pilot, 71% of exceptions in the low-risk codes were packaged in the same hour, with a median assembly time of 18 minutes. The rest were either missing a source the workflow could not read or were outside the low-risk list. Every payment in the pilot was still released by a person, using the existing control.
The desk did not get a new approval policy. It got the file in front of the person who already had the authority, with the reason code filled from the systems they trust.
What we'd do differently
We would have listed the low-risk codes with risk and operations in week one, in writing. We spent a week packaging codes that the risk team later pulled back out, which was the right outcome and a late one.