SWIFT Structured Addresses Explained: Why a Simple Karachi Address Has Become a Banking Data Problem

 

SWIFT structured, hybrid, and unstructured postal addresses explained with a Karachi example, showing how ISO 20022 turns free-text customer data into machine-readable payment information

I can write a Karachi address on an envelope without thinking much about it: House 24, Street 5, Block 13-D/2, Gulshan-e-Iqbal, Karachi, Pakistan. A courier understands it. A Pakistani bank employee probably understands it at first glance.

A payment-processing system sees something different. It sees words and numbers, but unless those pieces of information occupy defined fields, the system may not know which word identifies the city and which number identifies the house. That small distinction sits behind one of the less glamorous, but operationally important, changes accompanying ISO 20022.

Structured addresses are really about teaching payment systems what an address means.

A Karachi Address Makes the Problem Easy to See

Consider a Pakistani beneficiary receiving money from Germany:

Ahmed Khan
House 24, Street 5
Block 13-D/2, Gulshan-e-Iqbal
Karachi 75300
Pakistan

Nothing appears wrong. I can read it immediately and understand that Ahmed lives in Karachi, while 75300 is a postal code and Pakistan is the country.

A computer cannot safely make every one of those assumptions. "13-D/2" might represent a building, block or locality; "Gulshan-e-Iqbal" could appear in several different parts of a bank's customer database, and another system might record Karachi merely as "KHI."

Older payment formats tolerated much more of this ambiguity because banking systems often carried postal addresses as text. ISO 20022 approaches the problem differently by allowing individual parts of the address to carry their own semantic meaning.

That is the foundation of the structured-address concept.

What Is an Unstructured Address?

An unstructured address is basically free text.

Suppose a bank has the following customer information:

AHMED KHAN
H NO 24 ST 5 BLK 13D2
GULSHAN KHI PAK

A person working in Karachi can probably reconstruct that address within seconds. The problem begins when the same information moves through automated compliance engines, correspondent banks and payment-processing systems located thousands of kilometres away.

The machine has to infer what "KHI" means. It may have to recognise that "PAK" refers to Pakistan, while also determining whether "GULSHAN" is a district, street or another location component.

Free text therefore forces machines to interpret data rather than simply consume it.

Swift describes the migration away from fully unstructured addresses as part of the wider effort to improve the quality and usability of ISO 20022 payment data.

What Changes With a Structured Address?

Now take the same customer and separate the information.

Name: Ahmed Khan
Building Number: 24
Street Name: Street 5
Town Location: Gulshan-e-Iqbal
Post Code: 75300
Town Name: Karachi
Country: PK

The words have not changed much. Their meaning has.

Instead of leaving "Karachi" somewhere inside a free-text line, ISO 20022 can identify it specifically as:

<TwnNm>KARACHI</TwnNm>

Pakistan can appear as:

<Ctry>PK</Ctry>

The street can occupy:

<StrtNm>Street 5</StrtNm>

And the building number can appear as:

<BldgNb>24</BldgNb>

A fully structured postal address must contain Town Name and Country at minimum when an address is provided, while the AddressLine element cannot be used as part of that fully structured format. Swift's ISO 20022 guidance expressly identifies Town Name and Country as the minimum structured components.

This is where I think many explanations make the subject sound harder than it really is. Structured addressing does not mean that every possible address element must be filled.

A customer may not have a building name. Another address may lack a reliable postal code in the bank's database. The bank uses the structured fields that apply, subject to the relevant usage rules, while Town Name and Country provide the minimum structured location information.

Why Pakistani Addresses Complicate the Exercise

The concept becomes more interesting when I look at the addresses Pakistanis actually use.

Consider:

Flat 7-B, Al-Rehman Apartments, Block 2
Near Teen Talwar, Clifton
Karachi, Pakistan

"Karachi" fits neatly into Town Name. Pakistan becomes PK.

But where should "Near Teen Talwar" go?

A Karachi resident understands the landmark immediately. The phrase may be useful for locating the building, yet it does not naturally become a street name or building number.

DHA creates similar problems:

