| Field | Meaning | Required |
|---|---|---|
GrpHdr | The header of the message, holding the message identification, creation date and time, number of transactions and control sum. It identifies the file or message | M |
PmtId | The identification block holding instruction identification, end to end identification and transaction identification. End to end identification stays unchanged | M |
IntrBkSttlmAmt | The amount and currency settled between banks for this payment, for example USD 25,000. It is the amount the debtor agent transfers to the creditor agent. It ma | M |
IntrBkSttlmDt | The date on which settlement between banks takes place. It is the value date for the interbank leg and drives liquidity planning and nostro funding. The date mu | O |
SttlmInf | Information about how settlement will occur, including the settlement method, settlement account and clearing system. Values include INDA for instructed agent s | M |
Dbtr | The customer who ordered the payment, with structured name, postal address and identification. Rich debtor data supports sanctions screening and anti money laun | M |
DbtrAcct | The account of the debtor from which the payment is debited, identified by IBAN or other account identification. It links the payment to the correct customer ac | O |
DbtrAgt | The bank holding the debtor account and sending the payment instruction onward. It is identified by BIC and sometimes by name and address. The debtor agent is r | M |
CdtrAgt | The bank holding the creditor account and receiving the payment for onward credit. It is identified by BIC and sometimes by name and address. The creditor agent | M |
Cdtr | The final beneficiary of the payment, with structured name, postal address and identification. The creditor agent credits this party on receipt of funds. Comple | M |
CdtrAcct | The account of the creditor to be credited, identified by IBAN or other account identification. It tells the creditor agent exactly where to post the funds. A w | O |
ChrgsInf | Details of the charges applied to the payment, including the amount, currency, bearer and the agent that applied each charge. The bearer can be debtor, creditor | O |
Meridian Bank London sends a pacs.008.001.08 for USD 25,000 value 5 November 2026 to Harbour Bank Singapore, with a UETR, full structured debtor and creditor names and addresses, charge bearer SHAR, and remittance reference INV-1187. Harbour Bank screens the payment, credits Bright Logistics, and reports the status in a pacs.002.Valid example from the message catalogue. Scheme rules: pacs.008 is a base ISO 20022 message: the structure and fields below are the base definition, and each scheme adds or restricts elements for its rail. Under CBPR+ the message must carry a UETR for end
Worked Example: The Same EUR 10,000 Payment as pacs.008 Under CBPR+ and SEPA
What you will learn
Your objective. By the end of this lesson, you will be able to explain worked example: the same EUR 10,000 payment as pacs.008 under CBPR+ and SEPA. The payment is EUR 10,000 from a Paris customer, Atelier Lumiere, to a Frankfurt supplier, Rheinwerk GmbH, for a delivery of lighting equipment.
Why it matters. A business analyst should build a per rail mapping table, a tester should run the same payment through both rails and compare the results, and a product owner should make sure the screen asks for the right data for the rail the customer chose.
Chapter objective: How the standard is built, read and validated in real systems
Key learning points
- Payment: EUR 10
- Message: built for cross border
- UETR is not required
- CBPR+ version
- SEPA style message
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.
Charge bearer: A code that states who pays the charges for a payment. In ISO 20022 the values are DEBT for debtor, CRED for creditor, SHAR for shared and SLEV for service level.
ISO 20022 XML explorer showing Worked Example: The Same EUR 10,000 Payment as pacs.008 Under CBPR+ and SEPA.
Practise this lesson
Exercise
Read the pacs.008 message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the three levels of the message and name the field that carries the amount and the field that carries the end-to-end reference.
Correct result. The amount is carried in the instructed amount element and the reference in the end-to-end identification. The three levels are the group header, the payment information, and the credit transfer transaction information.
Why. A message is only useful if you can read it. The group header identifies the message, the payment information identifies the batch, and the transaction information carries the single payment.
Check your understanding
Practice question
Which of the following best describes worked example: the same EUR 10,000 payment as pacs.008 under CBPR+ and SEPA?
Takeaway and next step
What to remember
The UETR is not required in the same way, because the SEPA clearing system provides its own tracking, and the charge bearer is always shared under the SEPA rule.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "LEI, FATF Recommendation 16 and Mandatory Versus Optional Elements".
Transcript and full text
Show transcript
The payment is EUR 10,000 from a Paris customer, Atelier Lumiere, to a Frankfurt supplier, Rheinwerk GmbH, for a delivery of lighting equipment. Under CBPR+ rules, the pacs.008 carries the full debtor data, including the name Atelier Lumiere, the full postal address in Paris, the account number, and the LEI where available. It carries the full creditor data, including the name Rheinwerk GmbH, the Frankfurt address, the account, and the LEI. It carries a UETR for tracking, the instructed amount EUR 10,000.00, the charge bearer, the purpose code, and the remittance information with the invoice number. The message is built for the cross border chain, so it assumes the payment may pass through a correspondent bank and must be readable by every bank in that chain. Under SEPA rules, the same EUR 10,000 payment is a simpler message. The debtor is identified by name and IBAN, and the full postal address is not required, because the SEPA scheme standardises the data and the payment stays inside the euro area. The creditor is identified by name and IBAN, the BIC is optional, and the remittance information carries the invoice number in structured or unstructured form. The UETR is not required in the same way, because the SEPA clearing system provides its own tracking, and the charge bearer is always shared under the SEPA rule. The instructed amount is still EUR 10,000.00, the currency is still EUR, and the requested execution date is still present, but the message is shorter, because the scheme does not need the cross border data. The fields that change between the two versions are the party data, the tracking, and the charge handling. The CBPR+ version carries the full address and the LEI for both parties, while the SEPA version carries only the name and the IBAN. The CBPR+ version carries a UETR and a detailed charge bearer, while the SEPA version relies on the clearing system and the shared charge rule. The CBPR+ version may carry an equivalent amount if a conversion is involved, while the SEPA version never does, because the currency is always euro. The reason for each difference is the market, CBPR+ serves a global chain of banks that do not share a common clearing system, while SEPA serves a single currency area with a common clearing system and a common rule book. If a message built for one rail is sent on the other, it will fail, and the failure mode teaches the rule. A SEPA style message sent on the CBPR+ route will be rejected for missing debtor address and missing UETR, and the receiving bank will return a pacs.002 with a reason code for missing data. A CBPR+ style message sent on the SEPA route may be rejected for carrying fields the SEPA scheme does not expect, or it may be accepted but with the extra data ignored, depending on the clearing system. Either way, the payment is delayed, and the customer must be told why. A business analyst should build a per rail mapping table, a tester should run the same payment through both rails and compare the results, and a product owner should make sure the screen asks for the right data for the rail the customer chose.
The payment is EUR 10,000 from a Paris customer, Atelier Lumiere, to a Frankfurt supplier, Rheinwerk GmbH, for a delivery of lighting equipment. Under CBPR+ rules, the pacs.008 carries the full debtor data, including the name Atelier Lumiere, the full postal address in Paris, the account number, and the LEI where available. It carries the full creditor data, including the name Rheinwerk GmbH, the Frankfurt address, the account, and the LEI. It carries a UETR for tracking, the instructed amount EUR 10,000.00, the charge bearer, the purpose code, and the remittance information with the invoice number. The message is built for the cross border chain, so it assumes the payment may pass through a correspondent bank and must be readable by every bank in that chain.
Under SEPA rules, the same EUR 10,000 payment is a simpler message. The debtor is identified by name and IBAN, and the full postal address is not required, because the SEPA scheme standardises the data and the payment stays inside the euro area. The creditor is identified by name and IBAN, the BIC is optional, and the remittance information carries the invoice number in structured or unstructured form. The UETR is not required in the same way, because the SEPA clearing system provides its own tracking, and the charge bearer is always shared under the SEPA rule. The instructed amount is still EUR 10,000.00, the currency is still EUR, and the requested execution date is still present, but the message is shorter, because the scheme does not need the cross border data.
The fields that change between the two versions are the party data, the tracking, and the charge handling. The CBPR+ version carries the full address and the LEI for both parties, while the SEPA version carries only the name and the IBAN. The CBPR+ version carries a UETR and a detailed charge bearer, while the SEPA version relies on the clearing system and the shared charge rule. The CBPR+ version may carry an equivalent amount if a conversion is involved, while the SEPA version never does, because the currency is always euro. The reason for each difference is the market, CBPR+ serves a global chain of banks that do not share a common clearing system, while SEPA serves a single currency area with a common clearing system and a common rule book.
If a message built for one rail is sent on the other, it will fail, and the failure mode teaches the rule. A SEPA style message sent on the CBPR+ route will be rejected for missing debtor address and missing UETR, and the receiving bank will return a pacs.002 with a reason code for missing data. A CBPR+ style message sent on the SEPA route may be rejected for carrying fields the SEPA scheme does not expect, or it may be accepted but with the extra data ignored, depending on the clearing system. Either way, the payment is delayed, and the customer must be told why. A business analyst should build a per rail mapping table, a tester should run the same payment through both rails and compare the results, and a product owner should make sure the screen asks for the right data for the rail the customer chose.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.