pacs.009 Financial Institution Credit Transfer (core and COV)

When pacs.009 is used

CBPR+ defines one base message with three usage guidelines. The core pacs.009 is a plain bank-to-bank transfer (MT202, MT200, MT205). The pacs.009 COV is the cover for a customer payment sent as a pacs.008 (MT202COV, MT205COV). The pacs.009 ADV is an advice that a bank will receive funds whose settlement then comes in a core pacs.009.

A COV is recognised by the block UndrlygCstmrCdtTrf (underlying customer credit transfer). It carries a copy of the customer details of the pacs.008: debtor, debtor agent, creditor agent, creditor and remittance. That copy lets every correspondent in the cover chain screen the real parties, not only the banks.

The cover method is used when the debtor’s bank and the creditor’s bank do not hold accounts with each other. The debtor agent sends the pacs.008 straight to the creditor agent with settlement method COVE, and sends the pacs.009 COV to its own correspondent, which pays the creditor agent (directly or through its correspondent). The creditor agent matches the two by UETR and is told about the credit with a camt.054 (the old MT910). See the cover vs serial guide.

Market infrastructures use the same message for interbank transfers: the Bank of England lists pacs.009.001.08 for CHAPS (core and COV), and from May 2025 the Bank requires purpose codes and LEIs on CHAPS payments between financial institutions.

Versions in common use

pacs.009 key elements

Paths are relative to Document/FICdtTrf. Occurrence is from the base message (pacs.009.001.08); market practice such as CBPR+ or a CSD’s rules can make an optional element mandatory or forbid it.

Rules worth knowing

• One transfer per message in CBPR+: NbOfTxs is 1.
• Mandatory in CBPR+: InstrId, EndToEndId, UETR, IntrBkSttlmAmt, IntrBkSttlmDt, InstgAgt and InstdAgt with BIC, Dbtr and Cdtr. On Swift the message travels with a Business Application Header (head.001.001.02).
• Debtor and creditor are financial institutions, so they use the agent structure (FinInstnId), not a party name and address block. If either end is a customer, the message is a pacs.008.
• The COV and the pacs.008 it covers carry the same UETR. A COV without the underlying block is a core pacs.009 and will not be treated as cover.
• The ultimate debtor and ultimate creditor exist in the base message but are not used for cross-border CBPR+ transfers.
• The base pacs.009 has no ChrgBr and no InstdAmt at transfer level, unlike pacs.008.

pacs.009 XML example

A COV. ZagTrader Test Bank in Dubai (ZAGTAEADXXX) pays GBP 25,000.00 for Gulf Trading LLC to Acme Components Ltd at BANKGB2LXXX, but holds no account with BANKGB2LXXX. It sends a pacs.008 with settlement method COVE straight to BANKGB2LXXX, and this pacs.009 COV to its GBP correspondent ZAGTGB2LXXX, which debits ZagTrader’s account (INDA) and pays BANKGB2LXXX. Both messages carry UETR 34760e20-b74d-49c1-9175-bc06addd3940.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.009.001.08">
  <FICdtTrf>
    <GrpHdr>
      <MsgId>ZT26102000002</MsgId>
      <CreDtTm>2026-10-20T10:20:00+04:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>ZT2610200002</InstrId>
        <EndToEndId>GT-PO-2026-0458</EndToEndId>
        <UETR>34760e20-b74d-49c1-9175-bc06addd3940</UETR>
      </PmtId>
      <IntrBkSttlmAmt Ccy="GBP">25000.00</IntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-10-22</IntrBkSttlmDt>
      <InstgAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </InstgAgt>
      <InstdAgt>
        <FinInstnId>
          <BICFI>ZAGTGB2LXXX</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>AL ABRAJ STREET</StrtNm>
            <BldgNm>BUSINESS BAY TOWER</BldgNm>
            <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>
            <PstCd>EC2V 9ZZ</PstCd>
            <TwnNm>LONDON</TwnNm>
            <Ctry>GB</Ctry>
          </PstlAdr>
        </Cdtr>
        <CdtrAcct>
          <Id>
            <IBAN>GB42BANK40051587654321</IBAN>
          </Id>
        </CdtrAcct>
        <RmtInf>
          <Ustrd>INVOICE 2026-0458</Ustrd>
        </RmtInf>
        <InstdAmt Ccy="GBP">25000.00</InstdAmt>
      </UndrlygCstmrCdtTrf>
    </CdtTrfTxInf>
  </FICdtTrf>
</Document>

