What is the difference between MT202 and MT202COV?

Both move money between banks. The MT202 is for the banks’ own business, such as FX or money market settlement. The MT202COV is used only for the cover leg of a customer payment sent with the cover method, and adds a second sequence with the ordering and beneficiary customer details from the MT103.

What is the difference between MT103 and MT202?

An MT103 pays a customer: someone that is not a bank is at one or both ends. An MT202 has banks at every position, the ordering institution and the beneficiary institution in 58a included.

What does NONREF mean in field 21?

It is the code a bank writes in field 21 when it passes a transfer on but received no related reference to quote. The originator of a transfer should always put a real reference there, such as the deal number.

Is the MT202 still used after November 2025?

Not as the native interbank instruction on Swift for cross-border payments: that is now pacs.009. An MT202 that a bank still sends is converted by Swift’s contingency processing (charged from 1 January 2026), and many internal systems still produce MT202-style data.

What is field 58A in an MT202?

The beneficiary institution: the bank that finally receives the money. Field 57a, if present, is the bank that holds that institution’s account and will credit it.

What does 13C /CLSTIME/ mean?

It tells the correspondent the time by which a CLS pay-in must be credited to CLS Bank, expressed in CET with its UTC offset, for example /CLSTIME/0700+0100. The correspondent converts it to its own local cut-off.

Category 2: Financial institution transfers

MT202 General Financial Institution Transfer

Written and maintained by ZagTrader. Last reviewed 21 October 2026. How this page is sourced and checked

The MT202 is the Swift message one bank sends to move its own money to another bank: every party in it is a financial institution. It goes from the ordering institution, directly or through correspondents, towards the beneficiary institution named in field 58a, typically to settle FX deals, money market loans or nostro funding. Since 22 November 2025 the cross-border interbank instruction on Swift is the ISO 20022 pacs.009.

Message type: MT202
Category: 2
Structure: 11 fields listed
ISO 20022: pacs.009

When MT202 is used

An MT202 moves funds between banks for their own account. Typical cases are paying out the currency leg of an FX deal, repaying or placing a money market deposit, topping up a nostro account, funding CLS pay-ins and moving liquidity between two accounts the Sender holds with the same correspondent. All parties in the message (ordering, intermediary, account with and beneficiary institution) must be financial institutions.

The Sender is the ordering institution or acts on its behalf. The Receiver is usually the Sender’s correspondent in the currency of the payment: it debits the Sender’s account and pays the beneficiary institution in 58a, either on its own books or through the account with institution in 57a, often over the local RTGS system.

Field 21 always points to the deal or message behind the transfer, for example the common reference of the FX confirmation or field 21 of the MT202 received from the previous bank. If the Sender is passing on a payment and received no reference, it writes NONREF.

An MT202 must not be used to pay the cover for a customer payment sent with the cover method. Since November 2009 that leg goes in an MT202COV, which carries the ordering and beneficiary customer so that every bank in the chain can screen them. See the cover versus serial guide.

Like the MT103, every MT202 carries a UETR in field 121 of the user header block. A bank that forwards the transfer passes the UETR on unchanged; a new transfer gets a new UETR.

MT202 format: sequences and fields

Message text (block 4)Mandatory

The MT202 has no sequences: block 4 is a single list of fields. Field 13C may repeat.

