Payments Training Hub

LAB-03: Map MT103 to pacs.008 for a Migration

Data and messaging

Migrating from MT103 to pacs.008 is a data exercise before it is a technology exercise, and the quality of the mapping decides whether payments arrive intact. In this lab you build a source-to-target mapping for a real migration scope, starting from a canonical data model and working down to field level rules. You will decide which fields are mandatory, optional or defaulted, write the transformation rules for party data, addresses, remittance information and charges, and define the validation rules that catch bad data before it leaves the bank. You will also record data lineage, so that any field in the outgoing pacs.008 can be traced back to its source. By the end of the lab you will have a mapping sheet that developers can build from and testers can verify against.

0 of 5 steps done. Tick each step as you finish it, your progress is saved in this browser.

  1. Agree the canonical model for a payment: the parties, the agents, the accounts, the amount and currency, the value date, the charges and the remittance information. List the MT103 fields in scope and the pacs.008 elements they must feed, and mark any MT103 field that has no pacs.008 equivalent. Confirm the market practice rules that apply, since the same pacs.008 version behaves differently across markets, and record the scope decisions in the mapping sheet header so that nobody reopens them during the build.

  2. Map every source field to its target element, one row per field, with the source format, the target format, the data type, the maximum length and the transformation rule. Cover the debtor, the debtor agent, the creditor, the creditor agent, the remittance information and the charges. For structured addresses, map each address line to its structured element and state what happens when the source address is unstructured. Get the mapping reviewed by a second analyst, because a single wrong field mapping can corrupt thousands of payments.

  3. For each target field, state whether it is mandatory, optional or conditional, and what happens when the source is empty. Define the default values, for example the default charge bearer code when the source has none, and the enrichment rules, such as deriving the creditor agent BIC from the sort code table. State the rule for truncation when a name exceeds the target length, including whether the payment is repaired, truncated or rejected. Agree every default and truncation rule with compliance, because silently changing payment data creates regulatory risk.

  4. Write the validation rule for each field: format checks, length checks, character set checks, currency code checks and IBAN checksum checks. State the error code and the message that is returned when a rule fails, and whether the failure rejects the payment, sends it to repair, or passes it with a warning. Cover the cross field validations too, such as the instructed amount matching the equivalent amount after FX. Test each rule with a good value, a bad value and a boundary value before the mapping is signed off.

  5. Add a lineage column that traces each target field back to its source system, its source field and any intermediate transformation. List the open decisions and gaps, with an owner and a due date for each one. Run a walkthrough with technology, operations and compliance using three sample payments, one in dollars, one in euros and one in pounds, and trace each field from source to target live in the session. Correct the mapping where the walkthrough exposes a gap, then obtain formal sign off.

Templates.

Worked example. Meridian Bank, a fictional bank in London, is migrating its cross-border payments from MT103 to pacs.008 after the end of MT coexistence. The analyst maps field 59, the beneficiary customer, to the pacs.008 creditor element, splitting the free text name and address into structured name, postal address and country elements. Field 70, remittance information, maps to structured remittance information when the source carries an invoice number, and to unstructured remittance information otherwise. Field 71A, details of charges, maps to the charge bearer element, with a default of shared charges when the source is blank, a rule agreed with compliance. A test payment of 25,000 dollars from a London corporate to a supplier in New York carries a 35 character beneficiary name, which exceeds the 140 character limit only in a combined address test, so the mapping is exercised with a longer case: a 70,000 euro payment to Frankfurt with a structured address and a 140 character remittance reference, which passes validation cleanly. A second case with an invalid IBAN is caught by the mod-97 check and routed to repair with a clear error code. The mapping sheet, with 68 field rows, is signed off by technology and compliance, and the first 1,000 test messages transform with zero field errors.

Deliverables.