SWIFT gpi: what it is and how it changed tracking

SWIFT gpi, which stands for Global Payments Innovation, is a service launched by SWIFT in 2017 that transformed cross border payments by making them faster, more transparent and trackable. Before gpi, a cross border payment was a black box. The sender knew the payment had been sent, the beneficiary knew it had arrived, and nobody in between knew where it was or how much had been deducted. gpi changed that by requiring participating banks to follow a set of rules, to process the payment on the same day, to provide a status update, to confirm the credit to the beneficiary, and to make the payment trackable through a central tracker. Today most cross border payments travel on gpi, and the tracker is the standard tool for answering the question that every customer asks, where is my money. The payment itself still travels through correspondent banking and through the existing SWIFT messages, but the banks that handle it must follow the gpi rules. They must send the payment promptly, they must not deduct charges without disclosing them, they must confirm when the beneficiary has been credited, and they must update the tracker at each step. The tracker is a central service operated by SWIFT that collects the status updates from each bank and presents them in a single view, so that the sending bank, and the customer if the bank offers the service, can see the payment moving from bank to bank in real time. This is a major improvement over the old world, where tracing a payment meant sending a SWIFT query and waiting days for a reply. The gpi rules are specific and the analyst should know them. A gpi bank must process a payment on the same day it is received, must not deduct charges without disclosing them in the tracker, must send a status update when it forwards the payment, and must confirm when the beneficiary has been credited. The status updates use standard codes: ACSP means accepted settlement in process, ACSC means accepted settlement completed, ACCC means accepted credit completed, and RJCT means rejected. These codes are carried in the pacs.002 payment status report and in the tracker, so that the sending bank and the customer see the same status. A bank that does not follow the rules can be reported to SWIFT, and repeated failure can lead to suspension from gpi. The impact of gpi on the customer experience is significant. A customer who sends a payment can now see that it has been received by the intermediary bank, that it has been forwarded, and that it has been credited to the beneficiary, with timestamps at each step. A customer who is waiting for a payment can be told exactly where it is, instead of being told that it is in transit. An operations team that handles exceptions can see where a payment is stuck and can contact the right bank, instead of sending a query to every bank in the chain. A business analyst who works on cross border payments must understand gpi as a service level, not as a technology. The technology is the tracker, but the value is the commitment by banks to process quickly, to disclose charges, and to confirm credit. gpi also changed the economics of cross border payments, because it made the charges visible. Before gpi, an intermediary bank could deduct a charge without telling anyone, and the beneficiary would receive less than expected with no explanation. Under gpi, each bank must disclose the charges it deducted in the tracker, so that the sending bank can see the full cost and the customer can be told. That transparency has put pressure on charges, and has made it harder for banks to hide fees in the chain. The analyst should use the gpi charge data to review the cost of each corridor, to identify banks that charge more than their peers, and to renegotiate or reroute where the charges are excessive. gpi tracks the payment, but it does not move the money, and it does not guarantee that the payment will arrive on a particular day. A gpi payment can still be delayed by a compliance query, by a nostro liquidity problem, or by a bank that is slow to process. gpi covers the banks that have signed up, which is most large banks, but not every bank in every country, so a payment to a small bank in a remote market may not be tracked end to end. And gpi tracking is only as good as the status updates that banks send, so if a bank fails to update the tracker, the payment will appear stuck even though it has moved. The analyst must therefore treat the tracker as a tool, not as a guarantee, and must have a fallback process for payments that are not tracked. For a system design, gpi requires the following: the payment engine must generate a UETR for every cross border payment and carry it in the pacs.008; the engine must send status updates to the tracker at each step, using the pacs.002 message; the engine must receive status updates from other banks and store them; the customer portal must display the tracker view, with the status, the timestamps, and the charges deducted at each step; and the operations team must have access to the tracker so that they can answer customer queries without sending a SWIFT message. The analyst must specify each of these, and must test that the tracker view matches the actual status of the payment, because a tracker that shows the wrong status is worse than no tracker at all. The future of gpi is towards instant cross border payments, with SWIFT working on services that combine gpi tracking with faster settlement, including the ability to pre validate the beneficiary account before the payment is sent, and to confirm the credit in seconds rather than hours. The analyst should follow these developments, because they change the customer promise. A payment that is pre validated, tracked in real time, and confirmed in seconds is a different product from a payment that takes three days and cannot be traced. The analyst who understands gpi today will be able to design the instant cross border payment product of tomorrow.