ZagTrader

Payment message flow: serial vs cover (MT103, MT202COV, pacs.008, pacs.009 COV)

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

A cross-border customer payment can travel serially, with each bank in the chain passing an MT103 (pacs.008) to the next, or by the cover method, with the MT103 going straight to the beneficiary’s bank while the money moves between correspondents in an MT202COV (pacs.009 COV). Both messages of a cover payment carry the same UETR, and the cover message repeats the ordering and beneficiary customer so every bank that moves the funds can see who is paying whom.

The parties and where they sit in each message

Every customer payment has a debtor (the ordering customer) and a creditor (the beneficiary customer), each with an agent (their bank). When the two banks do not hold accounts with each other in the payment currency, one or more correspondents in that currency’s home market sit between them, and the question is how the payment instruction and the money travel through them.

Payment roles in MT and ISO 20022
RoleMT103 / MT202COV fieldpacs.008 / pacs.009 elementIn the examples below
Debtor (ordering customer)50a (MT202COV sequence B)Dbtr (pacs.009: UndrlygCstmrCdtTrf/Dbtr)Gulf Trading LLC, Dubai
Debtor agent (ordering institution)The Sender, or 52aDbtrAgtZAGTAEADXXX
Sender’s correspondent (instructing reimbursement agent)53aGrpHdr/SttlmInf/InstgRmbrsmntAgtBANKUS33XXX
Receiver’s correspondent (instructed reimbursement agent)54aGrpHdr/SttlmInf/InstdRmbrsmntAgtNot needed: both banks use BANKUS33XXX
Intermediary agent56aIntrmyAgt1BANKUS33XXX in the serial flow
Creditor agent (account with institution)57a, or the Receiver itselfCdtrAgtBANKGB2LXXX, London
Creditor (beneficiary customer)59aCdtrAcme Components Ltd, London
Unique end-to-end tracking referenceBlock 3 field 121PmtId/UETROne UUID per payment

Serial method: one MT103 per leg

The examples on this page use one payment. Gulf Trading LLC, a customer of ZagTrader Test Bank in Dubai (ZAGTAEADXXX), pays USD 150,000.00 to Acme Components Ltd, which banks with BANKGB2LXXX in London, for invoice 2026-0981, value 22 October 2026, charges shared. The Dubai and London banks do not hold US dollar accounts with each other, but both hold one with BANKUS33XXX in New York. All names, BICs, IBANs and UETRs are fictitious.

In the serial method the payment instruction follows the money. ZagTrader Test Bank sends an MT103 to its US dollar correspondent BANKUS33XXX, naming BANKGB2LXXX as the account with institution in 57A. BANKUS33XXX debits the Dubai bank’s account and sends its own MT103 to BANKGB2LXXX, with the same UETR and the same customer details, and credits the London bank’s account. BANKGB2LXXX credits Acme.

The serial method is simple and every bank sees the full customer details, because each one receives an MT103. Its costs are speed and charges: each leg is processed in turn, and with SHA or BEN each bank in the chain can deduct its fee (shown in 71F), so the beneficiary may receive less than was sent.

Serial method, first leg: MT103 from ZAGTAEADXXX to its correspondent BANKUS33XXX, with the beneficiary’s bank in 57A.

{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKUS33XXXXN}{3:{121:9b1e4c6a-2f3d-4a8b-b7e5-1c0d9f2a6e83}}{4:
:20:ZT2610200044
:23B:CRED
:32A:261022USD150000,00
:33B:USD150000,00
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/BUSINESS BAY TOWER
3/AE/DUBAI
:57A:BANKGB2LXXX
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0981
:71A:SHA
-}
Open this example in the parser

Cover method: MT103 direct, MT202COV through the correspondents

In the cover method the payment instruction and the money take different routes. ZagTrader Test Bank sends the MT103 directly to the beneficiary’s bank BANKGB2LXXX, with 53A:BANKUS33XXX telling it where the funds will come from. At the same time it sends an MT202COV to BANKUS33XXX, asking it to debit the Dubai bank and credit BANKGB2LXXX (field 58A). BANKUS33XXX moves the funds and confirms the credit to the London bank, for example with an MT910 or camt.054.

