| 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
CBPR Plus usage guidelines and scheme rules
What you will learn
Your objective. By the end of this lesson, you will be able to explain CBPR plus usage guidelines and scheme rules. The CBPR Plus usage guidelines define how ISO 20022 messages must be used for cross-border payments.
Why it matters. For a business analyst, the usage guidelines are the primary reference for any ISO 20022 project.
Chapter objective: Learner plans an MT to MX migration, explains CBPR+ scope and timelines, and maps MT103, MT202, and MT202COV to pacs.008, pacs.009, and pacs.009 COV equivalents with data gaps noted. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- CBPR Plus usage guidelines
- Always check that you
- Test plan should include test
- Pacs.004: payment return
- Unique end to end transaction reference
- Guidelines do not set value dates
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Market practice: An agreed way of using a message standard in a particular market or community, covering field usage, codes and validation rules.
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
ISO 20022 XML explorer showing CBPR Plus usage guidelines and scheme rules.
Practise this lesson
Exercise
Read the ISO 20022 messages 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 main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes CBPR plus usage guidelines and scheme rules?
Takeaway and next step
What to remember
Always check that you are reading the current release, not a version from before the cutover.
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 "What banks must do, readiness and testing".
Transcript and full text
Show transcript
The CBPR Plus usage guidelines define how ISO 20022 messages must be used for cross-border payments. They specify which messages are used for which business purpose, which fields are mandatory, and how banks should populate structured data such as party names, addresses, and remittance information. The guidelines are published by SWIFT and updated in annual releases, and each release adds new messages, new usage rules, and new validation requirements. The coexistence period that the guidelines once described ended on 22 November 2025. The current guidelines assume that all cross-border payment instructions use ISO 20022. MT messages are no longer accepted for cross-border payments on the SWIFT network. An analyst who reads an old version of the guidelines may still see coexistence rules and translation guidance, but those rules no longer apply to live cross-border traffic. Always check that you are reading the current release, not a version from before the cutover. The usage guidelines also define the validation rules that SWIFT applies to incoming messages. A pacs.008 that fails validation is rejected, and the sending bank must fix the error and resend. Common validation failures include missing mandatory fields, invalid BICs, incorrect currency codes, and unstructured data in fields that require structured data. The guidelines also define the scheme rules for specific flows, such as how to handle charges, how to populate the UETR, and how to report status back to the sender. For a business analyst, the usage guidelines are the primary reference for any ISO 20022 project. Your requirements should cite the specific guideline version, the specific message, and the specific usage rule. Your test plan should include test cases for each validation rule, including cases that should fail validation, so you can confirm that the system rejects bad messages correctly. Your project plan should include a regular check of the usage guideline releases, and a process for assessing the impact of each new release on your implementation. Each message has a defined business purpose in the usage guidelines. The pacs.008 is the customer credit transfer, used when the originator is a customer. The pacs.009 is the financial institution credit transfer, used for bank to bank payments and cover payments. The pacs.002 is the payment status report, which tells the sender whether a payment was accepted, rejected, or is pending. The pacs.004 is the payment return, used when a payment cannot be applied and the funds go back. The camt.056 is the cancellation request, and the camt.029 is the resolution of investigation, which answers it. Account reporting uses camt.052 for intraday reports, camt.053 for statements, and camt.054 for debit and credit notifications. The guidelines set strict rules for structured data. Postal addresses must be structured, with separate elements for street name, town, postcode, and country, and free text addresses are not accepted in fields that require structured data. Party identification must carry the name plus an account number or a BIC. Remittance information should be structured where possible, so the beneficiary can reconcile automatically. The UETR, the unique end to end transaction reference, is mandatory on pacs.008 and pacs.009, and must be carried forward on every message in the chain, so that any bank can track the payment from end to end. Charges have their own rules. In a pacs.008, the charge bearer is carried as a code, and the codes map from the old MT field 71A. The structured charges elements report what was actually deducted, so the beneficiary and the reconciliation team can see the full picture. The guidelines also define how status reporting works. A pacs.002 must be sent when a payment is rejected, with a reason code that explains why, and the reason codes are defined in the guidelines so that every bank uses the same codes for the same problems. The guidelines do not set value dates or cut off times themselves. Those are set by the banks, the clearing systems, and market practice. What the guidelines do set is the message behaviour around them, such as which date fields to populate and how to report status when a payment misses a cut off. The guidelines are updated in annual releases, and each release can add messages, change validation rules, or tighten structured data requirements.
The CBPR Plus usage guidelines define how ISO 20022 messages must be used for cross-border payments. They specify which messages are used for which business purpose, which fields are mandatory, and how banks should populate structured data such as party names, addresses, and remittance information. The guidelines are published by SWIFT and updated in annual releases, and each release adds new messages, new usage rules, and new validation requirements.
The coexistence period that the guidelines once described ended on 22 November 2025. The current guidelines assume that all cross-border payment instructions use ISO 20022. MT messages are no longer accepted for cross-border payments on the SWIFT network. An analyst who reads an old version of the guidelines may still see coexistence rules and translation guidance, but those rules no longer apply to live cross-border traffic. Always check that you are reading the current release, not a version from before the cutover.
The usage guidelines also define the validation rules that SWIFT applies to incoming messages. A pacs.008 that fails validation is rejected, and the sending bank must fix the error and resend. Common validation failures include missing mandatory fields, invalid BICs, incorrect currency codes, and unstructured data in fields that require structured data. The guidelines also define the scheme rules for specific flows, such as how to handle charges, how to populate the UETR, and how to report status back to the sender.
For a business analyst, the usage guidelines are the primary reference for any ISO 20022 project. Your requirements should cite the specific guideline version, the specific message, and the specific usage rule. Your test plan should include test cases for each validation rule, including cases that should fail validation, so you can confirm that the system rejects bad messages correctly. Your project plan should include a regular check of the usage guideline releases, and a process for assessing the impact of each new release on your implementation.
Each message has a defined business purpose in the usage guidelines. The pacs.008 is the customer credit transfer, used when the originator is a customer. The pacs.009 is the financial institution credit transfer, used for bank to bank payments and cover payments. The pacs.002 is the payment status report, which tells the sender whether a payment was accepted, rejected, or is pending. The pacs.004 is the payment return, used when a payment cannot be applied and the funds go back. The camt.056 is the cancellation request, and the camt.029 is the resolution of investigation, which answers it. Account reporting uses camt.052 for intraday reports, camt.053 for statements, and camt.054 for debit and credit notifications.
The guidelines set strict rules for structured data. Postal addresses must be structured, with separate elements for street name, town, postcode, and country, and free text addresses are not accepted in fields that require structured data. Party identification must carry the name plus an account number or a BIC. Remittance information should be structured where possible, so the beneficiary can reconcile automatically. The UETR, the unique end to end transaction reference, is mandatory on pacs.008 and pacs.009, and must be carried forward on every message in the chain, so that any bank can track the payment from end to end.
Charges have their own rules. In a pacs.008, the charge bearer is carried as a code, and the codes map from the old MT field 71A. The structured charges elements report what was actually deducted, so the beneficiary and the reconciliation team can see the full picture. The guidelines also define how status reporting works. A pacs.002 must be sent when a payment is rejected, with a reason code that explains why, and the reason codes are defined in the guidelines so that every bank uses the same codes for the same problems.
The guidelines do not set value dates or cut off times themselves. Those are set by the banks, the clearing systems, and market practice. What the guidelines do set is the message behaviour around them, such as which date fields to populate and how to report status when a payment misses a cut off. The guidelines are updated in annual releases, and each release can add messages, change validation rules, or tighten structured data requirements.
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.