Fintech · lending

KYC that approves the good and stops the bad.

Your user takes three photos. You run identity, AML lists and address —checks that chain together on their own, straight from the official sources.

Request access → View documentation ›
real identityAML listszero retention
OrigoID symbol
How it works

Three photos from your user. Three waves of verification.

An onboarding that verifies identity and meets AML, without endless forms. Each wave uses the previous one's response; you fire the calls and OrigoID answers; the cross-checks between responses are an if in your backend.

OrigoID serviceYour code
Your user
Front of their INEFrom their phone.
Back of their INEFrom their phone.
A selfieThat's where their part ends.
+ Proof of addressIf your file requires it.
Wave 1 · in parallel
Reads the INE and hands back the address readyOCR of front and back with the address normalized and split into fields — most OCRs give it to you exactly as printed.OCR INE
Cross-checks the back against what's printedFrom the back we extract the document information and the holder's face: two independent reads that must match.INE QR
Compares the selfie with the IDThe selfie's face against the INE photo: score 0–100 and configurable threshold.Face Match
Reads the proof of addressUniversal OCR (CFE, water, phone…) to close the file with the current address.Proof of address
Wave 2 · with the OCR response
You cross the two responsesName, CURP and keys from the OCR against the back — an if in your backend.your code
Validates the CURP and generates the RFCThe extracted CURP is validated against RENAPO; the RFC comes out in the same call. See Validate CURPCURP validation
Confirms validity in the registryWith the ID's keys: it exists and is valid in the Lista Nominal.Lista Nominal
Searches for politically exposed personsWith the name and CURP from the OCR: active, former and by-affinity PEPs in Mexico.PEPs
Cross-checks international sanctionsThe full name against the OFAC sanctions lists (SDN and more).OFAC
Compares the face on the front and the backThe two photos you already received, one against the other: the same person on both sides.Face Match
Wave 3 · with the RFC
Checks SAT article 69Delinquent, unlocatable, sentenced — SAT's 14 sublists.SAT 69
Checks 69-B (EFOS)Shell invoicers: presumed, definitive and cleared.SAT 69-B
A value doesn't match?

The envelope tells you exactly what failed —FACE_MISMATCH, IMAGE_UNREADABLE, a CURP of a deceased person (CURP_DECEASED)— and you ask again for only that photo or that value. The legitimate user passes without friction; the one who doesn't, stops before costing you money.

Ability to pay

Identity solved. Next: can they pay?

The flow above confirms who the person is. To decide on a loan you need the other half: whether they have a job, how much their employer reports and how stable they have been. IMSS answers that, with the same CURP you already extracted from the ID.

◈
Employment verificationWhether the person works today, for which employer, their base salary and the contributed days of the period.See employment verification →
§
Contribution weeksThe official PDF certificate, the full job history and signals for tenure, stability and salary evolution.See contribution weeks →
#
NSS lookupThe person's Social Security Number, without asking for the card.See NSS lookup →

Not sure which one you need? Compare the three IMSS services →

Raw infrastructure · 100% REST API

The same contract for identity and AML.

Every service returns the same envelope: a single JSON structure, clean and predictable. You learn the contract once and it works for INE, facial, CURP, OFAC, PEPs and SAT.

One single envelopeSame status, type, data at every step of the KYC — your parser is just one.
Always-live dataWe query the official source on every call, no cache: the status is from this moment.
Zero retentionYou reduce your compliance surface under the LFPDPPP: we don't store your users' data.
View documentation ↗
valida-curp 
import { OrigoidApiClient } from "@origoid/sdk";

const client = new OrigoidApiClient({ apiKey: process.env.ORIGOID_API_KEY });

const result = await client.renapo.validateCurp({
  curp: "TEST900101HDFRRN09",
  generateRfc: true,
});
from origoid import OrigoID

client = OrigoID(api_key=os.environ["ORIGOID_API_KEY"])

result = client.renapo.validate_curp(
    curp="TEST900101HDFRRN09",
    generate_rfc=True,
)
import (
  sdkgo "github.com/origoid/sdk-go"
  "github.com/origoid/sdk-go/client"
  "github.com/origoid/sdk-go/option"
)

c := client.NewClient(option.WithAPIKey(os.Getenv("ORIGOID_API_KEY")))

result, err := c.Renapo.ValidateCurp(context.Background(), &sdkgo.ValidateCurpRequest{
  Curp:        "TEST900101HDFRRN09",
  GenerateRfc: sdkgo.Bool(true),
})
curl -X POST https://api.origoid.com/mex/renapo/v1/curp-validations \
  -H "x-api-key: $ORIGOID_API_KEY" \
  -H "content-type: application/json" \
  -d '{"curp": "TEST900101HDFRRN09", "generateRfc": true}'
Response with the case already named
{
  "status": "OK",
  "type": "SUCCESS",
  "data": {
    "personalInfo": { "givenNames": "JUAN", "rfc": "PELJ900101AB7", … },
    "documentDetails": { "curpStatus": "AN", … }
  },
  "billable": true
}
Why OrigoID for fintech

Less fraud at the door, less risk in your file.

A fintech lives on approving fast without letting in who it shouldn't. Verification has to be real, meet AML and not turn you into a custodian of data you don't want to keep.

⊘
Zero retentionYour users' data is validated and discarded. By not keeping it, you reduce your own compliance surface under the LFPDPPP.
◈
Always-live dataNo cache: the status of a CURP or a list is from this moment, not yesterday's copy. A person enters the 69-B list today and your query today knows it.
⬢
Active redundancyInfrastructure across multiple regions, all serving at once — and in all of them the same rule: zero retention. Your data doesn't reside on any server, in any country.
$
Published pricingDown to $0.28 per verification depending on your volume — no "contact us" to find out what it costs. See pricing
FAQ

What people usually ask us.

What do I need to do KYC at a fintech?

Your user takes three photos: the front and back of their INE, and a selfie (plus proof of address if your file requires it). With that you run the OCR with a normalized address, the back read, the face match, CURP-RFC against RENAPO, the Lista Nominal and the AML lists — each response feeds the next call.

Which AML lists are checked?

OFAC (sanctions), Mexico PEPs (active, former and by affinity), and SAT's: article 69 (delinquent, unlocatable, sentenced — 14 sublists) and 69-B (EFOS: presumed, definitive and cleared). Same envelope as everything else.

Do you store my users' data?

No. Every query is validated, answered and discarded, without storing the data.

How much does it cost?

You start free: courtesy credits, no card. Then the price drops with your volume — down to $0.28 per verification. All plans published, without talking to sales.

Start free, no card.

Try the full KYC flow in production with courtesy credits. Access is enabled after a brief validation of your company.

Request access