A payment tracking system for wires is a layer that answers "where is this payment?" by reading the systems a bank already runs, the core, the payments hub, the Fedwire gateway, the correspondent's portal and tracker, case management and the contact center, and joining their events on the payment's references. The hard part is not storage; it is that each system knows one leg, uses its own identifier and was never built to talk to the others. Botminds' Wire Inquiry & Payment Tracking is a tracking layer of that kind: read-only on payments, it draws each wire's route stop by stop with the source cited, answers staff in plain words, and leaves every payment system where it is.
This page is for the people who would buy and connect one: operations and IT leads at community and regional banks. The examples come from a fictional sample bank, Tessaly Community Bank, as it runs through the solution; the Fedwire details are the Federal Reserve's own.
One wire, as a payment tracking system sees it
11
events on one sample wire, from submission to the reply to the correspondent
4
references joined: the UETR, the Fedwire IMAD and OMAD, and the correspondent's case
0
payment systems replaced
What is a payment tracking system?
A payment tracking system is software that follows a payment from instruction to credit and tells staff, and sometimes the customer, where it is. In everyday searches the phrase often means an app for bills or invoices. For bank wires it means something narrower: a view across the systems that each hold one leg of a funds transfer, so that a question about one payment can be answered from all of them at once.
Examiners already expect most of the raw material to exist. The FDIC's procedures ask whether a bank keeps an outgoing wire log with the originator, the amounts, the beneficiary and "Counterparty institution", whether there are "audit trails from receipt through posting to a customer's account", and whether incoming and outgoing messages are reconciled daily with the Reserve Bank, servicers, correspondents and clearing houses (FDIC, Electronic Funds Transfer Risk Assessment; the same check appears in the return nobody can post). A tracking system turns those records from evidence for an audit into answers for a phone call.
The stack map: what each system you already run knows about a wire
Every system in a wire's path holds a piece of the answer, and none holds all of it. The map below is the sample bank's, a bank that sends cross-border wires through a correspondent.
The stack map: what each system holds, and what a tracking layer reads from it
| System | What it holds about a wire | What the tracking layer reads | Key it joins on |
|---|---|---|---|
| Payments hub | The instruction, callbacks, screening result, approvals and release | Submitted, verified, released, by whom and when | The bank's wire number |
| Fedwire gateway | pacs.008 messages, acknowledgments, status reports, rejects | Accepted, settled, rejected, with the time the Reserve Banks recorded | IMAD, OMAD, UETR |
| Correspondent portal and tracker | Status beyond the first bank, requests for information, the correspondent's cases | Where the payment is now, and what any bank on the route wants | UETR, correspondent case number |
| Core banking system | Postings, fees, balances and the customer | Debited, the fee, the account and who may be told | Account number, customer |
| Case management | Investigations, approvals and notes | What has already been asked of another bank, and by whom | Case number, wire number |
| Contact center platform | Caller verification, the screen pop, uploaded documents | Who is on the line, verified how, and what they sent | Customer, call |
The join keys are the real integration work. The payments hub knows the bank's own wire number; the Fedwire gateway knows the IMAD and OMAD; the correspondent knows the UETR and its own case number; the core knows the account. A tracking layer that cannot join them shows four partial pictures. In the sample, the wire's record carries all four references side by side, and every event on its timeline names the system it came from.
Wire Inquiry & Payment Tracking joins every system's events into one wire timeline

