Investigation: the missing MT103

A missing MT103 is the most common cross-border investigation, and it means the customer payment message has not arrived at the bank that should have received it, so the beneficiary has not been credited and nobody can say where the payment is. In ISO 20022 terms the missing message is a pacs.008, because MT103 no longer governs new cross-border payments after the end of coexistence on 22 November 2025, but the investigation is the same, and the industry still calls it a missing MT103, so a 15-year SME must be fluent in both names. The investigation starts with the UETR, and it ends when the message is found, resent or proven never to have been sent. Source: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.008 and pacs.002 definitions; SWIFT gpi tracker guidance. Why a payment message goes missing is usually mundane, and the investigation must check the mundane causes before assuming a system failure. The sending bank may have failed validation and never sent the message, the message may have been sent to the wrong BIC, the receiving bank may have received it but failed to process it because of a data error, or the message may be sitting in a queue waiting for a compliance review that nobody has worked. Each of those has a different owner and a different fix, and the investigation that does not distinguish them will chase the wrong bank for days. The UETR is what makes the distinction possible, because it identifies the payment at every hop, and a bank that cannot produce the UETR for a payment it claims to have sent has not sent it. The parties are the debtor bank, which claims to have sent the payment, the intermediary banks, which should have forwarded it, the creditor bank, which should have received it, and the beneficiary, who is waiting for the credit. The enquiry messages are pacs.028 Payment Status Request, which asks the next bank for the status, and in the legacy MT world MT199 Free Format Message, which asks the same question in free text. The answer is pacs.002 Payment Status Report, which states whether the payment was received, accepted, settled, credited or rejected, with a reason code if it was rejected. Each hop has its own request and answer, so the investigation is a chain, not a single message. How the investigation runs is shown by a worked example. A customer in London sends USD 75,000 to a supplier in Hong Kong on Monday at 09:00, UETR 7c2d3e4f-5a6b-7c8d-9e0f-1a2b3c4d5e6f, and on Tuesday the supplier has not been credited. The London bank checks its own records and confirms the pacs.008 was sent at 09:05, so it sends pacs.028. The correspondent replies with pacs.002 status RCVD at 11:30, meaning it received the payment, and the London bank sends pacs.028. The Hong Kong bank is then asked, and replies at 16:00 that it never received the payment, so the gap is between the second bank and Hong Kong, and the second bank finds the payment in its outgoing queue, held because the beneficiary account number failed a format check, and releases it the same day. On success the message is found, the payment is released or resent, the beneficiary is credited, and the case closes with a note recording every hop, every status and every timestamp. On failure the investigation stalls because a bank in the chain does not answer the pacs.028, and then the requester must age the request, resend it, and escalate to a free-format message, MT199, and then to a phone call to the relationship manager. The most expensive failure is a payment that was never sent but the sending bank insists it was, because the investigation then chases banks that never had the payment, and the fix is to demand the sending bank produce the message identifier and the transmission record, which either proves it was sent or proves it was not. The data the investigation needs is the UETR, the original message identifier, the instruction identification, the amount and currency, the value date, the debtor and creditor banks, and the status history. The UETR is the field that matters most, because without it the responder must match on amount and date, which fails when two payments for USD 75,000 go to the same beneficiary on the same day. A BA must require the UETR to be stored with every payment from initiation to archive, and must specify the pacs.028 trigger, usually a payment with no status update after a defined interval, the responder, the timeout and the escalation, because a missing payment that is not chased systematically will be chased by the customer instead. Edge cases show the depth. A missing MT103 where the cover leg arrived but the customer leg did not is a different investigation from one where neither leg arrived, because the cover leg proves the sending bank acted, and the gap is in the customer leg only. A missing payment that was sent to the wrong BIC will be answered by the wrong bank saying it never received it, and the investigation must check the BIC on the original instruction, not just ask the intended receiver. A missing payment that was rejected for a compliance reason will have a pacs.002 RJCT with a reason code, and the investigation must read the reason code, not just the fact of rejection, because the reason decides the fix. The effect on the bank is a measurable investigation cost, and a manager who can see how many missing-payment cases are open and how old they are. The effect on the customer is the difference between a supplier paid on time and a supplier who stops delivery, because USD 75,000 is often a payment the supplier is waiting for. The effect on operations is a queue with ages and service levels, and a discipline that every pacs.028 is answered within a defined window, because a bank that does not answer status requests will be remembered when its correspondents choose routes. What a BA, PO or SME must understand is that a missing MT103 investigation is a chain of pacs.028 requests, one per hop, tied together by the UETR, and the investigation ends when the gap is found, not when the customer stops asking. The requirement must name the trigger, the UETR storage, the hop-by-hop request flow, the timeouts and the escalation to MT199. The test is to take one missing payment and trace it hop by hop to the bank that holds it, and if any hop cannot answer, that hop is the gap to fix. Further reading: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.028 and pacs.002; SWIFT gpi tracker guidance. Last reviewed 7 November 2026.