Transmute is live. It is a stateless, API-first financial message conversion service from 403 Enterprises for teams that still receive SWIFT MT messages, already send or consume ISO 20022 XML, and need dependable tooling between the two.

The simplest way to describe it is this: Transmute is a SWIFT MT to ISO 20022 converter, a parser, a validator, and a normalizer behind one small HTTP API. It converts formats such as MT940 to camt.053, MT942 to camt.052, MT103 to pacs.008, MT202 and MT205 to pacs.009, and many more. It also turns statement messages into clean JSON or manual-import files such as Xero-ready CSV, OFX, QFX, and QBO.

Two message queues labeled MT and MX side by side, joined by a central column of gold validation checkpoints, flanked by small metadata counter cards with sparklines and a status strip below

TL;DR

  • Transmute converts SWIFT MT and ISO 20022 messages across 81 directed pairs.
  • Message bodies are processed in request-scoped memory, never persisted, and never logged.
  • You can start on the Free tier with no credit card required.

Why this exists

Financial infrastructure is living in two message worlds at once.

The first world is SWIFT MT. It is compact, familiar, and still everywhere in bank statement and payment operations. Many teams still receive MT940, MT942, and MT950 statement messages from banks. Many treasury, ERP, and accounting import flows still expect MT-derived data or bank-statement files that look more like yesterday’s systems than tomorrow’s.

The second world is ISO 20022. It is structured, XML-based, and increasingly the target for payment and reporting systems. Downstream teams want camt.053 for statements, pacs.008 for customer credit transfers, pacs.009 for FI-to-FI credit transfers, and canonical JSON for reconciliation services that should not need to know every bank dialect.

The hard part is not acknowledging both worlds. The hard part is operating between them every day.

A bank sends MT940. A reconciliation service wants camt.053 or stable JSON. A treasury workflow needs OFX or QBO for manual import. A payments team needs to pre-flight a pacs.008 file and understand whether it passes syntax, schema, and CBPR+ usage checks. An integrator needs to accept camt.053 from one source and produce MT940 for another. These are practical gaps. They show up in production systems, migration plans, back-office tooling, and support queues.

Transmute exists for that layer. It is not a replacement for your payment system, treasury workstation, ERP, or accounting platform. It is the conversion and normalization API that sits beside them.

What Transmute does

Transmute converts financial messages between the legacy SWIFT MT format and ISO 20022 MX across 81 directed conversion pairs. That includes bank statements and reports, payment messages, returns, cancellations, charges, payment initiation, and notice-to-receive flows.

For statement-heavy teams, the core paths are direct:

  • MT940, MT942, and MT950 to camt.052, camt.053, and camt.054.
  • camt.052, camt.053, and camt.054 back to MT940 and MT950.
  • MT900 and MT910 debit and credit confirmations to and from camt.054.
  • Statement and notice sources to Xero-ready CSV, OFX, QFX, and QBO files for manual import.

For payments teams, Transmute also supports:

  • MT103 to and from pacs.008.
  • MT202 and MT205 to and from pacs.009.
  • MT103-RETN and MT202-RETN to and from pacs.004.
  • MT192 and MT292 to and from camt.056.
  • MT191 and MT291 to and from camt.106.
  • MT101 to and from pain.001.
  • MT210 to and from camt.057.

MX versions are selectable through options.targetVersion and auto-detected on input, including families such as camt.053.001.02, camt.053.001.08, and pacs.008.001.08. Mapping tables recognize SWIFT Standards Release versions SR2025 and SR2026.

Hub-and-spoke diagram with a glowing gold code-glyph API core at the center connected to labeled format tiles for MT940, MT103, OFX, camt.053, pacs.008, QBO, and JSON

Transmute also accepts real-world bank dialects that show up in production archives and file drops: MultiCash, ELBA, ING and Nordea :25: variants, ABN AMRO short-form :28:, and IBAN plus currency :25: suffixes.

Conversion is only one part of the API.

POST /v1/normalize turns any parseable format into one frozen canonical JSON shape built for bookkeeping and reconciliation. Amounts are strings, never floats. That is deliberate. Money should not move through binary floating-point arithmetic and then surprise an accounting system one cent later.

