Tracing a SWIFT Payment: UETR, gpi, and Where It Gets Stuck

When a SWIFT payment doesn’t arrive on time, the operator’s first instinct is often to call the bank and ask what happened. The bank’s answer — “we’re looking into it” — is not useful. The structured path is: obtain the UETR, read the gpi status, identify the stall category, and raise a formal case if the status doesn’t resolve. This article is that path.

The mechanics of how SWIFT payments are structured and what they cost are covered in SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained. For why payments arrive short and how charge instructions work, see OUR, SHA, and BEN: Why SWIFT Payments Arrive Short. This article covers the investigation layer: what the UETR is and how to use it, how to read gpi status codes, where payments get stuck, and how to get a resolution.

The UETR: Your Primary Diagnostic Key

Every cross-border SWIFT payment carries a Unique End-to-end Transaction Reference (UETR) — a 36-character UUID (Universally Unique Identifier) in the format of RFC 4122 UUID v4: eight hexadecimal characters, then four groups of four, then twelve, separated by hyphens (e.g. 5f4dcc3b-5aa7-459f-8914-e776856789ef).

The UETR lives in field 121 in Block 3 (the User Header block) of SWIFT FIN messages — MT103, MT103 REMIT, MT202, MT202 COV, and their variants. In ISO 20022 pacs.008 messages the UETR is a dedicated element (Payment Identification → UETR), distinct from the EndToEndId, which carries the originator’s customer reference. The UETR is generated by the ordering institution at payment initiation and must be passed through unchanged by every bank in the correspondent chain. No intermediary modifies it. This is what makes end-to-end tracking possible: the same identifier can be queried at any bank in the chain.

SWIFT made the UETR mandatory for all SWIFT users — not just gpi members — as part of Standards Release 2018, which went live on 18 November 2018. Before SR 2018, UETRs were only used by gpi member banks. After SR 2018, all SWIFT originators must generate a UETR, even if the receiving bank is not on gpi.

How to get the UETR for your payment:

1. At initiation: ask your bank to provide the UETR with the payment confirmation. If your treasury or payments platform supports SWIFT gpi for Corporates, the UETR may be surfaced directly in your dashboard.
2. After the fact: provide your bank with the payment reference (Field 20), value date, amount, and currency — they can retrieve the UETR from their gpi Tracker records.
3. If your bank cannot or will not provide the UETR, escalate — a UETR has existed on every SWIFT cross-border payment since November 2018 and must be in their system.

What the UETR unlocks: Once you have the UETR, your bank can query the SWIFT gpi Tracker and pull the full payment status history — every update from every bank that processed it, with timestamps and status codes. For banks not on the full gpi service, SWIFT’s Basic Tracker (available to all SWIFT customers since 2019) provides a lighter version of this visibility.

gpi and the Tracker: What It Guarantees and What It Doesn’t

SWIFT gpi (Global Payments Innovation), launched in 2017, added four commitments on top of the base SWIFT messaging infrastructure:

1. Same-day use of funds: gpi correspondent banks must credit the next institution in the chain within the value date, subject to cut-off times. This is a scheme obligation for gpi members, not just a target.
2. End-to-end tracking: every gpi payment gets a UETR, and every gpi bank in the chain must update the Tracker at each processing step.
3. Fee and FX transparency: correspondent banks must report fees deducted at their processing step, visible in the Tracker.
4. Remittance information carried unaltered: payment purpose and reference data must be passed through unchanged, not truncated by intermediaries.

By October 2024, SWIFT reported that 90% of cross-border payments on its network reach the destination bank within one hour — well ahead of the G20’s target of 75% credited to the end customer by 2027. But there is a gap: only 43% reach the end customer’s account within one hour, because the “last mile” from the beneficiary bank to the beneficiary account is subject to each bank’s own internal processing windows, compliance checks, and market-specific practices.

The coverage caveat: gpi’s guarantees apply within the gpi network. When a payment travels through a non-gpi correspondent (signalled by status code ACSP/G001), gpi obligations no longer bind that bank. Tracking updates may stop. Speed commitments do not apply. This is the most significant implementation gap in gpi: it only works end-to-end when every bank in the correspondent chain is a gpi member, which is not guaranteed for all corridors.

