Selo

The analysis starts when the user confirms the upload and runs in three stages, in this order: document authenticity, liveness and face comparison. If a stage fails, the following ones do not run. After them Selo checks uniqueness, which links the document to a single account.

Media is opened with the session key in memory only, during the analysis, and is never written in the clear. Scores and face models exist only while the analysis runs.

Accepts Brazilian ID cards (RG), driving licences (CNH) and passports. For passports the photo page is used; for the others, front and back. The stage checks printed features visible in a photo, the machine-readable zone (check digits and consistency with the visual zone), validity, legibility, and whether front and back belong to the same document.

Only three data points leave the document:

The sex field on the document is masked when it is read. The system cannot read it, and no schema, table or message in Selo has a sex or gender field.

The user receives a challenge on camera, valid for two minutes. The validity is checked on confirmation, and an expired challenge does not pass. The liveness engine must come, by contract, with an accredited lab test under ISO/IEC 30107-3, level 1 at minimum and level 2 as the target.

The face from the liveness check is compared with the face on the document. The operating point is at most 1 false match in 100,000 comparisons, per the engine calibration, and the false non-match rate is monitored on every release. The score does not go into the verdict, the logs or the database.

Fairness is tracked per group, in aggregate and with groups of at least 20 people, with a monthly review of refusal and reversal rates.

Once the three stages pass, the document pseudonym is linked to the account in a single transaction. If the same document is already linked to another active account, the images are destroyed immediately and the case goes to review without media.

Selo does not compare faces across accounts, because it stores no face models. That kind of deduplication is ruled out in the specification. The pseudonym is kept while the linked account exists, and velocity signals for 90 days.

Every automated refusal becomes a case for a trained person. The review console sits on a separate origin from the API, requires a second factor and keeps the session for eight hours. Each case is delivered to one person at a time, and the system enforces that rule.

The decision is approve or deny, within 48 hours of the case being created. An appeal is answered in writing within 48 hours, by a different person from the one who decided the original case. No role, including administrator, can export media.

The verdict is approved, refused with a technical reason, or under review. When a session ends without a decision on the merits, your company receives the closure: expired, review not completed, or document already linked, with a flag saying the user earned a free new attempt.

{
  "sessaoId": "ses_01J9K3MV7QX2",
  "versaoDoLaudo": 1,
  "versaoDoContrato": "2",
  "laudo": "aprovada",
  "motivo": null,
  "emitidoEm": "2026-10-03T14:21:07Z",
  "assinatura": { "kid": "2026-09", "nonce": "c6f1…" }
}

The webhook is signed with Ed25519, identifies the key by kid so it can be rotated, carries a timestamp with a 5 minute tolerance and a unique identifier, and is idempotent per session and verdict version. Status polling exists as a fallback. Every route has a closed response schema.

Gender, appearance and name mismatch do not exist as a reason, criterion or field. The reason returned is always technical.

Your application talks to Selo over mTLS at two moments. It opens the session, supplying a pseudonymous account reference, the consent record, the declared date of birth and the document type. And it receives the verdict through the webhook, with status polling as a fallback. Name, chosen name, gender and email are not sent to Selo, which has no field for them.

Capture is done by your application, and the user uploads the media straight to Selo with the session credential. The integration documentation, the versioned contract and the staging environment are delivered at the start of the pilot.