Most Engineers Who Build Payment Systems Have Never Read an MT202
I governed FX and Money Market settlement at Citi covering more than $3 trillion in annual settlement value. The MT202 is the message through which most of that value actually moved. Most engineers who build payment systems have never read one.
There is a gap in how payment systems engineering is typically taught and practised. Engineers learn the API layer, the transformation logic, the database schema, the event queue. These are real and important skills. What they rarely learn is the message that sits at the operational centre of interbank settlement — the message where the money actually moves.
For FX and Money Market settlement, that message is the MT202.
Understanding it — not just its format but its operational significance — is the difference between building a payment system and understanding a payment system.
What the MT202 actually is
The SWIFT MT202 is a Financial Institution Transfer message. It is how Bank A instructs Bank B to transfer funds to Bank C.
Three parties. One message. Zero tolerance for error.
This is not the customer payment instruction. That is the MT103 — the Single Customer Credit Transfer, which carries originator and beneficiary details and travels directly between the customer's bank and the beneficiary's bank.
The MT202 is the interbank settlement leg. When two banks settle an FX trade, when a correspondent bank moves funds on behalf of another institution, when the nostro account needs to be funded — the MT202 is the instrument. It moves between financial institutions, carrying settlement instructions that do not include customer details and are not designed to.
That design decision — keeping the interbank settlement message separate from the customer payment message — is what later created the MT202COV problem. But we will come to that.
The four fields that determine whether a payment succeeds or fails
The MT202 has many fields. Four of them are operationally critical in a way that others are not — meaning that an error in any one of them either fails the payment outright or creates a reconciliation problem that will consume hours of operations time to resolve.
Field 20 — Transaction Reference
The transaction reference must be unique across the institution's settlement operations and must be traceable end-to-end through the payment chain. This sounds obvious. In practice, reference management across legacy settlement systems, multiple booking systems, and correspondent relationships is one of the most common sources of operational breaks.
When a payment fails or goes missing, Field 20 is the thread you pull to find it. If the reference was not generated uniquely, if it was truncated by a system interface, if the format does not comply with the correspondent's validation rules — the payment may process but become invisible to the reconciliation system that needs to match it.
Reference management is not a technical afterthought. It is a first-class operational requirement that needs to be designed into the settlement system architecture.
Field 32A — Value Date, Currency, Amount
Value date, currency, and amount in a single field. One wrong digit in the amount fails the payment. One wrong date creates a funding mismatch. One wrong currency code — particularly in systems that process multiple currency pairs — sends the funds to the wrong settlement account.
The amount field in MT202 is formatted as a decimal number with a specific precision rule: the comma is used as the decimal separator in SWIFT messaging, not the period. Systems that generate MT202 messages from internal databases where the decimal convention is different need explicit format translation. This is a known, recurring source of payment failures in institutions that migrate settlement systems or integrate new trading platforms.
The value date in Field 32A is the settlement date, not the trade date. For FX spot transactions this is typically T+2. For same-day value trades it is T+0. The value date drives the funding timeline. Getting it wrong means either the nostro is unfunded on the settlement date or the funds are parked a day early — both create reconciliation issues.
Field 57A — Account With Institution
The Account With Institution is the correspondent bank that holds the account being credited. It is identified by BIC — Bank Identifier Code.
If the BIC in Field 57A is wrong, the payment goes to the wrong bank. Or to no bank at all, if the BIC does not exist or is no longer active. SWIFT BIC codes for correspondent banks change — banks merge, rebrand, restructure their correspondent networks. An SSI database that is not actively maintained will eventually contain stale BICs that cause payment failures.
The correspondent banking network is not static. Maintaining current SSI data for every correspondent relationship is an ongoing operational discipline, not a one-time setup activity.
Field 58A — Beneficiary Institution
The Beneficiary Institution is the final recipient of the funds — the bank whose nostro account is being credited. Like Field 57A, it is identified by BIC.
Field 58A must match the SSI — Standing Settlement Instruction — on record for the counterparty. This is where the SSI database becomes operationally critical. If the SSI has not been updated to reflect a change in the counterparty's settlement instructions, the payment will be sent to an account the counterparty no longer expects to receive it in. The payment may process successfully from the sending bank's perspective and create a reconciliation break at the receiving end.
SSI management is not glamorous. It is among the highest-leverage operational investments a settlement team can make.
The MT202COV — one message type change, six months of programme work
In 2009, SWIFT introduced the MT202COV — the Financial Institution Transfer for Own Account with Cover. It was introduced to close a regulatory gap that had been identified in the AML coverage of cover payment flows.
The gap was this: in a standard cover payment structure, Bank A sends an MT103 customer payment instruction directly to the beneficiary bank, and separately sends an MT202 to its correspondent to move the funds. The MT202 carries only interbank settlement details — it does not carry the originator and beneficiary information from the underlying customer transaction.
From a compliance perspective, the correspondent bank processing the MT202 cover payment had no visibility into who initiated the payment or who ultimately received it. Regulators — particularly FATF and the Wolfsberg Group — identified this as a systemic gap in AML transaction monitoring across the correspondent banking chain.
The MT202COV addressed this by adding two fields: Field 50 to carry originator information and Field 59 to carry beneficiary information. When a financial institution sends a cover payment in connection with an underlying customer transaction, it must use the MT202COV format and populate these fields.
I directed the MT202COV migration at Citi. The technical message format change was minor — two additional fields, well-defined population rules. The operational and data change was not minor at all.
Every correspondent relationship required SSI validation to confirm that the correspondent could receive and process MT202COV messages. Every cover payment flow required originator data to be captured at the point of trade initiation — which meant changes to front office trade capture systems, not just back office settlement systems. Every FX trade flow in the system had to be reviewed to determine whether it generated cover payments and whether those cover payments were now in scope for MT202COV.
The data lineage question was the most complex: where, in the journey from trade execution to settlement instruction generation, does the originator information live? In many legacy FX settlement architectures, the answer was: nowhere that the settlement instruction generation system could easily access it. The trade capture system knew the originator. The settlement system knew the correspondent banking details. The connection between them — required to populate Fields 50 and 59 in the MT202COV — did not exist as a clean data flow.
One message type change. Six months of programme work.
This is why SWIFT messages are not just formats. They are the operational contract between institutions. A change to the contract — even a technically minor one — propagates through every system and process that has been built to honour it.
What engineers building payment systems should understand
The MT202 is a window into how interbank settlement actually works — not as an abstraction but as an operational reality. Reading it, understanding its fields, tracing a failed payment through its reference chain — these are not specialist skills for operations staff. They are foundational knowledge for anyone building systems that generate, transmit, or process these messages.
Three things in particular are worth internalising:
The message format encodes operational requirements. Field 20's uniqueness requirement, Field 32A's precision rules, Field 57A's BIC validation, Field 58A's SSI matching — these are not arbitrary format constraints. They encode the operational agreements between correspondent banks about how payments will be processed and reconciled. Understanding why a field has its specific format and validation rules is more useful than knowing what the format is.
Data quality upstream determines settlement quality downstream. The MT202COV experience makes this concrete. The problem was not in the settlement system. It was in the absence of originator data at the point of trade capture. Settlement systems process what they receive. If the data they receive is incomplete, stale, or inconsistently formatted, the settlement message will reflect that — with consequences that are visible only at settlement time, under deadline pressure.
SSI management is a system design problem, not an operations problem. Standing Settlement Instructions change. Correspondent banks merge. BIC codes are retired. The SSI database is live data that degrades over time. Building systems that treat SSI as a one-time configuration rather than as a maintained reference dataset is building settlement risk into the architecture.
Read the MT202. Understand why each field is there. Trace a payment from trade execution through to nostro reconciliation. The engineers who have done this build materially better payment systems than the engineers who have not.
Frequently asked questions
What is an MT202 SWIFT message?
The MT202 is a Financial Institution Transfer — Bank A instructing Bank B to transfer funds to Bank C. It is the message through which most interbank FX and Money Market settlement actually moves. Three parties, one message, zero tolerance for error. The four critical fields are Transaction Reference (Field 20), Value Date/Currency/Amount (Field 32A), Account With Institution (Field 57A), and Beneficiary Institution (Field 58A).
What is the difference between MT202 and MT202COV?
The MT202COV added Fields 50 and 59 to carry originator and beneficiary information through the correspondent banking chain — closing an AML visibility gap that regulators identified in standard MT202 cover payments. The technical change was minor. The operational change required touching every FX trade flow to ensure originator data was captured at trade initiation and could flow through to settlement instruction generation.
What is a cover payment in correspondent banking?
A cover payment is the interbank settlement leg of a customer payment flowing through correspondents. The MT103 carries the customer instruction; the MT202 (or MT202COV) instructs the correspondent to move the underlying funds. The separation of these two message flows is what originally created the AML visibility gap that MT202COV was designed to close.
Why did the MT202COV migration take so long at major banks?
Because the technical change was minor but the data change was significant. Every correspondent relationship needed SSI validation. Every cover payment required originator data capture at trade initiation — changes in front office systems. Every FX trade flow needed review to determine cover payment scope. The data lineage from trade capture to settlement instruction did not exist as a clean flow in most legacy architectures.
Found this useful? I write weekly on SWIFT messaging, FX settlement, and the lessons 24 years at Citi and Standard Chartered taught me about payment operations at global scale. Subscribe to the newsletter — no spam, unsubscribe anytime.
Working on an MT202 migration, SWIFT integration, or FX settlement challenge? Explore my consulting services or get in touch directly.
Raj Thilak is Head of Technology for Data & Analytics with 24 years at Citi and Standard Chartered. He directed the MT202COV migration at Citi and governed FX and Money Market settlement covering more than $3 trillion in annual settlement value. Based in Pune, India. rajthilak.dev
Found this useful? Subscribe for weekly insights.
Join the conversation
Loading comments...