SWIFT gpi Tracker and UETR Statuses: ACSP, G000 to G004, ACCC, RJCT

The SWIFT gpi Tracker is a central record of every leg of a cross-border payment, keyed on the UETR. Each bank reports one of three statuses: ACSP (in progress, with a reason code from G000 to G004 saying why), ACCC (the beneficiary’s account is credited), or RJCT (rejected). Read the last event, see which agent holds the UETR, and you know where the money is before anyone writes an email.

Before gpi, “where is my payment?” meant an MT 199 to the next bank, a wait, another MT 199 to the bank after that, and a client on the phone for three days. The gpi Tracker replaced that chain of questions with one lookup. For an analyst, it is also the best free observability tool in correspondent banking: a timestamped, per-agent log of every hop, which you can read through an API.

This article sits in the status and reason codes section of The ISO 20022 Reference, next to ISO 20022 payment status codes. That article covers the full status ladder. This one covers the subset the Tracker uses, how it gets updated, and how to investigate with it.

What is SWIFT gpi, and what does the Tracker record?

SWIFT gpi (global payments innovation, now branded Swift GPI) is a set of rules and cloud services for cross-border payments. The rules cover speed, fee transparency, and confirmation of credit. The services cover the Tracker, the Directory of members, the Observer that monitors compliance with the rulebook, Stop and Recall, and the corporate services. SWIFT reports that nearly 60% of GPI payments reach the end beneficiary within 30 minutes and almost all within 24 hours.

The Tracker is the core. It holds one record per UETR (unique end-to-end transaction reference, the UUID version 4 that rides on the payment from first bank to last). Against that record it stores an event for each leg: who sent it, who received it, when, the amount, any charges deducted, any FX applied, and the status that agent reported.

Two things make it useful beyond gpi members:

1. Universal confirmations. Since 22 November 2020, every supervised financial institution or payment system participant that receives an MT 103 or pacs.008 must confirm the outcome to the Tracker: credited, on hold, or transferred onward. So even a non-gpi beneficiary bank leaves a footprint.
2. The UETR is first-class in ISO 20022. In a pacs.008 it is PmtId/UETR, a schema element rather than a header field. That is why identifier handling matters so much: a UETR that is dropped or regenerated at one hop splits one payment into two Tracker records, and the investigation trail dies at that bank.

What do the Tracker statuses mean?

The Tracker uses three transaction statuses from the ISO 20022 code set. The interesting information is in the reason code attached to ACSP.

Status	Reason	What the reporting bank is saying	Further update?
ACSP	G000	I passed the payment to the next agent or market infrastructure, and that transfer is tracked	Not from me
ACSP	G001	I passed the payment on, but the onward leg is not tracked	Not from me
ACSP	G002	Credit to the creditor’s account may not be confirmed today	Yes, from me
ACSP	G003	Credit is pending documents I have requested from the creditor	Yes, from me
ACSP	G004	Credit is pending: I am waiting for funds provided via a cover	Yes, from me
ACCC	none	Settlement completed on the creditor’s account	Final
RJCT	reject reason	The payment is rejected, with a reason code such as AC04 or BE01	Return follows

Current as of October 2026, the ISO 20022 external status reason code set (2Q2026 release) also defines G005 and G006 (delivered to the creditor agent with or without service level) and G007 and G008 (passed on, or received, via a payment market infrastructure). The GPI API’s status update operation accepts G000 to G004, so those five are the ones you will see in most Tracker work.

Three readings matter in practice.

ACSP is never “done”. A payment can carry four ACSP events, one per agent, and still be sitting at the last one. ACCC is the only status that means the beneficiary has the money. If your client portal maps ACSP to “completed”, you have shipped the ACSP versus ACSC mistake described in the status codes reference, with a correspondent bank in the middle.

G000 versus G001 tells you where visibility ends. G000 means the next hop is tracked, so the next event should appear. G001 means the payment left the tracked world, typically into a domestic clearing system or a non-gpi bank. After G001, silence is expected, and your investigation moves from the Tracker to the beneficiary bank.

G002, G003, and G004 are promises. Each one says the reporting bank will update again. A G003 that is three days old without a follow-up is a broken promise and a legitimate escalation. A G004 points at cover payment mechanics: the beneficiary bank received the pacs.008 but the pacs.009 COV carrying the funds has not arrived, so the next question is about the cover leg, not the customer leg.

RJCT always carries a reason from the external reject set, which is where the reason codes reference takes over. A rejection after settlement turns into a return (pacs.004), and the Tracker shows the return as its own leg linked to the same UETR.

How is the Tracker updated?

