| 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
ISO 20022 and One Leg Out: What Changes Next
What you will learn
Your objective. By the end of this lesson, you will be able to explain ISO 20022 and one leg out: what changes next. One leg out describes a payment where one part of the journey uses ISO 20022 and the other part does not.
Why it matters. A bank must therefore decide, field by field, what is preserved, what is mapped and what is lost, and it must record that decision in a mapping table that operations and compliance teams both understand and test.
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
- One leg out
- Payment: therefore end to end
- Banks must decide which party
- Mismatch creates a reconciliation break
- Business analysts and architects
- Normal operating model
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
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.
ISO 20022 XML explorer showing ISO 20022 and One Leg Out: What Changes Next.
Practise this lesson
Exercise
Read the ISO 20022 and 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
A vendor claims artificial intelligence will remove all payment exceptions within a year. A BA is asked to assess the claim. What is the right response?
Takeaway and next step
What to remember
It is a normal operating model that banks must run well.
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 ch6, Adoption timeline and CBPR Plus. This lesson looks forward to what changes next for ISO 20022, including one leg out.
Transcript and full text
Show transcript
One leg out describes a payment where one part of the journey uses ISO 20022 and the other part does not. The model appears when a payment starts or ends in a market, system or currency area that has not yet moved to ISO 20022, while the middle of the journey runs on the new standard. For example, a 120,000 euro payment from a German exporter to a buyer in a market still using MT messages may travel as a pacs.008 through the European leg and then convert to an MT103 for the final leg. The payment is therefore not end to end ISO 20022, even though the customer sees one instruction and one debit. The boundary between the two legs is where risk concentrates. Rich ISO 20022 data, such as structured remittance information, full party addresses and purpose codes, may not fit into the older MT format. If the converting bank truncates a name, drops a purpose code or shortens an address, the receiving bank may fail its sanctions screening or reject the payment. A bank must therefore decide, field by field, what is preserved, what is mapped and what is lost, and it must record that decision in a mapping table that operations and compliance teams both understand and test. Banks must also decide which party performs the conversion. In many corridors the first ISO 20022 bank converts the message before sending it onward, while in others the receiving bank accepts an ISO 20022 message and converts it internally. The choice affects fees, liability and the time a payment spends in queues. A bank that converts a 45,000 dollar payment from pacs.008 to MT103 must prove that the amount, currency, value date and beneficiary details are identical on both sides. Any mismatch creates a reconciliation break that operations must clear by hand. The one leg out model also changes testing and certification. A bank cannot test only its ISO 20022 engine. It must test the full journey, including the conversion point, the fallback when conversion fails, and the repair queue when a message is rejected. Test cases should include long names, structured addresses, special characters and remittance data that exceeds MT field lengths. A test pack that only covers clean, short payments will pass in the laboratory and fail in production, where real customer data is messy and far longer than the standard allows. For business analysts and architects, one leg out is a design problem as much as a messaging problem. The product must tell the customer what will happen to their data, the operations team needs a clear repair path, and the compliance team needs proof that screening still works after conversion. A good design names the converting party, shows the data that survives the boundary, and sets a service level for repair. Until the whole world moves to ISO 20022, one leg out is not a temporary exception. It is a normal operating model that banks must run well. Worked example with numbers: a German exporter sends EUR 120,000 to a buyer in a market that still runs on MT messages, and the payment travels as a pacs.008 through the ISO 20022 leg, then converts to an MT103 for the final leg. The pacs.008 carries a structured remittance of 140 characters and a purpose code for the trade invoice, but the MT103 field 70 can carry only 140 characters of free text, so the converting bank must fit the remittance into that field and drop the purpose code. If the purpose code is lost, the receiving bank cannot tell whether the payment is for goods or services, and its compliance team may hold the payment for a manual review that takes a day. Failure and recovery: the one leg out boundary fails when data is truncated, and the recovery depends on which field was lost. If a name is truncated, the receiving bank may fail its sanctions screening and reject the payment with a pacs.002 RJCT, and the sender must resend with a shorter name that still identifies the party. If a structured address is flattened into free text, the receiving bank may not be able to match the address to its customer record, and the payment goes to a repair queue. The recovery is a corrected message with the data re-entered in the format the receiving system accepts, and the sender must keep a record of what was changed, because a regulator may ask why the payment that left the bank differs from the payment that arrived. For a business analyst, product owner or subject matter expert, the one leg out requirement must name the converting party, list every field that survives the boundary and every field that does not, and state the fallback when conversion fails. The test pack must include a payment with a long name, a structured address, special characters and remittance data that exceeds the MT field length, because those are the cases that break in production. The requirement must also state who bears the cost when a payment is delayed by conversion, because the customer will ask, and the answer cannot be decided after the payment has failed. Source: SWIFT CBPR+ usage guidelines; ISO 20022 message definitions; last reviewed 7 November 2026. The next change in ISO 20022 is the move from migration to optimisation. The CBPR+ migration ends on 22 November 2025 for the in-scope payment instructions, but the work does not end there. The reporting migration continues to November 2028, the exceptions and investigations migration is deferred to the SR2026 package, and the MT101 relay migration was deferred by SWIFT on 27 August 2026 with no replacement date. After the migration, the focus shifts to using the richer data: the structured addresses, the purpose codes, the remittance information, and the charge details. A bank that migrated the messages but does not use the data has paid the cost without gaining the benefit. One Leg Out is the term for a payment where one leg is in ISO 20022 and the other is not. A payment from a European bank in ISO 20022 to a bank in a country that still uses MT will have one leg in each format, and the translation must happen somewhere, usually at the correspondent bank. The translation is lossy, because the MT message cannot carry all the data the ISO 20022 message carries, and the data that is lost is the structured address, the purpose code, and the remittance detail. The bank must therefore decide where the translation happens, what data is lost, and how the loss is communicated to the customer. The One Leg Out problem will persist until every country has migrated, which will take years. The future of ISO 20022 is the data, not the message. The message is the transport, and the data is the value. A bank that stores the full ISO 20022 data for every payment can analyse its payment flows, can forecast its liquidity, can detect fraud, and can report to the regulator, all from the same data. A bank that stores only the fields it needs for processing cannot do any of these, and will need to build a separate data pipeline. The business analyst must specify the data storage, the retention, and the analytics, because the message migration is only the first step.
One leg out describes a payment where one part of the journey uses ISO 20022 and the other part does not. The model appears when a payment starts or ends in a market, system or currency area that has not yet moved to ISO 20022, while the middle of the journey runs on the new standard. For example, a 120,000 euro payment from a German exporter to a buyer in a market still using MT messages may travel as a pacs.008 through the European leg and then convert to an MT103 for the final leg. The payment is therefore not end to end ISO 20022, even though the customer sees one instruction and one debit.
The boundary between the two legs is where risk concentrates. Rich ISO 20022 data, such as structured remittance information, full party addresses and purpose codes, may not fit into the older MT format. If the converting bank truncates a name, drops a purpose code or shortens an address, the receiving bank may fail its sanctions screening or reject the payment. A bank must therefore decide, field by field, what is preserved, what is mapped and what is lost, and it must record that decision in a mapping table that operations and compliance teams both understand and test.
Banks must also decide which party performs the conversion. In many corridors the first ISO 20022 bank converts the message before sending it onward, while in others the receiving bank accepts an ISO 20022 message and converts it internally. The choice affects fees, liability and the time a payment spends in queues. A bank that converts a 45,000 dollar payment from pacs.008 to MT103 must prove that the amount, currency, value date and beneficiary details are identical on both sides. Any mismatch creates a reconciliation break that operations must clear by hand.
The one leg out model also changes testing and certification. A bank cannot test only its ISO 20022 engine. It must test the full journey, including the conversion point, the fallback when conversion fails, and the repair queue when a message is rejected. Test cases should include long names, structured addresses, special characters and remittance data that exceeds MT field lengths. A test pack that only covers clean, short payments will pass in the laboratory and fail in production, where real customer data is messy and far longer than the standard allows.
For business analysts and architects, one leg out is a design problem as much as a messaging problem. The product must tell the customer what will happen to their data, the operations team needs a clear repair path, and the compliance team needs proof that screening still works after conversion. A good design names the converting party, shows the data that survives the boundary, and sets a service level for repair. Until the whole world moves to ISO 20022, one leg out is not a temporary exception. It is a normal operating model that banks must run well.
Worked example with numbers: a German exporter sends EUR 120,000 to a buyer in a market that still runs on MT messages, and the payment travels as a pacs.008 through the ISO 20022 leg, then converts to an MT103 for the final leg. The pacs.008 carries a structured remittance of 140 characters and a purpose code for the trade invoice, but the MT103 field 70 can carry only 140 characters of free text, so the converting bank must fit the remittance into that field and drop the purpose code. If the purpose code is lost, the receiving bank cannot tell whether the payment is for goods or services, and its compliance team may hold the payment for a manual review that takes a day.
Failure and recovery: the one leg out boundary fails when data is truncated, and the recovery depends on which field was lost. If a name is truncated, the receiving bank may fail its sanctions screening and reject the payment with a pacs.002 RJCT, and the sender must resend with a shorter name that still identifies the party. If a structured address is flattened into free text, the receiving bank may not be able to match the address to its customer record, and the payment goes to a repair queue. The recovery is a corrected message with the data re-entered in the format the receiving system accepts, and the sender must keep a record of what was changed, because a regulator may ask why the payment that left the bank differs from the payment that arrived.
For a business analyst, product owner or subject matter expert, the one leg out requirement must name the converting party, list every field that survives the boundary and every field that does not, and state the fallback when conversion fails. The test pack must include a payment with a long name, a structured address, special characters and remittance data that exceeds the MT field length, because those are the cases that break in production. The requirement must also state who bears the cost when a payment is delayed by conversion, because the customer will ask, and the answer cannot be decided after the payment has failed. Source: SWIFT CBPR+ usage guidelines; ISO 20022 message definitions; last reviewed 7 November 2026.
The next change in ISO 20022 is the move from migration to optimisation. The CBPR+ migration ends on 22 November 2025 for the in-scope payment instructions, but the work does not end there. The reporting migration continues to November 2028, the exceptions and investigations migration is deferred to the SR2026 package, and the MT101 relay migration was deferred by SWIFT on 27 August 2026 with no replacement date. After the migration, the focus shifts to using the richer data: the structured addresses, the purpose codes, the remittance information, and the charge details. A bank that migrated the messages but does not use the data has paid the cost without gaining the benefit.
One Leg Out is the term for a payment where one leg is in ISO 20022 and the other is not. A payment from a European bank in ISO 20022 to a bank in a country that still uses MT will have one leg in each format, and the translation must happen somewhere, usually at the correspondent bank. The translation is lossy, because the MT message cannot carry all the data the ISO 20022 message carries, and the data that is lost is the structured address, the purpose code, and the remittance detail. The bank must therefore decide where the translation happens, what data is lost, and how the loss is communicated to the customer. The One Leg Out problem will persist until every country has migrated, which will take years.
The future of ISO 20022 is the data, not the message. The message is the transport, and the data is the value. A bank that stores the full ISO 20022 data for every payment can analyse its payment flows, can forecast its liquidity, can detect fraud, and can report to the regulator, all from the same data. A bank that stores only the fields it needs for processing cannot do any of these, and will need to build a separate data pipeline. The business analyst must specify the data storage, the retention, and the analytics, because the message migration is only the first step.
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.