Financial messaging (ISO 20022)الرسائل المالية ISO 20022

Financial messaging is the language banks speak to each other in. When you transfer money nothing physical moves. A message moves, saying: pay this amount from this account to that one, for this purpose.

An instruction becomes useful when it can name the parties, amount, and purpose without ambiguity.

If SWIFT does not move money, what does it move?

This is the most common misunderstanding in cross-border payments. People say "I sent it by SWIFT" the way they say "I sent it through the bank". SWIFT has never touched a riyal.

Picture two banks that each hold an account with the other. When the first wants to move a million dollars to the second, what it needs is not an armoured truck. It is a trustworthy message saying: debit my account with you, and credit it to this person.

The problem is proving where the message came from. Who guarantees it really came from the bank and not from a fraudster? Before SWIFT, banks used telex and secret codes agreed bilaterally, which was slow, error-prone and forgeable.

SWIFT arrived in 1973 to solve exactly that: a closed network, verified membership, and messages in a common format everyone understands.

So SWIFT is not a payment system. It is secured post between banks. The money moves in the accounts they hold with each other, and the message tells them who moves what. Confusing the two leaves half the questions about international transfers unanswerable.

What a message carries

A payment message contains the sending and receiving banks, payer and beneficiary accounts, currency, amount, and reconciliation references. It may include party addresses, a payment purpose, an invoice number, and charge instructions. These fields are not a balance. They tell systems what should happen.

If a Saudi importer pays a German equipment manufacturer, the message carries bank identities, accounts, euros, and an invoice reference. Banks then reduce balances in correspondent accounts or separate settlement systems. An operations employee can see a successfully delivered message while settlement still waits for liquidity or another system to open.

"Delivered" does not mean the beneficiary can spend the money. It may confirm only that the messaging network handed the instruction to the next bank. That bank can later reject it, request a corrected field, or wait for the corresponding balance to settle. Every status must be tied to the event it actually confirms.

Other messages follow a payment instruction. A bank can send an acknowledgement, a rejection with a reason code, a request for information, a status report, or a return. Each needs a reference connecting it to the original instruction. Without one, reconciliation becomes a manual search across similar names and amounts.

Swift (سويفت) is a trusted network, not a bank account

Swift provides a secure network, rules, and addresses through which many financial institutions exchange messages. A connected bank has an identifier that helps route an instruction to the correct institution and branch. Swift does not maintain every bank's balance and transfer it as if it were a central ledger.

A message may travel over Swift while settlement occurs in a nostro account at a correspondent bank. The network may carry an instruction about a securities trade while the asset and cash move in local market infrastructure. Swift coordinates trusted communication without becoming the asset exchanged.

The message is still financially critical. A wrong account or currency can lead technically correct settlement to the wrong commercial result. A receiving bank will not trust an instruction if it cannot establish who sent it. The network therefore combines addressing, authentication, encryption, transport records, and format rules.

Two banks can also exchange instructions over a domestic network or direct connection. Swift is not required for every payment in the world. National payment systems operate their own channels and can adopt the same data standard without using the Swift network.

From free text to structured data

Older messages relied on short fields and free-text areas in which an employee entered a name, address, or purpose. One bank might write an address on one line while another divides it into city, country, and postal code. A person can read either version, but software struggles to identify every part reliably.

The newer model is ISO 20022. It is not merely XML or a particular arrangement of brackets. It supplies a dictionary, a business model, and message definitions with agreed meanings. A dedicated field can distinguish a street from a city and a debtor from the ultimate beneficiary.

This is structured data. Instead of hiding an invoice number inside a sentence, the sender places it in a dedicated element. Instead of combining a name and address, it separates their parts into known fields. Systems can then validate, sort, screen, and reconcile without guessing where a word sits.

Structure does not guarantee truth. A bank can put UNKNOWN in the city field, repeat a name inside an address, or truncate data when converting to a legacy system. An institution must measure content quality and completeness, not merely whether a file passed syntax validation.

One example exposes the difference

