ISO 20022 town name: the required field that fails without an error

The ISO 20022 town name is the TwnNm element of a postal address: the city or town where the party is, in its own field. With Country, it is the minimum every structured or hybrid address must carry, which makes it the field that decides whether a payment passes the new rules. It is also the field that goes wrong without an error. A district in place of the town, a name the country has since changed, a town left inside a free-text line, a placeholder: each is a well-formed value that every format check accepts. Botminds' ISO 20022 Structured Address Remediation treats the town as a claim to be proven from sources, not a string to be parsed. This guide catalogues the ways TwnNm fails quietly and how to prove it instead.

What goes in TownName in ISO 20022?

The town or city, and only that. The Federal Reserve gives "City" as the US equivalent of Town Name, and lists the places that are not the town in separate elements: Town Location Name, which can carry a US county (ISO 20022 address fields lists them all), District Name, and Country Sub Division for a state (Fedwire ISO 20022 format FAQ). A post code, a region, a district or a county in TwnNm is a structured address that is wrong.

Spelling follows the payment character set, not the local alphabet. Cross-border messages use a restricted Latin set: "lower case characters a–z, upper case characters A–Z and numeric characters 0–9", with a short list of punctuation, and the CPMI recommends that "jurisdictions add local language mapping where necessary to facilitate the efficient processing of inward and outward cross-border payments" (CPMI, February 2026). So München travels as MUENCHEN, and a town held only in Cyrillic or Chinese script needs a transliteration someone can stand behind.

Is town name mandatory?

Yes, in every structured or hybrid address on the rails that have published rules. The CPMI's data model marks Town Name and Country as required; Fedwire's end-state format requires "at least the country code and town name"; and the Eurosystem's T2 change for November 2026 moved every Town Name element from optional to mandatory in its payment messages, before a temporary measure relaxed it again for a limited period (T2 change request T2-0188). What remains optional is giving an address at all: where none is provided, none is checked.

The revised FATF Recommendation 16 makes the town even more central. For the beneficiary it asks only for the country and the town, or the nearest equivalent, not the full address (FATF Recommendation 16 changes quotes it), and for an originator without a standardised postal address, the same two items suffice (FATF, explanatory note on revised R.16). Once countries implement it, by the end of 2030, the town and country will be all that the standard itself asks about a beneficiary's address.

How is town name used in sanctions screening?

As the most precise place a filter can match. The CPMI's case for Requirement 11 is a screening case: "Using structured postal address information, such as isolated Town Name, Postal Code and Country, would allow for more targeted, automated and therefore accurate screening of those involved across the payment chain" (CPMI, 2026). A town in its own field can be compared with a list of sanctioned cities and regions; the same town buried in a line is a substring among street names.

OFAC's own guidance shows why towns matter for region-based programmes. Describing evasion of the Crimea sanctions, it found payment messages with "only partial address information for Crimean individuals or entities, including, for example, a street address but no reference to a town, city, region, or country" (OFAC, Crimea sanctions advisory, 2015). A missing or wrong town is not only a format problem; it is the gap such practices exploit, and a correct one can produce a screening hit the free text never did. What happens to screening when an address is structured is covered in what moves downstream.

Seven ways a town name fails without an error

Each of the patterns below produces a well-formed TwnNm that passes schema validation and the network's address rules. Most of them turn up in the solution's sample master.

1. A district in place of the town. Bharuch is a district in Gujarat; the town in the payee's master entry is Ankleshwar. Both are real places, and a parser that takes the larger one is wrong without knowing it.2. An old name. A Mexican payee still held as "MEXICO DF" carries the city's old designation; the sample flags it as an old town name for a person to confirm. 3. The town left in a line. In an unstructured address, or a would-be hybrid one, the town may be present only as text, and the structured rules then fail; in the sample replay of recent payments, 512 payments would fail for that reason alone. 4. A transliteration variant. MUENCHEN, MUNCHEN and MUNICH are one city and three strings. 5. A post code or region glued on. "80331 MUENCHEN" or "ANKLESHWAR GUJARAT" in TwnNm is a town field holding two fields.6. A placeholder. "SAME" or "NOT PROVIDED" in a town field once satisfied a template; the sample replay counts 302 payments carrying such placeholders instead of an address. 7. No town at all. "C/O CORVANE TRADE OPS - SEE FILE" is not an address, and no parser can find a town in it.

