Payments exception management system: keep the hub you have

A payments exception management system is the software a bank uses to work the payments that did not go as instructed, and the questions about them: wire inquiries, non-receipt claims, cancellations and returns, misapplied credits, compensation claims. Most of the evidence for those cases is already in systems the bank runs: the payments hub that processed the message, the Fedwire and SWIFT gateways that sent and received it, the core that posted it and the general ledger that carries the suspense and control accounts. What those systems do not hold is the case: one place where the request, every lookup, the decision, the reply and the approval sit together. That is a layer that reads the payment systems, not a replacement for them. Botminds' Payment Investigations is built that way: agents read the bank's systems, cite each record and draft the reply, and the hub stays where it is.

What is a payment exception management system?

It is a case system for payment exceptions: it receives the inquiry, links it to the payment, tracks who is waiting on whom, records the decision and the approval, and produces the reply and any correction. Banks also use the phrase for tools that sit inside the payments hub and manage the repair queue, the payments that fail validation before they are sent. The two overlap but are not the same. Repair happens before the payment leaves; investigation happens after someone asks about it. This guide is about the second.

The distinction matters when buying, because it decides what the system must connect to. A repair tool needs to change messages in flight. An investigation system needs to read settled payments across every system they touched, write cases and draft replies, and change money only through an approved correction. That is a much narrower set of write permissions, and a much wider set of reads.

Do we need to replace our payments hub?

No. The hub's job is to process payments, and it is already integrated with the gateways, sanctions screening, the core and the general ledger. An investigation system needs what the hub knows, not its job. Replacing the hub to get better investigations means re-testing every payment flow the bank runs in order to fix a process that starts after those flows have finished.

The volume of what the hub carries is the reason to leave it alone. In the third quarter of 2026 the Fedwire Funds Service processed 58.2 million transfers worth $313.9 trillion, an average of 895,446 a day. A bank's share of that, plus its SWIFT and book transfers, runs through its hub. An investigation layer needs to read a small fraction of those payments, and to change none of them.

What systems hold the data for a wire inquiry?

At least five, and often six: the payments hub, the gateways, the core banking system, the general ledger, the bank's case tool or ticketing system, and the document store that holds agreements, fee schedules and client instructions. Each holds part of the answer, and each identifies the payment by a different key. The investigator's first job is joining them.

What is the UETR used for in investigations?

It is the one reference that can follow a payment through every system and every bank, which makes it the natural key for an investigation. The UETR, the unique end-to-end transaction reference, is a 36-character identifier built to the internet standard RFC 4122 (version 4), which any bank can generate without a central registry, as the CPMI notes and IMAD vs OMAD, and where the UETR fits explains. In the Fedwire Funds Service's ISO 20022 format it is mandatory on every value message (the pacs.008, pacs.009 and pacs.004), and Fedwire checks its format but, by its own account, not its uniqueness (FRFS Format FAQs). So a domestic wire now carries the same kind of reference a cross-border tracker uses, and a mistaken duplicate reference is the sending bank's problem to catch.

The Committee on Payments and Market Infrastructures made the case for it in its harmonised ISO 20022 requirements, revised in February 2026: use of the UETR "will also simplify exception and investigation (E&I) handling, facilitating automated processing solutions that enhance the speed of cross-border payments overall", and "is also expected to indirectly reduce costs by enabling the automation of E&I management processes" (CPMI, updated report). The practical lesson for a buyer is to ask whether a system joins records by UETR first and falls back to amount, date and name only when it must, and whether it shows which join it used.

One case in Payment Investigations, joined across four systems by its reference

How does case management connect to Fedwire?

Through the bank's own Fedwire gateway, not directly. The gateway that connects the bank to the Fedwire Funds Service is where the investigation messages arrive and leave. Since the move to ISO 20022 on July 14, 2025, those include the return request and response pair (camt.056 and camt.029), the payment status request (pacs.028), and the investigation request and response (camt.110 and camt.111), which Fedwire's FAQ says replace most uses of the old service message. A case system needs read access to what the gateway receives and a route, through the gateway and the bank's own controls, for what it sends.

Two Fedwire behaviours are worth building into the case logic. A value message in process or intercepted produces a pacs.002 with status PDNG (pending), and Fedwire sends another pacs.002 by the close of business with ACSC (accepted, settlement completed) or RJCT (rejected) (FRFS Format FAQs). A case that reads those statuses can answer "did it settle?" without asking anyone. And Fedwire rejects a message whose IMAD it has already processed, so a resent payment that looks like a duplicate can be checked against the gateway's own record. How the investigation messages are built, field by field, is the subject of camt.110 and camt.111.