The Basic Tracker is available to all SWIFT customers, including non-gpi banks. It allows banks to confirm and track payment instructions manually. The full gpi Tracker with real-time per-hop status updates, fee transparency, and the gpi Observer monitoring service requires gpi membership. Corporate access to the gpi Tracker is available through the gpi for Corporates programme, either through a participating bank’s treasury API or directly via SWIFT’s gpi for Corporates API — implementation is bank-dependent.

Status Code Reference

gpi status codes are ISO 20022 ExternalPaymentTransactionStatus codes, used in the pacs.002 (Payment Status Report) message and surfaced through the gpi Tracker. The G-series sub-codes under ACSP are gpi-specific overlay codes providing more granular reason detail.

Note on G-series sub-codes: G000–G004 are widely implemented; G005 and G006 appear in PSP and API documentation (such as bank developer portals) rather than universally published SWIFT documentation, and must not be assumed as universal mandatory gpi statuses — exact sub-code coverage varies by bank and PSP Tracker integration. Verify with your bank which sub-codes their gpi Tracker implementation surfaces before relying on G005/G006 in operational runbooks.

Critical ACSP vs ACCC distinction for operators: ACSP means the beneficiary’s bank may have received the funds, but they have not been credited to the beneficiary’s account. Internal processing at the beneficiary bank — AML screening, account validation, manual review — can add hours or days after ACSP. ACCC is the only status that confirms the payment has reached the end recipient.

RJCT and return reason codes that operators encounter most frequently (includes rejection codes and return-flow codes such as FOCR, which appears on pacs.004 return messages following a cancellation):

What is not in this table: “Sanctions hold” and similar compliance reasons do not appear as formal reason codes in RJCT messages. A sanctions-blocked payment may sit in ACSP indefinitely or be returned with a generic code. Banks operating under sanctions compliance obligations may be legally prohibited from disclosing the specific reason for a hold. See the stall-points section below.

Triage Runbook: Payment Not Arrived

Use this sequence when a SWIFT payment has not credited by the expected value date.

Step 1 — Establish the timeline expectation. SWIFT payments on major corridors (USD, EUR, GBP, JPY) typically settle within one business day for gpi-enrolled chains. Emerging market corridors with fewer gpi banks and manual processing windows can take two to three business days. Before escalating, confirm whether the payment is actually late given the corridor, or whether you are escalating within normal processing time. If you are within the first business day, check the UETR status first before contacting the bank.

Step 2 — Obtain the UETR and pull the gpi status. Request the UETR from your sending bank. Ask specifically for the current gpi Tracker status, including all status updates and timestamps. If your platform supports it, pull directly from the gpi for Corporates interface. You want: (a) the current status code and sub-code, (b) the BIC of the last bank to update the Tracker, (c) the timestamp of the last update, (d) any fee deductions recorded at each hop.

Step 3 — Interpret the status.

• ACCC: Payment has been credited. Check that the beneficiary’s account details were correct. If the beneficiary says they have not received funds, the issue is internal to the beneficiary bank — the beneficiary should contact their bank directly.
• ACSP/G000 or ACSP/G005: Payment is moving normally through gpi banks. Wait for the next update.
• ACSP/G001 or ACSP/G006: Payment has exited the gpi network. You lose real-time visibility. Raise a bank enquiry — see Step 4.
• ACSP/G002: Payment is at a bank in manual review or pending credit. Note the BIC of the holding bank. If this persists beyond one business day past value date, raise a bank enquiry.
• ACSP/G003: Beneficiary’s bank needs documentation. Contact the beneficiary to provide their bank with whatever is required (commonly: source of funds declaration, invoice, purpose of payment).
• ACSP/G004: Cover payment hasn’t arrived. This is an interbank liquidity issue — escalate with your bank to confirm the cover leg is in transit.
• RJCT: Payment rejected. Obtain the full reason code from your bank. Act per the reason code table above.
• No status / no UETR findable: If your bank cannot locate a gpi status and the UETR has not been generated, the payment may not have left your bank yet — check their internal processing queues. If the UETR exists but no correspondent has updated it, the payment is stalled at or before the first correspondent.

Step 4 — Raise a formal bank enquiry if status is stalled. If the status has not changed for more than two business days past value date, ask your bank to initiate a formal case via SWIFT Case Management. Provide:

