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.

If you already have a reference or a bank status, start with which evidence answers which question. It shows what the record establishes and what to request before telling a beneficiary that the payment arrived.

Payment not received

Choose the evidence to request next

An explanatory evidence checklist, not live tracking. Interpret the actual reporting bank's feed and message/version scope; a sender receipt, network status, beneficiary credit and usable balance answer different questions.

Keep payment details with your bank. Do not submit a UETR, IBAN, bank login or account statement to PaymentBrief. This checklist cannot access a transaction or recover funds.

No UETR or bank reference available

What is known: You may have a sender receipt, but have not obtained the bank's tracing reference or route.

What it does not prove: A receipt or identifier alone does not establish beneficiary credit. Swift's SR2018 UETR mandate covers specified MT instructions regardless of gpi membership; it does not establish the route of this payment.

What to ask the bank or PSP for

• Ask the sending bank or PSP which payment rail and instruction it used.
• Request its payment reference and, for an in-scope Swift instruction, the UETR from its records.
• Request the latest available status, reporting institution and timestamp, plus its expected credit time.
• For a non-Swift leg, ask how the reference and status can be followed through that leg.

Link to this situationUETR and message scopeMT103 / pacs.008 field reference

Sources and scope: Swift SR2018: specified MT instructions and unchanged UETR

Bank reports payment still in process

What is known: An ACSP update reports settlement in process in the cited bank/provider status interface. It is not beneficiary credit confirmation.

What it does not prove: Elapsed time or ACSP alone does not diagnose the delay or establish an arrival date. G-series labels depend on the reporting interface; confirm the bank's actual mapping and coverage.

What to ask the bank or PSP for

• Ask for the last reported institution, status/sub-status and timestamp.
• Ask what that specific feed establishes, which bank has the next action and whether information is needed from either party.
• If the bank's expected credit time has passed, request an investigation and its case reference and next update time.
• Ask for beneficiary-credit evidence when credit is reported; do not treat an intermediate bank update as receipt.

Fictional case: a supplier payment shows ACSP after the sending bank's expected credit time. The operator requests the last reporting institution and timestamp, the bank's explanation of that update, and an investigation reference. No arrival date or cause is inferred from ACSP.

Link to this situationStatus and evidence referenceWhat to ask your bank

Sources and scope: StoneX status interface: ACSP and G-series scopeSwift Case Management: investigations

Credit reported, recipient cannot see or use funds

What is known: An ACCC update reports beneficiary-account credit in the cited status interface. First confirm the reporting bank, timestamp and the payment to which it refers.

What it does not prove: That reported credit alone does not explain a recipient's balance discrepancy, deductions or ability to use the balance. Do not infer an account restriction or contradict the recipient without the relevant bank's evidence.

What to ask the bank or PSP for

• Ask the sending bank for the reported credit evidence: reporting bank, timestamp, amount, currency and value date.
• Ask the recipient to raise the discrepancy with their own bank through its secure channel and request its credit and available-balance explanation.
• Have the banks reconcile the credit record with the recipient's account record, including any fees or FX differences.
• If the amount is short, confirm charge instructions and actual fee/FX records rather than assuming OUR guarantees an exact amount.

Fictional case: the sender is told ACCC, while the recipient cannot identify usable funds. The operator requests the bank's credit record and asks the recipient to obtain their own bank's explanation of the account entry and available balance. The checklist does not diagnose a hold or treat a screenshot as proof of access.

Link to this situationWhich evidence answers which question?OUR, SHA and BEN charge options

Sources and scope: Convera status interface: ACCC reports creditor-account settlementSwift: destination-bank arrival and end-customer receipt are distinct

Rejection or return reported

What is known: A bank reports rejection or a return. Ask which record and stage it is reporting: a rejected instruction and a return of settled funds are distinct.

What it does not prove: RJCT alone does not prove returned funds reached the sender. A cancellation/recall request does not prove recovery succeeded or authorize resending the original payment.

What to ask the bank or PSP for

• Request the reporting bank, exact status/reason, timestamp and original instruction reference.
• Ask whether the original payment settled; if funds were returned, request the return reference, amount/currency and reconciliation status.
• Ask the bank what can be remedied and whether a new instruction is appropriate before resending.
• Keep an investigation separate from a cancellation request; confirm the bank's supported channel and next update time.

Link to this situationpacs.002 status versus pacs.004 returnInvestigation evidence

Sources and scope: Swift PMPG April 2026, cover-payment section 3: separate Tracker, reject and return records (cover scope)Swift Case Management: enquiry versus cancellation

The UETR: Your Primary Diagnostic Key

In-scope Swift payment instructions carry 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 three 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 — separate from the Block 4 tags most field references cover; for what those other MT103 field tags carry, see the MT103 field-by-field operator reference. 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. For the MT instructions covered by Swift's mandate, an intermediary receiving a UETR must pass it unchanged into the next message in the transaction chain. A bank's ability to expose tracking remains a separate question; ask how the reference and status are carried onto any non-Swift leg.

Swift's Standards Release 2018 made field 121 mandatory for users of MT103, MT103 REMIT, MT103 STP, MT202, MT202 COV, MT205 and MT205 COV, whether or not they were gpi members. This is a mandate for specified messages, not a statement that every Swift message has a UETR.

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 provide the UETR, ask which message and payment route it used and request the available bank reference. For an in-scope instruction, ask the bank to investigate the missing UETR.