An old message might carry PAYMENT INV 4817 AHMED RIYADH in one text field. The company's accounting system must search for the number and infer that it is an invoice. A screening engine might confuse Ahmed with a company or another beneficiary. A bank can lose part of the text if its internal field is shorter.

In a structured message, 4817 sits in the invoice reference, Ahmed in the party name, Riyadh in the city, and a payment-purpose code in its own element. Accounting software can close the invoice automatically. Compliance software can compare the name and address separately. Customer service can explain a stop by pointing to the relevant field.

The benefit extends beyond banks. A company paying one thousand suppliers can match every debit to a purchase order. A government can distinguish a salary from a tax refund. A transfer app can display a verified beneficiary name before sending. The meaning travels with the amount instead of remaining in a separate file.

Sanctions screening depends on words

Banks screen party names, banks, countries, and some payment descriptions before execution. Their systems compare the data with sanctions lists, anti-money-laundering rules, and internal policies. Sending a message over Swift does not mean Swift made the compliance decision for every bank.

An innocent customer's name can resemble the name of a listed person and produce a potential match. A compliance employee then examines date of birth, address, nationality, and other context. If the message contains only an abbreviated name, manual work increases and the transfer may be delayed.

Structured data reduces some false alerts by separating names, streets, and countries. It does not eliminate human decisions or differing national rules. A sending bank may permit a transaction that a correspondent stops because its legal exposure and policies are different.

Leaving fields vague does not reliably produce faster processing. An incomplete message may move quickly at first and then wait for days while an intermediary requests an address or purpose. Data quality is therefore both a compliance tool and a speed tool.

Why migration takes ten years

A large bank does not change a message format at one gateway. Customer applications, payment engines, ledgers, treasury, compliance, archives, data warehouses, and dozens of connections all consume the data. Each system may store names at different lengths or use an old internal code.

Migration begins by cataloguing fields and meanings. The bank maps each element's source, path, and transformations. It builds new messages and tests them with counterparties. It then operates old and new forms together and watches for information lost during conversion.

One legacy counterparty can keep an old system alive. A bank may receive a rich message and convert it into a narrower format, truncating data that has nowhere to go. Another bank may later expand it into a new message without recovering what was lost. Format conversion is not the same as real data adoption.

Large industry programmes can therefore take roughly a decade from agreement to full use. The Swift community selected ISO 20022 for cross-border payments in 2018. Format coexistence began in March 2023. It ended on 22 November 2025, when covered payment instructions became subject to the new format, with limited transitional processing for some remaining old messages.

Migration does not finish at the deadline. A bank can send a valid new file while populating its rich fields from old free text. Operations teams may retain manual procedures built around previous message codes. Extracting value from the data follows basic format compliance.

The standard extends beyond Swift

Domestic market infrastructures and instant payment systems also use ISO 20022. The standard does not define one network. It lets different networks use similar vocabulary. A domestic scheme can add mandatory rules for local identities and addresses while retaining recognisable core meanings.

Saudi Arabia's sarie instant payment system is a nearby example. SAMA describes it as fully compliant with international standards and capable of interoperability in accordance with ISO 20022. The customer can use an IBAN or alternative identifier while structured messages carry details needed for verification and execution.

Using the same standard does not connect two systems automatically. Connectivity still requires agreement on participants, operating times, currencies, finality, compliance, and balance settlement. The standard solves a shared-language problem. It does not by itself solve trust, liquidity, or licensing.

Reading any messaging flow

Start by identifying who created, authenticated, and received the instruction. Then identify the network that carried it, the format in which it was written, and the system that will settle the money. Keep the customer reference, message reference, and settlement reference separate because each tracks a different layer.

Next, inspect the fields the beneficiary actually needs. An amount and account are not enough for a company reconciling one thousand invoices. Compliance needs clear names and addresses. Operations needs status and rejection codes that lead to an action.

Financial messaging becomes infrastructure when it carries meaning safely between institutions that do not share one database. It does not replace settlement, but it makes correct settlement routable, screenable, and reconcilable. Improving a message is therefore financial work, not merely a technical file-format change.