MX to MX Conversions
The ISO 20022 pairs that stay within MX: camt.052 to camt.053, re-rendering camt.053 and camt.052, camt.055 to camt.056, plus account reports and statements to MT942.
Why convert MX to MX
Most conversions change family, MT to MX or the reverse. A few problems sit entirely inside ISO 20022 (MX): a bank sends an account report (camt.052) where your ERP expects a statement (camt.053), a bank's camt.053 fails your importer's schema check, or a statement arrives in the old .001.02 version. For those, transmute offers a short, fixed list of same-family pairs:
| From | To | Use |
|---|---|---|
camt.052 | camt.053 | Re-issue an account report as a statement |
camt.053 | camt.053 | Re-render a statement: clean, schema-valid output, .02 upgraded to .08 |
camt.052 | camt.052 | Re-render an account report the same way |
camt.055 | camt.056 | Forward a customer's cancellation request as the interbank cancellation request |
pain.001 | pain.001 | The .001.03 / .001.09 version bridge, see Message Versions |
No other MX to MX pair and no MT to MT pair is supported. camt.053 → camt.052, camt.054 → camt.053 and pacs.008 → pacs.008 are deliberately absent: each would change what the message claims. Asking for one is a unsupported-conversion 422.
Report to statement (camt.052 → camt.053)
curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?to=camt.053" \
-H "Authorization: Bearer $TRANSMUTE_KEY" \
-H "Content-Type: application/xml" \
--data-binary @report.camt052.xml
# "meta": {"detectedType": "camt.052", "detectedVersion": "camt.052.001.08",
# "targetType": "camt.053.001.08", ...}
An account report is an intraday or interim view; a statement is the end-of-period record. Two gaps between them are reported, never papered over:
| Gap | What transmute does | Warning |
|---|---|---|
The report has no CLBD (closing booked) balance, typically only ITBD (interim booked) | Balances are copied as typed. An ITBD is never relabelled CLBD, because that would invent a closing figure the bank did not state. | STATEMENT_BALANCE_ABSENT (warning) |
The report has no legal sequence number (LglSeqNb) | The electronic sequence number (ElctrncSeqNb) is kept; no legal sequence is made up (the element is optional) | LEGAL_SEQUENCE_ABSENT (info) |
[
{ "code": "STATEMENT_BALANCE_ABSENT", "severity": "warning",
"sourceField": "Rpt[0]/Bal", "targetField": "Stmt[0]/Bal",
"detail": "account report carries no CLBD closing booked balance; balances carried verbatim by type, none retyped to CLBD" },
{ "code": "LEGAL_SEQUENCE_ABSENT", "severity": "info",
"sourceField": "Rpt[0]/LglSeqNb", "targetField": "Stmt[0]/LglSeqNb",
"detail": "account report carries no legal sequence number; none synthesized (element is optional)" }
]
A report that does carry a CLBD balance and a legal sequence number converts with neither warning.
Re-render (camt.053 → camt.053, camt.052 → camt.052)
A re-render parses the document and writes it again. It is not a byte-for-byte copy:
- Version upgrade.
.001.02input comes out as.001.08, with the elements renamed in.08(such asBICtoBICFI) moved to their new names. To go the other way, addtoVersion=camt.053.001.02; see Message Versions. - Schema-valid output. The sequence numbers
ElctrncSeqNbandLglSeqNbmust be at most 18 digits. A value that is longer or not a plain number is dropped, never shortened (a shortened sequence number would be a wrong one), withFIELD_OVERSIZED(lossy). Both elements are optional, so the output stays valid. - Content with no place in the model is dropped with a warning. Elements transmute does not model surface as
DROP_FIELDwarnings. Re-rendering promises clean, schema-valid, version-normalized output with a warning trail, not losslessness.
curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?to=camt.052" \
-H "Authorization: Bearer $TRANSMUTE_KEY" \
-H "Content-Type: application/xml" \
--data-binary @report.camt052.xml
{ "code": "FIELD_OVERSIZED", "severity": "lossy",
"sourceField": "statement[0].statementNumber", "targetField": "Rpt[0]/ElctrncSeqNb",
"detail": "ElctrncSeqNb value of length 22 exceeds 18 digits (schema type Number, max 18 digits); element dropped, never truncated" }
The same sequence-number check applies on every conversion that writes camt.052 or camt.053, for example from MT942.
Cancellation request (camt.055 → camt.056)
A camt.055 is a customer asking its bank to cancel a payment it initiated. Once the payment has left the bank, the bank forwards the request to the next bank as a camt.056. transmute converts in that one direction only.
- The original payment-information id (
OrgnlPmtInfId) has no place in the interbank message and is dropped withDROP_FIELD(lossy). - The instructed amount and requested execution date are copied into the original interbank settlement amount and date. They are copied, never computed.
- camt.056 elements the request does not supply, such as the assignee, are defaulted with
MISSING_REQUIRED_DEFAULTED(info).
camt.055 also converts to mt192 and mt292.
Account reports and statements to MT942
camt.052, camt.053 and camt.054 also convert to MT942, the MT interim transaction report:
curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?to=mt942" \
-H "Authorization: Bearer $TRANSMUTE_KEY" \
-H "Content-Type: application/xml" \
--data-binary @report.camt052.xml
For a report built from the quickstart MT940 sample, result is:
:20:STMT0001
:25:DE89370400440532013000
:28C:00042/001
:34F:EUR0,
:13D:2610081057+0000
:61:2606020602C250,00NTRFNONREF//BANKREF1
:86:INVOICE 4711
MT942 has two mandatory fields an ISO 20022 report does not supply directly:
| Field | Value | Warning |
|---|---|---|
:13D: date-time indication | The report's creation time with its UTC offset. Without one, the conversion time. | MISSING_REQUIRED_DEFAULTED (info), only when defaulted |
:34F: floor limit | Always a zero amount in the entries' currency. transmute never derives a floor limit from the entries. | MISSING_REQUIRED_DEFAULTED (info) |
Other behaviour:
- Balances (opening, closing, available, forward) and the reporting period have no MT942 field and are dropped with
DROP_FIELD(info). :90D:and:90C:(number and sum of debit and credit entries) are written only when the source states a transaction summary, copied as stated. They are never computed from the entries.field86Profileshapes:86:exactly as for MT940.- MT942 is not split into pages. An oversize report is written whole, with a warning.
All warning codes on this page are listed in the warning registry.