Payment legs sent over the SWIFT network reach the Tracker automatically. The status confirmations do not: each bank has to send them. SWIFT’s universal confirmations page lists three channels.

Channel	What it is	Status as of October 2026
trck.001	ISO 20022 XML message to the Tracker, published in MyStandards	The current message channel
GPI API	REST call to the Tracker, through the Swift Microgateway or SDK	Current, OpenAPI specification on the Swift Developer Portal
MT 199	Formatted MT 199 to the Tracker BIC (TRCKCHZZ in production)	Deprecated since November 2025: still accepted, no new functionality

A point that confuses many teams: a pacs.002 is not a Tracker update. The pacs.002 is the bilateral status report you send back up the chain to the bank that instructed you. If you reject a pacs.008, you send the pacs.002 RJCT to your counterparty and also confirm RJCT to the Tracker through one of the channels above. Specify both, or your rejection is invisible to every other bank and to the originator’s client looking at a GPI screen.

Here is the shape of an API status update, based on the request samples in the GPI Customer Credit Transfer API reference. It is simplified: take the full schema, including the instructed agent and charges objects, from the OpenAPI specification.

PUT /payments/{uetr}/status

{
  "from": "BANKGB2LXXX",
  "transaction_status": "ACSP",
  "transaction_status_reason": "G000",
  "transaction_status_date": "2026-10-09T09:02:11.000Z",
  "tracker_informing_party": "BANKGB2LXXX",
  "instruction_identification": "TRF-20261009-0042",
  "service_level": "G001",
  "payment_scenario": "CCTR"
}

Note the two different G001s. service_level: G001 is the gpi customer credit transfer service level code. transaction_status_reason: G001 is “passed on, not tracked”. Same four characters, different code sets. I have seen a mapping table conflate them, and the result was every payment reported as untracked. That is a test case.

One timing note. SWIFT’s 21 September 2026 update on Standards Release 2026 moved the deferred release, which includes Tracker messages, to 12 June 2027. If your project planned a Tracker message change for November 2026, re-baseline it.

How do you read the Tracker from your own systems?

The GPI Transaction Details API (v6.0.1 live as of October 2026) exposes two reads.

• GET /payments/{uetr}/transactions returns the payment and its events for one UETR: transaction_status, initiation_date_time, completion_date_time, last_update_date_time, and a payment_event array with one entry per leg or status update.
• GET /payments/changed/transactions is a delta query: every payment updated since from_date_time, filtered by payment_scenario (CCTR for customer credit transfers, COVE for cover payments, FCTR for FI transfers, CTCN and FTCN for cancellations), paged with a next token, and limited to 124 days of history in live.

The delta query is the one to design around. Polling one UETR per customer enquiry works for a support screen. Keeping a local copy of Tracker state, so operations can query “every payment older than 24 hours still in ACSP”, needs the delta feed into your own store. Once Tracker events sit next to your own payment records, stuck payments become a SQL query instead of a phone call.

The v6 contract renamed the event-level fields (transaction status, reason, and reject reason became event status, event status reason, and so on). If you inherited an integration built on an older version, check which names your parser expects before blaming the data.

What is Stop and Recall?

Stop and Recall is the gpi service for cancelling a payment in flight. The sending bank sends a cancellation request (camt.056, or the MT 192 equivalent where still used) to the Tracker BIC instead of only to the next bank. The Tracker blocks the UETR so gpi banks stop processing it, notifies every agent in the chain at once, and records each answer.

The difference from the old serial recall is speed. A fraud recall that hops bank to bank by message can take a day to reach the bank holding the funds. Stop and Recall reaches all of them in one step, which is the whole game when, as the returns, reversals, and recalls article puts it, recovery odds fall every hour.

Stop and Recall is now one of the two services in SWIFT’s Case Management. SWIFT’s plan is that from November 2027 every payment cancellation, for all underlying transaction types, goes through Stop and Recall in ISO 20022 format only (camt.056 and camt.029). The full timeline and the investigation messages that replace MT 199 queries are in CBPR+ exceptions and investigations.

Walkthrough: a payment stuck at an intermediary

A corporate client paid a supplier in Jakarta: USD 48,500, sent on Monday morning. On Tuesday afternoon the supplier says nothing has arrived. Here is how I work it, Tracker first.

Step 1: get the UETR. From the client’s pain.001 status report or from your outbound pacs.008. If the client gives you only an amount and a date, find the payment in your own records first; never search the Tracker by amount.

Step 2: read the events. GET /payments/{uetr}/transactions returns:

Time (UTC)	From	To	Status	Reason	Note
Mon 08:14	Your bank	US correspondent	ACSP	G000	Sent, tracked
Mon 08:31	US correspondent	Regional intermediary	ACSP	G000	Sent, tracked, USD 25 deducted
Mon 08:32	Regional intermediary				Leg received, no status since

