A Swift message a bank uses to pass on an interbank transfer it received to the next bank in the same country, naming the original ordering institution in field 52a and the beneficiary institution in 58a.

What is the difference between MT202 and MT205?

The MT202 is the general bank-to-bank transfer, sent by or on behalf of the ordering institution. The MT205 executes an incoming transfer within one country: the ordering institution (52a) is mandatory, field 21 points back to the incoming message and there is no field 54a.

What is the difference between MT205 and MT205COV?

The MT205COV is used when the transfer is the cover for a customer payment sent with the cover method. It adds a sequence with the ordering and beneficiary customers of the underlying MT103 and needs code COV in field 119. The plain MT205 must not be used for cover.

What goes in field 21 of an MT205?

Field 21 of the incoming MT202 or MT205, or field 20 of the incoming MT200, so the transfer can be traced back to the deal or instruction that started it.

Does an MT205 need a UETR?

Yes. Field 121 must be in the user header. Copy the UETR of the incoming transfer if it had one; otherwise, for example after an MT200, generate a new one.

What is the ISO 20022 equivalent of MT205?

The core pacs.009, Financial Institution Credit Transfer. The MT205COV maps to pacs.009 COV.

Category 2: Financial institution transfers

MT205 Financial Institution Transfer Execution

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

The MT205 is the message a bank sends to pass on an interbank transfer it has received, when it and the next bank are in the same country. The Receiver of an MT200, MT202 or similar transfer uses it to instruct the bank of the beneficiary institution, naming the original ordering institution in field 52a. It is never used for the cover of a customer payment: that is the MT205COV.

Message type: MT205
Category: 2
Structure: 10 fields listed
ISO 20022: pacs.009

When MT205 is used

An MT205 is the execution leg of a transfer between financial institutions. A correspondent receives a category 2 transfer, for example an MT202 or MT200 (or its ISO 20022 equivalent, a pacs.009), debits the ordering bank’s account and must now get the money to the institution that will credit the beneficiary institution. If that next institution is in the same country, the correspondent sends it an MT205, directly or through further correspondents.

The MT205 differs from the MT202 in three ways. The ordering institution in field 52a is mandatory, because the Receiver is not the originator’s correspondent and must know whose transfer it is. Field 21 points back to the incoming transfer. And there is no field 54a. In practice many markets execute this domestic leg through their RTGS or local clearing system instead, and the Swift guide shows the MT205 and the equivalent domestic clearing message as alternatives.

Field 21 links the chain: if the incoming message was an MT202 or MT205, the MT205 repeats that message’s field 21; if it was an MT200, it quotes that message’s field 20. (The standard also names the multiple versions MT203 and MT201, which were removed from the Swift network on 22 November 2025.) If the incoming transfer named no ordering institution, its Sender becomes the ordering institution in 52a. After an MT200, the beneficiary institution in 58a is the same bank as in 52a, because an MT200 moves a bank’s own funds.

Like the MT202, every MT205 carries a UETR in field 121 of the user header. A bank passing on a transfer that arrived with a UETR copies it unchanged; when the incoming message had none, for example an MT200, a new UETR is generated.

If the transfer is the cover for a customer payment sent with the cover method, the MT205 must not be used. The bank sends an MT205COV, which carries the ordering customer and beneficiary customer of the underlying MT103 so every bank in the chain can screen them.

MT205 format: sequences and fields

Message text (block 4)Mandatory

No sequences. Field 13C may repeat. The user header must carry the UETR in field 121.

Tag	Name	Status	Format	Meaning
20	Transaction Reference Number	M	16x	The Sender’s own reference for this message. No leading or trailing slash and no double slash (T26).
21	Related Reference	M	16x	Points to the transfer being executed: field 21 of an incoming MT202 or MT205, or field 20 of an incoming MT200 (the standard also lists the retired MT203 and MT201). Same slash rules as field 20.
13C	Time IndicationRepeatable	O	/8c/4!n1!x4!n	A processing time with its offset from UTC. Codes: CLSTIME (time by which a CLS funding payment must reach CLS Bank, in CET), RNCTIME and SNDTIME (credit and debit times of a TARGET2 payment, in CET). Example: `/CLSTIME/0915+0100`.
32A	Value Date, Currency Code, Amount	M	6!n3!a15d	Value date (YYMMDD), currency and amount, with a comma as the decimal mark. Metal codes XAU, XAG, XPD and XPT are not allowed (C08). See how to read 32A.
52a	Ordering InstitutionOptions A or D	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The institution that ordered the transfer. If the incoming message named none, its Sender is the ordering institution. It must be passed on to the beneficiary institution. Option A preferred; option D only when the institution has no BIC.
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	How the Sender will reimburse the Receiver. Leave it out when the single direct account in the currency is used; with several accounts, give the account in option B (account line only). It must be present when there is no direct account relationship in the currency.
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 to reach the account with institution. If 56a is present, 57a must be present too (C81).
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 will pay or credit the beneficiary institution. Absent means the Receiver is that institution. Required when 56a is present (rule C1).
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. When the transfer started as an MT200, this is the same bank as in 52a, because the originator is moving its own money.
72	Sender to Receiver Information	O	6*35x	Coded information: /ACC/, /BNF/, /INS/ (each earlier instructing institution, in order), /INT/, /PHON/, /PHONBEN/, /PHONIBK/, /TELE/, /TELEBEN/, /TELEIBK/ and /TSU/. Codes INS, ACC and BNF received in the incoming message must be passed on unchanged.

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 field 56a is present, field 57a must also be present (network rule C1, error C81).
The user header must contain the UETR in field 121. An intermediary passes on the UETR it received unchanged; in all other cases a new UETR is used.
The Sender and the Receiver of an MT205 are in the same country. All parties must be financial institutions.
The MT205 must not be used when the transfer is related to a customer credit transfer sent with the cover method. Use the MT205COV.
Field 21 carries field 21 of an incoming MT202 or MT205, or field 20 of an incoming MT200 (the standard also lists the retired MT203 and MT201).
If the initial transfer named no ordering institution, the Sender of that message is the ordering institution in 52a, and 52a must be forwarded to the beneficiary institution.
When a clearing code such as //FW, //AU, //CP, //IN or //RT is used, it should appear once, in the first of fields 56a, 57a and 58a that is present.
Codes INS, ACC and BNF in field 72 of the incoming message, with their details, must be passed on unchanged; new codes may be added but the original ones must not be altered or removed. A field 72 starting with /REJT/ or /RETN/ must follow the payments reject and return guidelines (T80).

