pacs.008

pacs.008 is the ISO 20022 message for a financial institution to financial institution customer credit transfer: the payment message a bank or payment service provider sends to another to move a customer's money. It replaces the SWIFT MT103 for cross-border payments and international wire transfers and is already the standard message in SEPA and most high-value payment systems.

section

Where pacs.008 is used

  • SEPA credit transfers and SEPA Instant credit transfers between payment service providers
  • the Eurosystem's T2 high-value payment system, since March 2023
  • the UK's CHAPS system, since June 2023
  • cross-border payments over SWIFT under the CBPR+ rules, where it has replaced MT103 since the end of the coexistence period in November 2025
Because the same message runs on domestic and cross-border rails, data entered by the payer can travel through the whole payment chain without being cut short or rekeyed.
section

The structure of a pacs.008

The pacs.008 message format has two main parts:
BlockWhat it holds
Group headerMessage identification, creation date and time, number of transactions, settlement method and clearing system
Credit transfer transaction informationOne block per payment: the references, interbank settlement amount and date, charge bearer, debtor, debtor agent, creditor agent, creditor and remittance information
Each transaction carries several identifiers: the instruction ID, the end-to-end ID set by the payer, and the UETR, the unique reference used to track the payment across intermediary banks. The debtor agent and creditor agent are the payer's and payee's banks, identified by their BIC, and the account identifier is usually an IBAN.The charge bearer field says who pays the fees: DEBT (the payer, like OUR), CRED (the payee, like BEN), SHAR (shared, like SHA) or SLEV, which follows the rules of the scheme and is used in SEPA.
section

Key data in a pacs.008

  • Transaction identification: the instruction ID, end-to-end ID, transaction ID and UETR, which together act as the transaction reference number at each stage.
  • Amounts and currency: the interbank settlement amount in the settlement currency, plus the instructed amount if the payer sent a different currency, such as USD converted to EUR.
  • Parties and accounts: names, addresses and account numbers for the debtor and creditor, and BICs for their agents and any intermediary agents.
  • Purpose and remittance: optional purpose codes and remittance information that tell the payee what the payment is for.
Each payment system publishes its own implementation guidelines, which say which fields are mandatory and how to fill them, on top of the global standard.
section

pacs.008 vs MT103

MT103pacs.008
StandardSWIFT MTISO 20022 (XML)
Party names and addressesFree text, limited to 4 lines of 35 charactersStructured fields, with separate town, country and postcode
Remittance informationUp to 140 charactersUp to 140 characters unstructured, or structured data
TrackingUETR in the headerUETR in the message itself
Used inLegacy cross-border paymentsSEPA, T2, CHAPS and cross-border (CBPR+)
The richer data in pacs.008 helps banks screen payments for sanctions with fewer false alerts, helps payees reconcile incoming payments, and supports payment transparency. Payment details that used to be squeezed into a few lines of free text now go into dedicated fields.
section

Related messages

  • pacs.002: the payment status report, confirming or rejecting a payment
  • pacs.004: the payment return, used to send funds back
  • pacs.009: the financial institution credit transfer, the successor to MT202
  • camt.056: a request to cancel or recall a payment
  • camt.053 and camt.054: account statements and debit or credit notifications
section

Structured addresses

Under the CBPR+ rules, banks were due to stop accepting fully unstructured postal addresses in cross-border pacs.008 messages from November 2026, keeping only structured or hybrid addresses with at least the town and country in their own fields. In August 2026, SWIFT deferred that change after requests from banks and said it would announce new timing by December 2026. Businesses that pay internationally should still keep supplier addresses complete and structured, because more banks will require it.
section

What it means for a business

You won't build a pacs.008 yourself unless you connect directly to a clearing system or use a payments API. Your bank or payment service provider creates it from your payment instruction. What matters is the data you give it: full names, structured addresses and clear remittance information pass through intact, which means fewer queries, faster screening and easier reconciliation. When you trace a payment, ask for the UETR.
section

How a pacs.008 travels

When a business pays a supplier abroad, its bank builds a pacs.008 from the payment instructions and sends it to the creditor agent, directly or through intermediary banks. Each bank in the payment chain reads the same message, deducts any payment charges allowed by the charge bearer code and passes it on. When the payee's bank credits the beneficiary, it can confirm the payment with a pacs.002, and the payer can follow every step by its UETR.
section

FAQ

It does the same job, a customer credit transfer between banks, but in the ISO 20022 format with more structured data. pacs.008 has replaced MT103 for cross-border payments on SWIFT.

Yes. SEPA credit transfers and SEPA Instant payments are exchanged between banks as pacs.008 messages.

pacs.008 moves a customer's money. pacs.009 moves funds between financial institutions, as MT202 did.

It carries the UETR, a unique reference that lets every bank in the chain, and the payer, track the payment.

The receiving bank may reject it with a pacs.002 status report, or return the funds later with a pacs.004. Missing or badly formatted party data is a common cause of delays.
section

Related terms and sources

ISO 20022 · MT103 · MT202 · UETR · SWIFT gpi · OUR, SHA and BEN · SEPA return codes · Browse the full glossary
section
Last reviewed November 2, 2026Disclaimer
This publication is provided for general information purposes and does not constitute legal, tax, or other professional advice from Narvi Payments Oy Ab or its affiliates, and it is not intended as a substitute for obtaining advice from a financial advisor or any other professional.
section
What We Offer
Our VisionDedicated IBANSEPA InstantAccount with Multi-User AccessOnline Banking PlatformAPI for DevelopersBanking-as-a-Service (BaaS)White-label BankingBecome an Affiliate
IBAN Accounts For Your Business
iGamingWeb3/CryptoSmall & Medium BusinessesNon-Resident & Cross-Border BusinessesFunds, Holdings & Hard-To-Bank StructuresFind Your Use Case
Support & Compliance
Help CenterFAQPricingContact UsSubmit a ComplaintLegal DocumentsLegal and LicensingFraud PreventionCareers
Narvi Knowledge Center
Alternative Investment Funds [whitepaper]Family Offices [whitepaper]Shipping Industry [whitepaper]How to Open a Business Account in FinlandNarvi vs. Wise, Revolut, N26, and other alternativesNarvi vs. Stable.comNarvi vs. payabl.Narvi vs. ConnectPayNarvi vs. IBAN4UNarvi vs. GenomeNarvi vs. PaxumNarvi vs. BilderlingsNarvi vs. NetellerNarvi vs. KontistPayments BlogPayments Glossary
Ask AI about Narvi
Claude
ChatGPT
Google
Narvi X
Narvi Linkedin
Narvi Payments Oy Ab is an Authorized Electronic Money Institution (EMI). Narvi’s EMI license is granted by the Finnish Financial Supervisory Authority (FIN FSA) with the registration number 3190214-6. Narvi’s license is passportised to all European Union countries.
FinlandBuilt and regulated in Finland

© 2026 Narvi. All Rights Reserved.

v1.331.0