What the UETR unlocks: Ask your bank to query the tracking service available to it and provide the recorded updates, reporting institutions and timestamps. A UETR alone does not guarantee a complete update from every bank. 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 — a different endpoint from the G20 end-customer target. 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

The status labels below may appear in interbank reporting and in a bank's gpi view, but the Tracker is not a collection of pacs.002 messages. pacs.002 is an FI-to-FI Payment Status Report. Swift's April 2026 cover-payment guidance separately calls for a Tracker update (which may use an API, a trck message or MT299) and a pacs.002 reject sent to the previous bank when appropriate. Ask your bank which feed its display reflects. The G-series sub-codes are gpi-specific overlay labels; their availability depends on the bank's integration.

Which evidence answers which question?

This is a PaymentBrief interpretation of the different records, not a mandatory sequence. For each disputed payment, request the UETR, last reported status and timestamp, confirmation of credit or the return reference as applicable, and the bank's explanation of any gap. The pacs.002 versus pacs.004 reference expands the status-versus-return distinction.

Illustrative case: a sender has a UETR and its bank shows ACSP with a timestamp, while the beneficiary says no credit is visible. The UETR identifies the transfer and the reported status describes processing; neither is evidence of beneficiary credit. Ask the bank for its latest Tracker update and whether it can obtain an ACCC update or a beneficiary-bank credit record. If the instruction was rejected or settled funds were returned, request the relevant status or return record instead. This example describes a possible evidence gap, not an actual tracked payment.

Note on G-series sub-codes: The reason-code descriptions here follow StoneX's published API documentation. They describe that interface, not a promise that every bank exposes every code or diagnoses the same underlying cause. Confirm the actual feed and code mapping with your bank.

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. An ACCC update reports beneficiary credit; confirm the reporting bank, timestamp and amount. A beneficiary account record is also evidence of credit.

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. Obtain the bank's expected credit time, route, cut-offs and holiday calendar. Distinguish arrival at a bank from beneficiary credit. Escalate against that commitment and business urgency rather than a universal corridor-duration rule.

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 reports non-receipt, compare the reporting bank, account, amount and timestamp with their bank; do not infer the cause from the label alone.
• ACSP/G000 or ACSP/G005: The interface reports forwarding or delivery to a gpi agent. Compare the timestamp with the expected credit time; this is not proof of beneficiary credit.
• ACSP/G001 or ACSP/G006: Payment was forwarded or delivered to a non-gpi agent in the cited interface. Ask which status visibility remains. Raise a bank enquiry — see Step 4.
• ACSP/G002: Payment is at a bank in pending credit. Note the BIC of the holding bank. If the expected credit time is missed, request an enquiry; the code alone supplies no deadline.
• 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: In the cited provider interface, funds from the previous bank are pending. Ask your bank whether a cover leg is involved and what evidence or action is needed; the code alone does not establish a liquidity problem.
• RJCT: Payment rejected. Obtain the full reason code from your bank. Act per the reason code table above.
• No status / no UETR findable: Ask the bank which route and reference it used and whether tracking is available. A missing status alone does not locate the funds or prove the payment has not left the bank.

Step 4 — Request an enquiry when the expected credit time is missed. Agree an internal escalation trigger with the bank; a two-business-day trigger can be your policy, but is not asserted as a network requirement. Ask which enquiry channel it supports. 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

Swift distinguishes investigations through Case Management (camt.110/camt.111) from cancellation through Stop and Recall (camt.056/camt.029). Confirm the supported channel and migration arrangements with the bank. Obtain the case reference and response commitment; a structured message does not establish a universal completion time.

Step 5 — Escalate if no resolution. If the bank misses its response commitment, contact its investigation team or relationship manager and request the applicable complaint or service-level process. Do not assume a corporate can directly open an Observer case or every delay proves a gpi breach.

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: a bank reports that a compliance review is pending, or the status stops updating beyond the expected value date. G002 alone reports pending credit and does not establish a compliance hold; ask the bank what it can disclose.

What banks will and won't tell you: Disclosure can be restricted by applicable law or investigation policy. Ask what the bank can provide and which documents it needs; limited disclosure does not establish a particular sanctions or AML diagnosis.

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: Obtain an expected update time and track outstanding documentation. Screening duration depends on the case and applicable requirements; no universal hold-duration range is established here.

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: Ask what the bank's OUR product covers, including intermediary deductions and separate receiving-bank charges. Reconcile credit, FX and fees rather than treating OUR alone as a full-amount guarantee. See OUR, SHA, and BEN.

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 an explained hold. 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: Obtain the relevant currency and channel cut-off from the bank and submit with an agreed buffer. A generic 11 AM instruction is not a corridor-wide rule.

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 in the cited provider interface means funds from the previous bank are pending. Ask the reporting bank whether this concerns a cover leg; G002 alone does not diagnose liquidity or compliance.

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.
• Address requirements: Confirm the applicable rail, release and bank usage guideline, including whether a permitted hybrid address is supported. A source-format or missing-address issue must be diagnosed from the actual bank response; it does not automatically establish a sanctions hold or a particular rejection code.
• 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):

• Field 121 UETR mandatory under SR2018 for the specified MT103/MT202/MT205 variants, for gpi and non-gpi users of those messages
• 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.
• ISO 20022 Investigation Messages: A camt Operator Reference — the camt.056 recall, camt.029 response, and camt.110/111 case-management messages behind a stalled-payment investigation.

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