Case lifecycle and stop or recall: running an investigation to closure

A payment case is the operational container that holds an investigation from the moment it is opened until it is closed, and the case lifecycle is the discipline of moving it through defined states with defined owners and defined deadlines. A case opens when a customer reports a missing payment, when a pacs.028 status request goes unanswered, when a camt.027 claim arrives, or when a return lands without explanation, and it closes only when the money is found, returned, recalled or written off with approval. Without a case, the same missing payment is chased by three people in three systems, and nobody knows what has already been tried. Source: SWIFT CBPR+ usage guidelines on investigations, and the ISO 20022 camt.056 and camt.029 messages for cancellation and resolution. Why a case lifecycle matters is that investigations fail by neglect more often than by difficulty. A payment that is missing on Monday is easy to find on Monday, because the messages are fresh and the people who sent them are at their desks, but the same payment is hard to find on Friday, because the trail has gone cold and the original sender has moved on. The lifecycle prevents neglect by assigning an owner at opening, a priority based on amount and customer impact, a deadline for the first action, and an escalation when the deadline passes. A EUR 500,000 payment for a payroll gets a same-day deadline, while a EUR 50 duplicate gets a three-day deadline, and the priority is set by the business impact, not by the order the cases arrived. The parties to a case are the case owner, usually in the payments operations team, the customer who reported it, the correspondent banks in the chain, and the beneficiary bank, and each has a role. The owner drives the case, the customer provides the references, the correspondents answer the status requests, and the beneficiary bank confirms the credit or the return. A stop or recall is a specific action inside a case: a stop asks the next bank not to forward the payment, and a recall, sent as camt.056, asks for the money back after it has been credited. The distinction matters, because a stop can still succeed if the payment has not moved, while a recall needs the beneficiary agreement, and confusing the two wastes the window in which a stop would have worked. How a case runs is shown by a worked example. A customer reports on Tuesday at 09:00 that USD 180,000 sent on Monday to a supplier in Dubai has not arrived. The case opens at 09:15 with priority high, because the amount is large and the supplier is threatening to stop delivery. The owner sends pacs.028 to the correspondent at 09:30, receives pacs.002 status ACSP at 11:00, and learns the payment is with the intermediary in New York. The owner sends pacs.028. The case closes at 16:00 with the credit confirmed, a total elapsed time of seven hours, and a case note recording every message, every answer and every timestamp, so that if the customer asks again, the answer is in the file. On success the case closes with the money found or returned, the customer told what happened, and the root cause recorded, which is how the bank stops the same failure happening again. On failure the case ages, the customer escalates, and the bank pays interest compensation or loses the customer, and the root cause is never recorded, so the same failure repeats next month. The most common failure is a case that is opened but never owned, because the person who opened it assumed someone else would act, and the lifecycle prevents that by making ownership explicit at opening, with a named person, not a team inbox. The data in a case file is the original payment references including the UETR, every message sent and received with timestamps, the status codes, the owner, the priority, the deadlines and the closure reason. The UETR is the key that links the case to the payment across every bank in the chain, and a case without a UETR is a case that cannot be traced. A BA writing requirements must specify the case states, for example open, awaiting correspondent, awaiting beneficiary bank, resolved and closed, the transitions between them, the deadlines per priority, and the escalation rule, because a case system without deadlines is just a list. Edge cases show whether the lifecycle is real. A recall case where the beneficiary refuses to return the funds cannot be closed as resolved, it must be closed as unresolved with the refusal recorded, and the customer must be told that the bank cannot force a return. A duplicate payment case must link the two payments by UETR and amount, and the recovery must be a return of one of them, not a recall of both. A case that is closed and then reopened because the customer disputes the answer must keep its original history, not start a new case, or the bank loses the evidence of what was already tried. The effect on the bank is a measurable investigation cost per case, and a manager who can see how many cases are open, how old they are, and which correspondents are slow to answer. The effect on the customer is a single point of contact and a factual update at each step, instead of being passed between teams. The effect on operations is a queue that is worked in priority order, not arrival order, which means the EUR 500,000 payroll case is worked before the EUR 50 duplicate, even though the duplicate arrived first. What a BA, PO or SME must understand is that a case is a product, not a pile of emails, and it needs states, owners, deadlines and closure reasons designed before it is built. The requirement must name the triggers that open a case, the states, the deadlines per priority, the escalation rule, the stop and recall actions and the closure reasons. The test is to open a case for one missing payment, work it to closure, and check that every action is in the file with a timestamp, because a case file that cannot prove what was done is not evidence. Further reading: SWIFT CBPR+ usage guidelines; ISO 20022 camt.056 and camt.029 definitions; SWIFT gpi case resolution guidance. Last reviewed 7 November 2026.