Adding CURP verification to our customer signup — worth the friction?

elena_product opened this thread · · 1 reply

curp-verificationcustomer-onboardinge-commerceinsurance

Question

E
elena_product Asker

Product manager here at an insurance startup. We're debating whether to add CURP customer verification to our policy purchase flow. Right now customers just fill in their info manually, and we get a lot of data quality issues — typos in names, wrong dates of birth, made-up addresses. This causes problems downstream when we need to process claims.

The idea is: ask for CURP during signup, validate it via API, and auto-fill the customer's verified legal name, DOB, gender, and state of birth. This would give us cleaner data and reduce fraudulent policy applications. But my concern is conversion impact — will asking for CURP scare customers away?

Some context on our business: we sell microinsurance products (device protection, health supplements, travel) with premiums between $50-500 MXN/month. Our customer base is primarily 25-45 year olds in urban areas. We currently get about 800 new signups per day with a 60% completion rate on the registration form.

What I'm evaluating for CURP customer verification:

  • UX impact — does asking for CURP reduce conversion? What do other companies report?
  • Reverse lookup — can customers verify without knowing their CURP by entering name + DOB instead?
  • Auto-fill experience — how much form data can we pre-populate from a CURP lookup?
  • Fraud reduction — what percentage of fake signups does CURP verification typically catch?
  • API reliability — can we make it a soft requirement (attempt verification but allow manual fallback)?

I've seen some e-commerce platforms in Mexico ask for CURP during checkout for invoice generation (facturación), so there's precedent for consumers providing it. But we'd be asking at signup, not purchase — different context and potentially different willingness.

From a technical standpoint, our frontend is React Native (mobile-first) and our backend is Go. We'd need a CURP API that responds fast enough to not feel laggy in the mobile signup flow. Anything above 2 seconds would feel broken to our users.

Really interested in hearing from product people and developers who've A/B tested CURP verification in consumer-facing flows. What was the conversion delta? Did you make it optional or mandatory? And how did you handle the case where someone genuinely doesn't remember their CURP?

Answers

I
insurtech_mx

We require CURP verification on every insurance policy and our conversion actually improved 8% after adding it. The trick is UX: user enters their CURP, you instantly validate it via API and auto-populate name, DOB, gender, state of birth. The user sees fewer form fields, not more. We frame it as "verify your identity to get your quote faster."

For users who don't know their CURP, we offer a reverse lookup — enter full name (with both surnames) plus date of birth plus state of birth, and the API returns matching CURPs. About 15% of our users use this fallback flow. The provider we use from apipull.com API Hub supports both forward and reverse lookups on the same endpoint.

Fraud-wise, we blocked about 3% of applications that were using invalid or non-existent CURPs. These would have become problematic claims later, so the ROI on the API cost is massive. Response time is around 250ms which feels instant on mobile.

● Thread open · 1 reply

Find API Providers on apipull.com