Plot 17-C, Khayaban-e-Seher
Phase VI, DHA
Karachi, Pakistan

"Phase VI" has genuine local meaning. So does DHA. Forcing either term into the wrong structured field simply to make the record look more organised can actually reduce data quality.

That is where the hybrid address becomes useful.

Hybrid Addresses Give Banks Some Flexibility

A hybrid address combines structured information with a limited amount of free text.

For our Clifton beneficiary, a simplified representation could look like this:

<TwnNm>KARACHI</TwnNm>
<Ctry>PK</Ctry>
<AdrLine>Flat 7-B, Al-Rehman Apartments, Block 2</AdrLine>
<AdrLine>Near Teen Talwar, Clifton</AdrLine>

Town Name and Country now have explicit meanings. Information that cannot be mapped cleanly can remain inside controlled AddressLine fields.

Under Swift's published requirements, a hybrid postal address must contain structured Town Name and Country. It can also contain up to two AddressLine elements, with each allowing up to 70 characters.

There is an important discipline here. A bank should not repeat structured information unnecessarily inside the free-text lines.

If KARACHI already appears as Town Name and PK appears as Country, putting "Karachi Pakistan" into an AddressLine as well defeats part of the purpose of restructuring the data.

Hybrid does not mean half-structured chaos. It means controlled flexibility.

Unstructured, Hybrid and Structured: One Example

The difference becomes clearer if I use the same Karachi address three ways.

1. Fully Unstructured

AHMED KHAN
H NO 24 ST 5 BLK 13D2
GULSHAN KHI PAK

The human must interpret it. The system may also need to infer several components.

2. Hybrid

Name: Ahmed Khan
Town Name: Karachi
Country: PK
Address Line 1: House 24, Street 5, Block 13-D/2
Address Line 2: Gulshan-e-Iqbal

The most important location data has become machine-readable, while locally specific information remains available.

3. Fully Structured

Name: Ahmed Khan
Building Number: 24
Street Name: Street 5
Town Location: Gulshan-e-Iqbal
Post Code: 75300
Town Name: Karachi
Country: PK

Now each usable component carries a defined meaning.

The progression is not merely:

messy address → neat address

It is closer to:

text → identified data

That difference matters throughout the payment chain.

Think About It Inside a pacs.008

Suppose someone in Munich sends EUR 5,000 to Ahmed Khan in Karachi.

The creditor information eventually appears in the ISO 20022 payment chain, commonly within a pacs.008 when financial institutions exchange a customer credit transfer.

An old customer record might contain:

AHMED KHAN
HNO24 ST5 GULSHAN KHI PAK

The payment itself can still contain enough information for a human operator to understand the beneficiary's location. Yet every intermediary that needs to screen or process that payment now depends partly on interpreting text.

A structured record changes the position.

The system knows that:

<TwnNm>KARACHI</TwnNm>

means the town.

It knows:

<Ctry>PK</Ctry>

means Pakistan.

"PK" is not an abbreviation somebody chose at an account-opening desk. It is the ISO two-letter country code.

The economic transaction remains exactly the same. The quality of the information describing the transaction improves.

Does Every Bank in the Payment Chain Need a Postal Address?

No.

This point caused understandable confusion when we discussed structured addresses earlier.

Suppose the Creditor Agent is identified through its BIC. The ISO 20022 message does not suddenly require a full postal address for that bank merely because structured postal addresses are becoming the standard.

Swift specifically states that if the beneficiary bank is identified using a BIC, no bank postal address is required for this purpose.

That distinction matters in operational training.

"Postal addresses must be structured" does not mean:

"Every institution appearing in a pacs.008 must have street, city and country populated."

The actual rule depends on whether postal address information is required and supplied, as well as how the party or agent is identified.

Then Swift Changed the November 2026 Timeline

Until 27 August 2026, banks had been working toward a major November deadline.

Swift's published implementation material stated that fully unstructured postal addresses would no longer be accepted for relevant CBPR+ payment messages after the November 2026 migration point. Earlier guidance specifically pointed to 14 November 2026, with Town Name and Country required in designated fields when postal addresses were included.

