Migrating from SR2025 to SR2026

What the SR2026 Standards Release changes in transmute output (structured postal addresses), how srVersion and X-Api-Version pin it, and the planned default change with the 14 November 2026 release.

transmute follows the yearly SWIFT Standards Releases (SR). You choose the release a request follows with two independent controls, and you can test SR2026 today without changing anything else.

Measured on: transmute main at commit f460e0e (7 October 2026). Every output below is reproducible with the curl commands on this page against that build.

1. The two controls

Control	Where	Values (at `f460e0e`)	Effect
`srVersion`	`options.srVersion` in a JSON envelope, `?srVersion=` on raw bodies, or the `X-Transmute-SR-Version` header (that order wins)	`SR2025`, `SR2026`	Explicit Standards Release for this request. Always wins.
`X-Api-Version`	Request header, or pinned on the API key when it is created	`2026-06-01`	A date-pinned behaviour version. Its policy picks the default release used when a request names no `srVersion`.

Resolution for each request: an explicit srVersion → otherwise the default release of the resolved API version (header → key pin → current version). GET /v1/formats lists accepted releases as srVersions; every response echoes the resolved version in the X-Api-Version header.

2. What SR2026 changes

At f460e0e, SR2026 differs from SR2025 in exactly one area: structured postal addresses in the four payment/initiation pairs, in both directions:

Pairs	SR2026 behaviour
MT103 → pacs.008, MT101 → pain.001	Unstructured address lines (`:50F:`/`:59:` free text, option-F `2/`, `3/` lines) are split into `StrtNm`, `BldgNb`, `PstCd`, `TwnNm`, `Ctry` when a town and country can be inferred. An info warning `ADDRESS_SPLIT_INFERRED` names the inferred components (never their values). Lines the structured elements already cover are not repeated as `AdrLine`.
pacs.008 → MT103, pain.001 → MT101	Structured addresses compose into option-F lines (`2/<number> <street>`, `3/CC/<postcode> <town>`, subdivision folded in) instead of free text.
Any of the four, address cannot be structured	Kept as is, with `ADDRESS_UNSTRUCTURED` (warning).
Every other pair	No SR2026 table exists, so the SR2025 table is used: output is byte-identical.

Validation follows the same release: with level=cbpr, SR2026 adds the rule cbpr.address_structure_required (a PstlAdr that carries AdrLine must also carry TwnNm and Ctry).

See the difference

This synthetic MT103 (TEST BICs, the published example IBAN) is converted under both releases:

cat > mt103.txt <<'MSG'
{3:{121:00000000-0000-4000-8000-000000002601}}{4:
:20:SR26DE001
:23B:CRED
:32A:261116EUR1500,00
:50F:/DE89370400440532013000
1/MAX EXAMPLE
2/HAUPTSTRASSE 12
3/DE/10115 BERLIN
:52A:AAAADEFFXXX
:57A:BBBBGB22XXX
:59:/DE89370400440532013000
ERIKA EXAMPLE
RINGSTRASSE 5
AT-1010 WIEN
:70:INVOICE SR26-001
:71A:SHA
-}
MSG

for sr in SR2025 SR2026; do
  curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?from=mt103&to=pacs.008&srVersion=$sr" \
    -H "Authorization: Bearer $TRANSMUTE_KEY" -H 'Content-Type: text/plain' \
    --data-binary @mt103.txt | jq -r '.result' | grep -o '<Dbtr>.*</PstlAdr></Dbtr>'
done

Debtor address, SR2025:

<Dbtr><Nm>MAX EXAMPLE</Nm><PstlAdr><TwnNm>10115 BERLIN</TwnNm><Ctry>DE</Ctry><AdrLine>HAUPTSTRASSE 12</AdrLine></PstlAdr></Dbtr>

Debtor address, SR2026 (plus two ADDRESS_SPLIT_INFERRED info warnings, one for :50a:, one for :59a:):

<Dbtr><Nm>MAX EXAMPLE</Nm><PstlAdr><StrtNm>HAUPTSTRASSE</StrtNm><BldgNb>12</BldgNb><PstCd>10115</PstCd><TwnNm>BERLIN</TwnNm><Ctry>DE</Ctry></PstlAdr></Dbtr>

Validating the SR2025 output with level=cbpr passes under srVersion=SR2025 and returns two cbpr.address_structure_required errors (creditor TwnNm and Ctry) under srVersion=SR2026.

3. The planned default change (14 November 2026)

Planned, not live. At f460e0e the current version is 2026-06-01 and its default is SR2025. The change below is prepared for the release that goes live on 14 November 2026 and is announced in the changelog first.

API version	Default Standards Release	Status
`2026-06-01`	`SR2025`	Current until the release; never re-pointed afterwards
`2026-11-14`	`SR2026`	Planned: becomes the current version with the 14 Nov 2026 release

What that means for you:

You send srVersion explicitly: nothing changes.
You pin X-Api-Version: 2026-06-01 (header or key): nothing changes; you stay on SR2025.
You send neither: your requests follow the current version, so they move to SR2026 on the release date. Only the address behaviour in §2 changes.
Batch jobs keep the release their request resolved to, even if the default moves while the job waits.

The SDKs take the version once as a client option (apiVersion in TypeScript, api_version in Python, WithAPIVersion in Go, .apiVersion(...) in Java, CreateHttpClient(apiVersion: ...) in .NET) and send nothing when you leave it unset.

On-premise connector. The planned release adds a top-level apiVersion key to the connector configuration: unset follows the current version, "apiVersion": "2026-06-01" keeps SR2025, and an explicit options.srVersion on a watch always wins. An unknown date stops the connector at startup.

4. Checklist

Run your own messages through srVersion=SR2026 on a test key and compare outputs (the loop in §2 works for any pair).
If you parse MX postal addresses, read StrtNm/BldgNb/PstCd/TwnNm/Ctry as well as AdrLine.
If you parse MT option-F parties, expect 2/ and 3/ lines composed from structured addresses.
Decide: pin X-Api-Version: 2026-06-01 (or srVersion: SR2025) to keep today's output, or leave both unset to move on the release date.
If you validate with level=cbpr, check SR2026 findings before the release date.

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

Was this page helpful?