The message rules link the two: when the cover method is used, field 20 of the MT103 is copied unchanged into field 21 of the MT202COV, and the UETR in field 121 of the MT103 is copied unchanged into field 121 of the MT202COV. The MT202COV is recognised by {119:COV} in its user header, and its sequence B repeats the underlying customer transfer: ordering customer, beneficiary, their banks and the remittance information.

The beneficiary’s bank now holds an instruction before, or without, the funds. Whether it credits the beneficiary on the MT103 alone, before the cover arrives, is its own credit policy decision. Most banks wait for the cover or for the correspondent’s credit advice.

Cover method, the instruction: MT103 from ZAGTAEADXXX straight to the beneficiary’s bank BANKGB2LXXX. 53A names the correspondent that will provide the funds.

{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKGB2LXXXXN}{3:{121:3f8c2d71-9a4e-4b6f-8d2c-5e1a7b9c0f34}}{4:
:20:ZT2610200045
:23B:CRED
:32A:261022USD150000,00
:33B:USD150000,00
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/BUSINESS BAY TOWER
3/AE/DUBAI
:53A:BANKUS33XXX
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0981
:71A:SHA
-}
Open this example in the parser

The MT202COV that moves the money

Sequence A of the MT202COV is the bank-to-bank transfer: its own reference in 20, the MT103 reference in 21, value date, currency and amount in 32A, and the bank to be credited in 58A. Sequence B is the underlying customer credit transfer, copied from the MT103: 50a ordering customer, 57a the beneficiary’s bank, 59a beneficiary, 70 remittance information and, optionally, the instructed amount in 33B.

Cover method, the funds: MT202COV from ZAGTAEADXXX to BANKUS33XXX. Same UETR as the MT103, the MT103 reference in field 21, and the customer details in sequence B.

{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKUS33XXXXN}{3:{119:COV}{121:3f8c2d71-9a4e-4b6f-8d2c-5e1a7b9c0f34}}{4:
:20:ZT2610200046
:21:ZT2610200045
:32A:261022USD150000,00
:58A:BANKGB2LXXX
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/BUSINESS BAY TOWER
3/AE/DUBAI
:57A:BANKGB2LXXX
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0981
:33B:USD150000,00
-}
Open this example in the parser

Serial and cover side by side

Serial vs cover method
SerialCover
Messages (MT)One MT103 per legMT103 to the beneficiary’s bank, plus MT202COV through the correspondents
Messages (ISO 20022)One pacs.008 per leg, settlement method INDA or INGApacs.008 with settlement method COVE, plus pacs.009 COV (pacs.009 with UndrlygCstmrCdtTrf)
Route of the instructionThrough every bank in the chainDirect from debtor agent to creditor agent
Route of the moneySame as the instructionThrough the correspondents named in 53a/54a (reimbursement agents)
Customer details seen by intermediariesYes, in each MT103Yes, in sequence B of the MT202COV (or the underlying block of the pacs.009 COV)
SpeedLeg by legInstruction arrives at once; credit depends on the cover arriving
ChargesEach bank may deduct fees with SHA or BENUsually fewer deductions; the cover moves the full amount between banks
TrackingSame UETR in every MT103Same UETR in the MT103 and the MT202COV
Main riskDelays and deductions along a long chainInstruction and funds getting out of step; cover not sent or rejected

The same flows in ISO 20022: pacs.008 and pacs.009 COV

Since 22 November 2025, cross-border payment instructions between banks on Swift are ISO 20022 messages. The serial method becomes a chain of pacs.008 messages, each with settlement method INDA (the instructed agent holds the account to be debited) or INGA (the account sits with the instructing agent, which credits the instructed agent). The cover method becomes a pacs.008 with settlement method COVE and the reimbursement agents in GrpHdr/SttlmInf, sent to the creditor agent, plus a pacs.009 COV sent to the correspondent.

The pacs.009 COV is a pacs.009 that contains the UndrlygCstmrCdtTrf block: the presence of that block is what makes it a cover message rather than a plain bank-to-bank transfer. The block carries the underlying debtor, debtor agent, creditor agent, creditor and remittance information, with more structure than the MT202COV sequence B (separate name and address elements, for example). Both messages carry the same UETR in PmtId/UETR.