How does a tracking system connect to Fedwire?
A tracking system connects to Fedwire through the bank's own Fedwire gateway, not to the Federal Reserve directly; it reads the messages the bank sends and receives. The Fed's format rules name two ways in, FedLine Direct and the FedPayments Manager application on FedLine Advantage, and they differ slightly: for messages created manually in FedPayments Manager, "The FedPayments Manager – Funds application will generate the UETR", while a FedLine Direct sender "must include a UETR that conforms to the proper format" (Fedwire ISO 20022 Format FAQs, question 11).
The messages worth reading are few and well defined. An Acknowledgment confirms that the sender's Reserve Bank took the message; an Advice of Credit tells the receiver of a credit to its Master Account (Operating Circular 6, sections 2.3 and 2.5). Status comes as a pacs.002: pending while the payment is in process or held by the Reserve Banks, then settled or rejected by the end of the day; rejects come as an admi.002 that carries the original message's IMAD. A tracking system that needs a copy can use a pacs.028 status request on a value message, which Fedwire accepts until 7:15 p.m. ET, or an admi.006 retrieval request (Fedwire operating hours).
Two dates belong in any project plan. Fedwire's ISO 20022 portfolio already includes the investigation messages camt.110 and camt.111, and the Fed says Fedwire is the first payment system anywhere to implement them (Fed360, June 2026). The structured data models for them were tied to a release the Fed has since moved to November 2027 (FRFS, November 2027 Release FAQ; the Fedwire ISO 20022 implementation delay). A tracking layer should read today's messages and be ready to read richer ones.
Can community banks use gpi tracking?
A community bank that sends cross-border wires through a correspondent sees the cross-border leg through that correspondent: its portal, its tracker view and its messages, keyed on the UETR. The CPMI notes that "FIs or payment platforms may have different mechanisms to provide updates on the processing status of cross-border payments", and adds that "there may be situations in which entities other than the account servicer and the customer are involved in the initiation of cross-border payments (eg relay scenarios)" (BIS CPMI, Harmonised ISO 20022 data requirements, 2026).
For a buyer, the practical question is therefore not "are we on gpi?" but "what does our correspondent give us, in what form, and how fast?" A portal behind a login, a file, an API and a forwarded message each need a different connector. In the sample, the correspondent's tracker supplied the status at the intermediary bank in Frankfurt, and its portal supplied the request for documents that actually explained the hold. What happens where no bank reports status is the other half of that answer.
Do we need a new payments hub to track wires?
No. Tracking reads; it does not originate, release, amend or return payments, so it needs read access to the hub, not a replacement for it. Replacing a payments hub to get tracking would be like replacing a core to get a better statement: a large, risky project to fix a problem that sits in how data is joined and shown.
A read-only path: what the tracking layer does, and where people decide
Agent
ReadPulls events from the hub, the Fedwire gateway, the correspondent, the core and case management.
Never: writes to a payment system
Agent
JoinMatches events on the wire number, IMAD, OMAD, UETR and correspondent case into one route.
Never: guesses a match it cannot prove
Agent
AnswerDrafts the sentence staff may say and lists what it held back, with every source cited.
Never: repeats another bank's compliance reason
Agent
WatchFollows wires in flight and opens an investigation at the bank's stuck mark.
Never: sends a request to another bank on its own
A person decides
ApproveThe wire operations supervisor approves written statements, escalations, recalls and resends.
What data does a payment tracking system need?
It needs the events, the references and the rules. The events come from the six systems above. The references are the join keys. The rules are the bank's own: what may be said and by whom, how long before a wire counts as stuck, and which statements need a second person.
What a payment tracking system for wires needs before it can answer a single call
- Wire records from the payments hub
Instruction, callback, screening result, approvals and release time, with the bank's own wire number.
- Fedwire messages with their IMAD, OMAD and UETR
Acknowledgments, status reports and rejects from the gateway, in the time order the Reserve Banks recorded.
- The correspondent's status and requests
Tracker status by UETR, requests for information and case numbers, in whatever form the correspondent offers.
- Core postings and customer records
The debit, the fee, the account and who is authorised to ask about it.
- Disclosure rules, approved wording and clocks
Versioned, with an owner for each: the BSA officer for what may be said, the supervisor for wording and stuck marks.
- Route history
How long each correspondent and beneficiary bank has taken before; without it, an arrival day has no basis.
- A sample of past inquiries
To test the answers against what the bank actually said, before anyone relies on them.
Retention follows from what the bank already owes. Funds transfer records must be kept five years under the Bank Secrecy Act rules (31 CFR 1010.430(d)), and an originator's bank must be able to retrieve its records "by reference to the name of the originator", and by account number for an established customer (31 CFR 1020.410(a)). A tracking layer that keeps its answers alongside those records, locked and for the same period, can be searched the same way.
What a wire tracking tool should never do
A tracking tool should never move money, never contact another bank without a person's approval, and never say more than the bank's rules allow. Each of those is a line a buyer can test in a pilot: ask it to recall a wire, to message a correspondent, and to explain a hold at another bank, and see what it does.
Approvals: anything written about another bank waits for a second person

