Tracing a payment through either method

Tracing a payment is the most practical skill in cross border operations, and the method decides how the trace is done. For a serial payment, the trace follows the chain. The analyst asks each bank in turn whether it received the pacs.008, when it received it, when it passed it on, and what charge it deducted. The payment can be found by its reference, which stays the same through the chain, and by its amount, which reduces by the charges at each step. A serial trace is like following a parcel through a series of depots. Each depot can confirm when the parcel arrived and when it left, and the parcel is in exactly one depot at any moment. For a cover payment, the trace has two legs to follow, and the analyst must check both. First, the analyst checks the instruction leg. Did the beneficiary bank receive the pacs.008, when did it receive it, and what is its status. Second, the analyst checks the funds leg. Did each bank in the cover chain receive the pacs.009 COV, when did it receive it, and when did it pass the funds on. The two legs are linked by the UETR, the unique end to end transaction reference, which is carried on both the pacs.008 and the pacs.009 COV, and the analyst must confirm that the funds leg matches the instruction leg in amount and UETR. A common problem in cover payments is that the funds arrive but cannot be matched to the instruction because the reference is different, or the instruction arrives but the funds are delayed because a bank in the cover chain has stopped them for a query. In both cases the beneficiary bank can see the instruction and can explain the position to the beneficiary, which is better than the serial case where the beneficiary bank may know nothing until the payment arrives. The analyst should check the gpi tracker first, because it shows the status at each bank in a single view keyed by the UETR, and it will usually show which leg is delayed and which bank is holding it. The tools for tracing are the SWIFT messages themselves, the gpi tracker, and the correspondent account statements. The analyst starts with the UETR and the gpi tracker, which shows the status codes at each bank, such as ACSP for accepted settlement in process, ACSC for accepted settlement completed, and ACCC for accepted credit completed. If the tracker shows the payment stuck at a particular bank, the analyst contacts that bank with a query, usually an MT199 or MT999 free format message quoting the UETR, the amount, the value date and the reference, and asks for the status. The bank replies with the status and the reason, and the analyst updates the customer. When the gpi tracker does not have the answer, the analyst goes to the correspondent account statements. The MT950 statement or camt.053 shows whether the funds left the nostro account and when, and whether they arrived in the next bank's account. If the funds left Bank A but did not arrive at Bank B, the payment is stuck between them, and the analyst contacts Bank A's correspondent. If the funds arrived at Bank D but the beneficiary was not credited, the problem is at Bank D, and the analyst contacts Bank D. The statement is the ground truth for the funds leg, and the message archive is the ground truth for the instruction leg, and the analyst must be able to read both. A good analyst keeps a checklist for a trace: the UETR, the amount, the value date, the sender, the receiver, the method, and the status at each bank. The analyst also keeps the customer informed. A customer who is told that the payment is with Bank C and is expected tomorrow is a satisfied customer, while a customer who is told nothing for five days is an angry customer, even if the payment arrives on the same day in both cases. Tracing is not just a technical skill, it is a customer service skill, and the analyst who can trace a payment and explain its position clearly is worth more than the analyst who can only describe the theory. The escalation path matters when a trace does not resolve quickly. If a bank does not respond to a query within two business days, the analyst escalates to a senior contact at that bank. If the payment is still not found after five business days, the analyst escalates internally to the head of operations and considers a formal investigation, which in ISO 20022 is a camt.056 cancellation request or a camt.029 resolution of investigation, depending on the situation. The customer must be told at each escalation, with a revised timeline, and the analyst must record every contact, every response, and every promise, because a trace without a record is a trace that cannot be audited. Finally, the analyst should record the outcome of every trace and use it to improve the product. If traces repeatedly show that payments to a particular corridor are delayed at the same intermediary bank, the routing should be changed to avoid that bank. If traces repeatedly show that cover funds cannot be matched because the UETR is missing, the system should be fixed to carry the UETR on every message. If traces repeatedly show that a particular customer sends payments with wrong references, the customer should be contacted and the capture screen improved. The trace log is a source of operational intelligence, and the analyst who reads it will find the improvements that matter most. Worked example with real numbers: a bank in Frankfurt sends EUR 750,000 to a beneficiary in Toronto, and the payment needs two cover messages, because the amount is split between two correspondents for liquidity reasons: EUR 400,000 through a correspondent in New York, and EUR 350,000 through a correspondent in London. The Toronto bank receives the customer payment and both covers, matches them by UETR, and credits the beneficiary EUR 750,000. The reference reconciliation is the key: the two covers must be matched to the one customer payment, and the total of the covers must equal the customer payment, EUR 400,000 plus EUR 350,000 equals EUR 750,000, and if the total does not match, the payment is held. Failure and recovery: the multiple cover case fails when one cover arrives and the other does not, so the Toronto bank holds the customer payment, because it has EUR 400,000 of the EUR 750,000, and it does not know whether the remaining EUR 350,000 is coming. The recovery is to send pacs.009. A bank that does not reconcile the cover total against the customer payment total will credit the beneficiary EUR 400,000 and leave EUR 350,000 in suspense, which is worse, because the beneficiary is underpaid and the bank has money it cannot explain. The BA must require the total to be checked before the credit, because a partial credit is a payment that is wrong by the missing amount. For a business analyst, product owner or subject matter expert, the tracing requirement must name the multiple cover case, the matching rule by UETR, the total check, and the suspense handling for a partial cover. In ISO 20022 the covers are pacs.009 COVs, each carrying the same UETR, and the requirement must map the MT202 COV references to the pacs.009 COV references, so the matching survives migration. A tracing that checks only one cover is a tracing that will miss the second, and the test must include a payment with two covers, one of which arrives late.