ISO 20022 structured addresses — what actually changes in November 2026

Three payment rails stop accepting a fully unstructured postal address in November 2026. This page states what each of them requires, quoting the document it comes from, and then shows the two things this API does about it.

It also states, plainly, what this API does not do about it. That part matters more than the rest, because the deadline is mostly a problem this API cannot help with, and a page that blurred the line would cost you a rejected payment file in November.

The deadline, rail by rail

Date	What happens	Source
14 November 2026	Swiss Payment Standards 2026 come into force — Business Rules v3.3, Implementation Guidelines Credit Transfer v2.3, QR-bill v2.4	SIX
16 November 2026	Fedwire Funds Service production release; cutover 14–15 November	Federal Reserve Financial Services
20 November 2026	Last SIC release that still processes payment orders carrying an unstructured address	SIX
R2026.NOV	T2 / RTGS release in production in November 2026	European Central Bank

Two things about that table.

It has no CBPR+ row, and that is deliberate. The CBPR+ usage guideline and the PMPG November 2026 postal address guidance — the document the Federal Reserve names as its own upstream reference — are both published on swift.com. Everything on this page comes from a document that was fetched and read; nothing on it comes from a document that was not. So we do not print a CBPR+ date, and the conformity checker below has no cbpr+ scheme.

Beware of one date that looks right and is not. 22 November is a real deadline — of 2025: it is when SPS 2025 came into force and when MT/MX coexistence ended. It is not a 2026 date, and a migration plan that carries it forward by a year is planning against nothing.

What the rules ask of an agent address: a town and a country

The single most useful fact about these rules, for anyone building payment software, is how little they demand of a financial institution address.

The Swiss field table for a Creditor Agent's PostalAddress offers exactly three elements: TwnNm (Must be used), Ctry (Must be used) and AdrLine (max 2). StrtNm, BldgNb and PstCd appear in that guideline only under Creditor and Ultimate Debtor — never under an agent. The Federal Reserve says the same in prose for its own rail: "require town name and country".

So: an agent address is a name, a town and a country. Not a street.

And it is often not required at all

Two of the three corpora make the agent address conditional on the BIC being absent.

Switzerland lists the ways a Creditor Agent may be identified, and a full address is one option among several — the BIC being another, and the recommended one for cross-border payments.

T2 / HVPS+ states the same mechanic as a validation rule: if BICFI is absent, then Name and PostalAddress must be present. It applies to DbtrAgt, CdtrAgt, the intermediary agents and the previous instructing agents.

The Federal Reserve does not state that trigger. Its page confirms the change reaches agents — "for all parties and agents across all message types" — which is compatible with the conditional mechanic but is not an attestation of it. Two rails state it; one does not; this page does not say that all three agree.

The reversal — and it is the real point of this page

Read the Swiss business rules once more: "depending on the payment type, it remains also possible to replace the address with another element like the BIC."

That sentence turns the whole problem around. If you hold a clearing code and no BIC, you are in the branch of the rule that demands a name and a full address. If you hold the BIC, that obligation does not apply to you at all.

Which means the useful question in November 2026 is often not "how do I structure this agent's address?" but "how do I get this agent's BIC so I never have to?" — and resolving a national clearing code into a BIC is what this API has always done:

Swiss IID / BC-Nummer → GET /v1/ch/clearing/:iid
German Bankleitzahl → bank_code_check on a validated IBAN
Austrian bank code → same block
Any IBAN → POST /v1/iban/validate resolves the BIC

No new code, no new endpoint, no new subscription. If the BIC resolves, the address requirement on that agent goes away.

`postal_address` — the seat in ISO 20022 vocabulary

Every answer that already carries an institution address now also carries it as an ISO 20022 PostalAddress, in the tag names of the standard, so you can map it into a pain.001 or a pacs.008 without a translation table.

It is additive. The existing address block is untouched and remains the full, untruncated record.

A Swiss institution: `structured`

curl https://api.ibanforge.com/v1/bic/POFICHBE

{
  "postal_address": {
    "strt_nm": "Mingerstrasse",
    "bldg_nb": "20",
    "pst_cd": "3030",
    "twn_nm": "Bern",
    "ctry": "CH",
    "format": "structured",
    "source": "SIX BankMaster (Swiss IID register)",
    "as_of": "2026-08-03"
  }
}

StrtNm and BldgNb are filled here because the SIX BankMaster register publishes them as two separate columns. It is the only source in this database that does.

A GLEIF-sourced institution: `hybrid`

curl https://api.ibanforge.com/v1/bic/BUKBGB22

{
  "postal_address": {
    "pst_cd": "E14 5HP",
    "twn_nm": "LONDON",
    "ctry": "GB",
    "adr_line": ["1 CHURCHILL PLACE"],
    "format": "hybrid",
    "source": "GLEIF",
    "as_of": "2026-04-13"
  }
}

No strt_nm — and this is the design decision to understand before you consume the field.

GLEIF publishes an address as a list of lines that we store joined into one string. House number, floor, building name and district can all be in there together. Splitting that into StrtNm and BldgNb would be a guess, and a guess is exactly what a payment rail bounces. So the line goes out as AdrLine, which is the hybrid format the rules explicitly allow, and format tells you which of the two you got.

Read an absent strt_nm as "the source published one concatenated line", never as "this institution has no street".

A town and a country alone: complete, not degraded

{
  "postal_address": {
    "twn_nm": "ZURICH",
    "ctry": "CH",
    "format": "structured",
    "source": "Redistributed SWIFT BIC directory (PeterNotenboom/SwiftCodes, MIT)",
    "as_of": null
  }
}

