Key points of this lesson, in order.
User Stories and Acceptance Criteria for the Migration
What you will learn
Your objective. By the end of this lesson, you will be able to explain user stories and acceptance criteria for the migration. The first user story covers the core conversion.
Why it matters. As a reconciliation analyst, I want a daily report showing every MT103 received and its converted pacs.008, so that I can prove no payment was lost or altered during migration.
Chapter objective: Learner completes a capstone project that designs an end-to-end payment solution for a stated business problem, integrating messages, rails, controls, and operations into one coherent proposal. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Core conversion
- Field validation
- Exception handling
- Duplicate detection
- Reconciliation reporting
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
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.
Clearing and settlement timeline showing User Stories and Acceptance Criteria for the Migration.
Practise this lesson
Exercise
Trace the payment in this lesson through its lifecycle stages.
Use the lifecycle stages in this lesson: acceptance, processing, clearing, settlement, beneficiary credit, ledger posting and reconciliation.
- What to do. Name each stage, state what happens, and say when the payment is truly final.
Correct result. Acceptance validates the instruction. Processing prepares it. Clearing sorts and nets it. Settlement moves the funds. Beneficiary credit puts the money in the creditor account. Ledger posting records it. Reconciliation proves it. Finality is only at settlement, not at acceptance or at status update.
Why. The lifecycle is the map of a payment. If you cannot say which stage a payment is in, you cannot answer where the money is.
Check your understanding
Practice question
Which of the following best describes user stories and acceptance criteria for the migration?
Takeaway and next step
What to remember
Another criterion states that given a converted message, when the analyst opens the report detail, then the original field 32A amount and the pacs.008 instructed amount must be shown side by side and must match exactly.
Map the message fields from this lesson in the mapping workbench.
Builds on "API Business Data, Rules and Validations".
Transcript and full text
Show transcript
The first user story covers the core conversion. As a payment operations officer, I want the system to convert an outward MT103 into a pacs.008 message automatically, so that cross-border payments meet the ISO 20022 standard without manual intervention. The acceptance criteria state that given an MT103 with field 32A value date 15 November 2024, currency USD and amount 125,000, when the message is converted, then the pacs.008 must carry the same value date, currency and amount. A second criterion states that given an MT103 with field 71A set to SHA, when the conversion runs, then the charge bearer in pacs.008 must be SHAR. The second user story covers field validation. As a payment operations officer, I want the system to reject MT103 messages with invalid data before conversion, so that no invalid pacs.008 message is ever sent to a correspondent bank. The acceptance criteria state that given an MT103 with a beneficiary IBAN that fails the modulus 97 check, when the message is submitted for conversion, then it must be routed to the repair queue with the error code INVALID_IBAN. Another criterion states that given an MT103 with an amount of zero, when the message is submitted, then it must be rejected with the error code INVALID_AMOUNT and the rejection must be logged. The third user story covers exception handling for the 50K and 59 parsing problem. As a payment operations officer, I want messages that cannot be parsed automatically to appear in a repair queue with the original text visible, so that I can correct them manually and release the payment. The acceptance criteria state that given an MT103 where field 59 has five lines and no recognisable account pattern, when the conversion runs, then the message must appear in the repair queue within one minute with the full original field 59 displayed. A further criterion states that given a repaired message, when the officer corrects the beneficiary account and submits it, then the conversion must complete and the payment must be released. The fourth user story covers duplicate detection. As a corporate customer, I want the system to warn me before sending a duplicate payment, so that I do not pay the same supplier twice by mistake. The acceptance criteria state that given a payment of 250,000 rupees to the same supplier account with the same value date submitted twice within 24 hours, when the second payment is submitted, then the system must return a duplicate warning with the first payment's reference. A second criterion states that given the warning, when the customer confirms the payment is intentional, then the second payment must be processed normally. The fifth user story covers reconciliation reporting. As a reconciliation analyst, I want a daily report showing every MT103 received and its converted pacs.008, so that I can prove no payment was lost or altered during migration. The acceptance criteria state that given 12,000 MT103 messages received on a day, when the report is generated at 6 in the evening, then it must list all 12,000 with a status of Converted, In Repair or Rejected, and the totals must reconcile to zero differences. Another criterion states that given a converted message, when the analyst opens the report detail, then the original field 32A amount and the pacs.008 instructed amount must be shown side by side and must match exactly.
The first user story covers the core conversion. As a payment operations officer, I want the system to convert an outward MT103 into a pacs.008 message automatically, so that cross-border payments meet the ISO 20022 standard without manual intervention. The acceptance criteria state that given an MT103 with field 32A value date 15 November 2024, currency USD and amount 125,000, when the message is converted, then the pacs.008 must carry the same value date, currency and amount. A second criterion states that given an MT103 with field 71A set to SHA, when the conversion runs, then the charge bearer in pacs.008 must be SHAR.
The second user story covers field validation. As a payment operations officer, I want the system to reject MT103 messages with invalid data before conversion, so that no invalid pacs.008 message is ever sent to a correspondent bank. The acceptance criteria state that given an MT103 with a beneficiary IBAN that fails the modulus 97 check, when the message is submitted for conversion, then it must be routed to the repair queue with the error code INVALID_IBAN. Another criterion states that given an MT103 with an amount of zero, when the message is submitted, then it must be rejected with the error code INVALID_AMOUNT and the rejection must be logged.
The third user story covers exception handling for the 50K and 59 parsing problem. As a payment operations officer, I want messages that cannot be parsed automatically to appear in a repair queue with the original text visible, so that I can correct them manually and release the payment. The acceptance criteria state that given an MT103 where field 59 has five lines and no recognisable account pattern, when the conversion runs, then the message must appear in the repair queue within one minute with the full original field 59 displayed. A further criterion states that given a repaired message, when the officer corrects the beneficiary account and submits it, then the conversion must complete and the payment must be released.
The fourth user story covers duplicate detection. As a corporate customer, I want the system to warn me before sending a duplicate payment, so that I do not pay the same supplier twice by mistake. The acceptance criteria state that given a payment of 250,000 rupees to the same supplier account with the same value date submitted twice within 24 hours, when the second payment is submitted, then the system must return a duplicate warning with the first payment's reference. A second criterion states that given the warning, when the customer confirms the payment is intentional, then the second payment must be processed normally.
The fifth user story covers reconciliation reporting. As a reconciliation analyst, I want a daily report showing every MT103 received and its converted pacs.008, so that I can prove no payment was lost or altered during migration. The acceptance criteria state that given 12,000 MT103 messages received on a day, when the report is generated at 6 in the evening, then it must list all 12,000 with a status of Converted, In Repair or Rejected, and the totals must reconcile to zero differences. Another criterion states that given a converted message, when the analyst opens the report detail, then the original field 32A amount and the pacs.008 instructed amount must be shown side by side and must match exactly.
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.