Tag	Name	Status	Format	Meaning
20	Transaction Reference Number	M	16x	The Sender’s own reference for this transfer. It must not start or end with a slash or contain two slashes in a row (T26).
21	Related Reference	M	16x	The reference of the deal or message that caused the transfer and means something to the beneficiary institution, for example the FX deal reference or field 21 of an incoming MT202. Use `NONREF` if you are not the originator and received no reference.
13C	Time IndicationRepeatable	O	/8c/4!n1!x4!n	A processing time with its UTC offset. Codes: CLSTIME (when a CLS pay-in must reach CLS Bank, quoted in CET), SNDTIME and RNCTIME (debit and credit times of a TARGET2 payment, in CET). Example: `/CLSTIME/0915+0100`.
32A	Value Date, Currency Code, Amount	M	6!n3!a15d	Value date (YYMMDD), ISO currency code and amount, with a comma as the decimal mark. The precious metal codes XAU, XAG, XPD and XPT are not allowed here. See how to read 32A.
52a	Ordering InstitutionOptions A or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The institution that ordered the transfer, when it is not the Sender. Once present it must be passed on to the beneficiary institution. A bank forwarding an MT202 it received names the original Sender here.
53a	Sender's CorrespondentOptions A, B or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	The account or institution through which the Sender reimburses the Receiver. Leave 53a and 54a out when the single direct account between the two banks in that currency is used. Option B with an account number picks one of several accounts, or names the account to debit when moving funds between two of the Sender’s own accounts.
54a	Receiver's CorrespondentOptions A, B or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	The branch of the Receiver or other institution where the funds will be made available to the Receiver. A branch of the Sender must not appear here, and a 54a naming a third bank must be preceded by 53a.
56a	IntermediaryOptions A or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	An institution the transfer must pass through between the Receiver and the account with institution. If 56a is present, 57a must be present too.
57a	Account With InstitutionOptions A, B or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 4*35x	The institution that holds the beneficiary institution’s account and will credit it. Absent means the Receiver itself is that institution. The party identifier can carry a clearing code such as `//FW` (pay by Fedwire) or `//RT` (pay through the RTGS system).
58a	Beneficiary InstitutionOptions A or D	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The financial institution that finally receives the funds. Option A with a BIC is expected; option D is for the exceptional case where the bank has no BIC. When the Sender moves money to its own account elsewhere, 58A carries that account number and the Sender’s own BIC.
72	Sender to Receiver Information	O	6*35x	Coded bank-to-bank information, one code per item between slashes: /ACC/ (for the account with institution), /BNF/ (for the beneficiary institution), /INS/ (an earlier instructing institution), /INT/ (for the intermediary), /PHON/, /TELE/ and similar contact codes. Uncoded or free text here usually sends the payment to manual repair.

Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).

Rules worth knowing

If 56a is present, 57a must also be present (network rule C1, error C81).
The user header block must carry the UETR in field 121. A bank acting as intermediary passes on the UETR it received, unchanged; in every other case a new UETR is generated.
All parties must be financial institutions. A transfer that relates to a customer payment sent with the cover method must use the MT202COV, not the MT202.
Field 21 must always refer to the related transaction; NONREF is used only when the Sender is not the originator and received no reference.
Field 32A must not use the precious metal codes XAU, XAG, XPD or XPT (error C08); metals have their own message category.
Moving funds between two of the Sender’s own accounts with the Receiver: 53B names the account to debit and 58A the account to credit plus the Sender’s BIC. Moving funds to the Sender’s account at another bank: 57a names that bank and 58A carries the account and the Sender’s BIC.
If 53a is present and is not a branch of the Receiver, the Sender must also send a cover (another MT202, or a local clearing payment) to the institution in 53a.
Clearing codes such as //FW, //RT, //AU, //CP or //IN should appear only once, in the first of fields 56a, 57a and 58a that is used.
Codes /INS/, /ACC/ and /BNF/ received in field 72 must be passed on unchanged to the next message in the chain. A field 72 that starts with /REJT/ or /RETN/ must follow the payments reject and return guidelines (error T80).

MT202 example

ZagTrader Test Bank in Dubai (ZAGTAEADXXX) has sold USD and bought EUR 1,000,000.00 in an FX deal with BANKDEFFXXX in Frankfurt and must pay the EUR leg. It instructs its EUR correspondent, BANKFRPPXXX in Paris, to pay the beneficiary institution BANKDEFFXXX on 22 October 2026. Field 21 carries the deal reference so that BANKDEFF can match the money to the trade.

{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKFRPPXXXXN}{3:{121:8597deeb-fe6f-4e64-aa88-4d8e8b9ddff0}}{4:
:20:ZT2610200088
:21:FX2610200042
:32A:261022EUR1000000,00
:58A:BANKDEFFXXX
:72:/BNF/FX SETTLEMENT EURUSD
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKFRPPXXXXN}{3:{121:8597deeb-fe6f-4e64-aa88-4d8e8b9ddff0}}{4:	Sender ZAGTAEADXXX, input MT202 to BANKFRPPXXX at normal priority, and the UETR in field 121 of the user header.
:20:ZT2610200088	ZagTrader’s own reference for this transfer.
:21:FX2610200042	Related reference: the FX deal this payment settles. BANKDEFF uses it to match the incoming money to the confirmation.
:32A:261022EUR1000000,00	Value date 22 October 2026, EUR 1,000,000.00. The decimal mark is a comma.
:58A:BANKDEFFXXX	Beneficiary institution. No 57a, so BANKFRPP pays BANKDEFF directly (for example through TARGET2 or a direct account).
:72:/BNF/FX SETTLEMENT EURUSD	Information for the beneficiary institution, introduced by the /BNF/ code.
-}	End of block 4.

