MT103 to pacs.008: Structured Address, Truncated Remittance Data and Charges
An Indian bank's trade operations team processes a USD 1.85 million import payment under an LC. The payment is sent to a beneficiary in Singapore by MT103. Field 33B is USD 1,850,000; field 71A is 'SHA'; field 71F is USD 25; field 70 reads 'INV 2025-0417 / LC 00123 / PO 8891'; field 59 has 'Marina Bay Tower, 10 Bayfront Ave, Singapore 018956' spread over four address lines, with the country name in the last line. The bank's core system truncates field 70 at 35 characters and does not hold a two-letter country code for the beneficiary. The bank is migrating this flow to ISO 20022 pacs.008. The correspondent has warned that unstructured address data and truncated remittance information will cause repair charges and possible rejection. The bank also wants to know how charges will behave under the new message.
1. Identify the main mapping risks in converting this MT103 to pacs.008 and explain how the bank should remediate them.
Read the worked answer
The first risk is the beneficiary address. MT103 field 59 allows unstructured address lines, but pacs.008 requires a structured postal address for CBPR+ use. The bank should parse 'Marina Bay Tower, 10 Bayfront Ave, Singapore 018956' into building name, building number, street name, post code, town and a two-letter country code. Singapore must be represented as 'SG', not as a free-text country name. If the core system does not hold the country code, the bank must enrich it from static data or reference data before generating the message. Simply carrying over four unstructured lines will invite repair or rejection.
The second risk is remittance information. Field 70 is limited and the core system truncates it at 35 characters. Under pacs.008, remittance information can carry substantially more data and can be structured. The bank should map the invoice number, LC number and purchase order number into structured remittance fields, or at least into a full unstructured remittance line of up to 140 characters. Truncating at 35 characters can lose the invoice reference and break reconciliation at the beneficiary.
The third risk is end-to-end identification. The bank should preserve a unique end-to-end transaction reference and ensure that the LC and invoice references are not merged into a narrative field that downstream systems cannot parse. It should also validate that field 59 name and address data are not split inconsistently.
2. How should the bank map field 71A 'SHA' and field 71F under pacs.008, and what should operations expect at settlement?
Read the worked answer
Field 71A 'SHA' means shared charges. In pacs.008, the equivalent charge bearer is 'SHAR'. The bank should map the instruction to SHAR and must not assume that the beneficiary will receive the full instructed amount. Under shared charges, the debtor side generally bears the sending bank's charges and the creditor side bears correspondent bank charges. The correspondent may deduct its charges from the amount passed on.
Field 71F, the sender's charges of USD 25, is a separate charges element. It should be mapped into the charges information of the pacs.008 message with the amount and the agent to which it relates, rather than being netted into the instructed amount. The bank should keep the instructed amount in field 33B equivalent separate from the settlement amount and the charges.
Operations should expect a possible difference between the amount debited from the applicant and the amount credited to the beneficiary. Reconciliation should therefore match on the payment reference, the end-to-end ID and the invoice or LC reference, not only on the amount. If the beneficiary requires the full invoice value, the parties should consider a different charge bearer, such as 'DEBT', but that shifts correspondent charges to the remitter and must be agreed commercially. The bank should also ensure that any charges deducted by the correspondent are reported consistently in the confirmation or statement.
3. What cutover controls should the bank put in place before switching this flow to pacs.008?
Read the worked answer
The bank should not switch live traffic until it has tested the full message chain with the correspondent and validated the CBPR+ usage guidelines. Testing should cover structured addresses, remittance information, charge bearer, charges information, and the treatment of the LC and invoice references. The bank should also test exception scenarios: missing country code, address that cannot be parsed, remittance data longer than the legacy field, and a return or rejection.
A translation layer should be built and independently checked. It should reject or flag incomplete data rather than silently truncating it. Static data should be cleansed so that beneficiary records carry a valid two-letter country code, post code and town. The bank should run a parallel period in which a sample of payments is translated and compared with the MT103 equivalent, with reconciliation of amount, charges and references.
Operationally, staff should be trained on repair queues and on the difference between an MT103 and a pacs.008 charge profile. The bank should monitor repair charges, rejections and returns, and have a fallback procedure if the correspondent cannot process a message. Sanctions screening should be reviewed because structured address fields and richer remittance data may change screening results. Finally, the bank should document the migration decisions and retain audit evidence of testing and sign-off.