In MT terms this is an MT202COV from ZAGTAEADXXX to ZAGTGB2LXXX with 58A BANKGB2LXXX and sequence B copying the MT103 parties.

Without the UndrlygCstmrCdtTrf block the same message would be a core pacs.009, the MT202 equivalent.

The correspondent pays BANKGB2LXXX through its own route (for example CHAPS), and BANKGB2LXXX matches the incoming funds to the pacs.008 by UETR.

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

pacs.009 and its MT equivalent

The core pacs.009 replaces the MT202 (and MT200, MT205); the COV replaces the MT202COV (and MT205COV). Swift ended MT/MX coexistence for cross-border payment instructions on 22 November 2025. An MT202 or MT202COV still sent is converted by Swift contingency processing, charged from 1 January 2026.

In MT, the cover was an MT202COV with a mandatory sequence B for the customer details. In ISO it is the same message as the core transfer with the UndrlygCstmrCdtTrf block added. Data that the pacs.008 can carry but MT202COV sequence B cannot (structured addresses, intermediary agents 2 and 3, longer remittance) is lost if the cover is translated back to MT. See truncation when translating MX to MT.

Common errors and rejects

1. Customer payment sent as a core pacs.009

   A transfer whose end parties are customers must go as a pacs.008, with its cover as a pacs.009 COV. Using a core pacs.009 hides the customers from screening in the correspondent chain and is a compliance finding, not just a format error.

2. COV and pacs.008 do not match

   The creditor agent receives the pacs.008 and later the funds. If the UETR, amount or value date differ between the pacs.008 and the COV, the cover cannot be matched and the payment sits in an exception queue. Generate both from one source record.

   How to fix it

3. Message NAKed against the CBPR+ guideline

   Missing InstrId, UETR or IntrBkSttlmDt, more than one transaction, or a debtor given as a party name instead of a financial institution identification all fail CBPR+ validation on the network.

4. Settlement method not accepted

   Some correspondents accept only INDA and INGA on pacs.009. With INDA a problem before settlement comes back as a pacs.002 reject; with INGA, where the sender has already paid, it comes back as a pacs.004 return.

   How to fix it

5. Purpose code or LEI missing for CHAPS

   Since May 2025 the Bank of England requires purpose codes and LEIs on CHAPS payments between financial institutions. A pacs.009 core without them is rejected in CHAPS even if it passes CBPR+ checks.

6. Cover detail cut in MT translation

   If a correspondent translates the COV to MT202COV, names, addresses and remittance can be cut to MT lengths, which can trigger sanctions screening hits or requests for information.

   How to fix it

Related messages

• MT202General Financial Institution Transfer
• MT202COVGeneral Financial Institution Transfer (cover payment)
• MT103Single Customer Credit Transfer
• pacs.008FI to FI Customer Credit Transfer
• pacs.002FI to FI Payment Status Report
• pacs.004Payment Return
• camt.054Bank to Customer Debit Credit Notification
• camt.056FI to FI Payment Cancellation Request

• Serial MT103 chains vs MT103 plus MT202COV cover, and the same flows in pacs.008 and pacs.009 COV.
• Securities messages stay on ISO 15022 alongside ISO 20022 after the November 2025 payments switch; the MT to MX map.

pacs.009 questions

What is a pacs.009 message?

The ISO 20022 Financial Institution Credit Transfer: a payment where both the debtor and the creditor are financial institutions. It replaced the MT202 and, as pacs.009 COV, the MT202COV on Swift.

What is the difference between pacs.009 core and pacs.009 COV?

The COV contains the UndrlygCstmrCdtTrf block with the customer details of the pacs.008 it covers. The core has no such block and is a pure bank-to-bank transfer.

What is a pacs.009 ADV?

A CBPR+ usage guideline for an advice: it tells a bank in advance that funds will arrive, and the settlement then comes in a core pacs.009. Not every bank supports it, so check with your correspondent.

Does a pacs.009 COV have the same UETR as the pacs.008?

Yes. The cover and the customer payment carry the same UETR, which is how the creditor agent and trackers link them, as the MT202COV did with the MT103.

Which pacs.009 version is used?

CBPR+ uses pacs.009.001.08 for core, COV and ADV, and the Bank of England lists pacs.009.001.08 for CHAPS.

Why does pacs.009 have no charge bearer?

Charge bearer describes who pays customer charges. In a bank-to-bank transfer there is no customer, so the base pacs.009 has no ChrgBr element. In a COV the charges belong to the underlying pacs.008.