Normalize also covers additional families that are useful when the target is reporting, indexing, search, or rules: pain.008, pain.002, pacs.002, camt.029, camt.110, camt.111, MT196, and MT296.

POST /v1/validate checks syntax, schema, and optional cbpr strictness. CBPR+ usage-restriction checks are layered on the plain ISO schemas. That makes validation a strong pre-flight signal for cross-border payments. It is not a network guarantee.

POST /v1/enrich validates and normalizes reference data such as IBANs, BICs, ISO 4217 currency codes, ISO 20022 external purpose codes, and bank transaction codes. It returns derived facts and findings, built on free, redistributable registry data.

The API is described by a hand-written OpenAPI 3.1 spec. SDKs are available for TypeScript as @403ent/transmute, Python as transmute-client, and Go. You can send JSON envelopes or raw bodies. You can post bare MT text or bare XML. Content negotiation works through Accept. Errors use RFC 9457 application/problem+json, with a closed documented error catalog. Responses include X-Request-Id, RateLimit-* headers, and Idempotency-Key is honored on POSTs.

The supporting endpoints are intentionally plain: GET /v1/formats for the live format registry, GET /v1/usage for usage, and unauthenticated /v1/health and /v1/version endpoints.

The portal at transmute.403fin.io supports email sign-in, teams, roles, invites, in-app plan changes, invoices, payment methods, self-serve spend caps, and usage alerts. The docs are at docs.transmute.403fin.io, and the product overview on this site lives at /transmute/.

Accounting-platform connections are coming soon. Today, the shipped integration surface is the API and file exports for manual import: Xero-ready CSV, OFX, QFX, and QBO. Transmute does not post bank-statement lines directly into accounting platforms.

Privacy is a product guarantee

Financial messages are sensitive. An MT940 statement can contain account identifiers, names, references, narrative text, transaction details, and IBANs. IBANs are personal data. Message conversion tooling should treat the body as data under strict handling rules, not as convenient debug material.

Transmute is stateless by design.

Message contents are processed in request-scoped memory. They are never persisted. They are never logged. Completing a request leaves exactly one usage metadata row: message type, size, duration, status, and warning counts. Not warning codes. Not raw fields. Not message content.

🔒
Transmute processes message bodies in request-scoped memory only. The database stores metadata, not financial message content.

The logging middleware, Prometheus metrics, and OpenTelemetry traces are body-free by construction. They record route pattern, method, status, and latency. That is enough to operate the service without turning observability into another place where sensitive financial data can leak.

Batch processing has one honest exception to call out. If you use the async batch API, content is held temporarily so the service can process queued items. Batch payloads are encrypted with AES-256-GCM, kept on a short TTL, and purged as soon as an item completes. The default TTL is one hour. The maximum is 24 hours. Signed webhooks carry metadata only, never message content.

For local operational flows, Transmute also ships a file-drop connector. It is a small daemon that watches a directory, converts each dropped file through the engine in-process, and deposits results next door. There is no HTTP in the hot path. Content never touches a database.

We also offer a DPA, have appointed EU and UK GDPR Article 27 representatives, and maintain Article 30 records. The main point is simpler than the legal paperwork: the product is engineered so message bodies do not become stored product data.

Correctness we can show

Message conversion is only useful if it is explainable under failure and boring under success. Transmute’s correctness work is built around that idea.

No conversion step should drop data silently. If Transmute has to assume, approximate, or represent a lossy mapping, it emits a structured warning in the response envelope. Warnings are severity-graded and deterministic. You can test against them. You can route them. You can reject a conversion in your own system if a warning class is not acceptable for your workflow.

📌
Nothing is dropped silently. Any lossy or assumed conversion step emits a structured, severity-graded warning in the response envelope.

The go-live verification campaign was measured on 2026-07-12 and shipped in v0.7.0.

The all-pairs test exercised 81 of 81 registered conversion pairs with valid output and namespace checks. The golden corpus replayed 39 byte-exact conversion flows across 157 cases over HTTP against both local and deployed staging containers. The result was 157 of 157 byte-exact.