How long does it take to connect a tracking system?
It depends on access more than on software. A bank whose hub and Fedwire gateway can export messages, and whose correspondent offers its status in a readable form, has most of the work done; a bank that sees its correspondent only through a browser portal has a connector to build first. We do not quote a number of weeks on this page, because the honest answer is the inventory above, system by system.
The sensible first step is cheap: run the tracking layer on a sample of the bank's own past wire inquiries and compare its answers with what the bank actually said. That shows where the data is thin, which correspondents report late, and which disclosure rules need writing down. The trace a tracking layer performs is set out step by step, and Wire Inquiry & Payment Tracking shows the screens.
Where Wire Inquiry & Payment Tracking fits, and where it does not
The solution fits banks that send and receive wires through a payments hub and a Fedwire gateway, answer a steady flow of "where is my wire" calls, and want those answered on the first call with evidence and a second person on anything written about another bank. It does not replace the hub, the gateway, the correspondent's tracker or case management; it cannot see a leg that no bank reports on; and it does not make another bank answer faster. Its design target is 88% of wire status questions answered on first contact; on the sample data the median from question to the sentence an officer may say was 2 minutes 10 seconds.
A buyer can measure a pilot on four numbers it can check itself. The share of past inquiries the layer could have answered from evidence on the first contact. How often its sentence matched, or improved on, what the officer actually said. How often it held back something the bank's rules required held back, and whether it ever failed to. And how many stuck wires its watch would have flagged before the customer's second call. None of these needs a vendor's benchmark; all of them come from the bank's own files.
Questions people ask
What is payment tracking software?
Software that shows where a payment is between instruction and credit. For bank wires it reads the payments hub, the Fedwire messages, the correspondent's status and the core, joins them on the payment's references, and answers staff questions; it should be read-only on the payments themselves.
Does a tracking system need access to customer accounts?
Read access to postings and customer records, yes, so it can confirm the debit and know who may be told. It does not need, and should not have, the ability to post, release or return. In the sample bank, account numbers are masked to the last four digits everywhere in the tracking layer.
Can customers see wire tracking in online banking?
They can, if the bank shows a customer view built from the same route. The sample bank's business customers see the stops in plain words, "our partner bank" instead of a correspondent's name, no internal references, no other bank's reasons, and an arrival day that says "expected".
Does it work for incoming wires?
Yes, with fewer sources: the Fedwire Advice of Credit, the posting and any message from the sending bank. The sample bank keeps approved wording for an incoming wire that cannot be found, because the honest answer can be that it has not reached the bank yet and only the sender's bank can trace it.
Can a payment tracking system predict when a wire will arrive?
Only from history, and it should say so. The sample bank's tracking layer predicts from the route's own record: the intermediary had released 14 of 15 held wires a median 5 hours 40 minutes after the answer, and the beneficiary's bank credits a median 38 minutes after receipt. The answer says "expected", never "will", and below its confidence threshold it hands the wire to a person.
How is a tracking system audited?
Through what it keeps: every answer with who asked, what was told, what was held back and why, the sources and the approvals. In the sample bank that answer log is kept five years, nobody can edit it, and exports for an examiner, internal audit and the BSA officer are logged too.