• UETR
• Sender’s Field 20 reference
• Value date
• Exact amount and currency
• Sender BIC and receiver BIC
• Last known status code and the BIC that reported it

Since November 2024, SWIFT’s Case Management uses structured camt messages: camt.110 for the initial claim / enquiry, camt.111 for the bank’s response. Prior to this, and at banks not yet using Case Management, enquiries are raised via MT199 (free-format SWIFT message) or the old MT195/MT192 system. The camt path resolves in days; MT199 enquiries typically take 5–10 working days.

Step 5 — Escalate if no resolution. If the enquiry yields no result within the timeframe your bank commits to, escalate through your relationship manager and request the case be raised to the gpi Observer team for SLA breach review. gpi member banks are subject to the gpi Rulebook SLAs monitored by the Observer; a documented breach is grounds for escalation. For non-gpi legs, the recourse is through standard banking complaint channels.

Where Payments Get Stuck: Six Stall Categories

Most SWIFT payment stalls fall into one of six categories. Each has a different detection signal and a different operator response.

1. Sanctions and Compliance Screening Holds

Every bank in the correspondent banking chain screens payment parties against sanctions lists (OFAC SDN, EU Consolidated, UK HMT, UN lists). Beneficiary name matches — even phonetic matches on common names — can trigger holds requiring manual adjudication. This is the stall type most invisible to operators.

Detection signal: ACSP/G002 (pending credit, manual review) or a payment that stops updating at a specific correspondent BIC. A payment that has been in ACSP at the same bank for more than 48 hours warrants an enquiry.

What banks will and won’t tell you: Banks operating under sanctions compliance programs may be legally prohibited from disclosing that a specific payment is subject to a sanctions review, and they are prohibited from “tipping off” a subject. Expect to receive limited information: you may only be told the payment is “under review” without specifics. This is a legal constraint, not bank obstruction.

Operator action: Confirm your payment details contain accurate, unambiguous beneficiary information. If the beneficiary name is a common name in a sanctions-dense corridor, ask your bank to pre-screen the payment. Ensure structured addresses per ISO 20022 requirements — unstructured or truncated addresses increase false-positive screening rates.

Timeline impact: Routine compliance holds are typically resolved in 1–3 business days. Complex cases involving true-positive matches or requests for source-of-funds documentation can take 2–4 weeks. Manual compliance review at a single correspondent can hold up the entire chain.

2. Intermediary Bank Fee Deductions and Short Arrivals

Under SHA charge instructions (the market default), each correspondent bank deducts its transit fee from the payment principal before forwarding. This does not stall the payment, but it means the recipient receives less than instructed — which can cause the recipient to report the “wrong” payment amount or fail auto-reconciliation.

Detection signal: ACCC status achieved (payment delivered), but recipient reports non-receipt or a short credit. Check the fee transparency data in the gpi Tracker: each gpi bank is required to report deductions at its processing step.

Operator action: Specify OUR charge instruction at payment initiation to prevent deductions. For retrospective analysis, pull the fee data from the gpi Tracker or request a fee breakdown per hop from your bank. For the full mechanics of OUR, SHA, and BEN, see OUR, SHA, and BEN: Why SWIFT Payments Arrive Short.

3. Cut-off Times and Value Date Misses

SWIFT messages arrive in seconds. The processing of those messages does not. Every bank in the chain has business-hours processing windows and cut-off times after which a payment instruction received that day will not be processed until the next business day. A payment that arrives at a correspondent bank at 4:30 PM local time on a Friday — after their Thursday/Friday cross-currency processing cut-off — may not move until Monday.

Detection signal: Payment leaves your bank but stops updating for 24+ hours without a G002 hold status. Check the timestamp of the last UETR update against the processing bank’s local business hours and known cut-off times.

Bank-dependent factor: Cut-off times are set by each individual correspondent bank and are not published in a standard format. Major US and European banks publish cut-off guidance for key currency pairs, but intermediary banks on less-traveled corridors may not. Your sending bank’s correspondent banking team should know the cut-off windows for the chains they use.

Operator action: For time-sensitive payments, submit before 11 AM in the sending bank’s timezone to maximize the probability of same-day processing through the correspondent chain. For corridor-specific cut-off guidance, ask your bank’s treasury services team.

