What is a pacs.008 message?

It is the ISO 20022 FI to FI Customer Credit Transfer: the message one bank sends to the next to pay a customer, carrying the debtor, creditor, amount, settlement date and routing. On Swift it replaced the MT103 for cross-border payments.

What is the difference between pacs.008 and pacs.009?

A pacs.008 pays a customer (at least one end is not a bank). A pacs.009 moves money between banks for their own account, and its COV form is the cover for a pacs.008 sent with settlement method COVE.

Which pacs.008 version is used?

CBPR+ on Swift uses pacs.008.001.08. The SEPA Credit Transfer inter-PSP guidelines of the 2025 rulebook and CHAPS in the UK also use pacs.008.001.08. Other market infrastructures publish their own guidelines, so check the version in the namespace of the message you receive.

Where is the UETR in a pacs.008?

In CdtTrfTxInf/PmtId/UETR. It is a lower-case UUID version 4 that stays the same at every bank in the chain, and a pacs.009 cover carries the same value. See how to read a UETR.

How do OUR, SHA and BEN map to pacs.008?

The charge bearer codes are DEBT for OUR, SHAR for SHA and CRED for BEN. The charges actually taken or prepaid go in ChrgsInf, one entry per agent, instead of MT fields 71F and 71G.

pacs: Payments clearing and settlement

pacs.008 FI to FI Customer Credit Transfer

Q: What do INDA, INGA, COVE and CLRG mean in pacs.008?

They are the settlement methods in GrpHdr/SttlmInf/SttlmMtd. INDA: the receiver debits the sender’s account it holds. INGA: the sender credits the receiver’s account it holds. COVE: funds follow in a separate pacs.009 cover. CLRG: settlement in a clearing system such as an RTGS.

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

The pacs.008 is the ISO 20022 message a bank sends to another bank to pay a customer: it carries the debtor, the creditor, the amount, the settlement date and the route between the banks. It goes from the debtor’s bank (the debtor agent) towards the creditor’s bank, directly or through intermediaries and clearing systems. Since Swift ended MT/MX coexistence on 22 November 2025, it is the instruction that replaced the MT103 for cross-border payments on Swift.

Message: FIToFICustomerCreditTransfer
Root element: FIToFICstmrCdtTrf
Common version: pacs.008.001.08
MT equivalent: MT103

When pacs.008 is used

A pacs.008 is used when at least one end of the payment is not a financial institution: a company paying a supplier abroad, a fund paying redemption proceeds to an investor, a person sending money home. If both ends are banks, the message is a pacs.009 instead.

Each bank in the chain sends its own pacs.008 to the next one. The sender of that hop is the Instructing Agent (InstgAgt) and the receiver is the Instructed Agent (InstdAgt). These two change at every hop, while the debtor, debtor agent, creditor agent and creditor stay the same from the first bank to the last.

The settlement method in the group header tells the receiver how it gets the money. INDA: the receiver debits the sender’s account that it holds. INGA: the sender credits the receiver’s account that it holds. COVE: the funds travel separately in a pacs.009 cover through reimbursement agents (the old MT202COV model, see the cover vs serial guide). CLRG: the payment settles in a clearing system such as an RTGS.

Banks inside cross-border chains on Swift follow the CBPR+ usage guidelines for pacs.008.001.08. Market infrastructures publish their own rules on the same base message: the SEPA Credit Transfer scheme, the UK CHAPS system (on ISO 20022 since 19 June 2023), the euro RTGS T2 (since 20 March 2023) and the US Fedwire Funds Service (since 14 July 2025).

The answers to a pacs.008 are other ISO 20022 messages: a reject before settlement is a pacs.002, a return after settlement is a pacs.004, a request to cancel is a camt.056 answered by a camt.029, and the account entry reaches the customer in a camt.054 or a statement.

Versions in common use

Version	Where it is used
pacs.008.001.08	CBPR+ cross-border payments on Swift (core and STP usage guidelines); SEPA Credit Transfer inter-PSP guidelines (2025 rulebook, effective 5 October 2025); CHAPS in the UK.

pacs.008 key elements

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

