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

MX → MT translator (CBPR+)

Paste an ISO 20022 MX XML on the left and get a deterministic MT FIN message on the right. Field-by-field mapping is shown below. Lossy reverses (value-date defaulted, charge codes collapsed) raise warnings.

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 APIMX → MT 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/mx-to-mt
Content-Type: application/json

{ "source": "<BizMsgEnvlp ...>...</BizMsgEnvlp>" }

Frequently asked questions

Which MX messages can I translate back?

pacs.008.001.08 → MT103, pacs.009.001.08 → MT202, pacs.009.001.08.COV → MT202COV, and pacs.002.001.10 → MT199 best-effort (status report wrapped as free-format narrative). camt.05x have no direct MT counterpart.

Why does my value-date default to today?

ISO 20022 IntrBkSttlmAmt has no inline value-date — the date lives elsewhere (group header or head.001). When translating back to MT 32A, the translator defaults to today and raises a `valuedate-default` warning so you can override it.

How are charge codes mapped?

DEBT → OUR, CRED → BEN, SHAR → SHA. The CBPR+ SLEV code has no MT equivalent and is collapsed to SHA with a warning.

Will the round-trip be lossless?

For the canonical samples shipped here, yes. Round-tripping arbitrary production XML can be lossy when the source uses structured postal addresses or non-IBAN account identifiers — warnings are emitted on every lossy step.

Other tools: MT → MX 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.