| 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: Design a 2026-Ready Payment Product
What you will learn
Your objective. By the end of this lesson, you will be able to explain exercise: design a 2026-ready payment product. Your brief is to design a payment product for a small business that imports goods from three countries and pays suppliers in euros, dollars and pounds.
Why it matters. This matters because the next payment product you work on may use one of these technologies. Knowing what is real and what is still a proposal is what separates a good analyst from a confused one.
Chapter objective: Learner explains one leg out, CBPR+ after migration, open banking and cryptocurrencies, and applies them in a 2026-ready payment product design. Learner uses real examples with amounts, banks and message names to show how the topic works in practice.
Key learning points
- Brief: to design payment product
- You cannot state the promise clearly
- Now list the controls
- Customer experience
- Present your
Key terms
Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Open banking: A system where banks share customer account data and payment services with licensed third parties through secure APIs, with customer consent.
ISO 20022 XML explorer showing Exercise: Design a 2026-Ready Payment Product.
Practise this lesson
Exercise
Work out what the beneficiary receives for a , dollars payment under OUR, SHA and BEN.
Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.
- What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.
Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.
Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.
Check your understanding
Practice question
Which of the following best describes exercise: design a 2026-ready payment product?
Takeaway and next step
What to remember
The goal is not a perfect product, but a product you can explain, defend and improve, which is exactly what a bank will ask you to do in 2026.
Follow , dollars through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "What This Means for Banks, BAs and Architects".
Transcript and full text
Show transcript
Your brief is to design a payment product for a small business that imports goods from three countries and pays suppliers in euros, dollars and pounds. The product must accept a payment instruction through an open banking interface, send the payment as an ISO 20022 pacs.008 where the rail supports it, and offer a stablecoin settlement option for corridors where the traditional route is slow or expensive. Start by writing the customer promise in one paragraph, including the settlement time, the fee, the exchange rate shown before approval, and the refund route if the payment fails. If you cannot state the promise clearly, the design is not ready. Next, draw the end to end flow from customer approval to supplier credit. Show the bank account, the open banking provider, the ISO 20022 leg, the conversion point for any one leg out corridor, and the stablecoin leg with its wallet and converter. Label the party responsible for each step, the data passed at each handoff, and the point where reconciliation happens. Use a real example, such as a 25,000 euro payment from a London importer to a supplier in Nairobi, and trace it through every step, including the value date and the fees charged at each stage. Now list the controls. For each step, name the check that must pass before the payment moves on, including customer authentication, consent validation, sanctions screening, stablecoin reserve checks and wallet screening. Add the failure path for each control, such as what happens when consent has expired, when a wallet address is sanctioned, or when a stablecoin loses its peg during the payment. A design with no failure paths is a design that has not been tested, and a reviewer will spot that gap immediately. Add the customer experience and the commercial model. Describe what the customer sees before approval, during the payment and after settlement, including status updates, tracking and the help route when something goes wrong. Then state the pricing, including the exchange rate margin, the flat fee and any correspondent charges, and explain why a customer would choose the stablecoin option over the traditional route. Be honest about the cases where the traditional route is better, such as a payment to a supplier who only accepts a bank transfer. Finally, present your design as a short pack with four parts, a one page product summary, a flow diagram, a control and failure table, and a list of open risks with owners. Include at least three open risks, such as regulatory change, stablecoin reserve quality and one leg out data loss, and say what would need to change before launch. Present the pack to a colleague, answer their challenges, and revise the design. The goal is not a perfect product, but a product you can explain, defend and improve, which is exactly what a bank will ask you to do in 2026. Worked example with numbers: the small business imports from Germany, the United States and Japan, and pays EUR 25,000, USD 30,000 and JPY 4,000,000 a month. The product must accept a payment instruction through an open banking interface, send the payment as a pacs.008 where the rail supports it, and offer a stablecoin option for the Japan corridor, where the traditional route takes three days and costs JPY 3,000 in correspondent charges. The design must show the exchange rate for each currency before approval, the fee for each route, and the settlement time, so the customer can choose the stablecoin route for Japan and the ISO 20022 route for Germany and the United States, and can see the saving before they approve. Failure and recovery: the design must handle a failure on each route, and each failure needs a different recovery. If the open banking consent expires, the customer must re approve, and the payment cannot proceed until that happens. If a one leg out corridor truncates the remittance data, the supplier cannot reconcile, and the recovery is a shorter remittance agreed in advance. If the stablecoin loses its peg during the Japan payment, the supplier receives less than invoiced, and the design must state who bears the shortfall before launch, because the dispute will arrive after the payment has settled and cannot be reversed. For a business analyst, product owner or subject matter expert, the design pack must show the four parts, a one page product summary, a flow diagram, a control and failure table, and a list of open risks with owners, and must include at least three open risks, such as regulatory change, stablecoin reserve quality and one leg out data loss. The pack must also state the pricing, the exchange rate margin, the flat fee and any correspondent charges, and must explain why a customer would choose the stablecoin option over the traditional route. A pack that shows the happy path only will not survive a review, because the reviewer will ask what happens when it fails. Source: PSD2; SWIFT CBPR+ usage guidelines; last reviewed 7 November 2026.
Your brief is to design a payment product for a small business that imports goods from three countries and pays suppliers in euros, dollars and pounds. The product must accept a payment instruction through an open banking interface, send the payment as an ISO 20022 pacs.008 where the rail supports it, and offer a stablecoin settlement option for corridors where the traditional route is slow or expensive. Start by writing the customer promise in one paragraph, including the settlement time, the fee, the exchange rate shown before approval, and the refund route if the payment fails. If you cannot state the promise clearly, the design is not ready.
Next, draw the end to end flow from customer approval to supplier credit. Show the bank account, the open banking provider, the ISO 20022 leg, the conversion point for any one leg out corridor, and the stablecoin leg with its wallet and converter. Label the party responsible for each step, the data passed at each handoff, and the point where reconciliation happens. Use a real example, such as a 25,000 euro payment from a London importer to a supplier in Nairobi, and trace it through every step, including the value date and the fees charged at each stage.
Now list the controls. For each step, name the check that must pass before the payment moves on, including customer authentication, consent validation, sanctions screening, stablecoin reserve checks and wallet screening. Add the failure path for each control, such as what happens when consent has expired, when a wallet address is sanctioned, or when a stablecoin loses its peg during the payment. A design with no failure paths is a design that has not been tested, and a reviewer will spot that gap immediately.
Add the customer experience and the commercial model. Describe what the customer sees before approval, during the payment and after settlement, including status updates, tracking and the help route when something goes wrong. Then state the pricing, including the exchange rate margin, the flat fee and any correspondent charges, and explain why a customer would choose the stablecoin option over the traditional route. Be honest about the cases where the traditional route is better, such as a payment to a supplier who only accepts a bank transfer.
Finally, present your design as a short pack with four parts, a one page product summary, a flow diagram, a control and failure table, and a list of open risks with owners. Include at least three open risks, such as regulatory change, stablecoin reserve quality and one leg out data loss, and say what would need to change before launch. Present the pack to a colleague, answer their challenges, and revise the design. The goal is not a perfect product, but a product you can explain, defend and improve, which is exactly what a bank will ask you to do in 2026.
Worked example with numbers: the small business imports from Germany, the United States and Japan, and pays EUR 25,000, USD 30,000 and JPY 4,000,000 a month. The product must accept a payment instruction through an open banking interface, send the payment as a pacs.008 where the rail supports it, and offer a stablecoin option for the Japan corridor, where the traditional route takes three days and costs JPY 3,000 in correspondent charges. The design must show the exchange rate for each currency before approval, the fee for each route, and the settlement time, so the customer can choose the stablecoin route for Japan and the ISO 20022 route for Germany and the United States, and can see the saving before they approve.
Failure and recovery: the design must handle a failure on each route, and each failure needs a different recovery. If the open banking consent expires, the customer must re approve, and the payment cannot proceed until that happens. If a one leg out corridor truncates the remittance data, the supplier cannot reconcile, and the recovery is a shorter remittance agreed in advance. If the stablecoin loses its peg during the Japan payment, the supplier receives less than invoiced, and the design must state who bears the shortfall before launch, because the dispute will arrive after the payment has settled and cannot be reversed.
For a business analyst, product owner or subject matter expert, the design pack must show the four parts, a one page product summary, a flow diagram, a control and failure table, and a list of open risks with owners, and must include at least three open risks, such as regulatory change, stablecoin reserve quality and one leg out data loss. The pack must also state the pricing, the exchange rate margin, the flat fee and any correspondent charges, and must explain why a customer would choose the stablecoin option over the traditional route. A pack that shows the happy path only will not survive a review, because the reviewer will ask what happens when it fails. Source: PSD2; SWIFT CBPR+ usage guidelines; last reviewed 7 November 2026.
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.