Element	Occurs	Meaning
GrpHdrGroup Header	[1..1]	Data that applies to the whole message.
MsgIdMessage Identification	[1..1]	The sender’s reference for this message. It is a point-to-point reference: the next bank creates its own. Status and return messages quote it as the original message ID.
CreDtTmCreation Date Time	[1..1]	When the message was created, as an ISO date and time. CBPR+ messages give it with the offset from UTC, for example `2026-10-20T10:15:00+04:00`.
NbOfTxsNumber Of Transactions	[1..1]	How many transactions the message holds. The base message allows several; CBPR+ allows one, so the value is `1`.
SttlmInfSettlement Information	[1..1]	How the money moves between the instructing and the instructed agent.
SttlmMtdSettlement Method	[1..1]	`INDA` (account held by the instructed agent is debited), `INGA` (account held by the instructing agent is credited), `COVE` (cover payment through reimbursement agents) or `CLRG` (settled in a clearing system).
SttlmAcctSettlement Account	[0..1]	The account to use for settlement when there is more than one between the two banks. In MT103 this was the account line of field 53a.
InstgRmbrsmntAgtInstructing Reimbursement Agent	[0..1]	With `COVE`: the sender’s correspondent that pays the cover. MT103 field 53a.
InstdRmbrsmntAgtInstructed Reimbursement Agent	[0..1]	With `COVE`: the correspondent at which the receiver gets the funds. MT103 field 54a.
ThrdRmbrsmntAgtThird Reimbursement Agent	[0..1]	A third bank in the reimbursement chain when the two correspondents differ. MT103 field 55a.
CdtTrfTxInfCredit Transfer Transaction Information	[1..n]	The payment itself. One occurrence per message in CBPR+.
PmtIdPayment Identification	[1..1]	The set of references for the payment.
InstrIdInstruction Identification	[0..1]	The sender’s reference for this hop, the equivalent of MT field 20. Optional in the base message, mandatory in CBPR+. Bank guides advise keeping it to 16 characters so it survives a translation into MT field 20.
EndToEndIdEnd To End Identification	[1..1]	The debtor’s own reference, passed unchanged to the creditor. Up to 35 characters. Banks reject dummy values such as `NOTPROVIDED` or `NONREF`.
TxIdTransaction Identification	[0..1]	A reference set by the first instructing agent and passed unchanged through the interbank chain.
UETRUETR	[0..1]	Unique end-to-end transaction reference: a lower-case UUID version 4, the same value at every hop. Mandatory in CBPR+. In MT it sat in block 3 field 121. See how to read a UETR.
SvcLvlService Level	[0..n]	A service code, for example `G001` for a Swift gpi tracked customer credit transfer. Its parent `PmtTpInf` also holds the local instrument and category purpose.
IntrBkSttlmAmtInterbank Settlement Amount	[1..1]	The amount that moves between the two banks of this hop, with the currency in the `Ccy` attribute: `<IntrBkSttlmAmt Ccy="GBP">25000.00</IntrBkSttlmAmt>`. The decimal mark is a dot, not the MT comma.
IntrBkSttlmDtInterbank Settlement Date	[0..1]	The value date between the banks, as `YYYY-MM-DD`. Optional in the base message, mandatory in CBPR+. Together with the amount it replaces MT field 32A.
InstdAmtInstructed Amount	[0..1]	The amount the debtor asked to pay, before charges and conversion. MT field 33B. Bank guides ask for it when it differs from the settlement amount or currency.
XchgRateExchange Rate	[0..1]	The rate used to convert the instructed amount into the settlement currency. MT field 36.
ChrgBrCharge Bearer	[1..1]	`DEBT` (debtor pays all, MT `OUR`), `CRED` (creditor pays all, MT `BEN`) or `SHAR` (shared, MT `SHA`). `SLEV` (follow the service level) is used by schemes such as SEPA, not in CBPR+.
ChrgsInfCharges Information	[0..n]	Each charge taken or prepaid, with the amount and the agent that took it. Replaces MT fields 71F and 71G.
PrvsInstgAgt1Previous Instructing Agent 1	[0..1]	A bank earlier in the chain, before the current instructing agent (2 and 3 also exist). In MT these were `/INS/` lines in field 72.
InstgAgtInstructing Agent	[0..1]	The bank that sends this hop. Mandatory with a BIC in CBPR+. The MT equivalent was the Sender in the header.
InstdAgtInstructed Agent	[0..1]	The bank that receives this hop. Mandatory with a BIC in CBPR+. The MT equivalent was the Receiver in the header.
IntrmyAgt1Intermediary Agent 1	[0..1]	The first bank between the instructed agent and the creditor agent. MT field 56a. Intermediary Agent 2 and 3 have no MT field.
UltmtDbtrUltimate Debtor	[0..1]	The party on whose behalf the debtor pays, for example the group company behind a central treasury. No MT103 field.
DbtrDebtor	[1..1]	The customer who pays. MT field 50a. Name, postal address and identifiers such as an LEI or BIC go in separate elements.
PstlAdrPostal Address	[0..1]	Structured address: `StrtNm` (street), `BldgNb` (building number), `BldgNm`, `Flr`, `PstCd` (post code), `TwnNm` (town), `CtrySubDvsn`, `Ctry` (ISO country code), plus `AdrLine` for unstructured lines. The same block is used for the creditor and for agents.
TwnNmTown Name	[0..1]	Optional in the schema, but required (with `Ctry`) in a structured or hybrid address under CBPR+ rules.
CtryCountry	[0..1]	Two-letter ISO country code. Required with `TwnNm` in a structured or hybrid address.
AdrLineAddress Line	[0..n]	Free-text address lines. Used alone they make a fully unstructured address; next to `TwnNm` and `Ctry` they make a hybrid address (up to 2 lines of 70 characters).
DbtrAcctDebtor Account	[0..1]	The account debited, as `Id/IBAN` or `Id/Othr/Id`. The account line of MT field 50a.
DbtrAgtDebtor Agent	[1..1]	The debtor’s bank. MT field 52a, or the Sender itself when 52a was absent. Identified by `FinInstnId/BICFI`, a clearing member ID (`ClrSysMmbId`) or name and address.
CdtrAgtCreditor Agent	[1..1]	The creditor’s bank. MT field 57a, or the Receiver when 57a was absent. A national clearing code, such as a UK sort code, goes in `FinInstnId/ClrSysMmbId`.
CdtrCreditor	[1..1]	The customer who is paid. MT field 59a.
CdtrAcctCreditor Account	[0..1]	The account credited, normally an IBAN where the country uses them. Mandatory in the CBPR+ STP variant. See IBAN and BIC errors.
UltmtCdtrUltimate Creditor	[0..1]	The party for whom the creditor receives the money. No MT103 field.
InstrForCdtrAgtInstruction For Creditor Agent	[0..n]	Coded instructions for the creditor’s bank: `CHQB` (pay by cheque), `HOLD` (hold cash for the creditor), `PHOB` (phone the beneficiary), `TELB` (telecom). The MT103 field 23E equivalent; passed on to the creditor agent.
InstrForNxtAgtInstruction For Next Agent	[0..n]	Free instructions for the next bank only (codes `PHOA`, `TELA`). The closest equivalent of free text in MT field 72; removed from the CBPR+ STP variant.
PurpPurpose	[0..1]	Why the money is paid, as an ISO purpose code in `Cd` (for example `GDDS` for purchase or sale of goods) or a proprietary value in `Prtry`.
RgltryRptgRegulatory Reporting	[0..n]	Data for central bank or balance-of-payments reporting: authority, country, code and amount. Replaces MT field 77B.
RmtInfRemittance Information	[0..1]	Information for the creditor about what is being paid.
UstrdUnstructured	[0..n]	Free-text remittance, up to 140 characters per occurrence. MT field 70 held only 4 lines of 35.
StrdStructured	[0..n]	Remittance in fields: referred document (invoice number, date), amounts, creditor reference. Bank guides say it needs bilateral agreement in the interbank space.

