Payment Information, the batch level details

The Payment Information block, often shortened to PmtInf, is the second level in a pacs zero zero eight, and it contains information that applies to a group of transactions that share the same debtor, the same debtor agent, and the same payment method. It includes the Payment Information Identification, which is a unique reference for the block, the Payment Method, which is usually TRF for a credit transfer, and the Requested Execution Date, which is the date on which the debtor wants the payment to be executed. It also includes the Debtor, the Debtor Account, and the Debtor Agent, which together identify who is paying, from which account, and through which bank. The Payment Information block also contains the Charges Account, if charges are to be debited from a different account, and the Charge Bearer, which states who bears the charges, using codes such as DEBT for the debtor, CRED for the creditor, SHAR for shared, and SLEV for service level. The Charge Bearer in a pacs zero zero eight is the equivalent of field 71A in an MT103, and it has the same business impact. If the Charge Bearer is SHAR, the beneficiary may receive less than the instructed amount, because intermediary and creditor agent charges will be deducted. If it is DEBT, the debtor bears all charges and the beneficiary should receive the full amount. A single pacs zero zero eight can contain multiple Payment Information blocks, for example if it contains payments from different debtors or through different debtor agents. Each block can contain multiple transactions, all of which share the same debtor and debtor agent. An analyst must understand this hierarchy, because it affects how messages are constructed, how they are validated, and how errors are handled. If one Payment Information block is invalid, the other blocks in the same message may still be processed, depending on the system. Your test cases should cover single block and multi block messages, and should check that the Payment Information details are correctly applied to every transaction in the block. Take a worked example with real numbers. A pacs.008 carries two Payment Information blocks. The first block has PmtInfId PAYINF-001, payment method TRF, batch booking true, number of transactions 50 and control sum EUR 500,000, requested execution date 2026-11-09, debtor Acme Manufacturing SARL, debtor account FR7630001007941234567890185, debtor agent Bank A, and charge bearer SLEV. The first block is a batch of 50 salary payments, and the second block is a single supplier payment, and the two are kept apart because they have different debtors and different execution dates. The second block has PmtInfId PAYINF-002, payment method TRF, batch booking false, number of transactions 1 and control sum EUR 25,000, requested execution date 2026-11-10, debtor Beta Retail Ltd, debtor account FR7630001007949876543210987, debtor agent Bank A, and charge bearer DEBT. The two blocks are in the same message because they share the same sender and the same settlement date, but they are separate batches because they have different debtors, different execution dates and different charge arrangements. Failure and recovery: a Payment Information block with a requested execution date in the past is rejected, because the bank cannot execute a payment on a date that has already passed, and the sender must correct the date and resend with a new MsgId. A block with a debtor account that does not exist is rejected with a pacs.002 and reason code AC01, and the sender must correct the account and resend. A block where the control sum does not match the transactions in that block is rejected, even if the Group Header control sum is correct, because each block is validated separately. A charge bearer code that the scheme does not allow, for example DEBT on a SEPA payment where only SLEV is permitted, is rejected with a pacs.002 and reason code AG01. Each failure is reported per block, so the sender knows which batch failed and which ones succeeded. For a business analyst, product owner or subject matter expert, the test is to state, for every batch, the payment method, the execution date, the debtor, the debtor agent and the charge bearer, and to explain why two payments are in the same block or in different blocks. Payments from the same debtor, with the same execution date and the same charge arrangement, go in one block. Payments from different debtors, or with different execution dates, go in different blocks. A requirement that puts all payments in one block will fail when the bank tries to execute them on different dates, and a requirement that puts each payment in its own block will create unnecessary messages. Source: ISO 20022 pacs.008.001.08, Payment Information. Last reviewed 7 November 2026.