Validate

POST /v1/validate — syntax, schema, usage-guideline (CBPR+, HVPS+, Fedwire, SEPA, CGI-MP) and MT network-rule validation with structured findings. Message problems come back as findings in a 200, not as errors.

The contract

POST /v1/validate checks a message and always answers 200 for content-level problems — an invalid message is a successful validation with findings, not an API error:

curl -sS -X POST "https://api.transmute.403fin.io/v1/validate?from=mt940&level=schema" \
  -H "Authorization: Bearer $TRANSMUTE_KEY" \
  -H "Content-Type: text/plain" \
  --data-binary @statement.mt940

{ "valid": false,
  "findings": [
    { "severity": "error", "path": ":62F:", "detail": "closing balance missing" }
  ] }

You only see 4xx errors for API-level problems: unparseable request forms (invalid-input), unknown formats (unsupported-format), and the like.

Validation levels

`level`	Input	Checks
`syntax`	MT or MX	Tokenization, field grammar, envelope structure
`schema` (default)	MT or MX	Everything in `syntax`, plus XSD validation for MX / field-content rules for MT
`cbpr`	MX	`schema`, then CBPR+ cross-border usage rules (pacs.008/009/004/002, camt.056/057/052/053/054)
`hvps`	MX	`schema`, then high-value payment system rules — the HVPS+ core as used by T2 and CHAPS (pacs.008/009/004, camt.056/029)
`fedwire`	MX	`schema`, then Fedwire Funds Service usage rules (pacs.008/009/004, camt.056/029)
`sepa`	MX	`schema`, then EPC SEPA scheme rules (pain.001, pain.008, pacs.008, pacs.004, camt.053)
`cgi`	MX	`schema`, then CGI-MP corporate-to-bank rules (pain.001, camt.053)
`network`	MT	`schema`, then cross-field rules between MT fields (MT103, MT101, MT940, MT950)

Every level beyond syntax and schema is a deployment feature: the hosted API serves all of them; an on-prem license may enable only some. A level your deployment does not serve is rejected with a 400 that lists the available levels, and GET /v1/formats returns them as validationLevels.

Guideline findings are located by path and use codes prefixed with the level (hvps.uetr_required, sepa.currency, ...). Network findings are located by line, use codes net.<message>_<n>, and name the public SWIFT error-code family (T, C, D, E or K) where a rule corresponds to one:

curl -sS -X POST "https://api.transmute.403fin.io/v1/validate?from=mt103&level=network" \
  -H "Authorization: Bearer $TRANSMUTE_KEY" \
  -H "Content-Type: text/plain" \
  --data-binary @payment.mt103

{ "valid": false,
  "findings": [
    { "level": "network", "code": "net.mt103_11", "severity": "error", "line": 10, "path": null,
      "detail": "with charges code OUR, no sender's charges (:71F:) are reported (found :71F:) [SWIFT error family E]" }
  ] }

Guideline levels reject MT input, and network rejects MX input, with a 400 naming the format. An ISO 20022 message type that a guideline level does not cover (see the table) gets the schema result with no guideline findings. Warnings leave valid: true. Control totals (NbOfTxs, CtrlSum) are checked with exact decimal arithmetic.

The rules are written in our own words from public summaries of each guideline. transmute is not affiliated with or endorsed by SWIFT, the EPC, the Federal Reserve, the Bank of England, the Eurosystem or the CGI-MP group; a clean result is a strong pre-flight check, not an acceptance guarantee.

Schema engine

For ISO 20022 input, the schema level checks the message against the message's XML schema (XSD). transmute has two engines for that check, and meta.schemaEngine in the response says which one ran:

`meta.schemaEngine`	What it checks
`structural`	Well-formedness, required elements, allowed code values, lengths and value patterns, from rules derived from the official schemas. It does not check element order or the full minimum and maximum occurrence counts
`libxml2`	Full XSD validation, including element order and occurrence counts
`null`	No XSD check ran: MT input, `level=syntax`, or input that could not be read as ISO 20022

{ "valid": true, "findings": [], "meta": { "schemaEngine": "structural" } }

The hosted API runs the structural engine. Full XSD validation (libxml2) is available in self-hosted deployments. If your downstream system rejects messages for element order, validate a sample with a full XSD validator as well before you go live.

Request forms

Identical to Convert: JSON envelope or raw MT/XML body, from auto-detected when omitted.

Billing note

Validation is a metered route: a 200 — valid or not — is billable work on a live key, as is a 400/422 (the engine parsed your input to reject it). Test keys never bill. See Test vs Live Keys.

Was this page helpful?