Migrating from Prowide

How the pieces of a Prowide-based MT pipeline map onto transmute's convert, normalize and validate endpoints, what changes operationally, and how to run both side by side before switching.

Many Java teams parse and build SWIFT MT messages with Prowide Core, the open-source (Apache-2.0) Java library, and add their own code or other products for validation and MT ↔ ISO 20022 translation. This page maps those jobs onto transmute so you can move a flow, or run both while you compare. It describes transmute only; for what any Prowide product does or costs, see Prowide's own documentation.

"Prowide" is a trademark of its owner, and "SWIFT" is a trademark of S.W.I.F.T. SCRL. transmute is not affiliated with, endorsed by, or certified by either; the names are used only to identify the software you may be migrating from.

Measured on: transmute main at commit f460e0e (7 October 2026); pair counts come from GET /v1/formats on that build.

1. Concept map

In a Prowide-based pipeline you…	In transmute you call…	Notes
Parse an MT into an object model (`SwiftParser` → `SwiftMessage`, then typed MT/field classes)	`POST /v1/normalize`	Returns one canonical JSON shape per message kind (statement, payment, …) that is the same whether the source was MT or MX. Amounts are decimal strings. With the Java SDK the response is a typed `NormalizeResponse`.
Build or write an MT from your own objects	`POST /v1/convert` with `to=mt940`, `mt103`, … from an MX document or from canonical JSON (`from=canonical`)	The registry lists which targets each source reaches.
Translate MT ↔ ISO 20022	`POST /v1/convert`	30 MT → MX and 30 MX → MT directions at `f460e0e` (checklist). Every assumption or loss is a structured warning.
Validate	`POST /v1/validate` with `level=syntax` or `schema`; usage-guideline packs `cbpr`, `hvps`, `fedwire`, `sepa`, `cgi` for MX; `network` for MT cross-field rules	Findings are structured (`level`, `code`, `path` or `line`). Levels beyond `syntax`/`schema` are deployment features listed by `GET /v1/formats` (`validationLevels`); see Validate for each level's coverage.
Upgrade the library each Standards Release	Pin `srVersion` or `X-Api-Version`; nothing to upgrade	See SR2025 to SR2026.

2. What changes operationally

In-process library → HTTP API. Messages leave your JVM. transmute is stateless: message content is never logged and the database records only metadata (type, size, duration, status, warning counts). Two things hold data for a limited time, the idempotency replay cache (24 hours, only when you send the header) and batch jobs (encrypted, deleted at the job TTL). If messages must not leave your network, ask about the self-hosted image and file-drop connector.
Exceptions and parse errors → problem documents and warnings. Failures are RFC 9457 application/problem+json with a stable type from the error catalog. Successful conversions carry warnings[] with codes from the warning registry instead of silently adapting data.
Your mapping code → declarative tables. Field mappings are data tables versioned by Standards Release; you do not maintain per-field code.
Java only → any language. Typed clients exist for Java, .NET, Go, TypeScript and Python, plus a Postman collection.

3. Side-by-side migration

Pick one flow (for example, inbound MT940 statements).
Normalize in parallel. Keep your Prowide parse; also send the same raw message to POST /v1/normalize. Compare the values you actually use: account, statement number, balances, entry amounts and dates, references, remittance text.
```
curl -sS -X POST 'https://api.transmute.403fin.io/v1/normalize?from=mt940' \
  -H "Authorization: Bearer $TRANSMUTE_KEY" -H 'Content-Type: text/plain' \
  --data-binary @statement.txt | jq '.result.statement | {account, openingBalance, closingBalance, entries: (.entries | length)}'
```
For the synthetic MT940 used throughout these docs (account DE89370400440532013000, opening C1000,00, one C250,00 entry, closing C1250,00), the result carries "amount": "1000.00", "amount": "250.00" and "amount": "1250.00" with "currency": "EUR", and no warnings.
Log differences, not messages. Record field names and counts of mismatches; do not store message bodies.
Switch the flow once differences are explained, then repeat for the next flow.

4. Things to check before switching

Bank dialects of :86:. Structured ?nn sub-fields are parsed automatically on input; field86Profile (plain or german) chooses how :86: is written when MT940/MT942 is the target.
Character set. On MT targets, characters outside the SWIFT X character set are transliterated with a warning; options.strict turns that into an error.
Paging. Long MT outputs are split into several messages: result becomes an array and meta.pages is set.
Volumes. Use Batch and Idempotency-Key for retries.

Was this page helpful?