Step 3: identify who holds the UETR. The regional intermediary received the payment 30 hours ago and has reported nothing. It is gpi and it is subject to universal confirmations, so silence is itself a finding.

Step 4: rule out your own causes. Check what you sent: the agent chain (is the intermediary agent the one your routing table intended?), the creditor agent BIC, the creditor address, the remittance field. A compliance hold at the intermediary often follows a screening hit on something you sent. If the creditor name or address is weak, expect an RFI rather than a credit.

Step 5: check charges and amount. The US correspondent deducted USD 25. If your client instructed OUR, that deduction is a separate problem, covered in charges, and worth logging now.

Step 6: ask the right bank the right question. You are not asking the beneficiary bank anything yet: it may never have seen the payment. You open a case against the intermediary, by UETR, through your investigations channel. On Case Management that is a camt.110 investigation request; in many banks, today, it is still an MT 199. Either way the question is specific: “UETR received Monday 08:32 UTC, no status since, please confirm status and expected action.”

Step 7: tell the client the truth. “Your payment left us Monday morning and reached an intermediary bank in the region, which has not yet processed it. We have opened an enquiry with that bank.” Not “it has been sent and should arrive shortly”. The Tracker gives you a specific, honest answer. Use it.

If the answer comes back ACSP/G003, the intermediary is waiting for documents, usually from a compliance enquiry, and the action moves to your client. If it comes back ACSP/G004 at the beneficiary bank instead, look for the cover leg. If it comes back RJCT, the return will follow and the failed payment investigation playbook applies.

The domain grounding behind walkthroughs like this one, correspondent chains and the messages that carry them, is in Break Into Banking, and the API test design for the Tracker integration below is covered in API Testing and QA Mastery for BAs.

What should an analyst specify for a Tracker integration?

Seven requirements cover most of it.

1. The UETR is generated once, at origination, and never regenerated. Inbound payments keep the UETR they arrived with on every onward leg, including returns.
2. Every received pacs.008 produces a Tracker confirmation, through a named channel (trck.001 or API), within the universal confirmations rulebook deadline.
3. Status mapping is explicit. Internal status to Tracker status and reason, in a table with an owner, including RJCT with the reject reason.
4. ACCC is sent when the creditor’s account is credited, not when the payment enters your books or passes screening.
5. G002, G003, G004 have a follow-up obligation. The system tracks open promises and alerts when a follow-up is overdue.
6. The delta feed is ingested into a local store, with the 124-day history limit understood for replays.
7. Customer channels render statuses honestly. ACSP is “in progress”, G003 is “waiting for information”, ACCC is “credited”.

What should you test?

#	Case	Expected result
1	Inbound pacs.008 credited to customer	ACCC sent to Tracker, UETR unchanged
2	Inbound pacs.008 forwarded to next agent over SWIFT	ACSP/G000 with the correct instructed agent
3	Inbound pacs.008 forwarded into a domestic clearing	ACSP/G001
4	Payment held for documents	ACSP/G003, then ACCC or RJCT when resolved, follow-up alert if overdue
5	Credit waiting for the cover pacs.009 COV	ACSP/G004, then ACCC when cover arrives
6	Inbound payment rejected	pacs.002 RJCT to the instructing agent and RJCT with reason to the Tracker
7	Status update for an unknown UETR	API error handled, alert raised, no silent drop
8	Service level G001 versus reason G001	Mapping keeps the two code sets apart
9	Return of a credited payment	Return leg linked to the original UETR
10	Stop and Recall received for a UETR in progress	Processing blocked, camt.029 answer sent
11	Delta query paging	All pages consumed via next, no duplicates in the local store
12	Customer screen for a payment in ACSP/G000	Shown as in progress, never as completed

Case 8 looks pedantic until it fails in production.

If you want to practise reading a payment API contract and spotting the status mapping gaps before they ship, the Analyze a Payment API lab is the same skill on a smaller system.

The takeaway

The gpi Tracker gives every cross-border payment a timestamped trail per agent, keyed on the UETR. ACSP means in progress and its G code says why, ACCC means credited, RJCT means rejected. Update it through trck.001 or the API, not just by sending a pacs.002 to your counterparty. Read it through the delta feed so stuck payments become a query. When a payment stalls, find the agent holding the UETR, read the reason code, and ask that bank a specific question.

Next, CBPR+ exceptions and investigations covers what happens after the Tracker tells you something is wrong: the camt.110 and camt.111 messages, Case Management, and the November 2027 deadline. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, SWIFT gpi, Payments, UETR, Investigations