“Where is my payment?”
One trace across 11 countries
A cross-border payment left one bank, crossed several intermediaries and produced status updates in systems owned by different teams. I worked on the shared data layer that turned those fragments into one real-time journey across 200 corridors.
A corporate payment crossed several banks and borders. When it slowed down, the answer to “Where is my payment?” lived in messages spread across local systems and operations teams in 11 countries.
I worked on the data layer that brought those events into one payment timeline across 200 corridors. Operations could investigate an exception from the same trace that clients saw in their tracking view.
The case study in 60 seconds
Following one payment through separate systems
Cross-border payments are not one database update. The sending bank releases an instruction, correspondent banks process their legs, compliance controls can pause it, fees may be deducted and the beneficiary bank confirms the credit. Each participant sees its own part.
SWIFT gpi provides the common thread: the Unique End-to-End Transaction Reference, or UETR. The platform problem was to preserve that thread while events arrived from different countries and systems, then turn it into a timeline an operator could trust.
One trace had to answer four questions
Show the latest confirmed state without erasing the events that led to it.
Measure each leg separately so a corridor delay is distinguishable from a compliance hold or a downstream bank delay.
Retain fee and currency information per leg instead of presenting only the final credited amount.
Give operations the diagnostic detail they need while exposing a simpler, safe status history to the client.
Build an event history, not a mutable status field
The useful unit was a payment event keyed by UETR: status, timestamp, participant, corridor and the information available for that leg. Kafka carried event updates; Spark prepared the consolidated history and the views consumed by tracking applications.
The critical choice was append-first. If a new status simply overwrites the previous one, the dashboard can say where the payment is but cannot explain how it got there. An ordered history supports both the current view and the later investigation.
The hard cases were not the happy-path payments
What changed for the people following the payment
Operations and clients now read the same consolidated payment history. Operations kept the bank-by-bank detail needed to investigate exceptions; clients saw the corresponding tracking status.
Three design rules survived the project
If an internal transformation drops the end-to-end identifier, the trace becomes a set of local records again.
The current status answers the client. The transition history answers operations, audit and incident review.
They need different detail, but they should never disagree about the underlying payment journey.
What this case study does not claim
The client is anonymized. The 11 countries and 200 corridors describe the project scope, not throughput or latency. No payment values, message volumes, latency percentiles or measured reduction in support contacts are published here. The Swift references explain the service; they do not independently verify this deployment.