Read, don't write: the access an investigation system needs

Broad read access, narrow write access, and every write behind a second person. The FFIEC's wholesale booklet asks for "logical access controls restricting access on a need to know basis" on payment messaging, and access based on "the concept of 'least possible privilege'" for funds-transfer applications (FFIEC, Wholesale Payment Systems). An investigation system that can change payments in the hub, or post entries without an approval, widens the bank's attack surface for no investigative gain.

In Payment Investigations, the research agent is read-only: it never places a hold or posts. The correction agent drafts reversals, credits, returns (pacs.004) and claim payments with their value dates and general ledger effect, and never posts without a checker's approval. Approval is the moment the solution posts and sends, in one signed step. Access follows need to know, with account numbers masked to the last four digits, and the administrator who configures the solution cannot act on cases.

What changes in the November 2027 Fedwire release?

Fedwire will carry the structured payment-investigation data models and the hybrid postal address, and the bank's systems need to read both. Federal Reserve Financial Services has rescheduled its Fedwire Funds release to November 2027; it intends to publish the final usage guidelines, including the Fedwire Funds Service ISO 20022 Implementation Guide, in November 2026, with peer-to-peer test registration in June 2027. In June 2026, when the release was still planned for November 2026, FRFS said it would incorporate "the two payment investigation structured data models that were not available at the time of initial cutover" (Fed360, June 2, 2026).

For a buyer, that is an argument for keeping the release work where it belongs. The hub and gateway teams will implement the new formats; a case layer that reads structured fields, and can still read the free text that arrives meanwhile, gets the benefit without a second migration. The BIS has warned that higher straight-through processing needs more than new messages, calling for an overhaul of operational workflows; the same is true of investigations.

How long does an integration take?

That depends on the bank, and a vendor who gives a number before seeing the systems is guessing. What can be planned is the order: read connections to the hub, gateways and core first, then the general ledger and the case tool, then the few approved write routes. The fastest way to find out whether a system works is to run it on the bank's own past cases before anything goes live, comparing its research and drafts with what the bank actually did.

A free-text inquiry, read field by field before any research runs

Where Payment Investigations fits, and where it does not

Payment Investigations is the case layer: it reads the request and the payment systems, works out what the facts mean under UCC Article 4A, Regulation J and the agreement, drafts the replies and entries, and puts every send and posting to a person. It does not process payments, repair messages before they are sent, screen for sanctions or replace the hub, the gateways or the core. It works beside the bank's case tool, keeping case records in step both ways, rather than asking the team to abandon it. Where a bank needs payment repair or fraud recall, those are separate solutions with their own controls.

The fit is best where the team's time goes on finding the payment and writing the reply, and where approvals still travel by email. It is weaker where the bank's systems cannot be read programmatically at all, because the agents can only cite what they can open. To see how inquiries are sorted before any of this begins, see payment inquiry management; to test a system on hard cases from your own files, see five test cases for a payment investigation tool. To see the solution on a sample case, start from Payment Investigations.

Questions people ask

What is the difference between payment repair and payment investigations?

Repair fixes a payment before it is sent, when it fails validation or screening in the hub. Investigation starts after a payment has been sent or received and someone asks about it: where it is, why it was not credited, whether it can be cancelled, what is owed. Different systems, different controls, and usually different teams.

Does a payments exception management system need write access to the core?

Only to post corrections, returns and claim payments, and only after a second person approves them. The research itself needs read access. The FFIEC's wholesale booklet asks for access on a need-to-know basis and the least privilege the job requires.

What is the UETR?

The unique end-to-end transaction reference: a 36-character identifier defined in RFC 4122 (version 4) that stays with a payment across every bank and system. It is mandatory on Fedwire value messages in the ISO 20022 format, and the CPMI's harmonised requirements call for it on all cross-border payments.

Does Fedwire support investigation messages today?

Yes. Fedwire's ISO 20022 message portfolio includes camt.110 and camt.111 for exceptions and investigations, alongside camt.056 and camt.029 for return requests. The structured investigation data models in the CPMI's 2026 update are planned for the Fedwire release now scheduled for November 2027.

Can an exception management system work with SWIFT and Fedwire at once?

It should, because a single case often spans both: a cross-border payment arrives through SWIFT and goes out to the beneficiary's bank over Fedwire. Ask whether it reads both gateways and joins the legs by the UETR, which both now carry.

Should the system replace our case or ticketing tool?

Not necessarily. A bank may keep a group-wide case tool for complaints and service requests. An investigation layer can keep its case records in step with that tool both ways, so service teams see status without the investigation evidence leaving the controlled record.