Line by line walkthrough of a pacs.008

Imagine a pacs zero zero eight where Acme Trading Ltd in London pays Meridian Supplies Pte Ltd in Singapore ten thousand US dollars for invoice 4567. The Document starts with the Group Header, which contains Message Identification ACME2026110501, Creation Date and Time the 5th of November 2026 at 9 in the morning, Number of Transactions 1, and Control Sum 10000. That header tells the receiving bank that this message contains one payment for ten thousand dollars, and that the message was created on the morning of 5 November 2026. If the receiving bank counts one transaction and sums to ten thousand, the header validates. Next comes the Payment Information block, with Payment Information Identification PmtInf001, Payment Method TRF, and Requested Execution Date 2026-11-05. The Debtor is Acme Trading Ltd, the Debtor Account is the London current account, and the Debtor Agent is the London bank with its BIC. The Charge Bearer is SHAR, which means charges are shared. Inside that block is the Credit Transfer Transaction Information, with Instruction Identification Instr001, End to End Identification INV4567, and Instructed Amount 10000 US dollars. The Creditor Agent is the Singapore bank, the Creditor is Meridian Supplies Pte Ltd, and the Creditor Account is the Singapore account. The Remittance Information is structured, with invoice number 4567, and the Purpose code is SUPP for supplier payment. Reading the message in this order, from Group Header to Payment Information to Transaction, mirrors how the payment flows in business, from the message envelope to the batch to the single payment. If the beneficiary receives less than ten thousand dollars, the analyst can point to the Charge Bearer SHAR and explain that charges were shared. If the supplier cannot reconcile the payment, the analyst can point to the End to End Identification INV4567 and show that it matches the invoice. If the payment is delayed, the analyst can check the Requested Execution Date and the Creation Date and Time to see whether it missed a cut off. That walkthrough is the skill that turns a pacs zero zero eight from a wall of XML into a readable business document. Continue the walkthrough with the settlement and charges. The interbank settlement amount is USD 10,000 and the interbank settlement date is 2026-11-05, and the settlement information says the settlement method is COVE, which means the funds travel as a cover payment through a correspondent bank. The charges information says the charge bearer is SHAR, so the debtor and the creditor share the charges, and the charges are USD 25 from the debtor agent and USD 15 from the creditor agent. The creditor agent is Bank B in Singapore, the creditor is Meridian Supplies Pte Ltd with account SG7150011123456789012, and the instruction for the creditor agent says to credit the account and notify the creditor by email. The purpose code is SUPP, and the remittance information is unstructured with the text Invoice 4567. Every field has now been read, from the Group Header to the Payment Information to the transaction, and the payment can be traced from the debtor to the creditor without a dictionary. Failure and recovery: a walkthrough that skips the settlement information will miss the most common failure in cross-border payments, which is a cover payment that arrives without its MT103 or pacs.008, or a pacs.008 that arrives without its cover. When the cover is missing, the creditor agent cannot settle the payment and holds it in a suspense account, and the operations team must trace the cover by its reference. When the charges are wrong, for example the charge bearer is OUR but the intermediary deducted charges anyway, the beneficiary receives less than expected and raises a claim, and the investigation uses the charges information in the pacs.008 to prove what was agreed. When the remittance information is missing, the creditor cannot reconcile the payment and the accounts receivable team must call the debtor, and the payment sits unallocated until the reference is provided. Each of these failures is visible in the walkthrough, and that is why the walkthrough matters. For a business analyst, product owner or subject matter expert, the test is to walk through any pacs.008, line by line, and to explain what each field means, where it came from, and what happens when it is wrong, without a dictionary. The walkthrough is also a test technique: a test case that covers each field, each validation rule and each failure mode is built from the walkthrough, and a tester who cannot walk through the message cannot write a good test. The walkthrough must be kept with the requirement, because a developer who implements from the requirement alone will misinterpret the fields, and a tester who tests from the requirement alone will miss the edge cases. Source: ISO 20022 pacs.008.001.08. Last reviewed 7 November 2026.