MT / MX Translations
MT to MX Translation
Convert FIN MT messages to their ISO 20022 MX equivalents using specific translator classes or the generic TranslatorFactory API. Each translator implements the SWIFT-defined mapping rules including logical message criteria and precondition checks.
// Specific translator class
MT564 source = MT564.parse(fin);
MT564_MxSeev03900202_Translation translator =
new MT564_MxSeev03900202_Translation();
MxSeev03900202 mx =
translator.translate(source);
// Or use the generic factory API
AbstractMT source =
AbstractMT.parse(fin);
Translator<AbstractMT, AbstractMX> t =
TranslatorFactory.getTranslator(source);
if (t != null) {
AbstractMX mx = t.translate(source);
System.out.println(mx.message());
}MX to MT Translation
Convert ISO 20022 MX messages back to FIN MT equivalents. Handles complex one-to-many mapping scenarios where a single MX type maps to multiple MT variants — such as pacs.009 translating to MT200, MT202, MT202COV, or MT205 depending on message content.
// MX to MT with variant resolution
MxPacs00900108 mx =
(MxPacs00900108) AbstractMX.parse(xml);
// Detect COV, OWN, or standard translation
if (isCOV(mx)) {
MxPacs00900108_MT202COV_Translation t =
new MxPacs00900108_MT202COV_Translation();
AbstractMT mt = t.translate(mx);
} else {
MxPacs00900108_MT202_Translation t =
new MxPacs00900108_MT202_Translation();
AbstractMT mt = t.translate(mx);
}
System.out.println(mt.message());Truncation Handling
When the source element value does not fit in the target message field, the translation will truncate the content. This is especially common when translating from MX to MT, where MT fields are shorter than MX elements.
By default, truncation is done with evidence — the translated content will contain an explicit + symbol at the end of truncated fields, signaling that data has been cut. The translator also stores the original and truncated content, so a full truncation report can be generated programmatically.
getTruncatedContent() method// Translate and check for truncation
MxPacs00800102_MT103_Translation translator =
new MxPacs00800102_MT103_Translation();
MT103 mt = translator.translate(mx);
// Check if any content was truncated
List<TruncatedContent> truncated =
translator.getTruncatedContent();
for (TruncatedContent tc : truncated) {
System.out.println(
"Field: " + tc.getTag()
+ " Original: " + tc.getOriginal()
+ " Truncated: " + tc.getValue());
}Preconditions & Compliance
For a valid translation output, three premises must be satisfied: the source message should be valid, the logical message criteria check should pass (the source must match the specific translation being applied), and the preconditions on the source message should pass.
The translation module does not run full compliance validation on source or target messages — the Prowide Integrator Validation module can be used for that purpose. Since translations are sensitive to data, it is recommended to run validation on the translated message as a final step before sending it through the network.
// Check preconditions before translating
MT564_MxSeev03900202_Translation translator =
new MT564_MxSeev03900202_Translation();
List<PreconditionError> errors =
translator.preconditionsCheck(source);
if (errors.isEmpty()) {
// Safe to translate
MxSeev03900202 mx =
translator.translate(source);
// Recommended: validate the result
// using the Validation module
} else {
// Handle precondition failures
for (PreconditionError e : errors) {
System.out.println(
e.getCode() + " "
+ e.getDescription());
}
}TranslatorStandard enum, which can be used as-is or as a base to derive more specific translators for different clearing systems. Base Translation Standards
| Standard | Description |
|---|---|
| ISO | Generic ISO 20022 base mappings |
| CBPR+ | SWIFT Cross-Border Payments and Reporting Plus |
| IAP | ISO Accelerator Package (v1.1 and v1.2) — base for many clearing-specific translators |
| SWIFTGO | SWIFT GPI translations |
The ISO, CBPR+, and IAP standards are fully covered. IAP in particular serves as the foundation for many clearing-specific translators, meaning regional customizations build on a well-tested, comprehensive base.
Clearing-Specific Translators
These standard translators can be used as-is, or as a base implementation to derive more specific translators for different clearing systems. The following regional RTGS and clearing systems have out-of-the-box customized translations:
SIC
Swiss RTGS — Swiss Interbank Clearing system translations with SNB-specific rules.
RITS
Australian RTGS — Reserve Bank Information and Transfer System translations.
CHATS
Hong Kong RTGS — Clearing House Automated Transfer System translations.
SCRIPS / MEPS+
Legacy Singapore Clearing and Payment System / MEPS+ Singapore RTGS translations.
T2S / TARGET2
Euro area TARGET2 system translations with ECB-specific rules for high-value payments and securities settlement.
LYNX
Canadian RTGS — Bank of Canada's high-value payment system translations.
FISC
Taiwan RTGS — Financial Information Service Co. payment system translations.
EBA
Euro Banking Association -- E1-S1 euro clearing and settlement translation variants.
Fedwire
US Federal Reserve wire transfer system translation variants with local market conventions.
And More
New clearing-specific translators are added continuously, or can be configured via JSON on top of a base translator package.
Payments (1xx / 2xx)
MT103 ↔ pacs.008, MT202 ↔ pacs.009, MT200 ↔ pacs.009, MT202COV ↔ pacs.009, MT205 ↔ pacs.009. Includes STP, REMIT, and COV variants with full CBPR+ compliance.
Cash Management (9xx)
MT940 ↔ camt.053, MT942 ↔ camt.052, MT900/910 ↔ camt.054. Statement and debit/credit notification translations.
Securities (5xx)
MT535 ↔ semt, MT536 ↔ semt, MT540-MT543 ↔ sese, MT548 ↔ sese, MT564 ↔ seev, MT566 ↔ seev, MT567 ↔ seev. Full corporate actions and settlement instruction translations.
Trade Finance & More
MT300 ↔ fxtr, MT700/MT707 ↔ tsmt. Foreign exchange confirmations and trade services translations with additional categories being added continuously.
Statements (SR2028)
MT940, MT942 and MT950 statements migrate to camt.053 / camt.052. SWIFT provides no MT-to-ISO conversion — receiving institutions must translate or consume camt natively from November 2027.
Direct debits (SR2028)
MT104 / MT107 / MT204 move to pain.008, pacs.003 and pacs.010. No SWIFT in-flow translation is offered for direct-debit traffic.
Charges & advices (SR2028)
MT19x / MT29x charges messages migrate to camt.105 / camt.106, again with no SWIFT conversion path.
Exceptions & Investigations (Nov 2027)
E&I moves to Case Management with camt.110 / camt.111 and cancellations camt.056 / camt.029 — no in-flow translation support.
MT101 (Nov 2026)
Only single, eligible MT101 messages are auto-translated to pain.001, for a fee; multi-instruction MT101 is rejected. The engine removes the dependency on SWIFT's chargeable bridge.
In-flow translation fees (Jan 2026)
SWIFT's in-flow translation for payments is chargeable from January 2026 and billed per sending BIC. An in-house engine with early SRG updates avoids the recurring charge.