Every MX golden output passes XSD validation. Nightly cross-validation runs against an independent xmllint XSD sweep and the open-source Prowide MT parser as oracles. The nightly generative property harness runs 200 samples per family and checks re-render idempotence, conversion determinism, and the survived-XOR-warned invariant: every dropped field must produce a warning.

Verification board with three test lanes labeled golden corpus, schema checks, and fuzz runs, each ending in a gold PASS gauge, feeding a crimson audit-ledger panel of metadata rows and tally bars

There are also 11 fuzz targets running nightly. Fuzzers must never panic.

All published sample data is synthetic. The examples use TEST BICs and published example IBANs, never real bank data.

Performance work follows the same pattern: cite the harness, not a vague claim. On v0.7.0-era code, Transmute measured about 600 conversions per second per vCPU with the repo’s reproducible k6 harness in July 2026. The service is CPU-bound, which makes capacity planning direct.

Try MT940 to camt.053 in 60 seconds

Here is the house synthetic MT940 sample used in our public examples:

{1:F01AAAADEFFXXXX0000000000}{2:I940BBBBDEFFXXXXN}{4:
:20:STMT0001
:25:DE89370400440532013000
:28C:00042/001
:60F:C260601EUR1000,00
:61:2606020602C250,00NTRFNONREF//BANKREF1
:86:INVOICE 4711
:62F:C260602EUR1250,00
-}

A conversion request to the production API looks like this:

curl https://api.transmute.403fin.io/v1/convert \
  -H "Authorization: Bearer $TRANSMUTE_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/xml' \
  -d '{
    "from": "mt940",
    "to": "camt.053",
    "message": "{1:F01AAAADEFFXXXX0000000000}...-}"
  }'

That request returns camt.053 XML, with the target version defaulting to camt.053.001.08 for this path, plus structured warnings and metadata when you request the JSON envelope. If you want an explicit target version, set options.targetVersion.

{
  "from": "mt940",
  "to": "camt.053",
  "options": {
    "targetVersion": "camt.053.001.08"
  },
  "message": "{1:F01AAAADEFFXXXX0000000000}...-}"
}

For reconciliation tooling, call POST /v1/normalize instead and receive the canonical JSON shape. For pre-flight checks, call POST /v1/validate. For reference data checks, call POST /v1/enrich.

Start with the docs if you want the OpenAPI reference, error catalog, SDKs, and quickstart. Start with the product portal if you want to create a tenant and issue a key.

Pricing

Transmute pricing is monthly flat pricing plus metered overage. One conversion means one billable convert, normalize, or validate call. Overage does not block on paid plans. The Free plan hard-stops at its included limit. Self-serve spend caps are available.

Plan USD /mo EUR /mo GBP /mo Included /mo Overage per 1,000 Rate limit
Free $0 1,000 5 rps
Micro $29.99 €28.99 £23.99 5,000 $7.50 / €7.10 / £6.00 10 rps
Small $49 €47 £39 10,000 $6.12 / €5.80 / £4.90 15 rps
Starter $99 €95 £79 25,000 $4.95 / €4.70 / £3.96 25 rps
Growth $299 €285 £239 250,000 $1.50 / €1.40 / £1.20 100 rps
Scale $999 €949 £799 2,000,000 $0.62 / €0.60 / £0.50 500 rps

The Free tier requires no credit card. Every tenant also gets a one-time pool of 250 test-key requests to try the API before moving production traffic.

The current release is v0.7.0, released on 2026-07-13. Production has been live since 2026-07-15. The API runs at https://api.transmute.403fin.io.

Get started

If you are holding MT940 statements and need camt.053, JSON, CSV, OFX, QFX, or QBO, start with the Free tier at transmute.403fin.io. No credit card is required.

If you are evaluating a migration path, building a bank-statement import flow, or checking payment messages before they hit a downstream system, read the Transmute docs and call the API with your own synthetic samples.

For product questions, support is available at support@403fin.io.

“SWIFT” is a trademark of S.W.I.F.T. SCRL. transmute converts SWIFT MT messages; it is not affiliated with, endorsed by, or certified by SWIFT.