It is the bank-to-bank transfer that funds a customer payment sent with the cover method. It moves the money through the correspondents while the MT103 goes directly to the beneficiary’s bank, and it carries the ordering and beneficiary customer so every bank in between can screen them.

How do I match an MT202COV to its MT103?

Field 21 of the MT202COV equals field 20 of the MT103, and both messages carry the same UETR in field 121 of the user header. Amount and value date in 32A normally match as well.

Why was the MT202COV introduced?

Because a plain MT202 cover named only banks, so correspondents could not see the originator and beneficiary and could not screen them. After a Basel Committee paper on cover payment transparency in May 2009, Swift introduced the MT202COV with mandatory customer fields, effective 21 November 2009.

What is the difference between MT202 and MT202COV?

The MT202 is for transfers that are the banks’ own business. The MT202COV is only for the cover of a customer payment and adds sequence B with the customer details. In the header, the MT202COV carries {119:COV}.

Does the beneficiary’s bank receive the MT202COV?

Not as a report. It receives the MT103 and the funds on its account with its correspondent; it learns of the credit from an MT910 or its statement (MT950 or camt.053). The standard says the MT202COV must not be forwarded to it for reporting.

What replaces the MT202COV in ISO 20022?

A pacs.009 with the underlying customer credit transfer block filled in (pacs.009 COV), sent alongside the pacs.008 with the same UETR.

Category 2: Financial institution transfers

MT202COV General Financial Institution Transfer for Cover Payments

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

The MT202COV is the bank-to-bank transfer that moves the funds for a customer payment sent with the cover method: the MT103 goes straight to the beneficiary’s bank, and the MT202COV pays that bank through the correspondents. Unlike a plain MT202, it repeats the ordering and beneficiary customer in sequence B so that every bank the money passes through can screen them. Since 22 November 2025 the Swift equivalent is the cover variant of pacs.009.

Message type: MT202COV
Category: 2
Structure: 2 sequences, 19 fields listed
ISO 20022: pacs.009

When MT202COV is used

In the cover method a bank sends two messages for one customer payment. The MT103 goes directly to the beneficiary’s bank and tells it whom to credit. The MT202COV goes to the Sender’s own correspondent in the payment currency and moves the funds, possibly through further correspondents, to the account the beneficiary’s bank holds in that currency. The beneficiary’s bank pays out when the MT103 and the funds have both arrived. The cover versus serial guide compares the two methods.

Before November 2009 the cover leg went in a plain MT202, which named only banks. The correspondents moving the money could not see who was paying whom, so they could not screen the payment against sanctions lists or monitor it. After a Basel Committee paper on transparency in cover payments (May 2009), Swift introduced the MT202COV, effective 21 November 2009, with a mandatory sequence for the underlying customer details.

The two legs are tied together twice. Field 21 of the MT202COV carries field 20 of the MT103, and field 121 in the user header carries the same UETR as the MT103. A correspondent that passes the cover on in another MT202COV copies both unchanged. Field 119 in the user header must contain COV: that is what tells the network to validate the message as a cover.

Sequence A is the bank-to-bank transfer and reads exactly like an MT202. Sequence B copies the customer side from the MT103: ordering customer (50a), beneficiary customer (59a), and, where the MT103 had them, remittance information (70), sender to receiver information (72) and the instructed amount (33B).

The MT202COV is only for the cover of a customer payment. It must not carry the customer instruction itself, it must not be used for any other interbank transfer, and it must not be forwarded to the beneficiary’s bank just to report the payment.

MT202COV format: sequences and fields

Sequence AGeneral InformationMandatory

The interbank transfer: the same fields and rules as an MT202. Field 13C may repeat.

Tag	Name	Status	Format	Meaning
20	Transaction Reference Number	M	16x	The Sender’s own reference for this cover message. No leading or trailing slash and no double slash.
21	Related Reference	M	16x	Field 20 of the underlying MT103. When a correspondent forwards a received MT202COV, it copies field 21 of the incoming message unchanged. `NONREF` only if no reference is available.
13C	Time IndicationRepeatable	O	/8c/4!n1!x4!n	A processing time with UTC offset, with the codes CLSTIME, SNDTIME or RNCTIME as in the MT202.
32A	Value Date, Currency Code, Amount	M	6!n3!a15d	Value date, currency and amount of the cover. Normally equal to 32A of the MT103. Comma as decimal mark; XAU, XAG, XPD and XPT are not allowed. 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 cover, when it is not the Sender. A correspondent forwarding the cover 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, as in the MT202.
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 or institution where the funds are made available to the Receiver.
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 cover must pass through to reach the account with institution. Requires 57a in sequence A.
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 bank that holds the beneficiary institution’s account in this currency, usually the beneficiary bank’s own correspondent. Absent means the Receiver holds that account.
58a	Beneficiary InstitutionOptions A or D	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The bank that receives the cover funds: in a cover payment, the Receiver of the MT103 (the beneficiary customer’s bank).
72	Sender to Receiver Information	O	6*35x	Coded bank-to-bank information for the cover leg (/ACC/, /BNF/, /INS/, /INT/ and the contact codes). /INS/, /ACC/ and /BNF/ received from an earlier bank are passed on unchanged.