Then Swift changed course.

On 27 August 2026, Swift announced that industry readiness remained uneven and that several communities had formally asked for additional time. Swift accepted that request and announced what it calls a controlled extension of Standards Release 2026 payment changes.

For structured addresses specifically, Swift said it will consult banks, central banks, payment market infrastructures and other industry groups to determine the revised timing and implementation approach. It expects to provide an update by December 2026 at the latest.

So, as I write this from Karachi on 29 August 2026, I would no longer describe 14 November 2026 as the active final enforcement deadline for this requirement.

The deadline moved.

The direction did not.

Banks Should Not Read the Extension as a Reversal

The extension matters operationally because some banks clearly need more preparation time.

Yet nothing in Swift's announcement suggests that structured addresses have been abandoned. In fact, Swift continues to describe rich structured data as fundamental to greater payment automation and more effective compliance processes.

For Pakistani banks, that means the extra time should probably be understood as migration space rather than an invitation to preserve free-text address practices indefinitely.

The real problem is not the XML.

It sits inside customer data.

The Hard Work Is Inside the Customer Database

I can imagine what the migration looks like when it leaves a PowerPoint presentation and enters a Pakistani bank's systems.

One record says:

DHA PH 5 KHI

Another says:

FLAT 7 BLK 14 FB AREA KARACHI

A third may contain:

OPP NIPA CHOWRANGI GULSHAN PAK

All three may be perfectly understandable to local staff. None necessarily provides cleanly separated address components.

A bank cannot solve that problem by simply wrapping old text inside new XML tags.

Suppose a system incorrectly treats "Sindh" as Town Name and Karachi as a district. The resulting message may look beautifully structured, yet its semantic content is wrong.

I find that risk more interesting than the formatting rule itself.

Free text admits that it is free text.

A structured field claims to know what the information means.

Account Opening Now Becomes Part of the Payment Problem

Structured addresses therefore reach far beyond the SWIFT department.

If the source customer database does not separately capture Town Name and Country, downstream payment systems must derive them somehow. Every derivation creates another opportunity for incorrect mapping.

Banks may eventually need cleaner capture at account opening and KYC refresh. Corporate customers may also need to change ERP payment files if those files still provide beneficiary details as broad address lines rather than identifiable components.

Swift's corporate guidance already tells firms to assess existing payment initiation formats and ensure that at least Town Name and the ISO two-letter Country Code can be supplied in structured form.

The message transformation therefore begins before pacs.008 is created.

That is easy to overlook from a SWIFT workstation.

Why Structured Addresses Matter Beyond Compliance

When I first examined this issue, it looked like another ISO 20022 formatting requirement.

The more closely I looked, the more it seemed to represent something larger.

Older financial messaging often focused on transporting information. ISO 20022 increasingly tries to transport the meaning of that information.

"Karachi Pakistan" inside a free-text line tells a person something.

<TwnNm>KARACHI</TwnNm>
<Ctry>PK</Ctry>

tells a machine what those words represent.

That distinction can improve validation and screening. It can also reduce manual repair when information moves between institutions whose staff do not share the sender's knowledge of local address conventions.

A compliance engine should not need to know that "KHI" means Karachi because somebody in Pakistan has always written it that way.

Karachi Is a Good Test of the ISO 20022 Idea

Pakistani addresses expose both the strength and the weakness of structured data.

Our addresses contain blocks, phases and schemes. Landmarks remain common. Some locations fit neatly into international postal concepts; others resist them.

ISO 20022 cannot eliminate that local complexity.

Hybrid addressing acknowledges it.

The system does not need to understand every cultural habit built into a Karachi address. But it can insist on knowing, with much greater certainty, where the town is and which country the customer belongs to.

That sounds like a small improvement.

Inside a global payment network carrying transactions between thousands of institutions, it is not small at all.

Swift has now given the industry additional time to make the change. Somewhere inside a Pakistani bank, however, there will still be a customer record that reads "H No 24, Gulshan, KHI, Pak."

A banker knows exactly what it means.

The harder task is teaching the payment system to know as well.