Abstract symbolic illustration for SWIFT MT/MX Implementation: ISO 20022 Migration + gpi at Simpaisa — Cross-Border Payments, brand-cyan editorial composition on dark canvas
← Product Work
Cross-Border Payments

SWIFT MT/MX Implementation: ISO 20022 Migration + gpi at Simpaisa

Wired SWIFT MT and MX (ISO 20022) messaging into the Simpaisa cross-border stack with gpi tracking, CSP attestation and dual-rail parsing — sustained 99.9%+ message-acceptance rate through the ISO 20022 migration window.

6 message types
Message types handled
99.9%+
Message acceptance rate
Live
gpi adoption
Annual, on time
CSP attestation
Executive summary

What this is, in one paragraph.

Stood up SWIFT MT and MX (ISO 20022) messaging inside the Simpaisa cross-border stack — message parsing, gpi UETR tracking, real-time sanctions screening, CSP attestation, and a dual-rail data model designed to absorb the ISO 20022 migration without re-platforming. Maintained 99.9%+ message-acceptance rate through the most aggressive correspondent-bank deadline window.

◆ Before / after
Cross-border tracking
Black-box (correspondent reliance)->UETR end-to-end via gpi
Sanctions screening latency
Batch only->Real-time pre-send + batch re-screen
Message format flexibility
MT-only->MT + MX dual-rail
◆ Additional proof
Real-time + batch re-screen
Sanctions screening
MX-shaped data model from day one
ISO 20022 readiness
Problem

The job to be done.

Simpaisa's cross-border corridors needed reliable SWIFT messaging into and out of correspondent banks across five markets. The platform was on the wrong side of the ISO 20022 migration deadline, with MT-shaped data inside the ledger, no UETR-level tracking, sanctions screening running batch-only, and a CSP (Customer Security Programme) attestation that had been postponed two years in a row. Correspondent banks were starting to push back on every category.

What I built

What I shipped.

  • Dual-rail message parser: MT (legacy) and MX (ISO 20022 pacs.008 / pacs.009 / camt.053 / camt.054) handled behind a single internal API
  • UETR (Unique End-to-end Transaction Reference) generation and end-to-end tracking integrated with SWIFT gpi
  • Real-time sanctions screening (pre-send block) plus batch re-screen daily, with auditable decision log
  • Correspondent-bank reconciliation engine matching MT940/MT950 statements + camt.053 against the internal ledger
  • CSP attestation evidence pipeline: control mappings, evidence collection cadence, audit-ready repository
  • Data model designed MX-first: every internal record carries the structured fields ISO 20022 requires, even when the upstream message is MT
Architecture

How it's put together.

  • SWIFT integration sits behind a stable internal API; MT vs MX is an implementation detail
  • UETR generated at transaction initiation; propagated through every internal hop; surfaced to merchants via the cross-border product UI
  • Sanctions screening: WorldCheck / Dow Jones list + central-bank lists per market; cached with 24h TTL; pre-send call blocks on hit
  • Ledger entries are MX-shaped (structured remitter, beneficiary, purpose, regulatory codes) regardless of upstream message format
  • CSP control mappings tracked in a register with quarterly attestation cadence
Operating model

How it actually runs.

  • Weekly SWIFT health review: message acceptance, gpi tracking coverage, sanctions screening hit rate, correspondent bank issues
  • Quarterly CSP attestation prep with internal audit + external advisor
  • Monthly correspondent-bank scorecard (uptime, response time, dispute resolution)
  • Real-time alerting on message-format rejection rate > 0.1%
My role

Where I sat in the work.

Owned the SWIFT product surface end-to-end: integration architecture, gpi adoption, CSP attestation, sanctions-screening product design, correspondent-bank governance, and the ISO 20022 migration roadmap. Direct accountability for SWIFT operational KPIs and audit posture.

Impact

What moved.

  • Held 99.9%+ message-acceptance rate through the ISO 20022 migration deadline window — when many regional acquirers saw rejection-rate spikes
  • Cut sanctions-screening false-positive rate by ~60% via per-corridor tuning, without lowering true-positive coverage
  • Brought CSP attestation back onto annual cadence after two missed years
  • Delivered gpi UETR end-to-end tracking, removing the 'black box' merchant complaint about cross-border transfers
  • Established the MX-shaped data model that absorbed the ISO 20022 migration without a platform re-write
Trade-offs

What I chose against.

  • Built MX-shaped data model before market demanded it — extra engineering cost in 2022/23, paid back the moment regulators set hard MX dates
  • Chose real-time sanctions screening over async; added 200-400ms to send latency in exchange for the audit posture banks demanded
  • Maintained MT parsing alongside MX — duplicate code paths during the migration window, accepted because correspondent banks moved at different paces
Lessons

What I'd take into the next build.

  • ISO 20022 is a data-model migration, not a message-format one. Teams that treat it as 'change the parser' rebuild in 18 months.
  • gpi UETR visibility was the merchant-facing change with the clearest support impact; it turned cross-border status from a back-office chase into a product surface.
  • CSP attestation is not a yearly audit event. It's a quarterly operating discipline that produces evidence as a by-product.
  • Sanctions screening tuning is a continuous product job, not a configuration. Per-corridor false-positive rates diverge fast.
Why it matters

Relevance to networks, PSPs and cross-border platforms.

The transferable core: making MX-shaped data, gpi visibility, sanctions checks and CSP evidence part of the product rhythm rather than a migration afterthought. Any bank, PSP or remittance platform still carrying MT-era assumptions faces the same work; only the logo changes.

Discussing payment infrastructure / product leadership roles?

Reference-available. Download the résumé or get in touch.