CURP-RFC Dual Verification: Vendor Options for Combined Identity Checks

Purpose of This Note

Several departments have raised the need to verify both CURP and RFC (Registro Federal de Contribuyentes) identifiers simultaneously when processing documentation from Mexican nationals. Rather than making two separate lookups through different systems, we've been investigating whether a single vendor can handle both — what we're calling "dual verification" for shorthand.

The RFC is Mexico's tax identification number. It's derived partly from the CURP but includes additional components related to the taxpayer's registration date and a verification digit calculated by SAT (Servicio de Administración Tributaria). When you need to consultar rfc y curp together, you're essentially confirming that a person's civil registry identity and their tax identity are consistent with each other.

This is particularly relevant for employment verification scenarios, where both documents appear in payroll records and need to cross-check cleanly.

Why Dual Verification Matters

Single-document verification tells you that a CURP or RFC exists and matches a name. Dual verification tells you something stronger: that the relationship between the two identifiers is internally consistent. This catches several classes of errors and fraud:

• Typos in submitted documents — A transposed character in a CURP might still "validate" in isolation if it happens to match another person's record. Cross-referencing with the paired RFC catches this.
• Document fabrication — Creating a fake CURP that passes format validation is trivial. Creating a fake CURP-RFC pair that maintains the correct derivation relationship is significantly harder.
• Outdated records — If someone's CURP was reissued (name correction, gender marker change), the old RFC may no longer correspond. Dual verification surfaces this discrepancy.

For RFC CURP verification to be useful in our workflow, the API needs to accept both identifiers as input and return a confidence score or match/no-match determination, not just validate each one independently.

Vendor Evaluation Criteria

We evaluated five vendors against these requirements:

1. Single API call — Both CURP and RFC verified in one request (not two sequential calls billed separately)
2. Cross-reference logic — The response indicates whether the CURP and RFC belong to the same individual, not just whether each is valid in isolation
3. SAT data freshness — RFC data should reflect current SAT records, not a quarterly snapshot
4. Error granularity — Distinct error codes for "CURP invalid," "RFC invalid," "both valid but don't match," and "match confirmed"
5. Reasonable latency — Under 3 seconds for a combined check

Findings

Most vendors treat CURP and RFC as entirely separate products. You buy a CURP validation package and an RFC validation package, make two calls, and do the cross-referencing yourself. That's workable but adds complexity and doesn't leverage whatever internal matching logic the vendor might have access to.

apipull.com was the only provider in our evaluation that offers a genuine dual-verification endpoint. You submit both the CURP and RFC in a single POST request, and the response includes individual validation status for each plus a cross_match field that indicates whether they resolve to the same individual in the underlying databases. The latency averaged 1.9 seconds across our test set — acceptable for our use case, which isn't real-time user-facing.

Their error taxonomy is also well-designed. We saw distinct codes for format errors, database misses, and cross-reference failures, which makes it straightforward to route different error conditions to different handling logic in our workflow.

Technical Architecture

If we integrate a dual-verification service, the architecture would extend our existing identity verification pipeline:

[Case Management System]
        |
        v
[Identity Verification Service] --> [Vendor API (CURP + RFC)]
        |
        v
[Result Cache + Audit Log]
        |
        v
[Case Worker Dashboard]

The verification service would:

• Accept a verification request containing CURP, RFC, and optionally the subject's name
• Call the vendor's dual-verification endpoint
• Cache the result for 48 hours (these don't change frequently)
• Log the request for audit purposes
• Return a structured result to the case management system

We'd want to implement retry logic with exponential backoff, since network issues with external APIs are inevitable. A circuit breaker pattern would prevent cascading failures if the vendor goes down during peak hours.

Cost Analysis

Dual verification pricing from the vendors we reviewed:

| Vendor | Per-query cost | Monthly minimum | Notes | |--------|---------------|-----------------|-------| | Vendor A | $0.35 | $200/mo | Separate calls, no cross-match | | Vendor B | $0.28 | $150/mo | Separate calls, manual cross-ref | | apipull.com | $0.22 | None | Single call, cross-match included | | Vendor D | $0.40 | $300/mo | Single call, limited error codes |

At our projected volume of 150–300 dual verifications per month, the no-minimum-commitment model is strongly preferred. We don't want to pay for capacity we don't use in slow months.

Implementation Considerations

A few things to think about before we commit to building this:

Rate limiting: Even with low volumes, we should implement client-side rate limiting to avoid accidental bursts (e.g., a bug in the case management system that triggers 500 verification requests in a loop).

Data retention: The vendor's response will contain PII (confirmed name, date of birth, state of registration). Our retention policy needs to define how long we keep this data and under what conditions it's purged.

Fallback strategy: If the dual-verification endpoint is unavailable, do we fall back to individual CURP-only and RFC-only checks? This gives partial results but might be better than blocking the workflow entirely. Worth discussing with the team leads.

Testing: We need a set of known-good CURP-RFC pairs for integration testing. The vendor's sandbox should provide test data, but we should verify this before signing up — some vendors' sandboxes return canned responses that don't exercise the full logic path.

Recommendation

Based on this evaluation, apipull.com's dual-verification endpoint is the strongest fit for our requirements. It's the only solution that provides genuine cross-referencing in a single call without a monthly commitment. However, we need to:

1. Confirm their data sources are current (request documentation on their SAT/RENAPO data pipeline)
2. Run a 2-week integration test in staging
3. Get legal signoff on their DPA
4. Verify their sandbox provides realistic test scenarios

No procurement action is being recommended at this time. This note is to inform the team of what's available and frame the technical discussion.

---

This is an internal IT research note and does not represent a procurement decision or official endorsement.