MT205 example

This continues the MT200 example. BANKUS33XXX in New York received ZagTrader Test Bank’s MT200 (reference ZT2610200101) asking it to move USD 5,000,000.00 to ZagTrader’s own account at CUSTUS33XXX, also in the United States. BANKUS33 debits ZagTrader and passes the transfer on to CUSTUS33 with an MT205.

{1:F01BANKUS33AXXX0000000000}{2:I205CUSTUS33XXXXN}{3:{121:3debe902-5e9f-4369-8ad6-d56b68b33234}}{4:
:20:BUS2610220455
:21:ZT2610200101
:32A:261022USD5000000,00
:52A:ZAGTAEADXXX
:58A:ZAGTAEADXXX
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01BANKUS33AXXX0000000000}{2:I205CUSTUS33XXXXN}{3:{121:3debe902-5e9f-4369-8ad6-d56b68b33234}}{4:	Sender BANKUS33XXX, input MT205 to CUSTUS33XXX. The MT200 had no UETR, so BANKUS33 generates a new one in field 121.
:20:BUS2610220455	BANKUS33’s own reference.
:21:ZT2610200101	The incoming message was an MT200, so field 21 quotes its field 20.
:32A:261022USD5000000,00	Same value date, currency and amount as the MT200.
:52A:ZAGTAEADXXX	Ordering institution: the MT200 named none, so its Sender, ZagTrader, is the ordering institution.
:58A:ZAGTAEADXXX	Beneficiary institution: after an MT200 the same bank as in 52a. No 57a, so CUSTUS33 itself credits ZagTrader’s account.
-}	End of block 4.

No 53a: BANKUS33 and CUSTUS33 settle through their single direct USD relationship (or the local clearing system).

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. Name the institution that will credit the beneficiary institution in 57a, or remove 56a.
Ordering institution missing (52a)
Field 52a is mandatory in the MT205, unlike in the MT202. When the incoming transfer did not name an ordering institution, put the Sender of that incoming message here.
UETR missing, changed or reused (U13, U15)
Field 121 must be present in the user header, in lower-case UUID version 4 format. A bank passing on a transfer copies the UETR it received; generating a new one breaks tracking, and reusing one from a different transaction is refused.
How to fix it
MT205 used for the cover of a customer payment
If the transfer covers an MT103 sent with the cover method, it must travel as an MT205COV with the customer details in sequence B. Correspondents treat a plain MT205 here as a transparency breach and query or return it.
Field 21 does not link back to the incoming transfer
Quoting your own reference in field 21 instead of the incoming field 21 (or field 20 after an MT200) means the beneficiary institution cannot match the funds to the deal behind them.
BIC not valid or not a financial institution (T27, T28, T29, T45, C05)
Every BIC in 52a to 58a must exist and belong to a financial institution. A corporate in 58a means the payment is a customer transfer, not an MT205.
How to fix it

MT205 in ISO 20022

The ISO 20022 equivalent is the core pacs.009 (Financial Institution Credit Transfer), which bank migration guides list as replacing the MT202, MT200 and MT205. The cover version, the MT205COV, maps to pacs.009 COV.

Since 22 November 2025, cross-border payment instructions between financial institutions on Swift are delivered in ISO 20022. BNY’s end-of-coexistence notice lists the MT205 among the messages Swift converts to pacs.009 in its contingency processing when a bank still sends one. The MT205 is a domestic leg by definition, so whether it travels as an MT205, a pacs.009 or a local clearing message depends on the market and the rules of its payment system.

In a pacs.009 the MT205 fields map to named elements: 32A to the interbank settlement amount and date, 52a to the debtor, 57a to the creditor agent, 58a to the creditor, and the UETR to the payment identification.

MT205 questions

What is an MT205?: A Swift message a bank uses to pass on an interbank transfer it received to the next bank in the same country, naming the original ordering institution in field 52a and the beneficiary institution in 58a.
What is the difference between MT202 and MT205?: The MT202 is the general bank-to-bank transfer, sent by or on behalf of the ordering institution. The MT205 executes an incoming transfer within one country: the ordering institution (52a) is mandatory, field 21 points back to the incoming message and there is no field 54a.
What is the difference between MT205 and MT205COV?: The MT205COV is used when the transfer is the cover for a customer payment sent with the cover method. It adds a sequence with the ordering and beneficiary customers of the underlying MT103 and needs code COV in field 119. The plain MT205 must not be used for cover.
What goes in field 21 of an MT205?: Field 21 of the incoming MT202 or MT205, or field 20 of the incoming MT200, so the transfer can be traced back to the deal or instruction that started it.
Does an MT205 need a UETR?: Yes. Field 121 must be in the user header. Copy the UETR of the incoming transfer if it had one; otherwise, for example after an MT200, generate a new one.
What is the ISO 20022 equivalent of MT205?: The core pacs.009, Financial Institution Credit Transfer. The MT205COV maps to pacs.009 COV.

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