What pacs.008 is, and when it is used

The pacs zero zero eight message, whose full name is FIToFICustomerCreditTransfer, is the ISO 20022 message used for a customer credit transfer between financial institutions. It is the direct successor to the SWIFT MT103, and it is used whenever a debtor agent sends a customer payment to a creditor agent, either directly or through intermediary banks. The message carries the debtor and creditor details, the amount and currency, the value date, the charges, and the remittance information, just as an MT103 does, but it carries them in XML with far richer structure and with more room for detail. It is the workhorse message for cross border customer payments under CBPR Plus. A pacs zero zero eight can contain one or more transactions, grouped under one or more Payment Information blocks. In practice, many banks send one transaction per message for cross border payments, to make tracking and exception handling simpler. A bulk pacs zero zero eight with many transactions is possible, but it requires careful handling, because a single error in one transaction should not cause the entire message to be rejected. The message is sent through the SWIFT network or through a domestic clearing system that has adopted ISO 20022, and it is validated against the CBPR Plus usage guideline before it is accepted. The pacs zero zero eight is used for supplier payments, salary payments, and any other customer credit transfer where the originator is not a bank. It is not used for bank to bank payments, which use pacs zero zero nine, and it is not used for direct debits, which use pacs zero zero three. An analyst must be able to distinguish those three messages, because they have different structures, different mandatory fields, and different business meanings. Confusing a pacs zero zero eight with a pacs zero zero nine is a common error in requirements and in testing, and it can cause a payment to be processed with the wrong charges, the wrong screening, or the wrong reconciliation. Take a worked example with real numbers. Acme Manufacturing SARL in Lyon owes Rhine Metals GmbH in Munich EUR 25,000 for invoice INV-2026-1187, due Friday. Acme instructs its bank, Bank A, to send EUR 25,000 by SEPA Credit Transfer. Bank A builds a pacs.008 with one Payment Information block and one transaction, sets the instructed amount to EUR 25000, the end to end reference to INV-2026-1187, and the charge bearer to SLEV, which means the charges follow the scheme rule. The pacs.008 travels from Bank A to the clearing system, settles in T2, and Rhine Metals is credited EUR 25,000 in full on the same day. The supplier reconciles the receipt against the invoice using the end to end reference, and the payment is closed. Failure and recovery: a pacs.008 is rejected as a whole when the Group Header control sum does not match the sum of the transaction amounts, and the sender must correct the control sum and resend with a new MsgId, because reusing the old MsgId would be treated as a duplicate. A pacs.008 with a wrong creditor account is accepted by the clearing system but returned by the creditor agent as a pacs.004 with reason code AC04 for a closed account or AC01 for an incorrect account number, and the debtor is refunded, usually within one to two business days. A pacs.008 sent to the wrong clearing system, for example a SEPA payment sent to a domestic-only system, is rejected with a pacs.002 and reason code AG01, and the sender must rebuild it for the correct system. Each failure has a different message, a different timeline and a different owner. The sender must also check the pacs.002 reason code, because AG01 means the scheme rejected the payment and AC04 means the creditor account is closed, and the two need different fixes. For a business analyst, product owner or subject matter expert, the test is to state, for every payment product, which message carries it, who sends it, who receives it, and what happens when it fails. A pacs.008 is the message for a customer credit transfer between financial institutions, and it is not the message for a bank to bank payment, which uses pacs.009, or for a direct debit, which uses pacs.003. A requirement that names the wrong message will be built wrong, tested wrong and will fail at the clearing system. The analyst must also state the version, because pacs.008.001.08 is the CBPR+ version for cross-border payments and pacs.008.001.10 is the current version, and a bank that sends the wrong version will have the whole file rejected. Source: ISO 20022 message definitions, pacs.008.001.08 and pacs.008.001.10. Last reviewed 7 November 2026.