Scope of work

Migrating an MT application to MX

Translation gets you onto the network. Migration gets you the benefit. This is the work between those two things: what has to change in the application, in the data, and in the operating model — sequenced so that the payments never stop.

Read the phase plan See the adapter that carries phase 1

Shape: Five phases, run sequentially with overlap at the seams
Duration: 12 to 18 months for a mid-size bank with a single core
Workstreams: Nine, of which two are not technology
Cutover: Dual-run, then release per corridor with rollback held open
Hard part: Party and address data, every time

01

Framing

This is not a file-format project

Teams that scope it as one deliver a translator, pass the network deadline, and then spend the following two years explaining why none of the promised benefits arrived. Three things make it an application programme rather than an interface change.

Reason 01

The data model is wider

ISO 20022 expects structured parties, structured addresses, purpose codes, extended remittance and a full agent chain. An MT-shaped database cannot express most of that, so the schema, the screens and the validation all move with it.

Reason 02

Downstream systems consume the difference

Screening, sanctions, fraud, liquidity, regulatory reporting and reconciliation all get better inputs — but only after each one is changed to read them. Every consumer of the payment record is in scope until proven otherwise.

Reason 03

Coexistence has an end date

The translation window is finite and set by the market, not by you. Anything still depending on MT text when it closes becomes an unplanned emergency, which is why phase 4 is in the plan from the start.

02

Baseline and destination

Where the boundary moves

Today the application owns MT and the gateway owns delivery. In the target state the application owns a canonical payment, and MT survives only where a counterparty still needs it. The distance between those two pictures is the scope.

Figure 1. Current and target states. The dashed boundary box is the only part of the target that is designed to disappear.

03

Sequence

Five phases, and what each one is allowed to claim

Durations below are indicative for a mid-size bank with one core platform and a single-region footprint. The sequence matters more than the numbers: each phase exists to make the next one safe.

Figure 2. Phase plan. Colour moves from MT amber to MX aqua as ownership of the payment record moves with it.

Phase004 weeks

Discovery and impact assessment

Nothing is estimated properly before this. Inventory every MT touchpoint including the ones nobody owns: batch jobs, spreadsheets, reporting extracts, that one Perl script. Profile the data you actually hold, not the data the schema allows.

Work: message and volume inventory; touchpoint and consumer map; party and address data profiling with a measured structured-address rate; rulebook selection per corridor; gap analysis against the target model; target-state decision and business case.

Exit criteria A per-corridor message inventory, a measured data quality baseline, a signed target state, and an estimate no longer built on assumption.

Phase0112 weeks

Translate at the boundary

The adapter goes in and the network sees MX. The application does not change, which is the point: this phase buys compliance and time, and it must not be mistaken for migration.

Work: adapter deployment and rule pack configuration; mapping build per message pair; dual-run comparison harness; repair desk process, staffing and handover; fidelity reporting; monitoring and alerting; bilateral and network testing; per-corridor release.

Exit criteria Every in-scope corridor sending validated MX, a difference report that is stable and understood, repair volumes inside an agreed threshold, and rollback rehearsed rather than theorised.

Phase0216 weeks

Canonical payment APIs

Internal consumers stop reading FIN text. This is where the programme starts producing value that survives the adapter's removal.

Work: canonical payment contract published and versioned; REST and event interfaces; consumer-by-consumer migration with strangler routing; screening and fraud moved onto structured names and addresses; regulatory reporting rebuilt on structured fields; reconciliation moved to camt.

Exit criteria No new consumer reads MT text, the top consumers by volume are migrated, and screening false positives are measured before and after.

Phase0324 weeks

MX-native core processing

The longest and most valuable phase. The payment record itself changes shape, which means schema, screens, capture, validation and history all move.

Work: data model extension for structured parties, addresses, purpose codes and extended remittance; capture and channel changes so structure is collected at source; historical data remediation policy; validation moved to the rulebook; MX persisted as the system of record; adapter reduced to counterparty-facing translation only.

Exit criteria New payments are captured and stored structured, the structured-address rate clears the corridor requirement without repair, and the adapter is no longer used for internal traffic.

Phase048 weeks +

Decommission

Deliberate, evidenced removal — not a hopeful ticket in the backlog. Translation stays only where a real counterparty still speaks MT, and each remaining route has a named owner and a review date.

Work: flow-by-flow retirement with usage evidence; removal of MT persistence and the code that reads it; archive and retention arrangement for historical MT; residual route register; run-cost reduction confirmed.

Exit criteria Every retired route evidenced as unused for an agreed period, and every surviving route justified in writing.

04

Delivery structure