Rules worth knowing

CBPR+ allows one transaction per pacs.008: NbOfTxs is 1 and CdtTrfTxInf occurs once.
In CBPR+ the following are mandatory even though the base schema makes some optional: InstrId, EndToEndId, UETR, IntrBkSttlmAmt, IntrBkSttlmDt, ChrgBr, InstgAgt and InstdAgt with a BIC, Dbtr, DbtrAgt, CdtrAgt and Cdtr.
On Swift a CBPR+ pacs.008 travels with a Business Application Header (head.001.001.02) that names the sender and receiver BICs, the message definition pacs.008.001.08 and the business service. A message that breaks the usage guideline is rejected (NAKed) by the network.
The UETR must be a lower-case UUID version 4 and stays the same at every hop. A pacs.009 cover for this payment carries the same UETR, which is how the creditor agent links the two.
Amounts use a dot as the decimal mark and no thousands separator, with no more decimals than the currency allows. The currency is an attribute, not a separate element.
Postal addresses come in three forms: fully structured (only structured elements, at least TwnNm and Ctry), hybrid (TwnNm and Ctry plus up to 2 AdrLine of 70 characters) and fully unstructured (AdrLine only). Hybrid has been allowed since November 2025. Swift planned to stop accepting fully unstructured addresses in CBPR+ in November 2026, but on 27 August 2026 it postponed the cross-border payments part of that release; as of late September 2026 no new date had been set.
The CBPR+ STP variant (business service for straight-through processing) is stricter: the creditor account is mandatory, agents are identified by BIC or clearing code without name and address, coded elements accept ISO codes only, and only unstructured remittance is allowed.