4. Nostro/Liquidity and Correspondent Chain Gaps

A correspondent bank can only forward a payment if it has sufficient balance in its nostro account at the next bank in the chain. Insufficient nostro liquidity — more common during high-volume periods, around month-end, or in less-liquid currency corridors — causes a hold until the correspondent can fund its position.

Detection signal: ACSP/G004 (waiting for cover payment) or ACSP/G002 at a non-compliance-intensive correspondent. The G004 code specifically flags that the debit instruction outran the liquidity cover.

Operator action: For payments that regularly stall on a specific corridor, ask your bank whether they have a direct nostro relationship for that currency pair, or whether the payment routes through a longer chain with less frequent settlement windows. For multi-currency treasury architecture and how to optimize corridor selection, operators should understand whether their payment volume justifies a bank that maintains direct nostro positions in the target currency.

Bank-dependent factor: Nostro liquidity is entirely bank-side infrastructure. Operators cannot directly observe or influence it. The only lever is bank selection and corridor routing.

5. Formatting, Truncation, and Data Quality Issues

Pre-November 2025, the SWIFT network ran on MT message formats with constrained field lengths — the MT103 free-text remittance field was limited to approximately 140 characters across four lines. Beneficiary name, address, and purpose details could be truncated or transformed as messages moved through the chain.

Post-November 2025, cross-border SWIFT traffic runs on ISO 20022 pacs.008 messages with richer structured fields. But the migration has not eliminated data quality problems — it has shifted their form. Key issues post-migration:

• Truncation during coexistence: Banks and corporates still at different stages of ISO 20022 implementation may inject truncated or legacy-format data into pacs.008 fields.
• Unstructured addresses: Fully structured postal addresses are required in CBPR+ messages; from November 2026 unstructured addresses are forbidden. Until then, unstructured address data increases compliance screening false-positive rates and can trigger NOAS (no answer from customer) or RR03 (missing creditor name/address) rejection codes.
• Field translation errors: MT-to-MX translation at banks still running legacy systems can drop or corrupt structured remittance data, causing auto-matching failures at the recipient.

Detection signal: RJCT with codes RR03 (missing creditor details), BE01 (beneficiary name mismatch), or AC01 (invalid account). Also: ACSP payments that stall at a correspondent known for manual processing, where investigation reveals the issue was unrecognized data.

Operator action: Ensure your payment initiation system sends fully structured ISO 20022 data — structured beneficiary name, structured postal address, Legal Entity Identifier (LEI) where applicable. For high-volume payment operations, verify with your bank that their outgoing MT-to-MX translation preserves your structured fields. For the exact field-by-field mapping between MT103 and pacs.008 — including where :72: free-text content ends up and how EndToEndId NOTPROVIDED artifacts enter the chain — see the MT103 to pacs.008 field mapping reference.

6. Non-gpi Legs and Corridor Gaps

gpi SLA obligations only bind enrolled gpi banks. A payment that routes from a gpi bank to a non-gpi correspondent enters a zone where: tracking updates may stop, same-day credit is not guaranteed, fee transparency is not required. This is signalled by ACSP/G001.

Detection signal: ACSP/G001 — payment has been forwarded to a non-gpi bank. Tracking visibility effectively ends here for the operator.

Operator action: Ask your bank which correspondents they use for the target corridor and whether those correspondents are gpi members. For critical payment corridors, preference banks with full gpi-enabled correspondent chains. For a corridor-by-corridor comparison of SWIFT gpi against alternative rails, see SWIFT gpi vs Local Rail Interconnects.

What to Ask Your Bank

When a payment investigation is necessary, structured requests get faster answers. Here is the information to request:

Immediately:

• The UETR for the payment
• The current gpi Tracker status, including all status updates with timestamps and the BIC of each reporting bank
• Whether the payment has exited the gpi network (ACSP/G001 at any hop)
• The value date that was instructed vs. the value date processed at each correspondent

If the payment is stalled:

• The BIC and name of the bank last holding the payment
• The specific reason for the hold (as much as the bank can disclose — compliance restrictions may limit this)
• The current case reference if an enquiry has been opened
• The expected resolution SLA your bank is committing to
• Whether a formal camt.056 recall or camt.110 exceptions enquiry has been raised

If the payment was rejected:

• The full RJCT reason code(s)
• The return path — has a pacs.004 return already been sent?
• Whether funds have been returned and their expected credit date to your account

If the payment arrived short:

• The fee breakdown per correspondent leg from the gpi Tracker
• The charge instruction used (OUR/SHA/BEN — MT103 field 71A or pacs.008 ChrgBr)
• Whether any FX conversion occurred at a correspondent and at what rate
• The receiving bank’s incoming wire fee (this is separate from SWIFT correspondent fees and not covered by OUR)

For ongoing operations:

• Ask your bank whether your payment portal or TMS can be configured to surface the UETR at initiation and receive real-time gpi status updates via the gpi for Corporates API
• Request a list of the correspondent banks your bank uses for each active currency corridor — knowing whether those correspondents are gpi members directly affects your expected tracking visibility

What Is Bank-Dependent vs Scheme-Mandated

Understanding the boundary between what is guaranteed by the gpi Rulebook and what is implementation-specific prevents misdirected escalation.

Scheme-mandated (applies to all gpi member banks):

• UETR mandatory on all cross-border SWIFT messages since November 2018 (SR 2018), for gpi and non-gpi banks alike
• gpi member banks must update the Tracker at each processing step
• Same-day credit obligation applies to gpi members within gpi SLA corridors
• Fee transparency reporting required from gpi members
• Remittance information must be passed unaltered by gpi members

Bank/implementation-dependent:

• Whether corporate clients can access the gpi Tracker directly (requires gpi for Corporates implementation by their bank)
• The correspondent chain used for a given corridor — your bank chooses its correspondents
• Whether those correspondents are gpi members
• Cut-off times per correspondent
• The amount of detail disclosed to operators about compliance holds
• Whether your bank’s outgoing payments platform exposes the UETR at initiation
• How quickly your bank acts on a case enquiry (gpi Rulebook sets an SLA; enforcement is through the Observer)
• The OUR surcharge your bank charges for collecting correspondent fees on your behalf

Not changed by gpi or ISO 20022:

• FX markup — still determined by individual bank treasury pricing
• Total settlement cost — still the sum of correspondent fees plus FX spread
• Fundamental settlement speed for non-gpi corridors
• The mechanics of charge instructions (OUR/SHA/BEN) — these work the same in ISO 20022 as in MT103, just in the ChrgBr field rather than field 71A

---

The structural improvement gpi brought to SWIFT payments — end-to-end tracking, fee visibility, same-day credit obligations — is real. But it is only as strong as the weakest link in the correspondent chain. For payment operations teams, the practical posture is: capture the UETR at initiation, monitor gpi status proactively on any payment past value date, and know in advance which corridors have full gpi coverage and which do not. The investigation process is faster and more structured than it was before gpi — but it still requires knowing what to ask, whom to ask, and what the status codes actually mean.

Scope note

• Primary sources: SWIFT documentation on gpi, the Tracker, UETR, ISO 20022, and Case Management, plus PSP gpi API references. Full citations are listed under Sources below.
• Standards-backed: the UETR format and its mandate (Standards Release 2018), the four gpi commitments, the ISO 20022 status codes (ACSP, ACCC, ACSC, RJCT), and the October 2024 SWIFT speed figures.
• PSP/operator-documented: the ACSP G-series sub-codes — G000–G004 are widely documented, while G005 and G006 appear in PSP and API documentation rather than universal SWIFT publications and should not be assumed as mandatory gpi statuses.
• Indicative, not fixed: sanctions and compliance hold durations are bank-dependent ranges; correspondent chains, cut-off times, and last-mile crediting times vary by bank and corridor.
• Verify with your bank or PSP: which gpi sub-codes their Tracker surfaces, the cut-off times for your corridors, and whether the correspondents they route through are gpi members.

Related references

• SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained — message structure, field anatomy, and the ISO 20022 migration.
• OUR, SHA, and BEN: Why SWIFT Payments Arrive Short — charge instructions, correspondent deductions, and short-arrival reconciliation.
• SWIFT gpi vs Local Rail Interconnects — when to route cross-border over gpi versus local instant rails.
• Multi-Currency Treasury Architecture for Payment Operators — nostro positioning, corridor selection, and settlement-cost control.

For term definitions — SWIFT, correspondent banking, FX markup — see the Payments Glossary.