Sequence BUnderlying Customer Credit Transfer DetailsMandatory

The customer side of the payment, copied from the MT103. It is not an instruction: nobody credits a customer on the basis of sequence B.

Tag	Name	Status	Format	Meaning
50a	Ordering CustomerOptions A, F or K	M	A: [/34x] 4!a2!a2!c[3!c] F: 35x 4(1!n/33x) K: [/34x] 435x	The ordering customer of the underlying MT103, normally copied from its field 50a. Option F with numbered lines (1/ name, 2/ address, 3/ country and town) is the structured choice.
52a	Ordering InstitutionOptions A or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The ordering customer’s bank in the underlying payment, when it is not the Sender of the MT103.
56a	Intermediary InstitutionOptions A, C or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] C: /34x D: [/1!a][/34x] 4*35x	The intermediary named in the underlying MT103, if any. Requires 57a in sequence B.
57a	Account With InstitutionOptions A, B, C or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] C: /34x D: [/1!a][/34x] 4*35x	The beneficiary customer’s bank from the underlying MT103, when it was given there (that is, when it differs from the MT103 Receiver).
59a	Beneficiary CustomerOptions no letter, A or F	M	No letter: [/34x] 435x A: [/34x] 4!a2!a2!c[3!c] F: [/34x] 4(1!n/33x)	The beneficiary customer of the underlying MT103, normally copied from its field 59a, with the account (an IBAN where the country uses them) on the first line.
70	Remittance Information	O	4*35x	If the MT103 carried remittance information, this field must carry it: /INV/, /RFB/, /ROC/, /IPI/ or free text.
72	Sender to Receiver Information	O	6*35x	If the MT103 carried field 72, this field must carry it. Codes /ACC/, /INS/ and /INT/ are used unless agreed otherwise.
33B	Currency/Instructed Amount	O	3!a15d	If the MT103 carried 33B, this field must carry it unchanged. It is information only and travels unchanged through the chain.

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 in sequence A, 57a must also be present in sequence A (rule C1, error C81).
If 56a is present in sequence B, 57a must also be present in sequence B (rule C2, error C68).
The user header block must contain field 119 with COV and field 121 with the UETR. The UETR of the underlying MT103 is copied unchanged; an intermediary copies the UETR it received; only when no UETR exists is a new one created.
Field 21 carries field 20 of the MT103. When an incoming MT202COV leads to an outgoing one, field 21 and field 121 are both passed on unchanged.
Fields 70, 72 and 33B in sequence B must repeat what the MT103 contained in those fields; 50a and 59a must name the ordering and beneficiary customer of the MT103.
The message is a general use message (no user group registration) with a maximum length of 10,000 characters.
The MT202COV must not be used to send the customer instruction, must not be used for an interbank transfer that has no underlying customer payment, and must not be sent to the beneficiary’s bank only as a report.
Market practice for filling the message is published by the Payments Market Practice Group (PMPG) in its guidelines for the MT202COV.

MT202COV example

Gulf Trading LLC asks ZagTrader Test Bank, Dubai (ZAGTAEADXXX), to pay USD 48,500.00 to Acme Components Ltd, a customer of BANKGB2LXXX in London. The two banks have no USD account with each other, so ZagTrader uses the cover method. It sends an MT103 (reference ZT2610200057, same UETR) straight to BANKGB2L with 53A BANKUS33XXX and 54A ZAGTUS33XXX, and sends this MT202COV to its USD correspondent BANKUS33XXX in New York, asking it to pay BANKGB2L at BANKGB2L’s USD correspondent ZAGTUS33XXX.

