pacs.008

pacs.008 is the ISO 20022 message called the FI To FI Customer Credit Transfer. A bank sends it to another bank, directly or through a payment system, to transfer funds on behalf of a customer to the account of a beneficiary. It is the core payment message of most modern payment systems, carrying salaries, supplier payments, consumer transfers and cross-border wires. In SWIFT cross-border payments it replaces the MT103 single customer credit transfer.

The message belongs to the "pacs" business area of ISO 20022, which covers payments clearing and settlement between institutions. It usually follows a customer's pain.001 instruction to its own bank, and its outcome may be reported back using a pacs.002 status report. Bank-to-bank transfers that do not involve a customer use the related pacs.009.

A pacs.008 has a group header and one or more credit transfer transaction blocks. The group header holds a message identifier, the creation date and time, the number of transactions and the settlement information, including the settlement method, for example settlement through a clearing system or across accounts the banks hold with each other.

Each transaction block contains:

• Payment identification. An instruction identification, an end-to-end identification set by the original payer, a transaction identification and, in cross-border use, a UETR that stays the same through the whole chain.
• Amounts and dates. The interbank settlement amount and currency, the settlement date and, where different, the instructed amount and exchange rate.
• Charges. A charge bearer code: DEBT when the debtor pays all charges, CRED when the creditor pays, SHAR when charges are shared and SLEV when charges follow the rules of a service level or scheme.
• Parties. The debtor and its account, the debtor agent, any intermediary agents, the creditor agent, and the creditor and its account, each with names, identifiers such as BICs and addresses.
• Purpose and remittance. Optional purpose codes, regulatory reporting data and remittance information, which can be unstructured text or structured references such as invoice numbers.

The message is used across many payment systems, each with its own usage rules:

• SEPA. SEPA Credit Transfers and SEPA Instant use pacs.008 between banks and clearing systems.
• High-value systems. RTGS systems such as the euro area's T2, the UK's CHAPS and the US Fedwire Funds Service use it for customer payments.
• Instant payment systems. Many real-time schemes, including those built in recent years, use pacs.008 for every payment.
• Cross-border. Under SWIFT's cross-border usage guidelines, pacs.008 carries correspondent banking payments, sent either from bank to bank along the chain or, where the banks have no direct account relationship, alongside a separate cover payment made with a pacs.009.

Suppose a company in Germany pays a supplier in Singapore in US dollars. The company sends a pain.001 to its bank, which creates a pacs.008 naming the company as debtor and the supplier as creditor. If the German bank and the Singapore bank do not hold accounts with each other, the pacs.008 may pass through one or more intermediary institutions in a serial payment, each forwarding the message after settling with the next bank. Alternatively, the pacs.008 goes directly to the Singapore bank while the funds move separately as a cover payment. When the funds arrive, the Singapore bank credits the supplier and may send it a camt.054 credit notification.

The pacs.008 carries the same basic information as the MT103 but in a much richer and more structured form. Names and addresses can be split into street, building, town and country fields rather than squeezed into a few lines of text. There is room for full remittance information, legal entity identifiers, purpose codes and details of ultimate debtors and creditors who differ from the account holders. This structure helps banks screen payments against sanctions lists more accurately, reconcile payments automatically and meet transparency rules. SWIFT and many market infrastructures have set deadlines for moving to structured or partly structured addresses.

The richer content also creates the risk of data truncation when a pacs.008 must be converted to an MT103 for a bank that has not migrated, which is one reason the industry set a firm end date for MT payment messages in cross-border traffic.

Banks that send pacs.008 messages must follow the usage guidelines of each system they use, since optional elements in the global standard may be mandatory or forbidden in a particular scheme. They must validate messages before sending, populate references consistently so that the beneficiary bank can match payments, and pass on all data received from earlier banks without altering it. Corporate customers benefit when remittance details from their own instructions are carried through to the beneficiary, which allows receivers to apply payments to invoices automatically and reduces enquiries.