SWIFT ended MT and MX coexistence for cross-border payment instructions on the FIN network on 22 November 2025. The MT101 templates did not go anywhere: they sit in treasury workstations, ERP export jobs and bank-portal integrations that were built around them for twenty years. Every one of those systems now has to produce an ISO 20022 pain.001 the bank will accept, and the Swift Standards Release 2026 adds structured-address requirements on top.
There are two ways to get there. Rewrite each export so it emits pain.001 directly, and re-test every field mapping by hand. Or keep the MT101 the system already emits, parse it into the flat records pain001 validates, and let the same pipeline that checks every other input produce the XML. The second path is what pain001-loader-mt101 is for.
What the loader does#
One function. parse_mt101(text) takes an MT101 message, with or without its {4:...-} block envelope, and returns one record per Sequence B transaction. The record keys are exactly the ones pain001 validates against the pain.001.001.09 JSON Schema, so the output passes SchemaValidator unchanged and flows through the scheme rulebook and the official XSD like any CSV batch.
= # one dict per transaction
The field-mapping table covers the mandatory and common-denominator tags: :20:, :30:, :21:, :32B:, the :50a:, :52a:, :57a: and :59a: party options, :70: remittance and :71A: charges. Sequence B overrides Sequence A, as the standard says. Tags that need human judgement, such as instruction codes, FX and intermediary routing, are deliberately out of scope and documented as such, so a file never leaves the loader half-converted: malformed input raises a precise error instead.
AI agents get the same capability as the convert_mt101 tool in the MCP server.
Why records, not XML#
Because conversion without validation is how malformed files reach banks. A converter that writes XML directly has to be trusted twice: once for the mapping and once for the output. Records go through the three layers every pain001 input goes through, the JSON Schema, the rail rulebook and the official XSD, and the XML you get is proven clean before submission. That is the property the example corpus documents for 42 scenarios, with provenance.
The migration in three steps#
-
Install both packages (Python 3.10 or later, no other dependency):
-
Parse the MT101 you already produce, keep the records, and generate the XML with
pain001for the edition and rail your bank names. The records are plain dictionaries, so the fields MT101 does not carry and the schema requires, which the loader synthesises with documented defaults, can be set from your own master data before generation. -
Prove it before the first live file. Run the result through the browser demo, which executes the real library in your browser and shows the three verdicts and the ISO 20022 JSON twin; nothing leaves your machine. The cross-border scenario loaded by that link is the shape most MT101 traffic takes.
When to ask for help#
The loader covers the public MT101 grammar. Your bank's usage guideline for pain.001, the elements it insists on and the ones it rejects, is a private document, and it is applied privately with the library's overlay tooling. If you want that derivation done for you, or a supported release channel while the migration runs, the enterprise page describes both. The software stays free either way.