Group Header, the message envelope

The Group Header is the first block in a pacs zero zero eight, and it contains information about the message as a whole rather than about any single transaction. It includes the Message Identification, which is a unique reference assigned by the sender to identify the message, the Creation Date and Time, which records when the message was created, and the Number of Transactions, which states how many credit transfer transactions are contained in the message. It also includes the Control Sum, which is the total of all the transaction amounts, and which can be used to check that no transaction has been lost or corrupted in transit. The Group Header also contains the Initiating Party, which identifies the party that created the message, and in some usage guidelines it contains the Settlement Information, which describes how the message will be settled, for example whether settlement is through a specific clearing system or through a correspondent account. The Group Header is not just administrative, it is used for validation, for tracking, and for reconciliation. If the Number of Transactions does not match the actual number of transactions in the message, the message will be rejected. If the Control Sum does not match the sum of the transaction amounts, the message will also be rejected, because that mismatch suggests a data error. For a business analyst, the Group Header is important because it is the first place to look when a message fails validation. A duplicate Message Identification can cause a message to be rejected as a duplicate, even if the transactions are new. A Control Sum error can cause an entire file to be held, even if only one transaction is wrong. Your requirements should state how the Message Identification is generated, how uniqueness is ensured, and how the Control Sum is calculated. You should also ensure that operations teams know how to read the Group Header, because it is the envelope that tells them how many payments to expect and what the total value should be. Take a worked example with real numbers. Bank A sends a pacs.008 with MsgId BANKA20261109-001, creation date and time 2026-11-09T09:30:00, number of transactions 3 and control sum EUR 75,000. The three transactions are EUR 25,000, EUR 30,000 and EUR 20,000, and the control sum is the total of the three. The initiating party is Bank A itself, identified by its BIC. The settlement information says the settlement method is CLRG, which means the payment settles through a clearing system, and the settlement date is 2026-11-09. If any of these fields is wrong, the whole message is rejected, because the Group Header is the envelope and the clearing system reads it before it reads any transaction. Failure and recovery: a duplicate MsgId is the most common Group Header failure, and it happens when a bank resends a message after a timeout without changing the MsgId. The receiver treats the second message as a duplicate and rejects it, and the sender must generate a new MsgId and resend. A control sum that does not match the transaction amounts is rejected with a pacs.002, and the sender must correct the sum and resend with a new MsgId. A creation date and time in the future, or a number of transactions that does not match the actual count, is rejected for the same reason. The recovery is always the same: fix the header, generate a new MsgId, and resend, because the header is the first thing the receiver validates and a header error stops the whole message. For a business analyst, product owner or subject matter expert, the test is to write the Group Header requirements for any pacs.008 product, naming each field, its source system, and its validation rule. The MsgId must be unique per sender per day, and the requirement must state how uniqueness is guaranteed, usually by a sequence number in the payment engine. The control sum must equal the sum of the transaction amounts, and the requirement must state who computes it and when. The initiating party must be the bank that created the message, not the corporate customer, and the requirement must state that distinction, because confusing the two is a common error in testing. Source: ISO 20022 pacs.008.001.08, Group Header. Last reviewed 7 November 2026.