Compliance

SAT Article 69-B Check (EFOS)

Credits: 1 per call.

Validates if an individual or legal entity is listed in the Mexican Tax Authority (SAT) Article 69-B blacklist. This list is specifically for EFOS (Empresas que Facturan Operaciones Simuladas), commonly known as ‘Factureros’ or shell companies involved in tax fraud and money laundering.

Business Rules (Search Priority):

The client must provide EITHER a name (name / Razón Social) OR an exact identifier (rfc).
If rfc is provided, the backend performs a strict exact match. If only name is provided, the backend performs a highly restrictive text search.

Risk Level Matrix (riskLevel mapped to SAT Status):

NONE: No matches found in the SAT 69-B list. Safe for automated approval.
LOW: The SAT status is ‘Desvirtuado’ (Investigated but successfully proved innocence) or ‘Sentencia Favorable’ (Won in court / cleared). Provided for audit trails and historical record.
MEDIUM: Reserved for intermediate risk states. Currently not produced by the SAT 69-B classification.
HIGH: The SAT status is ‘Presunto’ (Currently under investigation for simulated operations). Extreme caution advised; usually triggers Enhanced Due Diligence (EDD) or temporal blocks.
CRITICAL: The SAT status is ‘Definitivo’ (Confirmed shell company / EFOS). Legally binding block required for AML compliance.

Multi-match selection: A taxpayer may appear in more than one record (e.g., first listed as PRESUNTO, later reclassified to DEFINITIVO or SENTENCIA_FAVORABLE). The top-level riskLevel reflects only the record with the most recent publicationDateSat (falling back to publicationDateDof). All historical records are still returned in matches[] so you can audit the full timeline.

cURL

curl -X POST https://api.origoid.com/mex/compliance/v1/sat-69b-searches \
  -H "x-api-key: YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"name": "JUAN PEREZ LOPEZ"}'

{
  "status": "OK",
  "type": "SUCCESS",
  "message": "No SAT 69-B matches found",
  "data": {
    "matchFound": false,
    "riskLevel": "NONE",
    "totalMatchesFound": 0,
    "matches": []
  },
  "transactionId": "c3d4e5f6-a7b8-9c0d-1e2f-234567890123",
  "processedAt": "2026-03-19T10:05:00-06:00",
  "billable": true
}

Authorizations

x-api-key

string

header

required

Body

application/json

Option 1
Option 2

name

string

required

Full name for individuals or Legal Business Name for companies.

rfc

string

Subject's RFC. Prioritized for exact matching if provided.

Response

SAT Article 69-B search results (Strict Envelope Pattern).

status

enum<string>

required

High-level outcome. OK means the request was successfully processed (regardless of business result). ERROR means the request was rejected or could not be processed.

Available options:

OK,

ERROR

type

string

required

Stable result type code. Includes generic codes (SUCCESS, INVALID_REQUEST, UNAUTHORIZED, SERVICE_UNAVAILABLE, INTERNAL_ERROR, RATE_LIMIT_EXCEEDED) plus endpoint-specific result codes — see this endpoint's response examples.

message

string

required

Human-readable summary of the result. Always in English (per Language Conventions in the API overview).

transactionId

string<uuid>

required

Unique identifier of this request, generated by the API Gateway. Propagated end-to-end for traceability.

processedAt

string<date-time>

required

ISO 8601 datetime with Mexico City offset (-06:00). Always set by the API Gateway when the response leaves the system.

billable

boolean

required

Whether this request will be charged against the client's plan. Typically true for successful business results and false for validation errors or system errors that prevented processing.

data

object

Response payload. null on error responses. Shape depends on the endpoint — see each operation's response schema.

errors

object[]

Per-field error details. Present only on INVALID_REQUEST responses.

Show child attributes

