| 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
Truncation risk, the silent data loss
What you will learn
Your objective. By the end of this lesson, you will be able to explain truncation risk, the silent data loss. Truncation risk is the risk that data is lost when a longer MX field is translated to a shorter MT field, and it is one of the most important risks in the MT to MX migration.
Why it matters. An analyst who understands truncation risk can write requirements that minimise it, and can explain to stakeholders why a payment that looks correct in MX may fail after translation to MT.
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
- Truncation risk
- Truncation is not just
- Mitigating truncation risk
- Take a concrete example
- Truncated remittance reference can cause
- Testing: actually truncated before customers
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 Truncation risk, the silent data loss.
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
Find the field field 70 in the message described in this lesson and explain what it controls.
Use the field description and the example in this lesson.
- What to do. Write down what field 70 carries, what happens if it is wrong, and which system reads it.
Correct result. field 70 carries the value the lesson describes. If it is wrong, the payment is rejected, returned, or misrouted, and the exception must be investigated before the payment can proceed.
Why. Fields are the contract between systems. A wrong field is not a typo, it is a failed payment.
Check your understanding
Practice question
Which of the following best describes truncation risk, the silent data loss?
Takeaway and next step
What to remember
The beneficiary receives the money but cannot reconcile it, because the reference for the second invoice never arrived.
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 "Mapping types, direct, split, derived and needs care".
Transcript and full text
Show transcript
Truncation risk is the risk that data is lost when a longer MX field is translated to a shorter MT field, and it is one of the most important risks in the MT to MX migration. An MX message can carry a full structured postal address with street name, building number, town, postcode, and country, each in a separate element with generous length limits. An MT message can carry an address only as four lines of 35 characters each, and the total length is far shorter. When an MX address is translated to MT, the address must be truncated or abbreviated, and the receiving bank may not be able to identify the party correctly. Similarly, an MX remittance block with multiple invoices and amounts must be truncated to 140 characters in MT field 70, and the beneficiary may not be able to reconcile the payment. Truncation is not just a technical inconvenience, it has business consequences. A truncated name can cause a sanctions screening false positive, because the truncated name may match a sanctioned person even though the full name does not. A truncated remittance reference can cause a reconciliation break, because the creditor cannot match the payment to an invoice. A truncated address can cause a payment to be rejected by the creditor agent, because the agent cannot verify the beneficiary. These consequences are often silent, because the payment is not rejected at the translation point, but fails later, in a different system, with a different error code. That makes truncation hard to diagnose without understanding the translation chain. Mitigating truncation risk requires a combination of design, testing, and communication. The design should prioritise which data is most important and ensure that it is not truncated, for example by placing the invoice number at the start of the remittance field rather than at the end. Testing should include cases with long addresses, long names, and long remittance blocks, to see what is actually truncated and what the downstream impact is. Communication should warn customers and corporates that data may be truncated during coexistence, and should advise them to keep critical references short and at the start of the field. An analyst who understands truncation risk can write requirements that minimise it, and can explain to stakeholders why a payment that looks correct in MX may fail after translation to MT. Take a concrete example. A corporate customer sends a pacs.008 with a structured address that includes a long street name, a building number, a floor, a town, and a postcode. Translated to MT, that address must fit into four lines of 35 characters in field 59. The street name is cut, the floor is dropped, and the postcode is squeezed onto the last line. The receiving bank gets an address it cannot fully match to its customer record. Or take remittance information with several invoice numbers. Translated to MT field 70, only the first 140 characters survive, and the later invoice numbers are lost. The beneficiary receives the money but cannot reconcile it, because the reference for the second invoice never arrived. A truncated name can cause a sanctions screening false positive, because the shortened name may match a sanctioned person even though the full name does not. A truncated remittance reference can cause a reconciliation break, because the creditor cannot match the payment to an invoice. A truncated address can cause a payment to be rejected by the creditor agent, because the agent cannot verify the beneficiary. These consequences are often silent, because the payment is not rejected at the translation point. It fails later, in a different system, with a different error code, and the team investigating the failure has to work backwards through the translation chain to find the cause. Mitigation starts with design. Put the most important data first, so that if truncation happens, the critical reference survives. Keep invoice numbers short and at the start of the remittance field. Use structured fields natively in MX so that no translation is needed at all. Testing should include the longest realistic names, addresses, and remittance blocks, so the team sees what is actually truncated before customers do. Translation engines should log every truncation, so operations can see what was lost. And customers should be told during coexistence that data could be truncated, and advised to keep critical references short and at the start of the field.
Truncation risk is the risk that data is lost when a longer MX field is translated to a shorter MT field, and it is one of the most important risks in the MT to MX migration. An MX message can carry a full structured postal address with street name, building number, town, postcode, and country, each in a separate element with generous length limits. An MT message can carry an address only as four lines of 35 characters each, and the total length is far shorter. When an MX address is translated to MT, the address must be truncated or abbreviated, and the receiving bank may not be able to identify the party correctly. Similarly, an MX remittance block with multiple invoices and amounts must be truncated to 140 characters in MT field 70, and the beneficiary may not be able to reconcile the payment.
Truncation is not just a technical inconvenience, it has business consequences. A truncated name can cause a sanctions screening false positive, because the truncated name may match a sanctioned person even though the full name does not. A truncated remittance reference can cause a reconciliation break, because the creditor cannot match the payment to an invoice. A truncated address can cause a payment to be rejected by the creditor agent, because the agent cannot verify the beneficiary. These consequences are often silent, because the payment is not rejected at the translation point, but fails later, in a different system, with a different error code. That makes truncation hard to diagnose without understanding the translation chain.
Mitigating truncation risk requires a combination of design, testing, and communication. The design should prioritise which data is most important and ensure that it is not truncated, for example by placing the invoice number at the start of the remittance field rather than at the end. Testing should include cases with long addresses, long names, and long remittance blocks, to see what is actually truncated and what the downstream impact is. Communication should warn customers and corporates that data may be truncated during coexistence, and should advise them to keep critical references short and at the start of the field. An analyst who understands truncation risk can write requirements that minimise it, and can explain to stakeholders why a payment that looks correct in MX may fail after translation to MT.
Take a concrete example. A corporate customer sends a pacs.008 with a structured address that includes a long street name, a building number, a floor, a town, and a postcode. Translated to MT, that address must fit into four lines of 35 characters in field 59. The street name is cut, the floor is dropped, and the postcode is squeezed onto the last line. The receiving bank gets an address it cannot fully match to its customer record. Or take remittance information with several invoice numbers. Translated to MT field 70, only the first 140 characters survive, and the later invoice numbers are lost. The beneficiary receives the money but cannot reconcile it, because the reference for the second invoice never arrived.
A truncated name can cause a sanctions screening false positive, because the shortened name may match a sanctioned person even though the full name does not. A truncated remittance reference can cause a reconciliation break, because the creditor cannot match the payment to an invoice. A truncated address can cause a payment to be rejected by the creditor agent, because the agent cannot verify the beneficiary. These consequences are often silent, because the payment is not rejected at the translation point. It fails later, in a different system, with a different error code, and the team investigating the failure has to work backwards through the translation chain to find the cause.
Mitigation starts with design. Put the most important data first, so that if truncation happens, the critical reference survives. Keep invoice numbers short and at the start of the remittance field. Use structured fields natively in MX so that no translation is needed at all. Testing should include the longest realistic names, addresses, and remittance blocks, so the team sees what is actually truncated before customers do. Translation engines should log every truncation, so operations can see what was lost. And customers should be told during coexistence that data could be truncated, and advised to keep critical references short and at the start of the field.
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.