This is the shape most of the directory takes, and — per the section above — it is exactly what the rules ask of an agent address. A town and a country is not a partial answer here. It is the answer.

Measured over the shipped database on 26 August 2026: 99.3% of directory rows carry a city, while only about 30% carry any street at all. Re-measure before quoting it — the database is refreshed monthly and the figure drifts.

Two provenance rules that will not change

source names the dataset the address came from, and it can legitimately differ from address.source: a Swiss institution is served from the SIX register while the legacy block stays GLEIF. When the two registers disagree — both may publish a real, different seat for the same institution — you can see both and decide.

as_of is the date the source last stated the address. It is null when the dataset publishes none. It is never the date our database was refreshed, and it is never a clock read: an address stamped today from a file filed last year would be a false statement about the register.

The same block appears on the bic object of POST /v1/iban/validate, built by the same code, so the two endpoints cannot disagree about the same row.

`POST /v1/address/check` — free conformity check

The other half. You have structured an address; this tells you whether it satisfies a given rail's rules, rule by rule, with the document each rule comes from.

It reads no database of ours. That is why it is free.

curl -X POST https://api.ibanforge.com/v1/address/check \
  -H "Content-Type: application/json" \
  -d '{
    "scheme": "sps",
    "address": {
      "twn_nm": "Zurich",
      "ctry": "ch",
      "pst_cd": "8001",
      "adr_tp": "ADDR",
      "adr_line": ["Bahnhofstrasse 45", "8001 Zurich"]
    }
  }'

{
  "scheme": "sps",
  "conforms": false,
  "findings": [
    { "rule": "twn_nm_required", "verdict": "pass", "detail": "TwnNm is present (\"Zurich\")." },
    { "rule": "ctry_required", "verdict": "pass", "detail": "Ctry is present (\"ch\")." },
    { "rule": "ctry_iso3166", "verdict": "fail", "detail": "Ctry \"ch\" is not two uppercase letters." },
    { "rule": "adr_tp_forbidden", "verdict": "fail", "detail": "AdrTp \"ADDR\" was supplied. SPS marks Address Type \"N — Must not be sent\"." },
    { "rule": "adr_line_max_2", "verdict": "pass", "detail": "2 AdrLine supplied, within the maximum of 2." },
    { "rule": "adr_line_max_length_70", "verdict": "pass", "detail": "Every AdrLine is at most 70 characters." },
    { "rule": "adr_line_no_repeat", "verdict": "fail", "detail": "\"8001 Zurich\" repeats PstCd + TwnNm. SPS: \"Data already provided in another element must not be repeated.\"" }
  ]
}

Each finding also carries a source field, elided above for width — it names the document and its date, so you can forward the verdict to whoever produced the address.

The rules, and which rail each one belongs to

Rule	sps	hvps_plus	fedwire
`twn_nm_required` — unconditional	yes	—	yes
`ctry_required` — unconditional	yes	—	yes
`twn_nm_ctry_required_if_no_adr_line` — conditional	—	yes	—
`ctry_iso3166` — two uppercase letters, assigned	yes	yes	yes
`adr_tp_forbidden` — Address Type "Must not be sent"	yes	—	—
`adr_line_max_2`	yes	—	yes
`adr_line_max_length_70`	yes	—	yes
`adr_line_no_repeat`	yes	—	—

A dash means the fetched document for that rail states nothing on the subject. It does not mean the rule is inverted, and we do not import a neighbouring rail's rule to fill the gap — silence is reported as silence.

verdict has three values, not two. not_applicable marks a rule whose precondition is not met — an AdrLine rule on an address with no AdrLine. It is a real answer, not a polite pass, and conforms ignores it.

Why there is a `scheme` parameter and no "compliant" boolean

Because the three rails genuinely disagree, and a single boolean would have to pick one and hide it:

TwnNm + Ctry are unconditional for SPS and Fedwire, and conditional for T2 / HVPS+ — required only when AddressLine is absent.
AdrLine is capped at 2 by SPS and Fedwire, capped at nothing in the T2 validation appendix, and allowed up to 7 in base ISO 20022.
AdrTp is forbidden by SPS and unmentioned by the other two.

And cbpr+ is not one of the schemes, on purpose. Its rules could not be read from any public source. Sending "scheme": "cbpr+" returns a 400 that says so rather than a verdict we would have had to invent.

What this does not do

Three limits, stated here so nobody discovers them in November.

It does not solve a customer-address migration. The bulk of the November 2026 change falls on the addresses of the parties to a payment — Dbtr, Cdtr, UltmtDbtr, UltmtCdtr. That is your own customer address book, and this API holds no data about it and makes no claim about it. If someone tells you an IBAN and BIC API will settle that migration for you, they are selling you something they do not have.

It does not parse a free-text address into a structured one. Turning "ul. Sokolska 34, 40-086 Katowice" into StrtNm / BldgNb / PstCd / TwnNm requires national postal reference data across some 250 countries. That is the trade of Loqate, Smarty and Google's Address Validation API. We hold none of it, and a checksum-free guess at a street name is worse than no answer.

It does not certify CBPR+ conformity. No public source lets anyone do that honestly today. The checker names the rail it is judging against, and every finding names its document.

What is left after those three subtractions is small, and it is real: the ISO 20022 form of an institution seat we already hold, a rule check you can run for free, and — the part worth the most — the reminder that resolving a clearing code into a BIC often removes the address obligation altogether.