ISO 20022 structured addresses: rules and timetables

Each payment rail sets its own timetable. SIX still publishes 14 November 2026 for Swiss payment orders when an address is used. The EPC and Swift have postponed their deadlines. This page separates those dates from the address rules checked by the API.

Checked on 10 September 2026. The EPC decision of 9 September maintains unstructured addresses beyond 15 November 2026 under all five payment schemes; the new end date is to be set in October. Swift’s announcement of 27 August defers the payments changes without a replacement address date, with an update by December at the latest. SIX still publishes its separate Swiss timetable.

The published deadlines

These postponements do not themselves amend the Swiss rules. They do not change the fields checked by /v1/address/check either: a result describes conformity with the named document, not whether a bank must apply that rule on a given date. T2, Fedwire and CHAPS have their own timetables; see the dated source record in Which date is the date?.

The older 22 November 2026 date did appear in EPC guidance. It was replaced by 15 November 2026 in version 2.1, and that later deadline was postponed in September 2026. It is not a current deadline. The 22 November 2025 Swiss QR-bill change is a separate event.

For a whole Swiss QR-bill, POST /v1/ch/qr-bill/check checks the payload, including structured (S) or combined (K) addresses.

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

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.

The market-practice paper trail

The PMPG (Payments Market Practice Group, the independent body supporting ISO 20022 adoption) publishes a monthly Payment Insights newsletter whose August 2026 issue is squarely about this deadline — and, unlike the CBPR+ usage guidelines, it permits reproduction provided the source is acknowledged, so we can quote it. Three things in it are worth your attention: it described the then-planned November 2026 removal, a timetable superseded by the Swift and EPC postponements above; it names the hybrid postal address — the same format: "hybrid" this API serves — as the PMPG-endorsed shape for addresses that cannot be fully structured; and its gap-impact table ranks "one-off payment with incomplete creditor address data" as Limited impact, against High for missing country codes across high-volume files. Source: PMPG, Payment Insights, August 2026.