Standards Releases

What a Standards Release is

SWIFT publishes a Standards Release (SR) every November: a yearly revision of the MT message formats and of the usage rules that networks apply to ISO 20022 (MX) messages. A release can change which fields are allowed, how long they can be, or, as in 2026, how postal addresses must be structured.

transmute keeps one set of mapping rules per release. Every conversion, normalization and validation runs under exactly one release, and you can choose which. Pinning a release means your output only changes when you decide it should.

A release with no rules of its own for a pair falls back to the latest earlier release that has them, never to a later one. That is why SR2026 output is byte-identical to SR2025 output for every pair it does not change.

GET /v1/formats lists the releases this deployment accepts as srVersions:

curl -sS https://api.transmute.403fin.io/v1/formats \
  -H "Authorization: Bearer $TRANSMUTE_KEY" | jq '.srVersions'
# ["SR2025", "SR2026"]

Pin a release per request

srVersion works on /v1/convert, /v1/normalize, /v1/validate and on each item of /v1/convert/batch. There are three ways to send it; the first one present wins:

The set is closed. Any other value, including a different case or a future release, is a invalid-input 400 that names the supported values:

{
  "type": "https://docs.transmute.403fin.io/errors/invalid-input",
  "title": "Invalid input",
  "status": 400,
  "detail": "unsupported srVersion "SR2027": supported values are SR2025, SR2026",
  "instance": "/v1/convert"
}

What SR2026 changes

From 14 November 2026, cross-border ISO 20022 payments must carry each postal address as structured or hybrid data: at least the town and the country as their own elements, with at most two free-text address lines beside them. An address made only of free-text lines is no longer accepted.

Under srVersion=SR2026, transmute applies that to four pairs, in both directions:

Address-line splitting (MT or MX in)

transmute reads the free-text lines of a party or agent address and recognises the address layout of 12 countries: DE, AT, CH, FR, ES, IT, NL, BE, GB, US, CA and AU. Each country has its own post-code shape, town-line order (post code first in DE, 10115 BERLIN; post code last in GB and the US) and street-line order (number after the street in DE, HAUPTSTRASSE 12; number first in GB, FR and the US). US, CA and AU addresses also yield a state or province.

The country comes from, in order:

1. the country already given (the option F 3/CC/ line, or an MX Ctry element);
2. a line holding only a country code or a country name;
3. a CC- prefix on a line, such as AT-1010 WIEN.

The split is used only if it yields both a town and a country. It never overwrites a component the source already structured, and the original lines are always kept alongside. When it succeeds you get one ADDRESS_SPLIT_INFERRED info warning per address, naming the inferred components (never their values):

{ "code": "ADDRESS_SPLIT_INFERRED", "severity": "info",
  "sourceField": ":59a:", "targetField": "creditor",
  "detail": "inferred components: streetName, buildingNumber, postCode, townName, country" }

On MX output, the address is written as a hybrid address: the structured elements, plus only the lines they do not already cover, at most two. Further lines are dropped with TRUNC_ADDRESS (lossy). An address that could not be structured is kept as it is and flagged ADDRESS_UNSTRUCTURED (warning), so you can fix it before it reaches a network that rejects it.

Option F composition (MX in, MT out)

A structured address is written into option F lines:

• 1/ the name;
• 2/ street and building number in the country's order, then any free-text lines the structure does not cover;
• 3/ the country code, then post code and town in the country's order (with the state or province for US, CA and AU).

That layout is the one the splitter reads back, so an MT103 → pacs.008 → MT103 round trip keeps the structure. Characters outside the SWIFT X character set are transliterated before lines are shortened. When a party has to use a free-text option (:50K:, letterless :59:), the last line carries CC-<town line>.

See the difference

This synthetic MT103 is converted under both releases:

cat > mt103.txt <<'MSG'
{1:F01AAAADEFFAXXX0000000000}{2:I103BBBBDEFFXXXXN}{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:BBBBDEFFXXX
: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?to=pacs.008&srVersion=$sr" \
    -H "Authorization: Bearer $TRANSMUTE_KEY" \
    -H "Content-Type: text/plain" \
    --data-binary @mt103.txt | jq -r '.result' | grep -oE '<Cdtr>.*</Cdtr>'
done

Creditor under SR2025:

<Cdtr><Nm>ERIKA EXAMPLE</Nm><PstlAdr><AdrLine>RINGSTRASSE 5</AdrLine><AdrLine>AT-1010 WIEN</AdrLine></PstlAdr></Cdtr>

Creditor under SR2026:

<Cdtr><Nm>ERIKA EXAMPLE</Nm><PstlAdr><StrtNm>RINGSTRASSE</StrtNm><BldgNb>5</BldgNb><PstCd>1010</PstCd><TwnNm>WIEN</TwnNm><Ctry>AT</Ctry></PstlAdr></Cdtr>

Converting the SR2026 pacs.008 back to MT103 under SR2026 gives option F lines in each country's order:

:50F:/DE89370400440532013000
1/MAX EXAMPLE
2/HAUPTSTRASSE 12
3/DE/10115 BERLIN
...
:59F:/DE89370400440532013000
1/ERIKA EXAMPLE
2/RINGSTRASSE 5
3/AT/1010 WIEN

CBPR+ address rules

Validation follows the release too. With level=cbpr and srVersion=SR2026, two rules check every party and agent postal address on pacs.008, pacs.009, pacs.004, camt.056 and camt.057:

Under SR2025 neither rule runs. Validating the SR2025 pacs.008 from the example above passes under srVersion=SR2025 and returns two cbpr.address_structure_required findings (creditor TwnNm and Ctry) under srVersion=SR2026.

How the default release is chosen

When a request names no srVersion, the release comes from the request's API version, a date you can pin with the X-Api-Version header or on your API key. In full, the first rule that applies wins:

1. an explicit srVersion (envelope option, then query parameter, then header);
2. the default release of the resolved API version (X-Api-Version header, then the key's pin, then the current version);
3. the service default, SR2025.

A change of default release only ever ships as a new API version date. If you pin 2026-06-01 (or send srVersion: SR2025), you stay on SR2025 when the current version moves. If you pin nothing, you move with it. See API Versioning for the header, key pins and the closed date list.

Batch jobs and the connector

• Batch. Each item can carry its own options.srVersion. An item without one is stored with the release its request resolved to when the job was accepted, so a queued job keeps that release even if the current API version moves while it waits.
• On-premise connector. A watch's options.srVersion pins its release. An unknown value stops the connector at startup instead of falling back. A watch without one uses the service default, SR2025.

Before 14 November 2026

1. Run your messages through srVersion=SR2026 on a test key and compare the output.
2. If you read MX postal addresses, read StrtNm, BldgNb, PstCd, TwnNm and Ctry as well as AdrLine.
3. If you read MT option F parties, expect 2/ and 3/ lines built from structured addresses.
4. Decide whether to pin (X-Api-Version: 2026-06-01 or srVersion: SR2025) or to move with the default.

The step-by-step version of this list is in SR2025 to SR2026.

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