Home › Drafters › MT → MX translator (CBPR+)

MT → MX translator (CBPR+)

Paste an MT FIN block on the left and get a deterministic CBPR+ pacs.008 or pacs.009 XML on the right. Field-by-field mapping is highlighted below. Lossy conversions (value-date, charge codes) raise warnings — no data is silently dropped.

Why CBPR+ matters

CBPR+ ("Cross-Border Payments and Reporting Plus") is SWIFT's usage guideline that pins ISO 20022 to a single, interoperable subset of pacs.008, pacs.009, pacs.002, camt.054 and camt.053 for cross-border wire payments. From November 2025, every FIN participant must be able to send and receive these MX messages — MT/MX coexistence is the steady-state until the legacy MT format is retired. The big practical consequence: a payment that originates as MT103 may arrive at the beneficiary as pacs.008.001.08, and vice versa. A bank that translates these wrong introduces reconciliation breaks, sanctions-screening misses, and GPI tracking holes. This translator is a sanity check, not a production engine — but it implements the same field map your engine should.

Lossy vs lossless translation

CBPR+ is not a lossless format pair. Three structural mismatches force warnings on every real translation:

Value-date. MT 32A carries the settlement date inline (YYMMDD). pacs.008 / pacs.009 carry it on IntrBkSttlmDt, which is not part of the transaction body — it lives in the group header or the head.001 application header. Going MT → MX we drop the date with a valuedate-drop warning; going MX → MT we default to today and emit valuedate-default. Always override the default on the reverse direction.
Charge codes. MT 71A has three values (OUR / BEN / SHA). MX ChrgBr has four (DEBT / CRED / SHAR / SLEV). SLEV ("service level") has no MT equivalent and is collapsed to SHA with a charge-bearer-collapse warning. Unknown 71A values default to SHAR with a warning.
Party blocks. MT 50/59 are free-text 4×35 character blocks; pacs.008 Dbtr / Cdtr are structured (Name, Id/IBAN, Postal Address). The translator splits the first /-prefixed line as the IBAN/account and joins remaining lines as the name. Structured postal addresses are not synthesised — that is a lossy direction and your back-office must enrich.

Round-trip stability is a hard contract here: the canonical samples in the engine round-trip MT103 → pacs.008 → MT103 cleanly. The warning channel exists so silent data loss is impossible.

Common MT103 → pacs.008 gotchas

Missing UETR. CBPR+ pacs.008 / pacs.009 require CdtTrfTxInf/PmtId/UETR. If your MT envelope did not carry {121:}, the translator emits uetr-missing and you must mint one (UUID v4) before sending.
Amount decimal separator. MT 32A uses comma (1234,56); MX IntrBkSttlmAmt uses dot (1234.56). The translator flips automatically, but a manual paste often forgets this.
BIC padding. MT block-1 LT is BIC8 + LT-code (1 char) + branch (3 chars) = 12 chars. ISO 20022 BICFI is 8 or 11 characters. The translator strips the LT-code, which is correct, but means the BIC may shorten by one character — check against your CBPR+ enrichment.
Field 70 length. MT 70 is up to 4×35 = 140 chars across multiple lines. MX RmtInf/Ustrd is also 140 chars but on a single line. Multi-line MT 70 collapses with a single space.
Charge bearer "OUR" with deductions. Real-world MT103 sometimes carries OUR + 71F deduction codes. CBPR+ requires structured ChrgsInf if you express deducted charges. The translator drops 71F silently — fill it manually if your flow uses it.
50F structured party. MT 50F encodes a structured ordering customer with line tags (1/ name, 2/ address, 3/ country code). The translator only reads the name component; structured address pass-through is on the roadmap.

Field-by-field reference

Each of the three CBPR+ pairs (plus the MT199 best-effort wrapper) has a mapping table below. Rows highlight in real time when the current translation produces a warning that involves that field — click any row to see which engine rule it links to.

Field mapping (CBPR+)

All four mapping tables below are sourced from the open-source engine. Rows highlight when the current translation produces a warning that involves them.

MT103 ↔ pacs.008.001.08