pacs.008 for the cover method: settlement method COVE, BANKUS33XXX as instructing reimbursement agent, sent from ZAGTAEADXXX to BANKGB2LXXX (pacs.008.001.08, Document only).

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>ZT2610200045</MsgId>
      <CreDtTm>2026-10-20T10:15:00+04:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>COVE</SttlmMtd>
        <InstgRmbrsmntAgt>
          <FinInstnId>
            <BICFI>BANKUS33XXX</BICFI>
          </FinInstnId>
        </InstgRmbrsmntAgt>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>ZT2610200045</InstrId>
        <EndToEndId>INV-2026-0981</EndToEndId>
        <UETR>3f8c2d71-9a4e-4b6f-8d2c-5e1a7b9c0f34</UETR>
      </PmtId>
      <IntrBkSttlmAmt Ccy="USD">150000.00</IntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-10-22</IntrBkSttlmDt>
      <InstdAmt Ccy="USD">150000.00</InstdAmt>
      <ChrgBr>SHAR</ChrgBr>
      <InstgAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </InstgAgt>
      <InstdAgt>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </InstdAgt>
      <Dbtr>
        <Nm>Gulf Trading LLC</Nm>
        <PstlAdr>
          <StrtNm>Business Bay Tower</StrtNm>
          <TwnNm>Dubai</TwnNm>
          <Ctry>AE</Ctry>
        </PstlAdr>
      </Dbtr>
      <DbtrAcct>
        <Id>
          <IBAN>AE070331234567890123456</IBAN>
        </Id>
      </DbtrAcct>
      <DbtrAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </DbtrAgt>
      <CdtrAgt>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </CdtrAgt>
      <Cdtr>
        <Nm>Acme Components Ltd</Nm>
        <PstlAdr>
          <StrtNm>High Street</StrtNm>
          <BldgNb>1</BldgNb>
          <TwnNm>London</TwnNm>
          <Ctry>GB</Ctry>
        </PstlAdr>
      </Cdtr>
      <CdtrAcct>
        <Id>
          <IBAN>GB42BANK40051587654321</IBAN>
        </Id>
      </CdtrAcct>
      <RmtInf>
        <Ustrd>INV 2026-0981</Ustrd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>
Open this example in the parser

The pacs.009 COV in full

The pacs.009 COV goes from the debtor agent to the correspondent. Its transaction-level Dbtr and Cdtr are the two banks (the equivalent of the Sender and 58A), and the underlying block repeats the customer payment.

pacs.009 COV from ZAGTAEADXXX to BANKUS33XXX, settlement method INDA, with the underlying customer credit transfer (pacs.009.001.08, Document only).

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.009.001.08">
  <FICdtTrf>
    <GrpHdr>
      <MsgId>ZT2610200046</MsgId>
      <CreDtTm>2026-10-20T10:15:05+04:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>ZT2610200046</InstrId>
        <EndToEndId>INV-2026-0981</EndToEndId>
        <UETR>3f8c2d71-9a4e-4b6f-8d2c-5e1a7b9c0f34</UETR>
      </PmtId>
      <IntrBkSttlmAmt Ccy="USD">150000.00</IntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-10-22</IntrBkSttlmDt>
      <InstgAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </InstgAgt>
      <InstdAgt>
        <FinInstnId>
          <BICFI>BANKUS33XXX</BICFI>
        </FinInstnId>
      </InstdAgt>
      <Dbtr>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </Dbtr>
      <Cdtr>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </Cdtr>
      <UndrlygCstmrCdtTrf>
        <Dbtr>
          <Nm>Gulf Trading LLC</Nm>
          <PstlAdr>
            <StrtNm>Business Bay Tower</StrtNm>
            <TwnNm>Dubai</TwnNm>
            <Ctry>AE</Ctry>
          </PstlAdr>
        </Dbtr>
        <DbtrAcct>
          <Id>
            <IBAN>AE070331234567890123456</IBAN>
          </Id>
        </DbtrAcct>
        <DbtrAgt>
          <FinInstnId>
            <BICFI>ZAGTAEADXXX</BICFI>
          </FinInstnId>
        </DbtrAgt>
        <CdtrAgt>
          <FinInstnId>
            <BICFI>BANKGB2LXXX</BICFI>
          </FinInstnId>
        </CdtrAgt>
        <Cdtr>
          <Nm>Acme Components Ltd</Nm>
          <PstlAdr>
            <StrtNm>High Street</StrtNm>
            <BldgNb>1</BldgNb>
            <TwnNm>London</TwnNm>
            <Ctry>GB</Ctry>
          </PstlAdr>
        </Cdtr>
        <CdtrAcct>
          <Id>
            <IBAN>GB42BANK40051587654321</IBAN>
          </Id>
        </CdtrAcct>
        <RmtInf>
          <Ustrd>INV 2026-0981</Ustrd>
        </RmtInf>
        <InstdAmt Ccy="USD">150000.00</InstdAmt>
      </UndrlygCstmrCdtTrf>
    </CdtTrfTxInf>
  </FICdtTrf>
