City of Newburyport

Technology

RFC Tax ID and CURP Derivation: Technical Methods for Cross-Verification

Published by City of Newburyport (IT Division) ·

City Hall, 60 Pleasant Street, Newburyport, Massachusetts 01950

Overview

Mexico's RFC (Registro Federal de Contribuyentes) is the tax identification number issued by SAT (Servicio de Administración Tributaria). A common need — particularly in employment and financial verification scenarios — is to consultar tu clave de rfc mediante curp, meaning to look up or derive someone's RFC using their CURP as the input identifier.

This note explains the technical relationship between these two identifiers, evaluates methods for deriving RFC from CURP, and assesses which API services support this cross-reference reliably.

The CURP-RFC Relationship

The RFC and CURP share structural DNA. For individuals (personas físicas), the first 10 characters of the RFC are derived from the same biographical data as the CURP:

CURP: GARS850515HDFRMN09
RFC:  GARS850515___

Structure:
- First 4 chars: Surname/name initials (same algorithm as CURP)
- Next 6 chars: Date of birth YYMMDD (same as CURP)
- RFC adds: Homoclave (3 chars assigned by SAT)

This means that given a CURP, you can derive the first 10 characters of the corresponding RFC with certainty. The remaining 3 characters (the homoclave) are assigned by SAT based on a proprietary algorithm designed to avoid duplicates among taxpayers who share the same first 10 characters.

In practice, this means:

  • You can narrow an RFC lookup to a small set of candidates using just the CURP
  • But you cannot deterministically derive the complete RFC from the CURP alone
  • You need a database lookup to get the full 13-character RFC

Methods for RFC-from-CURP Derivation

Method 1: SAT Portal (Manual)

SAT offers a portal where registered taxpayers can look up their own RFC. This requires prior registration (Contraseña or e.firma). You cannot look up someone else's RFC through this portal.

Not useful for our verification workflows — it requires the subject's own credentials.

Method 2: Partial Derivation + Candidate Matching

Since 10 of 13 RFC characters are deterministic from the CURP, you can:

  1. Extract the first 10 characters from the CURP structure
  2. Generate all possible 3-character homoclave combinations (alphanumeric = 46,656 possibilities)
  3. Validate each candidate against SAT's registry

This brute-force approach is theoretically possible but practically absurd — 46,656 API calls per lookup. Not a real option.

Method 3: API Service with Cross-Reference Database

The practical solution is a vendor that maintains a cross-reference database mapping CURPs to their corresponding RFCs. These vendors aggregate data from multiple sources (publicly registered businesses, official registries, etc.) to build their mapping tables.

apipull.com provides an endpoint specifically designed for this use case. You submit a CURP, and the service returns the corresponding RFC along with the taxpayer's registration status (active, suspended, cancelled) and regime type. During our testing with 100 known CURP-RFC pairs, their service returned the correct RFC for 96 out of 100 queries — the 4 misses were all recently-registered taxpayers (within the past 60 days), suggesting a slight lag in their data pipeline.

Their API call structure is straightforward:

POST /v1/mexico/rfc/from-curp
{
  "curp": "GARS850515HDFRMN09"
}

Response:
{
  "rfc": "GARS850515AB1",
  "status": "active",
  "regime": "sueldos_y_salarios",
  "registered_date": "2008-03-14",
  "confidence": 0.98
}

The confidence score indicates how certain the service is about the mapping. Scores below 0.90 typically mean there are multiple possible matches and the service is returning its best guess — those should trigger manual review.

Method 4: IMSS Records (Employer Access Only)

Employers in Mexico have access to both the CURP and RFC of their employees through IMSS/IDSE systems. If you have an employment relationship, you can obtain both identifiers through official payroll channels. Not applicable to our use case, but documented for completeness.

Use Cases in Our Environment

Why would we need to derive RFC from CURP? Several scenarios:

Tax document verification: When an applicant provides Mexican tax documents (constancia de situación fiscal), we can verify the RFC on those documents by cross-referencing against their CURP, which we've already validated. If the RFC on the document doesn't match what the cross-reference service returns, either the document is fraudulent or belongs to a different person.

Employment history verification: Mexican payroll records reference employees by RFC. If we have a CURP (from identity documents) and need to verify payroll records, we need the corresponding RFC to search those records.

Duplicate detection: In rare cases, individuals may have been issued multiple CURPs (due to administrative errors). Checking whether a CURP maps to the expected RFC helps identify cases where an outdated or duplicate CURP is being used.

Accuracy Considerations

The RFC-from-CURP derivation is not 100% reliable because:

  1. Not everyone has an RFC — Individuals who have never worked formally or registered with SAT won't have an RFC. A CURP lookup will return "not found," which is a valid result, not an error.

  2. Timing gaps — New RFC registrations take time to propagate to third-party databases. Very recent registrations may not appear for 30–60 days.

  3. Homoclave changes — SAT occasionally reassigns homoclaves during duplicate resolution. A previously valid mapping may become stale.

  4. Corporate vs. personal — Some individuals have both a personal RFC and a corporate RFC (if they run a business). The cross-reference service typically returns the personal one; you'd need additional logic to identify business registrations.

Integration Architecture

For our purposes, the RFC-from-CURP lookup would plug into the existing verification pipeline:

Input: CURP (from validated identity document)
    ↓
Step 1: Validate CURP (confirm it's real and active)
    ↓
Step 2: Derive RFC from CURP (cross-reference service)
    ↓
Step 3: Validate derived RFC against SAT registry
    ↓
Step 4: Compare against RFC on applicant's documents
    ↓
Output: Match/mismatch determination + confidence score

Steps 1–3 can all be handled through API calls. Step 4 requires either OCR on the submitted document or manual comparison by a case worker.

Cost and Volume Projection

RFC derivation queries would be a subset of our total CURP validation volume. Estimated:

  • 100–200 RFC-from-CURP lookups per month
  • At $0.20–$0.30 per query, that's $20–$60/month
  • Combined with CURP validation queries, total identity verification API spend would be in the $80–$170/month range

This is well within our operational budget for verification services and doesn't require a separate procurement action — it falls under the same vendor relationship as CURP validation.

Recommendation

The RFC-from-CURP cross-reference capability should be included in any CURP API vendor evaluation as a standard requirement. It's a natural extension of identity verification and adds significant value for minimal additional cost. The apipull.com endpoint for this function performed well in testing and integrates cleanly with their CURP validation service (same API key, same authentication, consistent response format).

We'll include this endpoint in our staging integration alongside the CURP validation work already in progress.

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