By Barley Laing, the UK Managing Director at Melissa
Many data teams ask the same question - if a large language model (LLM) can write code, summarise contracts and hold a conversation, why can't they validate an address?
While this seems like a reasonable assumption, in practice address verification is one of the few tasks where an LLM's biggest strength, generating a plausible sounding answer, becomes its biggest liability.
Parsing and verifying are different things
Where LLMs excel is in cleaning up messy address input. They can reformat a free-text field, fix an obvious typo, or translate a structured address across languages. So if you ask a model to normalise “123 Main St, Apt 4B” into a standard format it will usually correctly do so.
However, accurately formatting an address and confirming that it actually exists are two distinct things. A model trained on text patterns learns what addresses typically look like, not whether specific street numbers, postal codes and unit combinations are real, current and deliverable. And when a model lacks sufficient information it may generate a plausible looking answer rather than reliably signalling that the address cannot be verified.
Why confidence doesn’t equal accuracy
Hallucinations occur across every domain where LLM models are asked to confirm facts against a real-world registry. In fact, NIST identifies “confabulation” as a recognised risk in generative AI, describing situations in which systems confidently generate erroneous or false information. Because LLMs produce outputs by predicting statistically plausible sequences rather than checking every answer against an authoritative real-world registry, factual verification remains important in applications requiring exact matches.
The more specific and structured the reference data, the more likely a language model is to make a guess rather than acknowledge uncertainty.
Address data is about as structured and specific as it gets, so a merged street name or a single incorrect digit in a postal code can send a shipment to the wrong warehouse, or fail to deliver a piece of mail that a customer was expecting. Unfortunately, these inaccuracies don’t show up as errors to the model generating the response, but downstream, in your logistics costs or customer support queue.
Postal systems evolve leading to stale data
Stale data is a huge issue as postal systems change constantly. Royal Mail says its Postcode Address File (PAF) receives up to 5,000 updates and changes every day, illustrating how frequently authoritative address records can evolve. A standalone LLM that relies primarily on its training data may not have access to the latest changes in postal records. Even recently trained models cannot be assumed to contain the same current, authoritative address information as continuously maintained postal or address databases.
Therefore, without access to a current authoritative data source, the AI model may have no reliable way of distinguishing an outdated address from a valid one.
The hidden cost of sending addresses to third-party models
As a postal address provides the physical location of an individual, address information can also raise data protection considerations. Organisations sending customer address data to a third-party AI service should therefore assess how that provider processes the information, including relevant contractual safeguards, security controls, retention arrangements, and whether its processing arrangements meet applicable data protection obligations, including GDPR, where relevant.
Where LLMs fit in the workflow
Language models still have an important part to play in the address verification pipeline. They’re excellent at the parts of the problem that involve language rather than address lookup. This means cleaning up optical character recognition (OCR) output, standardising formats across countries, handling multilingual input, and interpreting free-text form fields before checking anything against a source of truth.
The best process requires a division of labour. The LLM model handles the language work, and a verified address reference database handles the confirmation.
When an address needs to be checked against reality, the query must go to a system built on curated postal records, not to a model generating its best guess. A purpose built address verification system can return a verified match, flag ambiguity or indicate that the address cannot be confidently verified, reducing the risk of a plausible but fabricated address moving downstream.
The bottom line
Language models are strong at correcting language, but address verification is not a language problem; it’s a lookup problem. The two should not be confused simply because both can be automated. Teams that only use an LLM as a shortcut to deliver verified address data are trading a predictable licensing cost for an unpredictable one and risk an increase in returned shipments along with delivering customer records that appear clean until someone tries to use them.
The best approach plays on the strengths of both tools. Therefore, let the LLM model handle formatting and language, while ensuring a verified, regularly updated database is on hand to answer the only question that matters - does this address exist?