How SWIFT Cross-Border Payments Work
When you send a payout via SWIFT, the funds do not travel in a straight line from sender to beneficiary. Instead, they move through a chain of correspondent banks — intermediary institutions that maintain account relationships with each other to facilitate international settlements. A payment from Singapore to Kenya, for instance, may pass through two or three correspondent banks before it reaches the beneficiary’s local bank. Each bank in this chain independently processes the payment, applies any required compliance checks, and forwards it to the next institution. This multi-hop structure gives SWIFT its global reach — enabling payments across 200+ countries and 150+ currencies — but it has historically made it difficult to know where a payment is at any given point in its journey.What Is SWIFT GPI?
SWIFT GPI (Global Payments Innovation) is a tracking and transparency layer built on top of the traditional SWIFT messaging network. Launched in 2017, GPI introduced a standardised way for every bank in a payment chain to report the status of a payment as it moves through them. Think of it as a courier tracking number for cross-border payments. Just as a parcel tracking system records each scan at every warehouse and delivery checkpoint, GPI records each processing event at each correspondent bank — giving you a real-time, hop-by-hop view of where your funds are.At the core of GPI is the UETR (Unique End-to-End Transaction Reference) — a UUID assigned to every SWIFT payment at the point of initiation. This reference travels unchanged through every bank in the chain and is the key that unlocks the full tracking timeline.
GPI Status Codes
As a payout moves through the correspondent banking chain, each bank updates its processing status. These updates are expressed as GPI status codes (also called reason codes). There are two layers of status codes:- Top-level codes indicate the overall state of the payment — whether it is in transit, delivered, credited, or has failed.
- ACSP sub-codes (G000–G004) provide additional detail about what is happening while the payment is in transit.
GPI State Transition Diagram
The diagram below illustrates how a SWIFT payment moves through GPI states, from initiation through to a terminal outcome.
- The payment always starts with a UETR assignment and enters the ACSP (in-progress) state.
- While in ACSP, the sub-codes G000–G004 describe what is happening at each hop.
- ACSC and ACCC are the two success terminals — ACSC means the beneficiary bank has received the funds; ACCC means the funds have been credited to the beneficiary’s account (the stronger confirmation).
- RJCT and CNCL are true terminal states — the payment will not progress further.
- PDNG is a transient hold, not a terminal state. A suspended payment may resume back into ACSP if the investigation clears, resolve directly to ACCC if approved, or end in RJCT if rejected.
- Solid arrows represent the normal payment flow. Dashed arrows represent exceptional or conditional paths.
Limitations of GPI Tracking
GPI significantly improves visibility into cross-border payments, but there are inherent constraints you should be aware of: 1. Tracking stops at non-GPI banks. If a correspondent bank in the payment chain is not a GPI member, it will not report a status update to the tracker. When this happens, the last known GPI status will be ACSP/G001, and no further GPI events will be received — even if the payment continues to move and ultimately succeeds. The payout’s lifecycle status on Tazapay (e.g., succeeded) remains the source of truth for the final outcome. 2. GPI tracking is additive — it does not change payout status. GPI events provide routing and transit visibility only. They do not alter the payout’s own status (processing, succeeded, failed). A payout can show ACSP/G001 as the final GPI state and still succeed. 3. Speed varies by corridor. While GPI has dramatically improved settlement times — with 90% of payments reaching the destination bank within one hour in major corridors — speed still depends on the banks involved, their operating hours, and local compliance requirements. Payments to lower-income countries or through regions with capital controls may take longer. 4. UETRs are required for tracking. If a UETR was not generated for a SWIFT payout (typically for older payouts), GPI tracking will not be available for that transaction. 5. Tracking service delays. If a correspondent bank’s reporting is delayed, there may be gaps in the GPI timeline. Tazapay retries automatically and emits the event once the update is confirmed.Typical Turnaround Times by GPI State
The following are general benchmarks based on SWIFT’s own reported data and industry norms. Actual times will vary by corridor, correspondent bank, and destination country.These timelines reflect GPI network benchmarks.
How to Track GPI Status on Tazapay
Tazapay surfaces GPI tracking data through two channels: the Dashboard (for manual lookup) and Webhooks (for programmatic, real-time updates).- Via the Dashboard
- Via the API (Webhooks)
You can view the full GPI tracking timeline for any eligible SWIFT payout directly from the Tazapay Dashboard.This section displays each GPI hop in reverse chronological order (most recent first), with the status label, reason code, a human-readable description, the BIC of the reporting bank, and the timestamp of each event.The examples below illustrate different GPI timeline patterns you may encounter in practice.
1
Open Payouts
Navigate to Payouts in the left sidebar.
2
Select a payout
Click on the payout you want to inspect.
3
View the GPI timeline
On the payout detail page, scroll down to the SWIFT GPI Tracking via UETR section.
Example 1 — Full tracking with successful credit (ACCC)
Example 1 — Full tracking with successful credit (ACCC)
This timeline shows a payment that was fully tracked end-to-end through GPI-enabled correspondent banks. Starting with ACSP/G000 (forwarded to intermediary bank ABSAZAJJXXX), the payment then progressed through ACSP/G002, ACSP/G003, and ACSP/G004 — each representing a processing step at a correspondent bank. The terminal event is ACCC: Funds credited to beneficiary account, which is the strongest confirmation that the payment has reached the beneficiary. This is the ideal GPI timeline: full hop-by-hop visibility from initiation to credit.
Example 2 — Partial tracking: non-GPI bank followed by re-entry into GPI network
Example 2 — Partial tracking: non-GPI bank followed by re-entry into GPI network
This timeline illustrates a common real-world scenario where the payment briefly exits the GPI network. The first event (ACSP/G001) shows the payment was forwarded to a non-GPI bank (CIBCCATTMPS), at which point tracking became unavailable. However, the payment subsequently re-entered a GPI-enabled segment of the chain — evidenced by the later ACSP/G000 events via SCBLUS33XXX, BOFAUS3NXXX, and TDOMCATTTOR — before reaching the terminal ACCC state. Note that a G001 event does not always mean tracking is permanently lost; it indicates tracking was unavailable at that specific bank. The payout succeeded regardless.
Example 3 — Tracking stops at a non-GPI bank (ACSP/G001 as final state)
Example 3 — Tracking stops at a non-GPI bank (ACSP/G001 as final state)
This timeline shows only a single ACSP/G001 event — the payment was forwarded to a non-GPI-enabled bank (NTBCLKLXXXX) and no further GPI updates were received. This does not mean the payment failed. The payout lifecycle status (visible at the top of the payout detail page) is the authoritative indicator of whether the payment ultimately succeeded or failed. When GPI tracking stops at G001, the payout status remains your source of truth.