Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Verifying identity address details for a fintech signup
Opening an account at a digital bank involves a stack of identity checks, document verification, sanctions screening, proof of address, run in sequence because each one is a genuine cost in time and sometimes money, and it makes sense to run the cheapest, fastest checks first to filter out obviously broken applications before spending effort on the expensive ones.
Address plausibility turned out to be one of the cheapest and earliest checks a digital bank could run. Before an application moved on to document upload and identity verification, the address a new customer had typed into the signup form went through two quick checks. /v1/forward attempted to match the address and reported how confidently it resolved, catching cases where the street name did not exist, the address was incomplete, or the format did not correspond to any real location. /v1/postcode checked the entered postal code against the city and region also entered, catching the specific and common mistake of a postal code copied from a different location or simply mistyped.
Neither check on its own determines whether someone is who they claim to be, and the bank was explicit internally that this step did not replace the identity verification and know your customer process that followed. What it did was cheaply catch a category of application that would otherwise waste the time of the more expensive downstream steps: an address that could not possibly be real does not need to proceed to document review, and flagging it at the address step, in seconds, saved the cost of running a fuller verification against an application that was going to fail anyway.
Applications with a clean, well-formed address moved straight into the standard identity verification queue. Applications with an address that failed to resolve, or where the postal code and city clearly disagreed, were flagged either for a quick correction prompt back to the applicant or, if the pattern looked more deliberate than accidental, straight to manual fraud review rather than the standard queue.
The bank kept a clear internal boundary around what this step was for. Address plausibility is a data quality and early fraud signal, not a compliance control on its own, and it did not substitute for the actual proof of address documentation or the sanctions and identity checks a regulated financial institution has to run regardless of how clean an applicant's typed address looks. The value here was entirely in filtering and triage, moving the obviously broken applications out of the expensive part of the pipeline earlier, not in replacing any part of the actual compliance process.
Volume matched signup volume, one pair of checks per new application, a workload that stayed inside the free daily allowance for a digital bank at moderate signup volume, with prepaid credit as the natural next step during a growth period or a marketing push that drove a surge of new applications.
For a regulated business, the appeal of a check like this is less about catching fraud outright and more about not wasting expensive verification steps on applications that were never going anywhere. Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/postal-code-lookup/.