Source	Target	Notes
`Block 3 {121:} UETR`	`CdtTrfTxInf/PmtId/UETR`	End-to-end unique transaction reference. Required on both sides.
`MT 20 Sender's Reference`	`GrpHdr/MsgId + PmtId/InstrId + EndToEndId`	MT 20 is a single 16-char ref; on MX it splits into MsgId, InstrId, EndToEndId. The translator copies it to all three by default.
`MT 23B Bank Operation Code`	`(implicit CRED)`	MT 103 distinguishes CRED/SPRI/SSTD/SPAY; pacs.008 only encodes CRED via element semantics.
`MT 32A amount (1234,56)`	`IntrBkSttlmAmt (1234.56)`	Decimal separator flips from comma to dot. Currency code copied verbatim.
`MT 32A value-date (YYMMDD)`	`(not on wire — defaulted to today on reverse)`	pacs.008 does not carry the value-date on the FI-to-FI message; reverse translation defaults to today.
`MT 50K/F/A Ordering Customer`	`Dbtr (Nm + Id/IBAN [+ BIC])`	Free-text party block parsed into structured Dbtr. First /-prefixed line treated as IBAN.
`MT 52A Ordering Institution`	`DbtrAgt/FinInstnId/BICFI`	Falls back to the block-1 sender BIC if 52A is absent.
`MT 56A Intermediary`	`IntrmyAgt1/FinInstnId/BICFI`	Optional. Mapped 1:1.
`MT 57A Account With Institution`	`CdtrAgt/FinInstnId/BICFI`	Falls back to the block-1 receiver BIC if 57A is absent.
`MT 59 Beneficiary`	`Cdtr (Nm + Id/IBAN [+ BIC])`	Same parsing rules as MT 50.
`MT 70 Remittance Information`	`RmtInf/Ustrd`	Multi-line MT 70 collapsed to a single Ustrd line; truncated to 140 chars on reverse.
`MT 71A Details of Charges (OUR/BEN/SHA)`	`ChrgBr (DEBT/CRED/SHAR)`	Direct mapping. MX SLEV collapses to MT SHA with a warning.

MT202 ↔ pacs.009.001.08

Source	Target	Notes
`Block 3 {121:} UETR`	`CdtTrfTxInf/PmtId/UETR`	Required on both sides.
`MT 20 Sender's Reference`	`MsgId + InstrId`	Translator copies to both fields.
`MT 21 Related Reference`	`EndToEndId`	1:1 mapping; defaults to MT 20 if 21 is absent.
`MT 32A amount`	`IntrBkSttlmAmt`	Comma → dot, currency copied.
`MT 32A value-date`	`(not on wire)`	Same caveat as MT103/pacs.008.
`MT 52A Ordering Institution`	`DbtrAgt/FinInstnId/BICFI`	Defaults to block-1 sender BIC.
`MT 56A Intermediary`	`IntrmyAgt1/FinInstnId/BICFI`	Optional.
`MT 58A Beneficiary Institution`	`CdtrAgt/FinInstnId/BICFI`	Defaults to block-1 receiver BIC on reverse.

MT202COV ↔ pacs.009.001.08.COV

Source	Target	Notes
`All MT202 FI fields`	`Cover (top-level) pacs.009 block`	Same as MT202 ↔ pacs.009 above.
`MT 50A/K Underlying Ordering Customer`	`UndrlygCstmrCdtTrf/Dbtr`	Parsed into structured Dbtr.
`MT 59 Underlying Beneficiary`	`UndrlygCstmrCdtTrf/Cdtr`	Parsed into structured Cdtr.
`MT 70 Underlying Remittance Info`	`UndrlygCstmrCdtTrf/RmtInf/Ustrd`	Truncated to 140 chars on reverse.
`(missing underlying sequence)`	`(translator warning)`	COV without underlying is a malformed message.

MT199 ↔ pacs.009.001.08 (best-effort)

Source	Target	Notes
`(entire MT199 free-format)`	`(minimal pacs.009 envelope)`	MT199 is a free-format narrative message with no native ISO 20022 counterpart. The translator produces a syntactically-valid envelope and stages the narrative as remittance info — manual review required.
`MT 20 Sender's Reference`	`MsgId + InstrId`	Copied to both.
`MT 21 Related Reference`	`EndToEndId`	Defaults to MT 20 if 21 is absent.
`MT 79 Narrative`	`RmtInf/Ustrd (truncated 140)`	Free-text narrative lines joined with spaces, then capped at 140 chars.
`(no amount in MT199)`	`IntrBkSttlmAmt (defaulted XXX 0.00)`	MT199 carries no amount; you must fill IntrBkSttlmAmt manually.

