Skip to main content
All posts
KYCIdentity VerificationAddress StandardisationAddress Validation

Your KYC Is Rejecting Good Customers Over a Typo

Formatting differences like Apt 4B vs Unit 4B should not fail identity verification. Address standardization fixes KYC false rejections.

G
GoodVat Team
·2 min read

A customer signs up. They type “Flat 2, 14 Kensington Park Rd” into your form. Your KYC system pulls their credit bureau record, which says “Unit 2, 14 Kensington Park Road.” The string comparison fails. The customer gets bumped to manual review.

Same person. Same address. Different formatting. $5–15 wasted on a review that should never have happened.

This isn’t an edge case. KYC address mismatches caused by formatting differences are one of the most common reasons for false rejections. And every false rejection means delayed onboarding, frustrated customers, and compliance team hours burned on reviewing what’s obviously the same address — if only the system could see it.

The Real Cost of Format Mismatches

Manual KYC reviews cost $5–15 per case and delay onboarding by hours or days. In financial services, 68% of customers will abandon an onboarding process that takes too long. That’s not just lost revenue from one account — it’s lifetime customer value walking out the door.

And the compliance burden keeps growing. Global KYC compliance costs have surpassed $37 billion annually across financial institutions. A huge chunk of that spend goes to manual reviews triggered by formatting differences that a standardization layer would catch instantly.

“Apt 4B” and “Unit 4B” are the same thing. “St” and “Street” are the same thing. “W 42nd St” and “West 42nd Street” are the same thing. Your KYC system just can’t tell.

The Fix: Standardize Both Sides

The key insight is that you need to standardize both the submitted address and the reference address from the bureau or government source. Standardizing only one side still leaves format mismatches. Standardize both, and “Apt 4B” and “Unit 4B” converge to the same canonical form in expansions — making comparison reliable instead of brittle.

GoodVat’s Address Standardization API does exactly this. Run both addresses through the same endpoint, compare the structured output. One API call each, 10ms p99, 200+ countries, $5/mo unlimited.

Terminal window
curl -X POST "https://api.goodvat.com/v1/address/normalize" \
-H "Authorization: Bearer $GOODVAT_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "query": "Flat 2, 14 Kensington Park Rd, London W11 2EU" }'
{
"houseNumber": "14",
"road": "kensington park rd",
"unit": "flat 2",
"postcode": "w11 2eu",
"city": "london",
"country": "GBR",
"expansions": [
"flat 2 14 kensington park road london w11 2eu uk",
"flat 2 14 kensington park road london w11 2eu united kingdom"
]
}

Compare houseNumber, road, unit, postcode, or match on canonical expansions. No more string-matching gymnastics. No more false rejections over “Flat” vs “Unit” or “Rd” vs “Road.” Set confidence thresholds for auto-pass vs. manual review based on how many fields match.

Stop Losing Customers to Formatting

Every false rejection is a customer you failed to onboard and $5–15 you didn’t have to spend. Fix the comparison, not the customer.

Read the docs and start auto-passing the KYC checks that should have passed all along.