pacs.008 XML example

The same payment as the MT103 example: ZagTrader Test Bank in Dubai (ZAGTAEADXXX) pays GBP 25,000.00 for its customer Gulf Trading LLC to Acme Components Ltd, whose account is with BANKGB2LXXX in London. ZagTrader holds a GBP account with BANKGB2LXXX, so the settlement method is INDA: the receiver debits that account. Charges are shared and the payment is gpi tracked.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>ZT26102000001</MsgId>
      <CreDtTm>2026-10-20T10:15:00+04:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>ZT2610200001</InstrId>
        <EndToEndId>GT-PO-2026-0457</EndToEndId>
        <UETR>ed154219-a6d0-477d-a698-b8f543d107bb</UETR>
      </PmtId>
      <PmtTpInf>
        <SvcLvl>
          <Cd>G001</Cd>
        </SvcLvl>
      </PmtTpInf>
      <IntrBkSttlmAmt Ccy="GBP">25000.00</IntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-10-22</IntrBkSttlmDt>
      <InstdAmt Ccy="GBP">25000.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>AL ABRAJ STREET</StrtNm>
          <BldgNm>BUSINESS BAY TOWER</BldgNm>
          <Flr>12</Flr>
          <Room>1204</Room>
          <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>
      <Purp>
        <Cd>GDDS</Cd>
      </Purp>
      <RmtInf>
        <Ustrd>INVOICE 2026-0457</Ustrd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

Decode this example in the parser

Compare with the MT103: field 20 became InstrId, block 3 field 121 became UETR, 32A split into IntrBkSttlmAmt and IntrBkSttlmDt, 33B became InstdAmt, 50F became Dbtr plus DbtrAcct, 59F became Cdtr plus CdtrAcct, 70 became RmtInf/Ustrd and 71A SHA became ChrgBr SHAR.

The addresses are fully structured: town and country sit in their own elements instead of the 3/AE/DUBAI line of option F.

On the Swift network the Document travels with a Business Application Header (not shown) carrying the sender and receiver BICs and the message definition.

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

pacs.008 and its MT equivalent

The MT equivalent is the MT103 (and its STP and REMIT forms). Swift ended the coexistence period for cross-border payment instructions on 22 November 2025: since then FI-to-FI payment instructions on Swift are delivered in ISO 20022, and an MT103 that a bank still sends is converted by Swift’s contingency processing, which Swift charges for from 1 January 2026. Reporting and exception and investigation messages were not part of that cut-off.

Translation is not one-to-one. A pacs.008 has room for an ultimate debtor and creditor, three intermediary agents, structured addresses, LEIs, purpose codes, regulatory reporting and 140-character remittance lines that an MT103 cannot hold, so a pacs.008 translated back to MT103 can lose data. See truncation when translating MX to MT.

Field 72 is split up: /INS/ lines become previous instructing agents, instructions for the beneficiary’s bank become InstrForCdtrAgt, and the rest becomes InstrForNxtAgt.

ISO 20022 element	MT field	Note
`GrpHdr/MsgId`	none	New: identifies the message; status and return messages quote it.
`CdtTrfTxInf/PmtId/InstrId`	20	Sender’s reference of this hop.
`CdtTrfTxInf/PmtId/EndToEndId`	70 /ROC/ or none	The customer reference; in MT it had no field of its own.
`CdtTrfTxInf/PmtId/UETR`	121 (block 3)
`CdtTrfTxInf/PmtTpInf/SvcLvl`	111 (block 3)	Service type identifier; in ISO the gpi customer transfer code is `G001`.
`CdtTrfTxInf/IntrBkSttlmAmt + IntrBkSttlmDt`	32A	Date, currency and amount split into two elements.
`CdtTrfTxInf/SttlmTmReq/CLSTm`	13C /CLSTIME/
`CdtTrfTxInf/InstdAmt`	33B
`CdtTrfTxInf/XchgRate`	36
`CdtTrfTxInf/Dbtr + DbtrAcct`	50a	Account line into DbtrAcct, name and address into Dbtr.
`CdtTrfTxInf/DbtrAgt`	52a	Or the Sender when 52a is absent.
`GrpHdr/SttlmInf/InstgRmbrsmntAgt`	53a	When 53a is only an account, it becomes SttlmInf/SttlmAcct.
`GrpHdr/SttlmInf/InstdRmbrsmntAgt`	54a
`GrpHdr/SttlmInf/ThrdRmbrsmntAgt`	55a
`CdtTrfTxInf/IntrmyAgt1`	56a
`CdtTrfTxInf/CdtrAgt`	57a	Or the Receiver when 57a is absent.
`CdtTrfTxInf/Cdtr + CdtrAcct`	59a
`CdtTrfTxInf/RmtInf/Ustrd`	70
`CdtTrfTxInf/ChrgBr`	71A	DEBT = OUR, CRED = BEN, SHAR = SHA.
`CdtTrfTxInf/ChrgsInf`	71F / 71G
`CdtTrfTxInf/InstrForCdtrAgt`	23E	Codes such as CHQB, HOLD, PHOB, TELB.
`CdtTrfTxInf/PrvsInstgAgt1..3`	72 /INS/
`CdtTrfTxInf/InstrForNxtAgt`	72 (other codes)
`CdtTrfTxInf/Purp`	26T (roughly)	Purpose codes are far richer than 26T.
`CdtTrfTxInf/RgltryRptg`	77B
`CdtTrfTxInf/InstgAgt / InstdAgt`	Sender / Receiver (header)
`none`	23B	CRED is implied; there is no bank operation code element.