</Document>
Open this example in the parser

Why cover transparency matters

Before the MT202COV existed, banks covered customer payments with a plain MT202, which names only banks. The correspondents moving the money could not see who was paying whom, so they could not screen the customers against sanctions lists or monitor the flow for money laundering. Supervisors, including the Basel Committee on Banking Supervision in its guidance on due diligence and transparency for cover payment messages, asked banks to fix this, and the MT202COV with its mandatory customer sequence was the result.

The rule for operations is short: a cover for a customer payment is always an MT202COV or pacs.009 COV, never a plain MT202 or pacs.009, and the customer details in it must match the underlying MT103 or pacs.008. A correspondent that finds missing or inconsistent details will hold the payment and ask questions, typically with an MT199 or a camt.029 exchange, and may reject it.

The UETR makes the two halves traceable: because the MT103 and the MT202COV (or pacs.008 and pacs.009 COV) carry the same UETR, each bank can see both legs of the payment in the tracker and answer a "where is my money" query without manual matching. See how to read a UETR.

Checks before you release a cover payment

  1. Decide the method from your account relationships in the currency: if you hold no account with the beneficiary’s bank, choose serial through your correspondent, or cover with 53a (and 54a if the beneficiary’s bank uses a different correspondent).
  2. Generate one UETR and use it in both messages; copy the MT103 field 20 into the MT202COV field 21.
  3. Copy the customer details into the cover exactly; do not shorten names or drop the account numbers.
  4. Make sure the amount and value date in the cover match the funds the beneficiary’s bank expects, after any charges you have agreed.
  5. Send both messages at the same time; monitor the cover until the correspondent confirms it, and answer the beneficiary’s bank if it asks where the funds are.
  6. If one half is rejected, act on both: recall or cancel the other half (MT192 or camt.056) or resend the missing one, so instruction and funds stay in step.

Questions

What is the difference between a serial and a cover payment?
In a serial payment the MT103 passes from bank to bank along with the money. In a cover payment the MT103 goes directly to the beneficiary’s bank while the money moves separately between correspondent banks in an MT202COV.
What is the difference between MT202 and MT202COV?
An MT202 moves money between banks for their own account. An MT202COV moves money that covers a customer payment, and must repeat the ordering and beneficiary customer details from the underlying MT103 in its sequence B. It is flagged by {119:COV} in block 3.
What is pacs.009 COV?
The ISO 20022 equivalent of the MT202COV: a pacs.009 that contains the UndrlygCstmrCdtTrf block with the underlying customer transfer details. It is sent together with a pacs.008 that uses settlement method COVE.
Does the MT202COV use the same UETR as the MT103?
Yes. When the cover method is used, the UETR in field 121 of the MT103 must be copied unchanged into field 121 of the MT202COV, so both legs can be tracked as one payment.
Can the beneficiary bank credit the customer before the cover arrives?
It may, but it is a credit risk decision for that bank. Many banks wait until the correspondent confirms the funds, which is why a cover that is late or rejected delays the beneficiary.
Which field in the MT103 shows that a cover is coming?
Field 53a (Sender’s correspondent), and 54a when the Receiver’s correspondent differs. Apart from a few cases involving branches of the Sender or the Receiver, a 53a in the MT103 means a cover message such as an MT202COV must be sent to the bank named there.

Messages in this guide

All guides · Troubleshooting