Address Standardization for Fraud & Risk Scoring

Fraud rings often reuse or slightly vary a small set of physical addresses across many accounts to evade detection. If your matching logic only catches exact string duplicates, small formatting differences let them slip through.

The problem

"12 Main St Apt 3" and "12 Main Street, Unit 3" are the same address, but naive string comparison sees two different accounts. Risk teams either miss the link or have to maintain brittle, manual fuzzy-matching rules.

How address standardisation helps

Standardising every submitted address into structured components and canonical expansions ensures that intentional superficial formatting differences ("St" vs "Street", "Ste" vs "Suite", differing case or punctuation) converge on the exact same canonical strings — making hash-based multi-account fraud clustering reliable and immediate.

Example

POST /v1/address/normalize

curl -X POST "https://api.goodvat.com/v1/address/normalize" \
  -H "Authorization: Bearer $GOODVAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "12 Main Street, Unit 3, Springfield IL 62701" }'

200 OK

{
  "houseNumber": "12",
  "road": "main street",
  "unit": "unit 3",
  "postcode": "62701",
  "city": "springfield",
  "state": "il",
  "country": "USA",
  "expansions": [
    "12 main street unit 3 springfield il 62701 usa",
    "12 main street unit 3 springfield illinois 62701 usa"
  ]
}

Key response fields

Field	Why it matters here
expansions	Standardized canonical strings that defeat evasion attempts based on abbreviation or formatting tricks.
houseNumber / road / unit	Core structural key for linking accounts to the same physical address.
postcode	Cheap secondary signal for narrowing candidate matches before full identity graph analysis.
country	Prevents accidental collisions between similarly-formatted addresses in different countries.