Common errors and rejects

Message NAKed: usage guideline not respected
Swift validates a CBPR+ pacs.008 against the usage guideline, not just the schema. Missing UETR, InstrId or IntrBkSttlmDt, a second transaction, elements in the wrong order or a code outside the allowed list stop the message at the network. Validate against the CBPR+ guideline before release; the schema alone is not enough.
Dummy or reused references
Values such as NOTPROVIDED, NONREF or NOREF in EndToEndId are rejected by banks and can be NAKed. A UETR copied from an earlier payment, written in upper case or not in UUID version 4 form breaks tracking and matching.
How to fix it
Rejected by the next bank with a pacs.002
If the instructed agent cannot process the payment before settlement (wrong account, closed account, unknown BIC, missing regulatory data) it answers with a pacs.002 with status RJCT and a reason code such as AC01, AC04 or RC01. Read the reason, fix the data and send a new payment with a new UETR.
How to fix it
Wrong IBAN or creditor agent identifier
An IBAN with a bad check digit, a BIC8 where a BIC11 was needed, or a sort code put in the wrong element leads to a reject before settlement or a pacs.004 return after it. Check IBAN length and check digits for the country, and put clearing codes in ClrSysMmbId.
How to fix it
Data lost when translated to MT103
A receiving bank that still runs MT103 internally may cut names, addresses and remittance information to MT field lengths, and drop elements such as the ultimate parties or the second and third intermediary. Keep critical information in elements that map to MT, and check what your correspondent receives.
How to fix it
Address format refused
An address with AdrLine only is fully unstructured. Swift has announced it will stop accepting this form in CBPR+ (postponed from November 2026, new date pending). Send town and country in TwnNm and Ctry, and use at most 2 address lines next to them.

pacs.008 questions

What is a pacs.008 message?: It is the ISO 20022 FI to FI Customer Credit Transfer: the message one bank sends to the next to pay a customer, carrying the debtor, creditor, amount, settlement date and routing. On Swift it replaced the MT103 for cross-border payments.
What is the difference between pacs.008 and pacs.009?: A pacs.008 pays a customer (at least one end is not a bank). A pacs.009 moves money between banks for their own account, and its COV form is the cover for a pacs.008 sent with settlement method COVE.
What do INDA, INGA, COVE and CLRG mean in pacs.008?: They are the settlement methods in GrpHdr/SttlmInf/SttlmMtd. INDA: the receiver debits the sender’s account it holds. INGA: the sender credits the receiver’s account it holds. COVE: funds follow in a separate pacs.009 cover. CLRG: settlement in a clearing system such as an RTGS.
Which pacs.008 version is used?: CBPR+ on Swift uses pacs.008.001.08. The SEPA Credit Transfer inter-PSP guidelines of the 2025 rulebook and CHAPS in the UK also use pacs.008.001.08. Other market infrastructures publish their own guidelines, so check the version in the namespace of the message you receive.
Where is the UETR in a pacs.008?: In CdtTrfTxInf/PmtId/UETR. It is a lower-case UUID version 4 that stays the same at every bank in the chain, and a pacs.009 cover carries the same value. See how to read a UETR.
How do OUR, SHA and BEN map to pacs.008?: The charge bearer codes are DEBT for OUR, SHAR for SHA and CRED for BEN. The charges actually taken or prepaid go in ChrgsInf, one entry per agent, instead of MT fields 71F and 71G.

All ISO 20022 messages · MT messages · MT to ISO 20022 migration