Nine workstreams

Two of them are not technology work, and they are the two that decide whether the programme lands: data remediation and the operating model. Fund them accordingly.

Workstreams, content and primary deliverable
Workstream	Included	Primary deliverable	Peak
Standards & rulebook	Message version selection, usage guideline interpretation, CBPR+ and local market practice, release-calendar tracking, change impact per corridor	Corridor specification set, maintained	P0–P1
Mapping & translation	Per-pair mapping build, code-word rules, fidelity outcome policy, conformance tests against published samples, regression pack	Mapping specifications and passing test suite	P1
Data quality & remediation	Party and address profiling, parsing and enrichment, reference-data matching, customer outreach for what cannot be inferred, capture-time validation	Structured-address rate at target, per corridor	P0–P3
Integration & platform	Adapter deployment, routing, Kafka topics, idempotency, observability, environments, non-functional testing, capacity	Production platform with runbooks	P1–P2
Core application change	Data model extension, capture and screen changes, validation relocation, history handling, canonical persistence	MX-native payment record	P3
Downstream consumers	Screening, fraud, liquidity, regulatory reporting, reconciliation, data warehouse, customer-facing statements and advices	Consumer migration register at zero	P2–P3
Testing & certification	Mapping conformance, usage-guideline validation, bilateral counterparty testing, network pilot, operational readiness, rollback rehearsal	Certification evidence pack	P1–P3
Operating model & people	Repair desk design and staffing, escalation paths, SLA changes, training for operations and front office, procedure rewrites	Run model in place before go-live	P1
Risk, compliance & audit	Screening effectiveness evidence, regulatory reporting equivalence, data-protection review of the audit store, model and change governance	Sign-off with evidence, not assertion	P2–P4

On sequencing the two non-technology streams. Data remediation starts in phase 0 and never stops; if it starts when the core change starts, the core change waits for it. The operating model has to be live before the first corridor is released, because the repair queue exists from the first message, not from the first complaint.

05

The workstream that decides the programme

Party and address data

Every MT-to-MX programme discovers the same thing at the same point: the format converts in weeks and the data takes months. Free-form name-and-address lines cannot be turned into structured elements by a mapper, because the information needed to split them was never captured.

Figure 3. Remediation shape. Phase 0 profiling replaces these proportions with yours — and the outreach band is the one that sets the timeline.

Scope of the data workstream

Included

Profiling of every party-bearing field, by corridor and by channel
Parsing and enrichment rules, with a confidence score per inference
Matching against customer reference data, KYC files and postal reference sets
Outreach design: who is contacted, by whom, in what order, and what happens if they do not reply
Capture-time validation so the problem stops being created
A remediation dashboard with the structured-address rate as the headline number

How progress is measured

One number, per corridor

The structured-address rate: the share of outbound payments that meet the corridor's structured requirement without human repair. It is reported weekly from phase 1 and it is the only data metric the steering committee needs.

Everything else — repairs per thousand, truncation counts, unmapped residues, screening false positives — is diagnostic underneath it. When the rate is high and stable, the migration is real. When it is propped up by a repair desk, it isn't, and the number will say so.

06

Transition approach

Dual-run, then release one corridor at a time

No big-bang cutover, and no dark launch that nobody reads. Both paths process real traffic, the outputs are compared automatically, and a corridor is released only when its difference report has been empty long enough to be boring.

Figure 4. Dual-run and per-corridor release. The candidate path processes everything and releases nothing until the gate opens.

Figure 5. Certification path. Each message pair walks the whole line; a pair that skips bilateral testing fails in production instead.

07

Boundaries

In scope, out of scope, and assumed

The exclusions matter as much as the inclusions. Anything below the line either belongs to another programme or needs its own funding decision before it is added here.

In scope

Message pairs listed in the inventory below, both directions
Adapter build, configuration and production operation through phases 1 to 3
Core payment data model extension and capture changes
Canonical payment API and consumer migration
Party and address remediation, including outreach design
Screening, reporting and reconciliation changes needed to read structured data
Testing to and including network pilot, plus operational readiness
Repair desk design, staffing model and training
Decommissioning of retired MT routes

Out of scope

Core banking platform replacement or upgrade beyond the payment data model
New payment products, schemes or corridors not in the inventory
Instant-payment scheme onboarding, unless separately scoped
Securities, trade finance and treasury message families
Replacement of the screening or fraud engines themselves
Customer-facing channel redesign beyond structured capture
Historical data migration beyond the agreed retention window
Network connectivity, hardware and licence procurement

