What a UETR is
UETR stands for Unique End-to-end Transaction Reference. It is a 36-character identifier, generated when a payment is first created, that travels unchanged with the payment through every bank it touches. It follows a standard format known as a UUID: 32 hexadecimal characters split into five groups by hyphens.
An illustrative UETR looks like this: 3f2a9c14-7b6e-4d1a-9e2f-8c5b0a7d6e31. The exact characters are random. What matters is that no two payments share one, and that every bank in the chain can look it up.
Before UETRs, each bank in a chain tended to assign its own transaction reference. Chasing a payment meant asking bank A for its reference, then asking bank B to find the payment using that reference, and so on. Mismatched references were a common reason for slow investigations. The UETR solves that by giving everyone the same key.
How SWIFT gpi tracking works
SWIFT gpi, the global payments innovation service, sets rules for banks that join it. Among other things, gpi banks commit to update a central tracker as they process each payment. When a bank receives a gpi payment, it records what it did: passed it on, credited it, rejected it or put it on hold. Where charges are deducted, those are recorded too.
The ordering bank, and in many cases the payer through their provider's tools, can query the tracker with the UETR and see the payment's path. A typical view shows each bank in the chain, the time it received the payment, its status, and the amount and currency at each step.
Tracking is only as complete as the banks involved. If a payment passes through a bank that does not participate in gpi, the trail may go quiet at that point. The tracker will usually show that the payment was sent to a non-gpi bank, and after that the picture depends on what the remaining banks report.
What the status updates mean
Tracker statuses use ISO 20022 codes. The labels you see in a provider's portal may be friendlier, but they usually map to a small set of standard codes. The common ones are below, in plain terms.
| Code | Meaning in plain terms | What to do |
|---|---|---|
| ACSP | Accepted and in progress. A bank has the payment and is processing it. | Check the reason code and which bank last updated. |
| ACSP with G000 | Passed on to the next bank, which is a gpi member. | Normal. Wait for the next update. |
| ACSP with G001 | Passed on to a bank that does not report to the tracker. | Further visibility may be limited. Allow for a slower trail. |
| ACSP with G002 | Credit to the beneficiary may not be same day. | Often a timing or batching issue at the receiving bank. |
| ACSP with G003 | Credit pending documents or more information. | A query is likely on its way. Prepare documents. |
| ACSP with G004 | Pending receipt of funds, often cover funding. | Usually a settlement step between banks. |
| ACCC | Credited to the beneficiary's account. | The payment has arrived. Ask the beneficiary to check. |
| RJCT | Rejected by a bank in the chain. | Find out why and expect the funds to return. |
Banks may use additional codes and the exact presentation varies, so treat the table as a general guide. The two most useful facts on any tracker are the last bank to update and the time of that update.
Reading a trace
Here is an illustrative trace for a euro payment from Canada to a supplier in Poland.
- Monday 15:10 Pacific time: ordering bank sends the payment. Status ACSP, G000.
- Tuesday 08:40 Central European time: euro correspondent receives it, passes it on. Status ACSP, G000. A small charge is recorded.
- Tuesday 11:15 Central European time: beneficiary bank receives it. Status ACSP, G002.
- Tuesday 14:30 Central European time: beneficiary bank credits the account. Status ACCC.
Reading it, you can see the overnight gap caused by time zones, the deduction taken by the correspondent and a short wait at the receiving bank before credit. If the supplier says on Tuesday afternoon that nothing has arrived, you can tell them the credit time and the amount credited, and ask them to check with their bank.
Credited but the beneficiary cannot see it
An ACCC status means the beneficiary bank has reported the funds as credited. If the beneficiary insists they have not arrived, the usual reasons are mundane.
- The beneficiary is looking at the wrong account, often a different currency account at the same bank.
- Their bank has credited the funds but not yet updated online banking or statements.
- The amount is lower than expected because of deductions, so they have not recognised it.
- The reference was truncated and their accounts team cannot match the payment.
Send the beneficiary the UETR, the amount credited, the value date and the credit time from the tracker. Ask them to give those details to their own bank. Their bank can find the payment in seconds with that information.
What to ask for when a payment is late
A payment is late when it has passed the point at which it would normally be credited for that corridor. Before chasing, check the obvious: cut-off times, public holidays in the currency's home market and at both ends, and whether the payment was released when you thought it was.
If it is still late, ask your provider for specific information rather than a general update.
- The UETR and the full tracker history.
- The last bank to update, and its status and reason code.
- Whether any bank has raised a query or request for information, and its exact wording.
- Whether the payment passed through any bank outside gpi.
- The amount and currency at each step, to see where any conversion or deduction happened.
If a bank in the chain has gone quiet, your provider can ask its bank to send a status enquiry to that institution, using the UETR. That is a formal request and tends to get a better response than an informal chase.
What not to do
A few instinctive reactions to a late payment make things worse.
- Do not send a second payment to cover the first. If the original arrives, you have paid twice, and recovering the duplicate is slow and not guaranteed.
- Do not change the beneficiary details while a payment is in flight because someone suggests the account was wrong. Confirm through a known contact first. Fraudsters exploit delays.
- Do not ask for a recall just because a payment is slow. A recall request can complicate an investigation and may not succeed. The guide to payment returns and recalls explains why.
Keep the UETR in your own records
Treat the UETR as part of the payment record, alongside the amount, date, beneficiary and invoice number. Store it in your accounting system or payment log. When a supplier queries a payment months later, or an auditor asks for evidence, the UETR and the confirmation are what prove the payment was made and where it went.
If you send a large number of payments, ask whether your provider's confirmations or export files include the UETR as a field. That makes it easy to match tracker data to your own ledger.
Where payments usually stall
Over time, operations teams learn that payments stall in a small number of places, and each leaves a recognisable mark on the tracker.
- At the first correspondent. The tracker shows the payment sent by the ordering bank but no update from the correspondent for a long time. This often means a screening alert or a query is being worked on.
- At a non-gpi bank. The last status shows the payment passed to a bank that does not report. The trail goes quiet. That alone does not signal a problem, but it limits what you can see.
- At the beneficiary bank, pending documents. A G003 type status, or a long wait after receipt, suggests the receiving bank wants more information, sometimes from the beneficiary rather than the payer.
- At the beneficiary bank, pending credit. The payment has arrived, but the bank credits incoming payments in batches or checks names manually before applying them.
Knowing which of these you are looking at tells you whom to ask. A stall at the beneficiary bank is often cleared fastest by the beneficiary calling their own bank, while a stall at an intermediary needs to go through your provider.
What to send a beneficiary who is chasing
When a supplier or partner says they have not been paid, a vague reply such as "it has been sent" does little to settle the matter. A short, factual message with the right details lets them chase their own bank effectively.
- The UETR.
- The amount and currency sent, and the charge option used.
- The date the payment was released and the value date.
- The account name, account number or IBAN and bank identifier used, so they can confirm the details were correct.
- The reference, so their accounts team can search for it.
- A copy of the payment confirmation.
Most banks can locate an incoming payment from the UETR alone. Giving the beneficiary everything at once avoids a series of back-and-forth emails while the payment sits unclaimed.
General information
This article is general information about payment tracking and is not legal or regulatory advice. Tracker coverage and status presentation depend on the banks involved. CCYFX Online includes payment tracking and downloadable confirmations; the platform page explains how they work for clients.


