Payment inquiry management is the handling of every question a bank receives about a payment it has sent or received: logging it, working out what is being asked, routing it to the right person, answering it within the deadline and keeping the record. The inquiries arrive in every format, from structured camt.110 messages to free-text emails, but they ask for only a few things: where is the payment, it was not received, cancel or return it, change it, we cannot apply it, we need information, and you owe us money. Each of those has its own message, its own legal clock and its own approver, so the most useful thing a desk can do is sort by intent before anyone starts researching. Botminds' Payment Investigations reads each inquiry in whatever format it arrives, sorts it by what the sender wants, and drafts the answer for a person to send.
What one correspondent asked for over 90 days, in Payment Investigations' sample data
A sample correspondent's 14 cases in 90 days
- Not credited: name and number mismatch · 42.9%
- Where is it · 21.4%
- Cancel · 14.3%
- Amend · 14.3%
- Fee claim · 7.1%
What is payment inquiry management?
It is the front half of the investigation process: intake, classification, routing and the answer. Done well, it means a routine status question is answered quickly by whoever is free, while a non-receipt claim that may end in a correction goes to an experienced analyst with time to research it, and a compliance request goes only to people allowed to see the answer. Done badly, every inquiry joins one queue in arrival order, and the expensive cases wait behind the cheap ones.
The difference is mostly in the first five minutes. Reading an inquiry well enough to sort it means extracting the payment's references, the sender's identity, the deadline and, above all, the intent. That is the step most worth automating, because it is repetitive and because a mistake there wastes every later step.
How are wire inquiries categorized?
By what the sender wants. The structured messages already encode it. The CPMI's harmonised model for the camt.110 investigation request lists four investigation types: Unable To Apply (UTAP), Creditor Claim Non-Receipt (CCNR), Creditor Agent Claim Cover Non-Receipt (CONR), and Request For Information (RQFI) with sub types for anti-money laundering, financial crime compliance, fraud, the funds/wire transfer regulation, sanctions, and unable to execute (CPMI technical annex, 2026). Cancellation and return requests travel separately as camt.056, answered by camt.029, and status requests as pacs.028.
The sort the ISO 20022 investigation request already carries
4
investigation types in the CPMI's camt.110 model: UTAP, CCNR, CONR and RQFI
6
request-for-information sub types, from anti-money laundering to unable to execute
3
camt.111 statuses: closed, pending or rejected, with a reason required for the last two
Free-text inquiries need the same sort done by reading. A desk that uses the same categories for both, so that an email asking "has our client been paid?" lands in the same queue as a camt.110 of type CCNR, can measure and staff its work consistently while its counterparties migrate. How each field of the structured request works is set out in camt.110 and camt.111, field by field.
Seven intents, each with its own message, clock and approver
The table below is the sort a payment inquiry desk can apply to every request, whatever its format. The third column is why the sort matters: each intent carries a different legal clock, and some of them run whether or not anyone has read the inquiry yet.
Seven things a payment inquiry can ask for, and what each sets in motion
Where is it?
Message in and outpacs.028 status request; a request for information; a call or email
The clockThe requester's deadline
Who answersThe analyst sends a status that admits nothing and moves nothing.
It was not received
Message in and outcamt.110 type CCNR → camt.111 with a confirmation or transaction status
The clockA beneficiary's bank owes notice to an account beneficiary by midnight of the next funds-transfer business day (4A-404(b))
Who answersRoutine if the credit is found; a second person if a correction follows.
Cancel it, or send it back
Message in and outcamt.056 → camt.029; funds back by pacs.004
The clockAfter acceptance, only with the receiving bank's agreement (4A-211(c)); Fedwire cutoff 7:00 p.m. ET for the camt.056, 6:45 p.m. ET for a pacs.004 returning a customer transfer
Who answersA second person for any return or debit.
Change the details
Message in and outAn amendment request, by message or in free text
The clockAn amendment is a cancellation plus a new order (4A-211(e)), so the cancellation rules apply
Who answersA second person if money moves.
We cannot apply it
Message in and outcamt.110 type UTAP → camt.111 with remittance data or a narrative
The clockAn unaccepted order lapses at the close of the fifth funds-transfer business day (4A-211(d))
Who answersThe analyst for the answer; a second person for a return.
We need information for compliance
Message in and outcamt.110 type RQFI with a sub type such as AMLI, FRAD or SANC → camt.111
The clockThe requester's deadline, within what the bank may disclose
Who answersCompliance decides what is said; nothing reveals a suspicious activity report.
You owe us interest or a fee
Message in and outA claim by message or letter; camt.110 can carry requested compensation
The clockFees become recoverable if a valid demand is refused before suit (4A-305(e))
Who answersAlways a second person to pay.
Two intents in that list deserve a closer look. A request to "change the details" sounds administrative, but under Article 4A an amendment "is deemed to be cancellation of the original order at the time of amendment and issue of a new payment order in the amended form at the same time" (4A-211(e)). After acceptance it needs the same agreement a cancellation does, so it belongs with cancellations, not with status questions. And "we cannot apply it" has a deadline built in: an order the receiving bank never accepts is cancelled by operation of law at the close of the fifth funds-transfer business day after its execution or payment date (4A-211(d)).
What is an MT 199?
An MT 199 is one of SWIFT's free-format message types, as the BIS glossary on ISO 20022 migration describes the MT199 and MT299 (CPMI Brief No 11): a text message between banks, with no field for the investigation type, the payment's references or the deadline. Free-format messages keep arriving beside structured ISO 20022 messages while banks migrate.
For inquiry management the problem with free text is not that it is old but that it has to be read to be sorted. An email that asks for the status of a wire and adds that the client has not received it could be a simple status question or the start of a non-receipt claim, depending on what the records show. A message asking to cancel only if the payment has not yet been credited is a conditional cancellation, not a cancellation. Reading those correctly, and noticing when a date such as "03/04" could be March or April, is the work an inquiry tool must do before it can route anything.
A free-text inquiry in Payment Investigations, read and sorted before research starts
How do you prioritise payment investigations?
By the earliest clock that matters, then by what is at stake. The requester's deadline is the obvious clock, but the legal ones can be earlier: a beneficiary's bank's next-day notice duty under 4A-404(b), the fifth-day lapse of an unaccepted order, and Fedwire's 7:00 p.m. ET cutoff for return requests and investigation messages (FRFS operating hours). At stake means money that may still be recoverable, such as a misdirected credit still sitting in the wrong account, and liability that grows with each day of delay.
A queue sorted only by arrival order hides all of that. A queue sorted by the earliest deadline, with the reason a case is at risk written beside it, lets a team lead move work before it is late rather than explain afterwards why it was. In Payment Investigations the inbox is sorted by the requester's deadline, and a deadline agent predicts which cases will miss and why, then proposes how to rebalance work across analysts; it never reassigns without the team lead.
One queue, filtered by intent and sorted by the requester's deadline
Which inquiries need a second approver?
Those whose answer admits liability, moves money or pays a claim. A status answer that the payment was credited at 3:07 p.m. commits the bank to nothing it has not already done. A reply saying the bank misapplied a payment, a correction that debits one customer and credits another, a return of funds and an interest payment each commit the bank, and the FFIEC's wholesale booklet expects officer review of corrections, reversals and adjustments (Wholesale Payment Systems). Sorting by intent tells the desk early which cases will need that second signature, so the team lead's time can be planned rather than interrupted.
One intent needs a different kind of control. A request for information about anti-money laundering, fraud or sanctions, or any case that touches a referral to Financial Crimes, must be answered without revealing a suspicious activity report or anything that would reveal one (31 CFR 1020.320(e)). In Payment Investigations such cases are restricted: client service sees status only, and the drafting agent removes restricted wording from every client and correspondent reply.
Can inquiries be answered automatically?
They can be drafted automatically; whether they should be sent without a person depends on the intent. A routine status reply, built from the bank's own records, is the safest candidate for speed. A reply that concedes an error is the least safe, because its wording is a decision about the bank's liability. Why that is so under the misdescription rule is set out in UCC 4A-207.
In Payment Investigations, agents draft every reply but send none on their own: the analyst sends routine replies, and a team lead approves anything that admits liability, moves money or pays a claim, with the maker unable to approve their own draft. The design target is that 100% of replies that admit liability, move money or pay a claim are approved by a second person. That split is what lets a desk move faster on the routine without loosening control of the rest.
What a payment inquiry management tool should sort by
A tool earns its place by sorting well before it researches anything. The questions below test that, and pair with the harder cases in five test cases for a payment investigation tool.
Questions to ask of a payment inquiry management tool
- Does it sort by intent, the same way for structured and free-text inquiries?
A camt.110 of type CCNR and an email saying "not received" should land in the same queue.
- Does it read the deadline from the request, in the requester's time zone?
"By 17:00 Frankfurt" is 11:00 a.m. in New York.
- Does it know the legal clocks behind each intent?
Next-day notice, the fifth-day lapse, Fedwire's cutoffs.
- Does it merge requests about the same payment?
An investigation request and a cancellation request about one payment are one case.
- Does it mark, at intake, which cases will need a second approver?
So the team lead's day can be planned.
- Does it restrict compliance-sensitive cases from the start?
Before anyone drafts a client reply.
- Does it verify the sender before answering?
An inquiry from an address not on file waits for a callback.
- Can it count intents and causes by correspondent?
So repeat problems reach the relationship manager.
The last question is where inquiry management feeds back into the business. In the sample above, six of one correspondent's 14 cases in 90 days were the same problem: the beneficiary's name and account number did not match. The solution's trends agent drafts a note for the relationship manager with the cases behind each number, and proposes a control change, such as raising the name-check threshold, for the administrator and the Head of E&I to approve. For how a sorted case is then worked to the end, see the payment investigation process; to see it on a sample case, start from Payment Investigations.
Questions people ask
What is the difference between a payment inquiry and a payment investigation?
An inquiry is the question; an investigation is the work to answer it. Many inquiries, such as a status question about a payment already credited, are answered from the bank's own records and never become a full investigation. Sorting by intent at intake decides which ones do.
What is an unable to apply payment?
A payment the receiving bank cannot apply as instructed, for example because the beneficiary or account cannot be identified. In the CPMI's camt.110 model it is the investigation type UTAP. Under UCC 4A-207(a), if the identification refers to a nonexistent or unidentifiable person or account, acceptance cannot occur.
How do correspondent banks send wire inquiries?
By structured ISO 20022 messages where both sides support them (camt.110 for investigations, camt.056 for cancellation and return requests, pacs.028 for status), and by free-format messages such as the MT 199 where they do not. Clients also ask by email and phone.
Is a wire amendment the same as a cancellation?
Under UCC 4A-211(e), an amendment is treated as cancelling the original order and issuing a new one in the amended form. After acceptance, it therefore needs the receiving bank's agreement, like any cancellation.
How fast should a payment inquiry be answered?
No regulation sets a single deadline for interbank inquiries; the requester's deadline, the bank's agreements and its own service standards do. The legal clocks behind some intents, such as a beneficiary's bank's next-day notice duty, can be shorter than the service level, which is why the sort should come first.
Who should see compliance-related payment inquiries?
Only the people who need to, and never the client in a form that reveals a referral. A request for information about sanctions, fraud or money laundering should be routed to staff allowed to see the answer, and any client or correspondent reply should be free of restricted wording.