| 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
Exercise: Build a UAT Pack for a pacs.008 Change
What you will learn
Your objective. By the end of this lesson, you will be able to explain exercise: build a UAT pack for a pacs.008 change. Start the exercise with a clear change description, because a UAT pack without a scope is impossible to sign.
Why it matters. This matters because operations is where payments are reconciled, investigated and fixed. The work in this lesson is what keeps the money right.
Chapter objective: Learner plans payment testing and certification, including test cases, test data, simulators, and scheme certification, and writes a test plan for a new payment feature. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- Start the exercise
- Write the first UAT scenario
- Expected result
- Invalid BIC
- Cases: cases business signer
- Signature: moment when bank accepts
Key terms
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.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
pacs.008: An ISO 20022 message for a financial institution to financial institution customer credit transfer. It replaces MT103 in cross border payments and carries structured debtor, creditor, charges and...
ISO 20022 XML explorer showing Exercise: Build a UAT Pack for a pacs.008 Change.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
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 exercise: build a UAT pack for a pacs.008 change?
Takeaway and next step
What to remember
That signature is the moment when the bank accepts that the change is ready for real money, and the quality of your pack decides whether that signature is given with confidence.
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 "Defect Management, Entry and Exit Criteria".
Transcript and full text
Show transcript
Start the exercise with a clear change description, because a UAT pack without a scope is impossible to sign. Suppose the bank has changed its pacs.008 generation so that the charge bearer is now SHAR for all cross border payments, and a 15 dollar charge is deducted from a 20,000 dollar payment to Standard Chartered in Hong Kong. The UAT pack must state the change, the affected corridors, the message version, and the release date. It should also list what is out of scope, such as domestic Faster Payments, so that testers do not waste time on flows that have not changed and cannot be affected by this release. Write the first UAT scenario as a happy path case with full detail. Precondition. A corporate user is logged into the payment portal, the test account holds at least 25,000 dollars, and the beneficiary is Standard Chartered Hong Kong with a valid account and BIC. Steps. Create a payment for 20,000 dollars, select SHAR charges, submit for approval, approve as a second user, and release the payment. Expected result. A pacs.008 is created with amount 20,000 dollars, charge bearer SHAR, a 15 dollar charge, a debit of 20,000 dollars to the customer account, and a pacs.002 acceptance within five minutes. Each expected result is measurable and can be checked in the message log. Write the second scenario as a negative path case that proves the system fails safely. Precondition. The same corporate user and the same beneficiary, but the amount is 0 dollars. Steps. Enter the payment, try to submit it, and check the validation response. Expected result. The system rejects the payment before creation, shows a clear message that the amount must be greater than zero, creates no pacs.008, posts no debit, and writes a validation error to the log. A second negative case should use an invalid BIC, and a third should use a value date in the past, each with the same structure of precondition, steps and expected result. Add regression scenarios that prove existing flows still work after the change. One scenario sends a 5,000 euro SEPA payment from NatWest to Deutsche Bank and expects the existing SEPA charge rule to apply unchanged. Another scenario sends a 100,000 pound CHAPS payment and expects the existing CHAPS handling to remain correct. A third scenario processes a pacs.004 return of 3,000 dollars and expects the original payment to be matched and the customer account to be credited correctly. These cases prove that the SHAR change did not break other corridors, and they are the cases that a business signer will ask for first. Finish the pack with a sign off sheet and an evidence checklist. Each scenario should have a tester name, a date, a pass or fail result, and a reference to the evidence, such as a pacs.008 copy, a pacs.002 acknowledgement, or a camt.053 statement extract. The pack should also list any defects found, their severity, and their retest results. The business owner signs only when every mandatory scenario has passed and every critical defect is closed. That signature is the moment when the bank accepts that the change is ready for real money, and the quality of your pack decides whether that signature is given with confidence.
Start the exercise with a clear change description, because a UAT pack without a scope is impossible to sign. Suppose the bank has changed its pacs.008 generation so that the charge bearer is now SHAR for all cross border payments, and a 15 dollar charge is deducted from a 20,000 dollar payment to Standard Chartered in Hong Kong. The UAT pack must state the change, the affected corridors, the message version, and the release date. It should also list what is out of scope, such as domestic Faster Payments, so that testers do not waste time on flows that have not changed and cannot be affected by this release.
Write the first UAT scenario as a happy path case with full detail. Precondition. A corporate user is logged into the payment portal, the test account holds at least 25,000 dollars, and the beneficiary is Standard Chartered Hong Kong with a valid account and BIC. Steps. Create a payment for 20,000 dollars, select SHAR charges, submit for approval, approve as a second user, and release the payment. Expected result. A pacs.008 is created with amount 20,000 dollars, charge bearer SHAR, a 15 dollar charge, a debit of 20,000 dollars to the customer account, and a pacs.002 acceptance within five minutes. Each expected result is measurable and can be checked in the message log.
Write the second scenario as a negative path case that proves the system fails safely. Precondition. The same corporate user and the same beneficiary, but the amount is 0 dollars. Steps. Enter the payment, try to submit it, and check the validation response. Expected result. The system rejects the payment before creation, shows a clear message that the amount must be greater than zero, creates no pacs.008, posts no debit, and writes a validation error to the log. A second negative case should use an invalid BIC, and a third should use a value date in the past, each with the same structure of precondition, steps and expected result.
Add regression scenarios that prove existing flows still work after the change. One scenario sends a 5,000 euro SEPA payment from NatWest to Deutsche Bank and expects the existing SEPA charge rule to apply unchanged. Another scenario sends a 100,000 pound CHAPS payment and expects the existing CHAPS handling to remain correct. A third scenario processes a pacs.004 return of 3,000 dollars and expects the original payment to be matched and the customer account to be credited correctly. These cases prove that the SHAR change did not break other corridors, and they are the cases that a business signer will ask for first.
Finish the pack with a sign off sheet and an evidence checklist. Each scenario should have a tester name, a date, a pass or fail result, and a reference to the evidence, such as a pacs.008 copy, a pacs.002 acknowledgement, or a camt.053 statement extract. The pack should also list any defects found, their severity, and their retest results. The business owner signs only when every mandatory scenario has passed and every critical defect is closed. That signature is the moment when the bank accepts that the change is ready for real money, and the quality of your pack decides whether that signature is given with confidence.
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.