{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKUS33XXXXN}{3:{119:COV}{121:49ada093-d0ce-4602-8109-165871e4e4fc}}{4:
:20:ZT2610200058
:21:ZT2610200057
:32A:261022USD48500,00
:57A:ZAGTUS33XXX
:58A:BANKGB2LXXX
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/OFFICE 1204 BUSINESS BAY TOWER
3/AE/DUBAI
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0613
:33B:USD48500,00
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKUS33XXXXN}{3:{119:COV}{121:49ada093-d0ce-4602-8109-165871e4e4fc}}{4:	The message type in block 2 is 202. Field 119 COV in the user header makes it an MT202COV; field 121 carries the same UETR as the MT103.
:20:ZT2610200058	ZagTrader’s reference for the cover message.
:21:ZT2610200057	Field 20 of the underlying MT103. This is how BANKGB2L matches the cover to the customer payment.
:32A:261022USD48500,00	Value 22 October 2026, USD 48,500.00, the same as 32A of the MT103.
:57A:ZAGTUS33XXX	Account with institution: the bank where BANKGB2L holds its USD account.
:58A:BANKGB2LXXX	Beneficiary institution: the Receiver of the MT103, which will credit its customer.
:50F:/AE070331234567890123456	Start of sequence B. Ordering customer, copied from the MT103.
1/GULF TRADING LLC
2/OFFICE 1204 BUSINESS BAY TOWER
3/AE/DUBAI
:59F:/GB42BANK40051587654321	Beneficiary customer and account, copied from the MT103.
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0613	Remittance information from the MT103, repeated as the standard requires.
:33B:USD48500,00	Instructed amount from the MT103, carried unchanged.
-}	End of block 4.

Sequence B has no 16R/16S markers: it starts with the first sequence B field (50a).

After paying, BANKUS33 can confirm the debit to ZagTrader with an MT900, and ZAGTUS33 can confirm the credit to BANKGB2L with an MT910 quoting ZT2610200057 in field 21.

All BICs, names, IBANs and the UETR are made up. The IBANs carry valid check digits.

Common errors and rejects

Field 119 COV missing
Without {119:COV} in the user header the message is treated as a plain MT202, and a sequence B field such as 50a or 59a then makes it fail validation. Check the header your payment system builds, not only block 4.
56a without 57a in either sequence (C81, C68)
C81 points to sequence A and C68 to sequence B. In sequence B the fields are copied from the MT103: if the MT103 named an intermediary, it must also have named the account with institution.
Field 21 or UETR does not match the MT103
Not a network reject, but the beneficiary’s bank cannot match the cover to the customer payment and holds the funds or sends an enquiry. Field 21 must equal MT103 field 20, and field 121 must equal the MT103 UETR.
How to fix it
Customer details missing or shortened in sequence B
Correspondents screen 50a and 59a. A sequence B with only an account number, or a name cut short, triggers requests for information by MT199 and delays the funds. Copy the full details from the MT103.
How to fix it
Option F lines in 50F or 59F out of order (T54, T56, T73)
Numbered lines must start with 1/, appear in numerical order and include a line 3/ with a valid ISO country code.
Amount format in 32A or 33B
Comma as decimal mark, at least one digit before it, no more decimals than the currency allows.
How to fix it

MT202COV in ISO 20022

The ISO 20022 equivalent is pacs.009 used as a cover (often called pacs.009 COV): the interbank transfer in the main transaction block, and the underlying customer payment in the CdtTrfTxInf/UndrlygCstmrCdtTrf block, which takes the place of sequence B. The customer instruction itself travels as a pacs.008, and both carry the same UETR.

Since 22 November 2025, cross-border payment instructions on Swift are delivered in ISO 20022, and an MT202COV that a bank still sends is converted by Swift’s contingency processing, charged from 1 January 2026.

The ISO 20022 cover can hold structured addresses, identifiers and longer names that the MT fields cannot. When a pacs.009 COV is translated back to MT for a bank that still processes MT, those details can be cut. See truncation in MX to MT translation.

MT202COV questions

What is an MT202COV?: It is the bank-to-bank transfer that funds a customer payment sent with the cover method. It moves the money through the correspondents while the MT103 goes directly to the beneficiary’s bank, and it carries the ordering and beneficiary customer so every bank in between can screen them.
How do I match an MT202COV to its MT103?: Field 21 of the MT202COV equals field 20 of the MT103, and both messages carry the same UETR in field 121 of the user header. Amount and value date in 32A normally match as well.
Why was the MT202COV introduced?: Because a plain MT202 cover named only banks, so correspondents could not see the originator and beneficiary and could not screen them. After a Basel Committee paper on cover payment transparency in May 2009, Swift introduced the MT202COV with mandatory customer fields, effective 21 November 2009.
What is the difference between MT202 and MT202COV?: The MT202 is for transfers that are the banks’ own business. The MT202COV is only for the cover of a customer payment and adds sequence B with the customer details. In the header, the MT202COV carries {119:COV}.
Does the beneficiary’s bank receive the MT202COV?: Not as a report. It receives the MT103 and the funds on its account with its correspondent; it learns of the credit from an MT910 or its statement (MT950 or camt.053). The standard says the MT202COV must not be forwarded to it for reporting.
What replaces the MT202COV in ISO 20022?: A pacs.009 with the underlying customer credit transfer block filled in (pacs.009 COV), sent alongside the pacs.008 with the same UETR.

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