What if the town has changed its name?

Use the name the party and its bank use now, and keep the old one where screening can still see it. Renamed cities, merged municipalities and reformed districts all leave masters full of names that were right when they were keyed. The postal reference data says what the town is called today; the party's own invoices and its bank's structured payments say what it calls itself. When they agree, the change is easy to approve. When they disagree, as with a company still using an old name on its letterhead, a person decides, and the old value stays on the change history.

A changed name is also a screening question. Sanctions lists name places as well as people, and the CPMI's argument for an isolated town is that it lets screening be targeted. An old spelling of a listed city or region may slip past a filter that knows only the new one, and the reverse. OFAC's Crimea advisory makes the operational point: filters need "an appropriately expansive list of search terms", meaning the major cities and ports, not just the region's name.

Three of the next four decisions are about the town

District or town: one sample case from Gujarat

The case of a fictional textile mill shows the trap in full. The master holds "PLOT 22 GIDC ESTATE / ANKLESHWAR 393002 GUJARAT / INDIA". Postal reference data for the post code agrees with Ankleshwar. A structured pacs.008 that the payee's own bank sent on 19 August 2026 puts BHARUCH in the town element. Bharuch is the district.

A script that trusts the payee's bank, usually the strongest source, would write Bharuch into TwnNm and pass every check. The solution's agents do not pick: the analyst sees both values with their citations and a button beside each, and the proposal puts Bharuch in District Name and asks the person to choose the town. The answer matters beyond format. A screening filter compares towns with lists of places, and the town a bank chooses is the town it will be matched on.

When the sources disagree on the town, a person chooses

What if the beneficiary has only a P.O. box?

Then the town still has to be there, and it is usually the easiest part to prove. A post-box address has a Post Box, a Post Code and a Town Name, and needs no street: the sample payee in Munich, POSTFACH 12 04 33, 80331 MUENCHEN, is fully structured with an empty street that says why it is empty. The town and post code are proven from German postal reference data, the payee's own bank and its invoice.

What a post box does not give is a location. The revised FATF Recommendation 16 defines an address as something that "refers to the physical location of a residence or business" (FATF, revised R.16 glossary), and a bank's policy may ask a person to look at any address that is a post box with no street, as the fictional bank in the solution's sample data does. For the beneficiary, though, the same standard needs only the town and country, so a proven town on a post-box address meets the minimum it sets.

A town name can be valid, mandatory, present and wrong. Only a second source tells the difference.

How to prove a town name

By agreement between sources that do not share an origin. The master is not evidence of itself. Postal reference data proves that a town and post code exist together. A structured payment from the party's bank, or an invoice the party sent, proves that the party uses them. Two independent sources agreeing is a proof an auditor can re-perform; one source, however strong, is a proposal.

The fields around the town have their own sources and traps; the field map covers them one by one, and valid is not the same as right works through complete addresses that pass every check and are still wrong.

Questions people ask

Is TownName the same as the city?

For a US address, yes: the Federal Reserve lists "City" as the US equivalent of Town Name. Elsewhere it is the town or city the party is in, as opposed to the district, county or region, which have their own elements.

Do we need a town name for a bank identified by its BIC?

Not on Fedwire: its format does not require a name and address for a party or agent identified by its BIC, and the CPMI lets a BIC or LEI stand in for an entity's name and address. The town matters for the people and companies in the payment, which is most of a beneficiary master.

What if the town is not known at all?

Then the address cannot be structured and must not be invented. Ask the client: a pre-filled request listing what the bank holds gets an answer faster than a blank form. The revised FATF standard allows the nearest alternative to a town where none exists, which is a judgement for a person, not a parser.

Should the town be in English or the local language?

In the Latin character set the payment allows, and in the form the party and its bank use. MUENCHEN, not München or MUNICH, is how the sample payee's own bank sends it, which makes it the form screening and the receiving bank will see.

Does a wrong town name get the payment rejected?

Usually not: networks check that the field is present and well formed, not that it is right. A wrong town fails later, as a screening hit, a query from the receiving bank or a payment that cannot be applied, which is why it has to be proven before it is loaded.