Free REST APIMT → MX translator (CBPR+) API

100 translations per IP per day. No auth. CORS open. Returns { ok, sourceKind, targetKind, target, mapping, validation, warnings }.

POST https://ohmyfin.org/api/draft/mt-to-mx
Content-Type: application/json

{ "source": "{1:F01DEUTDEFFAXXX0000000000}{2:I103NWBKGB2LAXXXN}{3:{121:...}}{4:...-}" }

Frequently asked questions

Which MT messages can I translate?

MT103 → pacs.008.001.08, MT202 → pacs.009.001.08 (core), MT202COV → pacs.009.001.08 with the underlying customer credit transfer sequence (COV), and MT199 → pacs.009.001.08 as a best-effort wrapper (MT199 is free-format, so the translator emits a minimal envelope with a `best-effort` warning and stages narrative as remittance info).

What gets lost?

The MT 32A value-date is not preserved on the wire in pacs.008/pacs.009 (it travels in head.001 application header or out of band). Free-text 50/59 lines are split into Dbtr/Cdtr Nm + IBAN heuristically. Both produce machine-readable warnings.

Is the output CBPR+ compliant?

The XML is wrapped in BizMsgEnvlp + head.001.001.02 AppHdr and uses the .08 schemas required for the November 2025 migration. Mandatory CBPR+ fields like UETR are checked; missing values raise validation errors.

Do you log my message?

No. The endpoint is rate-limited per IP but does not persist source or target content. For full off-grid use, self-host the open-source @ohmyfin/swift-draft package.

Other tools: MX → MT translator (CBPR+) All drafters

Trademarks & Non-Affiliation Notice

SWIFT, SWIFTNet, SWIFT GPI, SWIFT Go, UETR, BIC, MT, MX, FIN, pacs.008, pacs.009, camt, ISO 20022 and related message-type identifiers, codes and logos are trademarks, service marks or registered marks of Society for Worldwide Interbank Financial Telecommunication SCRL (S.W.I.F.T. SC), with registered office at Avenue Adèle 1, 1310 La Hulpe, Belgium, and/or ISO 20022 Registration Authority. IBAN is published under ISO 13616. Visa, Mastercard, SEPA, Fedwire, FedNow, CHAPS, TARGET2, RTGS and all bank names, brand names, BIC codes and logos referenced on this site are the property of their respective owners and are used purely for descriptive and reference purposes under nominative fair use.

Ohmyfin Organisation is an independent payment-status search and reference service. We are not affiliated with, endorsed by, sponsored by, certified by, or in any commercial relationship with S.W.I.F.T. SC, the ISO 20022 Registration Authority, the European Central Bank, the U.S. Federal Reserve, any central bank, any commercial or correspondent bank, any clearing house, or any payment-system operator. References to SWIFT message types, status codes, GPI tracking, ISO 20022 messages or any third-party product or trademark are made solely to describe the publicly documented payments ecosystem within which our independent search service operates.

We are not a bank, money-services business, payment institution, electronic-money issuer or settlement agent. We do not hold, transfer, send, receive, custody or settle funds. We do not initiate, modify, cancel, recall or release SWIFT or ISO 20022 payment messages. Information returned by our tools is provided on an “as-is” basis for informational and convenience purposes only and does not constitute financial, legal, regulatory or compliance advice. For binding confirmation, settlement status, value-date confirmation, refunds, recalls, investigations or any official record of a payment, customers must always contact their bank or licensed payment service provider directly.

Official domain. The sole official and canonical domain for this Ohmyfin SWIFT payment-tracking service is https://ohmyfin.org. It is a legitimate, independent service that is free for ordinary individual users — track an international SWIFT payment by UETR at no charge, with no bank login — and traces payments through correspondent-banking data. Ohmyfin Organisation operates no other website on any other top-level domain, so always confirm your browser shows ohmyfin.org before entering a payment reference. See /what-is-ohmyfin for more.