What is pacs.008?
The CBPR+ successor to MT103.

A pacs.008 is the ISO 20022 message one financial institution sends another to move a customer payment. Under SWIFT CBPR+, it succeeded the MT103 for cross-border customer-payment instructions when coexistence ended in November 2025. It carries the debtor, creditor, amount, currency, charges, and the payment's 36-character UETR.

The prefix pacs stands for Payments Clearing and Settlement, one of the ISO 20022 business areas, and 008 is the number of the message inside that area. The message's full name is FIToFICustomerCreditTransfer: a financial institution to financial institution customer credit transfer. In plain terms, it is the file one bank sends another to pay a customer.

A pacs.008 is used by financial institutions to instruct a customer credit transfer. Under CBPR+, it carries the customer-payment instruction for a cross-border transfer: who pays (the debtor), who receives (the creditor), the amount, the settlement date, who bears the charges, and the UETR that lets the payment be tracked bank by bank.

Both carry the same customer credit transfer, but MT103 is the legacy SWIFT FIN format made of numbered fields in a flat text layout, while pacs.008 is a structured ISO 20022 XML document with named elements. pacs.008 carries richer, machine-readable data: structured names and addresses, a dedicated UETR element, structured remittance information, and room for explicit records of the charges banks deducted along the way.

Functionally similar, technically different. A pacs.008 does the same job the MT103 did, moving a customer payment between financial institutions, and both carry the same UETR. The syntax is entirely different: MT103 uses numbered tags like :32A: and :59:, while pacs.008 uses XML elements like IntrBkSttlmAmt and Cdtr. Under CBPR+, financial institutions have exchanged pacs.008 customer-payment instructions instead of MT103s since November 2025, while banks may still issue MT103-format confirmations to customers.

A pacs.008 is an XML document with two main parts: a Group Header (GrpHdr) with the message identification, creation timestamp, and settlement method, and the Credit Transfer Transaction Information block (CdtTrfTxInf), exactly one per message under CBPR+, with the payment itself: payment identifiers including the UETR, the interbank settlement amount and date, the charge bearer, the debtor and creditor with their agents and accounts, and remittance information.

It is the fully qualified version of the message: pacs is the business area, 008 the message number, 001 the variant, and 08 the version. CBPR+, the usage guideline for cross-border payments on SWIFT, adopted version 08, so cross-border pacs.008 traffic today is pacs.008.001.08. Later versions exist in the ISO 20022 catalogue, and market infrastructures adopt them on their own schedules.

In the Group Header: the message identification, the creation date and time, the number of transactions, and the settlement information. In the transaction block: the payment identification, the interbank settlement amount, the charge bearer, the debtor, the debtor agent, the creditor agent, and the creditor. The CBPR+ guidelines for cross-border payments additionally require the UETR and the interbank settlement date. Accounts, remittance information, and intermediary agents are added when the payment needs them.

In the Payment Identification block of the transaction: CdtTrfTxInf, then PmtId, then UETR. It is a dedicated element that holds the same 36-character reference the MT103 carried in field 121 of its Block 3 header. Under the CBPR+ guidelines that govern cross-border payments on SWIFT, the UETR element is mandatory on every pacs.008.

EndToEndId is the reference the ordering customer assigned to the payment, and it is chosen by people, so it can repeat. The UETR is the 36-character tracking identifier, generated once by the sending bank's system and then preserved unchanged by every bank in the chain. Because EndToEndId is mandatory, banks fill it with the literal text NOTPROVIDED whenever the customer supplied no reference, which also happened when legacy MT103s were translated. For tracking, use the UETR.

A pacs.008 moves a customer payment: a person or company is the debtor and creditor. A pacs.009 (FinancialInstitutionCreditTransfer) moves money between banks themselves, and its COV variant carries the cover funds for an underlying customer payment, the role MT202 and MT202COV played in the legacy world. In a cover arrangement the pacs.009 COV references the same UETR as the pacs.008 it covers.

The pacs.008 is the payment instruction; the pacs.002 (FIToFIPaymentStatusReport) is the answer a bank returns to the bank that instructed it. The codes it carries, such as ACSP (accepted, settlement in process), ACCC (credited to the beneficiary), and RJCT (rejected), are the same codes banks confirm to the SWIFT gpi Tracker against the UETR, and they are what a UETR tracker reads back to you.

A pacs.008 confirmation from the sending bank is the bank's own record that the payment instruction was released into the interbank network, the same role the MT103 copy played. It records dispatch, not arrival: the money can still be at an intermediary bank or under a compliance review. Pair the confirmation with a UETR status check to read the latest status the banks report before treating it as settled.

Ask the sending bank for the payment confirmation of your transfer. Banks may issue it in the familiar MT103 layout even though the interbank message travelled as a pacs.008; either way it is the bank's own record of the instruction it sent. Corporate banking portals expose it under the payment's details; retail customers can request it through the branch or a secure message. The UETR printed on it is what you track with.

Find the transfer's UETR on your confirmation or in your banking portal, then check it against banks' public trackers. uetr.ai does this in one step: paste the 36-character UETR with the amount, currency, and date, and it checks multiple international banks on the SWIFT network for that same reference. Checking is free, with no account and no bank login.

Not unilaterally once it has been released. The sending bank requests cancellation with a camt.056 message (the ISO 20022 successor to the MT192 request), and the outcome depends on the banks further down the chain. If the funds have not yet been credited, they can be returned in a pacs.004 Payment Return. Once the beneficiary has been credited, recovery needs the beneficiary bank's and usually the beneficiary's cooperation.

CBPR+ (Cross-Border Payments and Reporting Plus) is the set of usage guidelines that defines exactly how ISO 20022 messages such as pacs.008 are used for cross-border payments on the SWIFT network: which elements are mandatory, which code lists apply, and how legacy MT fields translate. It is why cross-border pacs.008 traffic is uniform across thousands of banks rather than each bank interpreting the standard its own way.

ChrgBr is the Charge Bearer element, which declares who pays the banks' charges. DEBT means the debtor pays all charges, the successor of OUR in the MT103's field 71A. CRED means the creditor pays, the successor of BEN. SHAR means the charges are shared, the successor of SHA, and it is the common default for cross-border transfers. The ISO 20022 code list also carries SLEV, meaning charges follow the rules of the service level being used, which appears in domestic and market infrastructure usage rather than in CBPR+ cross-border traffic.

Banks and other financial institutions, not customers. You instruct your bank through its own channels, and the bank composes the pacs.008 and sends it to the next institution in the chain, directly or through intermediary correspondents. What you receive as a customer is a confirmation document derived from it, and the UETR inside is the piece you can act on yourself.

No. The UETR is deliberately format-neutral: the same 36-character UUID that sat in field 121 of an MT103 sits in the UETR element of the pacs.008, unchanged in length, format, and meaning. Payments that started life in one format and were translated to the other keep the same UETR, so tracking works identically across the migration.