Normalize

Why normalize

If your systems receive statements or payments from many counterparties — some sending MT940, some camt.053, some bank-dialect variants — normalization gives you one JSON shape to parse, regardless of source:

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.mt940

{
  "result": {
    "type": "statement",
    "statement": {
      "account": { "iban": "DE89370400440532013000" },
      "openingBalance": { "amount": "1000.00", "currency": "EUR" },
      "entries": [ { "amount": "250.00", "creditDebit": "credit", "..." : "..." } ]
    }
  },
  "warnings": [],
  "meta": { "detectedType": "mt940", "durationMs": 2 }
}

The envelope is {"type": "statement" | "payment" | "investigation", ...} with the matching object populated. The canonical shape is frozen public API — fields are only ever added (optional), never renamed or retyped.

Two rules worth knowing

• Amounts are strings, never floats. "250.00", not 250.0. Parse them with a decimal type; JSON floats corrupt money.
• Comma-decimal MT amounts are normalized — MT940's 1250,00 arrives as "1250.00".

Request forms

Identical to Convert: JSON envelope, raw MT (text/plain), or raw XML (application/xml), with the same from precedence and auto-detection when from is omitted. There is no to — the target is always canonical JSON.

Some formats are normalize-only (they can be parsed to canonical JSON but not converted to another wire format — for example camt.110/camt.111 investigations). GET /v1/formats shows which.

Warnings apply here too

Parsing a dialect quirk or inferring a date surfaces in warnings[] exactly as in conversion — see the warning registry.