pacs.028 Payment Status Request: asking where a payment is

The pacs.028 Payment Status Request is the ISO 20022 message a bank sends when it needs to know the status of a payment it has already sent, and it is the formal, auditable way to ask where the money is. It replaces the phone call and the free-format email with a structured request that names the original payment, the original message identifier and the business reference, and it obliges the receiver to answer with a pacs.002 Payment Status Report stating whether the payment was received, accepted, settled, credited or rejected. Source: ISO 20022 pacs.028 message definition, and SWIFT CBPR+ usage guidelines for payment status reporting. Why pacs.028 exists is that a payment can be in an unknown state for hours, and unknown is the most expensive state in payments. The debtor bank has debited its customer, the creditor bank has not credited the beneficiary, and nobody can say whether the money is in transit, held for compliance, rejected or lost. Before pacs.028 the only remedy was an MT199 free-format message, which a human had to read and answer, with no structured status and no deadline. The pacs.028 turns the enquiry into a machine-readable request with a machine-readable answer, so the status can be tracked, aged and escalated automatically, and the customer can be given a factual answer instead of a guess. The parties are the original sender, which becomes the requester, and the next bank in the chain, which becomes the responder, and the request travels hop by hop, not end to end. If Bank A sent to Bank B and Bank B sent to Bank C, Bank A asks Bank B, and Bank B must either answer from its own records or ask Bank C and pass the answer back. Each hop has its own pacs.028 and its own pacs.002, and the UETR, the unique end-to-end transaction reference, is what ties the chain together, so the requester can prove it is asking about the same payment at every hop. A BA must draw this as a chain of requests, not as one message to the beneficiary bank. How it works is best shown with a worked example. Bank A in London sends USD 125,000 to a beneficiary in Singapore on Monday at 09:00, UETR 8a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d, and by Tuesday 10:00 the beneficiary still has not been credited. Bank A sends pacs.028 to its correspondent Bank B naming the original pacs.008 message identifier and the UETR, and Bank B replies with pacs.002 status ACSP, accepted settlement in progress, meaning the payment is with Bank C. Bank A then knows the money is not lost, it is in transit, and it can tell the customer the payment is with the next bank and the expected credit is today. If Bank B had replied RJCT with reason code AC04, Bank A would know the beneficiary account was closed and could start a return. On success the requester gets a status code it can act on, and the customer gets a factual update with a next step and a time. On failure the pacs.028 itself can go unanswered, and that is a distinct failure with its own handling: the requester must age the request, resend it after a defined interval, and escalate to a free-format enquiry or a phone call if the second request also goes unanswered. The service level matters here: a bank that answers pacs.028 within two hours keeps its customers informed, while a bank that takes two days forces its correspondents to guess, and the correspondent will remember that the next time it chooses a route. The data in a pacs.028 is the original message identification, the original instruction identification, the UETR, the amount and currency, and the requested status, plus the requester identification so the answer can be routed back. 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 the same amount 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, because a status request for a payment whose UETR was lost is a manual investigation, not a pacs.028. Edge cases show the depth of the topic. A pacs.028 for a payment that was never sent, because the original pacs.008 failed validation, should return a status that says so, not a rejection of the request, and the requester must then fix and resend the original payment rather than chase a ghost. A pacs.028 for a payment that has already been returned should return the return status with the pacs.004 reference, so the requester can close the case. A pacs.028 sent twice for the same payment must be deduplicated by the responder, or the responder will do the investigation twice and return two different answers. The effect on the bank is a measurable reduction in investigation cost: each pacs.028 that returns a structured status is one phone call that did not happen, and a bank that processes 500 status requests a month saves hundreds of staff hours. The effect on the customer is a faster, factual answer, which is the difference between a customer who waits patiently and a customer who escalates to a complaint. The effect on operations is a queue with ages and service levels, and a manager who can see at 10:00 how many status requests are older than two hours and why. What a BA, PO or SME must understand is that pacs.028 is the first message to send when a payment goes quiet, and it must be sent before the phone call, not after it, because the structured answer is what the case file needs. The requirement must name the trigger, usually a payment with no status update after a defined interval, the responder, the timeout, the retry rule and the escalation to a free-format message. The test is to take one missing payment and trace the pacs.028 chain hop by hop to the beneficiary bank, and if any hop cannot answer, that hop is the gap to fix. Further reading: ISO 20022 pacs.028 and pacs.002 definitions; SWIFT CBPR+ usage guidelines; SWIFT gpi and UETR guidance. Last reviewed 7 November 2026.