# MT103 to ISO 20022 Migration Move cross-border payments from legacy MT messages to ISO 20022 before the coexistence deadline This project migrates cross-border payment instructions from SWIFT MT103, MT202 and MT202 COV messages to ISO 20022 pacs.008 and pacs.009 messages, following the end of MT coexistence on 22 November 2025. The work covers a 10,000 dollar payment from a London corporate to a New York supplier, a 50,000 euro payment to a Frankfurt beneficiary and a 25,000 pound payment to a Singapore exporter, so that transformation, truncation and screening are tested on real cases. The business analyst maps every MT field to its ISO 20022 target, defines rules for structured party and address data, handles fields that truncate or have no direct equivalent, and writes requirements that developers, testers and operations teams can use. The project ends with SWIFT certification, user acceptance testing and a controlled production cutover. ## Phases ### Discovery and Current State Analysis - Document the as is MT103, MT202 and MT202 COV flows and volumes - Interview operations, compliance and technology stakeholders - Collect sample MT messages for USD, EUR and GBP payments - Identify downstream systems that consume MT data ### ISO 20022 Analysis - Analyse pacs.008, pacs.009 and pacs.002 structure and CBPR+ rules - Compare MT and MX fields and identify gaps and truncations - Document structured address and party data requirements - Review SWIFT MyStandards usage guidelines for each market ### Mapping and Transformation Design - Create the MT to MX field mapping sheet for all message types - Define truncation, enrichment and default value rules - Agree handling for fields with no direct MX equivalent - Validate mapping with compliance and screening teams ### Requirements and Design - Write the BRD and FSD with business and functional rules - Define API contracts for initiation and status reporting - Design repair, rejection and reversal workflows - Agree non functional requirements for performance and audit ### Build Support and Testing - Support developers during transformation engine build - Create UAT scenarios for standard, truncated and sanction hit cases - Support SWIFT certification and community testing - Track defects and update requirements where needed ### Cutover and Go Live - Plan the phased cutover from MT to MX traffic - Prepare operations runbooks and training material - Support hypercare and monitor message success rates - Close the project and hand over to operations ## Deliverables ### BRD The Business Requirements Document states what the business needs from the MT103 to ISO 20022 migration, why the change is required, and what success looks like. It covers the scope of MT103, MT202 and MT202 COV migration, the affected payment products, the business rules for structured data, truncation and enrichment, and the non functional requirements for performance, audit and reporting. It is signed off by business, operations, compliance and technology before design starts. Template sections: - Executive Summary - Business Objectives and Scope - Current State MT103 Process - Target State ISO 20022 Process - Business Rules and Data Requirements - Stakeholders and RACI - Risks, Assumptions and Dependencies - Acceptance Criteria and Sign Off ### FSD The Functional Specification Document describes how the payment hub, transformation engine and screening systems must behave to convert MT103 messages to pacs.008 messages. It defines field level mapping rules, validation rules, error handling, status reporting through pacs.002, and the behaviour for repair, rejection and reversal. It gives developers and testers a precise, testable specification for every message type, interface and business rule in scope. Template sections: - Introduction and Scope - System Context and Interfaces - Message Flow and Processing Steps - Field Mapping and Transformation Rules - Validation and Error Handling - Status Reporting and Notifications - Non Functional Requirements - Appendices and Reference Data ### Process Flow The Process Flow shows the end to end journey of a cross-border payment from MT103 receipt to pacs.008 delivery, including validation, enrichment, screening, transformation and settlement. It uses swimlanes for customer, operations, compliance and technology, shows decision points for repair and rejection, and identifies the systems and people responsible at each step. It is the reference that operations and business teams use to understand the new process. Template sections: - Process Overview and Scope - Actors and Swimlanes - As Is MT103 Flow - To Be pacs.008 Flow - Decision Points and Exception Paths - Controls and Handoffs - Timing and Cutoffs - Glossary ### Solution Architecture The Solution Architecture describes the target technology design for the migration, including the payment hub, the message transformation engine, the SWIFT interface, the screening platform and the core banking system. It shows how messages flow between systems, where data is stored, how resilience and failover work, and how the design meets security, performance and audit requirements. It guides developers and infrastructure teams during build and deployment. Template sections: - Architecture Overview - System Landscape and Components - Message Flow and Integration Pattern - Data Architecture and Storage - Security and Access Control - Resilience, Performance and Scalability - Deployment and Environments - Risks and Design Decisions ### Data Mapping Sheet The Data Mapping Sheet lists every MT103 field and its target in pacs.008, with the transformation rule, the data type, the length, the mandatory or optional status, and the handling for truncation, enrichment and default values. It covers party data, agent data, remittance information and charges, and it flags fields that have no direct equivalent and need a business decision. Developers build from this sheet and testers verify against it. Template sections: - Mapping Overview and Conventions - MT103 to pacs.008 Field Mapping - Party and Agent Mapping - Remittance and Charges Mapping - Truncation and Enrichment Rules - Validation Rules per Field - Open Decisions and Gaps - Version History ### API Specification The API Specification defines the interfaces that expose payment initiation, payment status and message transformation services to channels, the core banking system and partner systems. It lists each endpoint, the request and response payloads in ISO 20022 XML or JSON, the authentication method, the error codes and the service level for response time and availability. It lets channel and integration teams build against a stable contract. Template sections: - API Overview and Principles - Authentication and Authorisation - Endpoint Catalogue - Request and Response Payloads - Error Codes and Handling - Data Validation Rules - Performance and Rate Limits - Versioning and Change Control ### Jira User Stories Jira User Stories break the migration into small, deliverable pieces of work that a development team can build and test in a sprint. Each story states the user need, the business value and the acceptance criteria, and it is linked to the BRD, the FSD and the data mapping sheet. Stories cover message ingestion, transformation, screening, status reporting, repair screens and regression testing, with clear priorities and dependencies. Template sections: - Epic and Story Structure - Story: MT103 Ingestion - Story: MT to MX Transformation - Story: Screening and Validation - Story: Status Reporting - Story: Repair and Exception Handling - Story: Regression and Certification - Definition of Done ### Acceptance Criteria Acceptance Criteria define the conditions that must be met before a user story, a release or the full migration is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given input, including message validation, transformation accuracy, screening behaviour and status reporting. Criteria are agreed before development starts and are used as the basis for user acceptance testing and sign off. Template sections: - Acceptance Criteria Principles - Criteria per User Story - Message Transformation Criteria - Validation and Error Criteria - Performance Criteria - Security and Audit Criteria - UAT Entry and Exit Criteria - Sign Off Checklist ### UAT Scenarios UAT Scenarios describe the business tests that prove the migration works end to end, from a customer instruction to beneficiary credit and status reporting. Each scenario states the precondition, the test steps, the input message, the expected output and the evidence required. Scenarios cover a 10,000 dollar MT103 to a US beneficiary, a 50,000 euro payment with structured remittance data, a payment with a truncated name, a sanction hit and a timeout, so the business can sign off with confidence. Template sections: - UAT Scope and Approach - Test Environment and Data - Scenario: Standard Payment - Scenario: Structured Data and Truncation - Scenario: Sanction Hit and Repair - Scenario: Rejection and Reversal - Scenario: Performance and Volume - Defect Management and Sign Off ### RTM The Requirements Traceability Matrix links every business requirement in the BRD to its functional specification, its design component, its user story, its test case and its UAT result. It shows which requirements are covered, which are in progress and which have failed testing, so that no requirement is lost during build. It is the main evidence that the migration meets the agreed scope and is ready for production release. Template sections: - Traceability Principles - BRD to FSD Mapping - FSD to User Story Mapping - User Story to Test Case Mapping - Test Case to UAT Result Mapping - Coverage Summary - Open Items and Gaps - Sign Off