Message inventory in scope
MT	MX	Use	Mapping complexity	Phase
MT103 / STP / REMIT	pacs.008	Customer credit transfer	High — parties, charges, remittance, field 72	P1
MT202 / MT202COV	pacs.009 / COV	Bank transfer and cover	High — underlying customer credit transfer	P1
MT199 / MT299	pacs.002	Status and free format	Medium — reason codes, correlation	P1
MT900 / MT910	camt.054	Debit and credit advice	Low	P2
MT940 / MT950	camt.053	Statement	Medium — balance types, transaction codes	P2
MT942	camt.052	Intraday report	Medium	P2
MT101	pain.001	Request for transfer	Medium — batching and mandates	P3
MT192 / MT196	camt.056 / camt.029	Cancellation and response	Medium — case management	P3

Assumptions

Taken as given

One core platform, one region, one primary network
Test connectivity and a usable non-production environment already exist
Business owners are named and available for mapping decisions
Volumes and corridor lists supplied in phase 0 are accurate
Standards releases follow the published calendar

Dependencies

Outside our control

Counterparty readiness for bilateral testing
Vendor delivery for the core platform and screening engines
Customer response rates during address outreach
Network testing windows and pilot slots
Internal change-freeze and release calendars

Acceptance

Definition of done

All in-scope corridors live on MX with rollback closed
Structured-address rate at or above the corridor requirement, unaided
Repair volumes within the agreed threshold for a full month
No consumer reading MT text, evidenced by access logs
Retired routes evidenced unused; surviving routes justified in writing
Certification pack accepted by risk and audit

08

Honest register

What actually goes wrong

These are not generic project risks. Each one has been the reason a real MT-to-MX programme slipped, and each has a mitigation that has to be funded rather than noted.

Risk register, ranked by how often it bites
Risk	How it shows up	Mitigation
Address data underestimated	Phase 3 stalls because the structured rate will not move, and the repair desk quietly becomes permanent headcount	Profile in phase 0, publish the rate weekly from phase 1, fund outreach as a business activity rather than an IT task
The adapter becomes the destination	Phase 1 succeeds, pressure lifts, phases 2 and 3 lose funding, and MT is still internal when coexistence ends	Fund phases 2 and 3 in the same approval as phase 1; report on the phase-4 date from month one
Field 72 and code-word sprawl	Every corridor turns out to have local conventions in free-text fields, and the mapping rule count grows without limit	Freeze a corridor rule set per counterparty, treat anything unclaimed as an explicit residue, and refuse silent inference
Downstream discovery	An unregistered consumer of MT text surfaces during dual-run, often in reporting or reconciliation	Touchpoint inventory in phase 0 built from access logs rather than interviews, plus a standing register
Standards release drift	A new schema version or usage-guideline change lands mid-build and invalidates completed mapping work	Carry multiple versions in the adapter, keep rule packs separable from schemas, and plan a release-absorption slot each cycle
Screening effectiveness regression	Structured names change match behaviour, and false positives move in an unexpected direction	Baseline before phase 2, run screening in parallel on both shapes, and get compliance sign-off on measured results
Counterparty unreadiness	A corridor cannot be released because the other side is not testing, and the gate stays shut	Sequence corridors by counterparty readiness, keep MT translation for laggards, and never let one counterparty hold the programme

09

Resourcing

Team shape

Indicative for the shape described above. The two roles most often missing are the payments standards specialist and a data lead with authority over customer records.

01
Payments standards specialist — owns the corridor specifications, reads the rulebooks properly, and is the final word on a mapping decision. One, full time, from phase 0.
02
Integration engineers — adapter, routing, mapping build and the conformance suite. Two to four, peaking in phase 1.
03
Core application engineers — data model, capture, validation and persistence. Peaks in phase 3 and is the largest single cost.
04
Data lead — owns remediation and the structured-address rate, with the authority to direct customer outreach. One, full time, phases 0 to 3.
05
Test lead — owns the certification path, the difference report and the gate evidence. One, full time, phases 1 to 3.
06
Operations lead — repair desk design, staffing, procedures and training. Part time from phase 0, full time before the first release.
07
Compliance and audit partner — screening equivalence and reporting evidence. Part time throughout, not consulted at the end.
08
Programme lead — owns the phase-4 date and defends phases 2 and 3 when the pressure comes off after phase 1.

Next step

Phase 0 is four weeks and it changes every number on this page

Everything above is a shape, not an estimate. Discovery replaces the indicative durations with measured ones, the illustrative funnel with your actual data profile, and the generic inventory with your corridors. It is also the cheapest phase to get right and the most expensive to skip.

See the adapter that carries phase 1 How translation loss is reported