Why Cross-Border FX Is So Bad At Tracking Payments

Meet Tomás, a treasury operations analyst at an auto-parts manufacturer in São Paulo. Twice monthly, he pays his component suppliers in Beijing.

We think that money is data and it should move like it, trouble is that for Tomás, it does not. He can't just convert BRL to CNY directly, because Brazil's foreign exchange rules require all conversions to happen onshore. So before any money crosses the border, Tomás has to clear a domestic exchange contract with his bank.

That’s one hurdle.

Once he files the paperwork with the central authority, then he can begin the process of actually paying his supplier. Assuming that payment happens in the traditional way, it then becomes a SWIFT message, and is tossed into the correspondent banking chain.

But even that isn’t entirely certain.

Beginning in 2023, Brazil and China established a local-currency clearing relationship. If his supplier's bank is part of CIPS, China's clearing system, the payment may route through it instead. This is a totally separate rail with its own status codes, one that isn't tracked through SWIFT.

Now lets imagine the worst case, for some reason the supplier doesn't get the money in time, where should Tomas look for it?

That’s difficult to say, our man has no way of knowing whether the money went via SWIFT or CIPS. So he calls the bank and waits and waits and waits.

This is clearly not ideal, but it’s also relatively common in traditional cross-border transactions. The market's opacity makes it hard to understand where your money is at any given moment, and harder still to do anything about it.

Solving this opacity is one of the major goals of the kind of API-driven automation that we are working to develop.

No one knows where your money is

Traditional cross-border FX lacks robust, existing tracking systems. Some years ago SWIFT’s GPI introduced Unique End-to-End Transaction References, more commonly referred to as UETR. This system was designed to allow correspondent banks greater visibility into the status of transactions as they pass through the network.

In 2025, SWIFT moved from its ancient MT103 protocol to the more modern, XML-driven pacs.008.

This new standard gave them much more “room” to embed information that could then be used to investigate where money was on the chain.

These solutions, however, would not help our friend Tomás except in the most ideal of scenarios. For one, UETR can’t talk to CIPs, which runs its own status codes, so if his transaction did travel those rails he wouldn’t be able to audit anything.

Even if it traveled along more traditional routes, GPI and UETR are for member banks, not for Tomás. As a corporate user of the rails, Tomás would not have access to the status codes that might tell him where his money is, unless his bank happened to subscribe to GPI and his company subscribed to the corporate version of the program.

This is a very long and complicated way to say that in almost every case, Tomás will only know what happened to his money when it lands, and even then, only partially.

Towards a stateful cross-border FX stack

This is an instance where API-driven rails powered by stablecoins can do a much better job. Wallet-to-wallet transfers are tracked on the blockchain itself, making them easily auditable by anyone who knows the transaction history. When plugged into an end-to-end platform that also handles banking and compliance, status codes provide a clear, traceable route for funds.

You also don’t have to worry about which rails the transaction travels down as orchestration is being handled by the API itself. The API maintains the “state” of the payment at every point, and can pass that state back to Tomás and his treasury team.

The more complex the corridor, the more important statefulness becomes, because your transaction is more likely to travel across multiple legs and through multiple, disparate regulatory regimes before it lands. Statefulness also allows you to act on the states it produces. If the platform tells you that execution failed, you can set up a trigger to initiate another transfer assuming market conditions remain the same.

Statefulness then sits at the center of all automation. You cannot create a system that makes decisions, without the signals that drive those decisions.

Back to Tomás

So what does this mean for Tomás?

As we’ve said elsewhere, most of the problems with cross-border FX are the rails themselves. Even if Tomás solved his problem in this corridor, he would just have to do the same thing in the next and the next and the next.

The more complex the conversion, the messier the data he would receive, if he receives anything at all.

Traditional cross-border FX was never built for transparency, and that’s unlikely to change in the near future.

Even if it was, Tomás would still need to do everything manually. When something went wrong, he would have to spend hours on the phone with his bank solving the problem, that assumes his bank even knew where his money was at all.

What Tomás needs is not better GPI, but a solution that actually empowers him to scale his business more efficiently. A stateful system, that produces the same, easy-to-audit status codes regardless of the corridor the money moves through, one that is also programmatic, available 24/7 at a price he can rely on.

It’s a tall order, one that many people pitching him payment APIs may not be able to actually execute upon, but it’s one that sits at the center of what we are trying to create.