OFAC Sanctions List Check**Credits:** 1 per call. Searches the consolidated OFAC sanctions lists for the provided name. Coverage includes: - **SDN consolidated** — Specially Designated Nationals (general SDN, plus sub-programs `SDGT` Specially Designated Global Terrorists and `SDNTK` Specially Designated Narcotics Traffickers / Kingpin Act). - **Non-SDN consolidated** — Foreign Sanctions Evaders (`FSE`), Sectoral Sanctions Identifications (`SSI`), Correspondent Account / Payable-Through Account restrictions (`CAPTA`), Menu-Based Sanctions (`NS-MBS`), Iran Sanctions Act non-SDN (`NS-ISA`), Palestinian Legislative Council (`NS-PLC`). - **UN consolidated sanctions** — surfaced as `OFAC_UN` for clients who want a single endpoint covering both US and UN screening. Each match carries the originating list (`listType`), the sanction programs that apply, entity type (individual, entity, vessel, aircraft), full aliases and any compliance remarks published with the record. **Risk Level Matrix (`riskLevel`):** - `NONE` (envelope `type: SUCCESS`): no matches at or above `minSimilarityScore`. Safe for automated approval from an OFAC perspective. - `CRITICAL` (envelope `type: SUCCESS`): one or more matches found in **any** OFAC or UN sanctions list. Treat as a hard block, reject the relationship, and file the SAR (Suspicious Activity Report) required by your jurisdiction. There are intentionally only two levels. AML best practice treats any sanctions list hit — SDN, sectoral, informational, anywhere — as a binding stop. Surfacing intermediate gradations (HIGH / MEDIUM / LOW) misleads the client into believing some hits are merely advisory and is the most common cause of regulatory findings against KYC systems. The `listType` and `complianceDetails.programs` of every match are still surfaced so your compliance team can apply finer policy on top of the binary verdict. **Multi-match handling:** common names can produce dozens of fuzzy hits. The response returns **every record at or above `minSimilarityScore`**, sorted by `similarityScore` descending. There is no fixed truncation, so a genuine hit will never be hidden by a cap. If the volume of matches is higher than your review process can absorb, raise `minSimilarityScore` to tighten the match. `data.totalMatchesFound` mirrors `matches[].length` and is provided for convenience. **Which variant matched:** every entry in `matches[]` carries a `matchedOn` object indicating whether the query matched the canonical `entityName` or one of the record's aliases: - `matchedOn.type` is either `entityName` (the query matched the canonical name) or `alias` (the query matched an alias on the record). - `matchedOn.value` is the alias text that produced the hit when `type` is `alias`, and `null` when `type` is `entityName`. Why this matters: OFAC sometimes lists a person under a family member's record (e.g. `OSEGUERA CERVANTES, Nemesio` — better known as El Mencho — is published as an alias of the canonical `OSEGUERA CERVANTES, Ruben`). Without `matchedOn` a reviewer scanning the response would see `Ruben` with score 100 and discount the hit. With `matchedOn` the alias is surfaced explicitly so the reviewer can confirm the right person was matched. **Multi-identifier matching:** `name` is required, but you can pass `passportNumber` and/or `nationalIdNumber` alongside it to tighten the match. Each extra identifier you provide is used to: - **Boost the score** when it agrees with the record (record's passport or national ID matches the one you sent → +5 added to `similarityScore`, capped at 100). - **Downgrade or filter the match** when it contradicts the record (different passport or national ID → −20 points). If the final score falls below `minSimilarityScore`, the record is excluded from `matches[]` entirely. - **Stay neutral** when the record does not publish that identifier (most OFAC records don't have a passport number, for example). Missing data never penalises a match — only contradicting data does. A `matchedOn` entry per match always carries an `identifiersMatched` array — for example `name` and `passportNumber` — listing exactly which fields agreed, so the reviewer can audit the confidence behind a hit. **Practical coverage of the identifier boost:** OFAC publishes passport numbers and national IDs on a minority of records — most often on non-Mexican subjects (Iranian, Russian, Venezuelan, Cuban records carry passports more frequently). For purely Mexican counterparties the boost rarely applies in practice: OFAC does not publish CURP, RFC appears only on a handful of records, and most Mexican subjects are sanctioned with name + aliases only. Use these identifiers for cross-border screening where the upside is real; for MX-only KYC the `name` field is what does the work and the optional identifiers stay neutral.

cURL

curl -X POST https://api.origoid.com/mex/compliance/v1/sat-69b-searches \
  -H "x-api-key: YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"name": "JUAN PEREZ LOPEZ"}'

{
  "status": "OK",
  "type": "SUCCESS",
  "message": "No SAT 69-B matches found",
  "data": {
    "matchFound": false,
    "riskLevel": "NONE",
    "totalMatchesFound": 0,
    "matches": []
  },
  "transactionId": "c3d4e5f6-a7b8-9c0d-1e2f-234567890123",
  "processedAt": "2026-03-19T10:05:00-06:00",
  "billable": true
}