Structuring or verifying an address: which approach do you need?

Payment systems increasingly need usable address data, but much of what arrives wasn't captured with payments in mind: free text, inconsistent formats, no reliable way to tell one field from another.

A few months ago we reviewed addresses from a card network partner's platform: one long free-text string, no country code, building numbers buried inside street names. Before checking any of it, we asked a simpler question: what are the parts of this address?

"Address verification" gets used for several different problems. Two are worth separating: structuring an address so systems can read it, and verifying whether it holds together. Neither replaces the other: you may need one or both.

1. Structuring: turning free text into fields a machine can use

The first problem is mechanical: is the address broken into parts a system can reason about, or one string a person has to read?

ISO 20022 defines structured postal address fields (street, building number, postcode, town, subdivision, country) so systems can reason about each piece separately instead of pattern-matching a blob of text.

Take a messy free-text US address:

123 main st apt 4b springfield il 62701

IPID's Address Verification capability can structure that into fields such as:

{
 "response_code": 2000,
 "response_message": "Request Successful",
 "data": {
   "structured_address": {
     "country": "US",
     "country_subdivision": "IL",
     "city": "Springfield",
     "post_code": "62701",
     "street_name": "Main Street",
     "building_number": "123",
     "unstructured_line": "Apt 4B",
     "postal_address": "123 Main Street, Springfield, IL 62701, United States of America"
   }
 }


That's a clean structured address, with an unstructured_line field for overflow and a composed postal_address for display.

The case for this doesn't depend on a regulatory deadline: Swift notes standardised postal address data improves data quality, automated processing and screening, and that many ERP systems still hold addresses as free text. CBPR+ is also moving away from unstructured addresses, though the planned November 2026 change was postponed in August 2026.

A structured address is a starting point, not proof it's right. A street name associated with Singapore, paired with a country field of China and a city of Beijing, can be filled in correctly and still not hold together. That's not a structuring failure. It's a different problem.

2. Verification: does the address hold together?

Verification deals with addresses that are perfectly well structured but still incomplete or inconsistent: the Singapore/Beijing conflict above, a postcode that doesn't belong to its city, or a missing postcode, city or subdivision to enrich.

This matters more as address data is asked to do more. Revised FATF Recommendation 16 strengthens the originator/beneficiary location information expected in cross-border payments, with revisions due by the end of 2030, but having the data isn't the same as knowing it's complete or consistent.

Verification also has its own dependency: checking whether a postcode belongs with a city first requires knowing which part of the data is which. If the address already arrives in defined fields, that's not an issue. If it arrives as one ambiguous string, interpreting the components comes first.

IPID is extending Address Verification to cover that gap too: flagging conflicts like the one above and filling gaps in incomplete addresses, alongside the structuring capability already available today.

Structuring and verification aren't competing, or mandatory stages of one process: structuring suits inconsistent free text, verification suits data that's structured but unchecked. Some flows need both.

3. Which approach fits which problem?

The right starting point depends on the data you have.

The useful question isn't which approach is better. It's what problem you're solving with the data you have.

Regulation is the reminder, not the reason

For fintechs moving money across borders, this problem exists regardless of the regulatory calendar. Address data arrives from onboarding forms, card networks and partner integrations as free text, then sits inside systems that were never built to make much sense of it.

Waiting for a scheme deadline treats the symptom as the cause. The real problem is already there: can your systems actually use the address data flowing through them? That question exists today, independent of FATF's 2030 timeline or CBPR+. Screening, monitoring and automated processing all depend on data systems can interpret, not just data they happen to receive.

The practical next step isn't the regulatory calendar. It's looking at the address data entering your payment flow, finding where it breaks down, whether unreadable, incomplete or inconsistent, and deciding what needs to change now.