There is no 53a or 54a: ZagTrader holds a single EUR account with BANKFRPP, which BANKFRPP simply debits.

BICs, references and the UETR are made up.

Common errors and rejects

56a without 57a (C81)
An intermediary is named but no account with institution. If the transfer really passes through an intermediary, name the bank that holds the beneficiary institution’s account in 57a; otherwise remove 56a.
UETR missing or changed in block 3
Field 121 must be present. Intermediaries that generate a new UETR instead of copying the one received break tracking for every bank after them, and the transfer can no longer be traced end to end.
How to fix it
Amount or currency format in 32A (T40, T43, C03, C08)
The amount needs a comma as decimal mark, at least one digit before it and no more decimals than the currency allows. Metal codes such as XAU are refused in an MT202.
How to fix it
BIC in 52a to 58a not valid (T27, T28, T29, T45, C05)
Each BIC must exist in the BIC directory and must belong to a financial institution. A corporate BIC in 58A is refused: a company being paid means you need a customer payment, not an MT202.
How to fix it
MT202 used for the cover of a customer payment
Not a network reject, but correspondents treat it as a compliance breach: the cover leg of an MT103 must be an MT202COV so that the ordering and beneficiary customers are visible. Expect a query by MT199 or a return.
Free text in field 72
Narrative without a code, or instructions that belong in another field, stop straight-through processing at the Receiver. Use the standard codes and keep field 72 for what has no field of its own.

MT202 in ISO 20022

The ISO 20022 equivalent is pacs.009 (Financial Institution Credit Transfer). Swift ended the MT/MX coexistence period for cross-border payment instructions on 22 November 2025: since then interbank transfers on Swift are delivered as pacs.009, and an MT202 a bank still sends is converted by Swift’s contingency processing, which Swift charges for from 1 January 2026.

The cross-border usage rules (CBPR+) define separate pacs.009 usage guidelines for the plain bank-to-bank transfer, the cover of a customer payment (pacs.009 COV, the successor of the MT202COV) and an advice variant. The plain MT202 maps to the core pacs.009: 32A becomes the interbank settlement amount and date, 58a the creditor (a financial institution), 57a the creditor agent and 52a the debtor, and the UETR moves into the payment identification.

Rejections that used to come back as MT199 or MT299 free text are now reported in pacs.002, returns travel as pacs.004, and cancellation requests use camt.056.

MT202 questions

What is the difference between MT202 and MT202COV?: Both move money between banks. The MT202 is for the banks’ own business, such as FX or money market settlement. The MT202COV is used only for the cover leg of a customer payment sent with the cover method, and adds a second sequence with the ordering and beneficiary customer details from the MT103.
What is the difference between MT103 and MT202?: An MT103 pays a customer: someone that is not a bank is at one or both ends. An MT202 has banks at every position, the ordering institution and the beneficiary institution in 58a included.
What does NONREF mean in field 21?: It is the code a bank writes in field 21 when it passes a transfer on but received no related reference to quote. The originator of a transfer should always put a real reference there, such as the deal number.
Is the MT202 still used after November 2025?: Not as the native interbank instruction on Swift for cross-border payments: that is now pacs.009. An MT202 that a bank still sends is converted by Swift’s contingency processing (charged from 1 January 2026), and many internal systems still produce MT202-style data.
What is field 58A in an MT202?: The beneficiary institution: the bank that finally receives the money. Field 57a, if present, is the bank that holds that institution’s account and will credit it.
What does 13C /CLSTIME/ mean?: It tells the correspondent the time by which a CLS pay-in must be credited to CLS Bank, expressed in CET with its UTC offset, for example /CLSTIME/0700+0100. The correspondent converts it to its own local cut-off.

All MT messages · Category 2 messages · ISO 20022 messages · Codes · Troubleshooting