Inside a Remittance Message: What the Fields Decide

Part IV · Cross-Border and Regional Clearing Rails (Chapters 13–19) Builds on: Chapter 7 (the lesson of ISO 8583), Chapter 12 (push is one of the two global roads), Chapter 13 (correspondent banking, multiple hops, SWIFT doesn't move money) New concepts in this chapter: MT103 and pacs.008, charge bearer (OUR / SHA / BEN), serial and cover, UETR, SWIFT gpi

This chapter opens up a real message. You don't need to be able to write one, but you do need to know which of its fields decide the product experience — above all, the charge-bearer field.

1. The Question the Previous Chapter Left Open¶

In the previous chapter's four-hop table, every hop carried the same phrase: "an instruction travels to the next bank over SWIFT."

What is actually inside that instruction?

This is not technical trivia. The complaints customers file most often about cross-border products are all answered inside the message's fields: how much the payee will actually get, which hop the money has reached, and why the other side says nothing arrived while your side shows it was sent.

2. What a Remittance Message Carries¶

For decades, the workhorse message of cross-border remittance was called MT103. As of November 2025 it is retired, replaced by ISO 20022's pacs.008 (the changeover is covered later in this chapter). But the industry still talks in the old names, and the business meaning of the fields hasn't changed — so learn them by their MT103 field tags first.

The core fields of a remittance message:

The message header carries one more thing, not shown among the business fields but just as critical — the UETR (unique end-to-end transaction reference, a payment's globally unique tracking number). It is a UUID, generated at the first hop, that rides with the payment the whole way.

The :59a: line deserves one more sentence. The payee's name and address are free text, and sanctions screening works by matching that text against the lists. The fuzzy matching and false positives that the compliance skeleton will cover trace straight back to how loose this field is.

3. Charge Bearer: One Field Decides Who Pays the Intermediaries¶

:71A: takes only three values, but what it decides is real money.

(If you're doing an integration, watch out: the new message's codes look nothing like the old three words, and partner documentation may use either set.)

Run the previous chapter's $1,000 through it. The four charges were 25 outbound, 15 and 10 for the intermediaries, 5 for crediting — 55 in total.

Cross-check: in all three rows, "pays" minus "receives" equals 55. The total charge doesn't move by a cent. Only who pays it moves.

The blocks in all three rows are the same length; only their position slides. This field cannot change the total charge — only which side of the principal line it lands on.

The previous chapter's example was BEN — all four charges came out of the principal, which is why the payee got 945. Switch it to OUR, same route, same four hops, and the payee gets 1,000.

This difference has two direct product consequences.

First, under SHA and BEN, the arrival amount cannot be promised at sending time. How much the intermediaries will take, how many hops there will be — the payer doesn't know in advance. So any cross-border product that promises "you'll know the exact arrival amount" either runs on OUR or doesn't run on this chain at all.

Second, OUR is no cure-all. The sending bank collects an estimated charge from the payer up front; if the actual intermediary fees run over, it bills or refunds the difference afterward. The message can dictate who pays. It cannot dictate how much.

4. Serial and Cover: Two Ways to Route the Same Payment¶

The previous chapter's four-hop table drew the serial method: the payment message is passed like a relay baton, each bank receiving it and forwarding it to the next.

There is another routing called the cover method, which splits one payment across two tracks:

Cover's benefit is concrete: when the payee's bank gets the payment instruction, it doesn't have to wait for the funds chain to finish — it can credit the customer first and reconcile the interbank transfer afterward.

The price is transparency. The intermediaries' deductions happen on the other track, invisible in the message the payee's side holds. Half of the "opacity" the previous chapter complained about comes from exactly this.

5. UETR and gpi: Where Is the Money Right Now¶

Before 2017, a cross-border payment, once sent, was essentially a black box. When a customer asked "where is my money," the bank's only move was to send inquiry messages down the chain, one bank at a time.

SWIFT gpi (global payments innovation) is what changed that. Its core is not new technology. It is three rules:

Note what it is: gpi is not a new rail. It is a set of rules and status reporting laid on top of the existing correspondent chain. The money moves the same way, through the same hops, at the same fees — only now someone tells you where it is.

This is one more instance of the line from the four-party model: what networks like this sell is the enforceability of rules. SWIFT has no power to make the money move faster. It has every power to require that all members report status by the same rulebook.

6. November 2025: MT Retired¶

On November 22, 2025, cross-border payment messaging officially cut over to ISO 20022. MT103, MT202COV — formats in service for decades — were replaced on SWIFT's cross-border channel by pacs.008 and pacs.009(COV).

The migration isn't finished: the interbank MT101 (request for transfer) is scheduled to retire in November 2026, and unstructured address fields end at the same deadline — after that, structured or hybrid format only.

(Timetables like this shift every quarter; check the current bulletins when you need them.)

The practical changes are worth reading against the ISO 8583 section of the card transaction lifecycle:

The structured-address line goes straight at compliance cost. As the four cost sources will show, a large share of sanctions-screening false positives come from free-text names and addresses. Once the fields are split apart, machines have more to match on, and the false-block rate has room to fall.

Back to the lesson of the card transaction lifecycle: the message standard sets the product ceiling. ISO 8583's fixed-length fields constrained card transactions for decades; MT's free text constrained cross-border remittance just as long. Swapping the message standard is this industry's most expensive, slowest-to-pay-off class of renovation — and the one that raises the ceiling the most.

7. Why Cards Don't Take This Road¶

Now we can answer a question that has been waiting since the card chapters: if SWIFT covers the globe, why doesn't a cross-border card swipe travel on it?

Because the two roads were never designed for the same job. Domestic and global called them two different workarounds; here they are in one table:

The third row is the crux, so let's complete that question. The card transaction lifecycle dissected a card swipe's first second or two: the issuer confirms the card is valid, confirms the limit covers it, runs a risk score, then returns an approve or a decline. The card authorization message carries exactly that question and answer.

A remittance message has no such step. The payer has decided to pay; the message's only job is to deliver that decision.

A card authorization message is, at bottom, an inquiry. A SWIFT remittance message is, at bottom, a notification.

An inquiry has to make the round trip in seconds, carrying enough context for a risk decision; a notification only has to arrive, and a little slow is fine. Those two requirements cannot produce the same message format, and cannot grow the same network.

So it isn't that "cards don't use SWIFT." It's that the two roads solve different problems, and forked from day one.

8. The Question This Chapter Leaves Open¶

The message is now fully taken apart: the fields, the charge bearer, the two routings, the tracking number, and the changeover that just completed.

But a message only carries "who pays whom how much" to the other side. What happens once it lands — how the money moves on the ledger over there, at what hour, and whether it can still be pulled back — happens in a different class of system, and this course has so far waved all of it through with one sentence: "it finally lands on some country's central bank ledger."

That ledger has never been opened.

The next three chapters open one each: the euro, the renminbi, the pound. Every judgment tool the course has handed you so far — the gap between clearing and settlement, RTGS versus DNS, finality, the hierarchy of money — grew out of this class of system, and opening these ledgers is where you see the originals.

The next chapter starts with the euro area, and opens with a set of four questions you can use to size up any clearing rail you have never seen before. As for where that 74 went, the accounting comes back once all three ledgers are open.

9. Self-check questions¶

1. A Chinese exporter is owed $100,000 by a US customer; 99,850 lands. It asks its bank, and the bank says "the sender chose SHA." Explain what happened using this chapter's fields, and say what the exporter should require of its customer to prevent it.
2. The cover method gets the payee their money faster. Why does it also make the fees less transparent?
3. Why is SWIFT gpi not a new rail? What exactly did it change?

10. Answers¶

Answer for yourself before reading on.

1. SHA means the payer covers only the sending bank's leg; the intermediaries' charges along the route come straight out of the remitted amount. So the missing $150 was taken by intermediaries in transit — nothing to do with the receiving bank, and impossible to announce in advance.

   To prevent it, the exporter should write into the contract that the payer use OUR (DEBT in ISO 20022): all charges borne by the payer, full amount to the payee.

   One caution, though: OUR guarantees who pays, not how much — the payer may get billed the difference afterward. For a truly certain amount, switch to a channel that doesn't run through multi-hop correspondents.

2. Because cover splits one payment across two tracks: the payment instruction goes straight to the payee's bank, while the funds instruction takes the correspondent chain. The intermediaries' deductions happen on the funds track, but what the payee's side holds is the payment track's message — which carries no record of those deductions.

   Under the serial method every hop marks the same message, so the fees are, ironically, visible. Fast and transparent are a trade-off here.

3. Because it didn't change how the money moves. Still correspondents, still multiple hops, still the same prefunded money and the same fees.

   What gpi changed is the rules: a mandatory unique tracking number on every payment, mandatory status reporting at every hop, member commitments to a service level. It turned a "send it and lose sight of it" black box into a queryable process.

   This is the same thing the four-party model said about card networks selling the enforceability of rules — a network's value often lies not in the pipes but in its power to make every participant act by one rulebook.

Previous: Chapter 13 · The Root Problem of Cross-Border: There Is No Global Central Bank Next: Chapter 15 · Euro-Area Clearing Rails: Four Questions That Decode Any Rail