pain.001 Customer Credit Transfer Initiation

When pain.001 is used

In the corporate-to-bank channel a pain.001 is a payment file: a treasury or ERP system sends a batch of supplier payments, payroll or treasury transfers to its bank, which executes them and reports back with a pain.002 status and, after booking, camt.054 or camt.053 statements.

In CBPR+ the pain.001 has a narrower job on the Swift network. A customer sends its instruction to its relationship bank (the forwarding agent), which relays it to the bank that holds the account to be debited (the debtor agent). CBPR+ also lets a financial institution act as the initiating party to start multi-bank sweeps for a corporate customer. This is the relay scenario that the MT101 request for transfer covered on FIN.

The message has three levels. The group header describes the file and who initiated it. Each payment information block holds the debit side: debtor, debtor account, debtor agent, requested execution date. Each credit transfer transaction under it holds one payment: amount, creditor agent, creditor, remittance. The CBPR+ version allows exactly one of each.

The debtor agent checks the instruction against its mandate with the customer, debits the account on the requested date and sends the payment on as a pacs.008 (or pacs.009 when the creditor is a bank), keeping the end-to-end reference and UETR.

Versions in common use

pain.001 key elements

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

Rules worth knowing

• CBPR+ restricts the base message: GrpHdr/NbOfTxs has the single value 1, PmtInf occurs once, CdtTrfTxInf occurs once, the payment-information NbOfTxs is removed and supplementary data is removed.
• In CBPR+ the UETR is mandatory and a Business Application Header (head.001.001.02) is mandatory.
• CBPR+ makes structured and unstructured remittance mutually exclusive: send Ustrd or Strd, or neither.
• In CBPR+ names, addresses and remittance may use an extended character set (including characters such as @, # and &); other text fields are limited to the FIN-X character set.
• The status of a pain.001 comes back in a pain.002 (customer payment status report), not in a pacs.002, because the conversation is between the customer side and its bank.
• Corporate channels (host-to-host links, scheme rules such as SEPA) publish their own pain.001 guidelines; a file built for one bank or scheme is not automatically valid for another.

pain.001 XML example

CBPR+ relay. Gulf Trading LLC banks with ZagTrader Test Bank in Dubai (ZAGTAEADXXX) and also holds a GBP account with ZAGTGB2LXXX in London. It asks ZagTrader to relay an instruction: debit the London account on 22 October 2026 and pay GBP 25,000.00 to Acme Components Ltd at BANKGB2LXXX. ZagTrader is the forwarding agent, ZAGTGB2LXXX the debtor agent.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <MsgId>ZTREL2610200001</MsgId>
      <CreDtTm>2026-10-20T09:00:00+04:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <InitgPty>
        <Nm>GULF TRADING LLC</Nm>
      </InitgPty>
      <FwdgAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </FwdgAgt>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>GT-BATCH-2026-1020</PmtInfId>
      <PmtMtd>TRF</PmtMtd>
      <ReqdExctnDt>
        <Dt>2026-10-22</Dt>
      </ReqdExctnDt>
      <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>GB38ZAGT40051512345678</IBAN>
        </Id>
      </DbtrAcct>
      <DbtrAgt>
        <FinInstnId>
          <BICFI>ZAGTGB2LXXX</BICFI>
        </FinInstnId>
      </DbtrAgt>
      <ChrgBr>SHAR</ChrgBr>
      <CdtTrfTxInf>
        <PmtId>
          <InstrId>GT2610200001</InstrId>
          <EndToEndId>GT-PO-2026-0470</EndToEndId>
          <UETR>20afebc9-c689-4b40-adf4-07752183cb0e</UETR>
        </PmtId>
        <Amt>
          <InstdAmt Ccy="GBP">25000.00</InstdAmt>
        </Amt>
        <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>
        <Purp>
          <Cd>GDDS</Cd>
        </Purp>
        <RmtInf>
          <Ustrd>INVOICE 2026-0470</Ustrd>
        </RmtInf>
      </CdtTrfTxInf>
    </PmtInf>
  </CstmrCdtTrfInitn>
</Document>

ZAGTGB2LXXX debits Gulf Trading’s account on 22 October and sends a pacs.008 to BANKGB2LXXX with the same end-to-end ID and UETR.

In MT terms this is an MT101 from ZAGTAEADXXX to ZAGTGB2LXXX with 50H for the ordering customer and the account, 30 for the execution date and one sequence B.

On Swift the Document travels with a Business Application Header (not shown).

All identifiers are made up; the IBANs carry valid check digits.

MT equivalent

The FIN equivalent is the MT101 Request for Transfer, in which a forwarding bank passes its customer’s instruction to the account-holding bank, with one sequence A for the debit side and a repeating sequence B for the payments. CBPR+ defines pain.001.001.09 for the same relay scenario, limited to one payment per message.

MT101 is a request, not an interbank payment, so the interbank leg that follows is a pacs.008 or pacs.009. Structured or hybrid addresses must be present in the MT101 (option F of field 50 and 59) if they are to appear in an ISO 20022 equivalent; conversion does not structure an address for you.

Common errors and rejects

1. More than one payment in a CBPR+ pain.001

   A corporate payment file with many transactions is fine on a host-to-host channel but breaks the CBPR+ guideline, which allows one payment information block with one transaction. Split relay instructions into one message per payment.

2. UETR missing in the relay message

   The base schema makes the UETR optional, CBPR+ makes it mandatory. Generate a lower-case UUID version 4 and keep it for the pacs.008 that follows.

   How to fix it

3. Both structured and unstructured remittance

   CBPR+ rejects a transaction that carries both Ustrd and Strd. Choose one.

4. Wrong or missing creditor identifiers

   An invalid IBAN or creditor agent BIC passes the pain.001 checks of some channels and fails later as a pacs.002 reject. Validate IBAN check digits and BICs before sending.

   How to fix it

5. Address does not meet the CBPR+ rules

   Debtor and creditor addresses need at least town and country as separate elements in a structured or hybrid address. Swift has postponed the end of fully unstructured addresses (planned for November 2026), but banks already ask for structured data.

Related messages

• pacs.008FI to FI Customer Credit Transfer
• pacs.009Financial Institution Credit Transfer
• pacs.002FI to FI Payment Status Report
• camt.054Bank to Customer Debit Credit Notification
• camt.053Bank to Customer Statement
• MT103Single Customer Credit Transfer

• Securities messages stay on ISO 15022 alongside ISO 20022 after the November 2025 payments switch; the MT to MX map.

pain.001 questions

What is a pain.001 message?

The ISO 20022 Customer Credit Transfer Initiation: a payment order from an account holder (or a bank relaying for it) to the bank that holds the account. The bank executes it as interbank payments such as pacs.008.

What is the difference between pain.001 and pacs.008?

A pain.001 goes from the customer side to the debtor’s bank and asks for payments. A pacs.008 goes between banks and carries the payment itself. One pain.001 transaction usually leads to one pacs.008.

What is the MT equivalent of pain.001?

The MT101 Request for Transfer for relay between banks on Swift. In corporate channels pain.001 also replaced proprietary and national file formats.

Which pain.001 version is used?

CBPR+ uses pain.001.001.09, as do the SEPA Credit Transfer customer-to-bank guidelines of the 2025 rulebook. Corporate banks publish their own versions and rules, so check your bank’s guide.

How many payments can one pain.001 contain?

The base message has no fixed limit: many payment information blocks, each with many transactions. CBPR+ allows one block with one transaction on the Swift network.

Where does the status of a pain.001 come back?

In a pain.002 Customer Payment Status Report from the bank. Booked debits then appear in camt.054 notifications or camt.053 statements.