Inyo360 — Verificação de Identidade (KYC)

A API de Verificação de Identidade faz parte da suíte de conformidade Inyo360 — uma nova tecnologia de verificação de identidade desenvolvida internamente pela Inyo. Ela combina machine learning e IA agêntica com técnicas avançadas de visão computacional para realizar uma verificação KYC robusta, em vez de depender de um fornecedor terceirizado.

O cliente fotografa um documento emitido pelo governo — passaporte, carteira de motorista ou carteira de identidade — e tira uma selfie. A Inyo extrai os dados do documento, valida-os, verifica se o documento é autêntico e não está vencido, confirma que a selfie é de uma pessoa real e compara essa pessoa com o retrato do documento. A IA agêntica orquestra essas verificações e decide os casos limítrofes, e você recebe um resultado normalizado.

O que esse resultado conclui depende do seu modo de decisionamento. Sob decisionamento não gerenciado — o padrão — a Inyo publica a avaliação e você decide. Sob decisionamento gerenciado a Inyo também chega a um veredito, entregue como decision: approved, declined, inconclusive ou in_review enquanto uma pessoa avalia.

Como Funciona

sequenceDiagram
    autonumber
    participant Y as Seu Sistema
    participant I as Inyo
    participant C as Cliente
    Y->>I: POST /v1/sessions
    I-->>Y: sessionId +<br/>widgetUrl
    Y->>C: entrega o widgetUrl
    C->>I: documento<br/>frente / verso
    C->>I: selfie + prova de vida
    Note over I: Executa<br/>verificações
    I-->>Y: webhook assinado<br/>ou redirecionamento
    Y->>I: GET /v1/sessions/{id}
    I-->>Y: avaliação, e uma<br/>decisão se gerenciado
    Y->>C: mostra o resultado

Duas Formas de Integrar

Escolha uma por verificação — ambas produzem o mesmo resultado normalizado e respeitam a mesma configuração.

Etapas de Integração

Vai pular o widget? Substitua as etapas 2-4 por uma verificação server-to-server, e leia a etapa 6 em GET /v1/verifications/{verificationId}.

O Que Você Recebe

Cada verificação resulta em um único resultado normalizado contendo os dados extraídos do documento e da pessoa, as verificações individuais e — sob decisionamento gerenciado — a decisão:

{
  "sessionId": "…",
  "userRef": "user-123",
  "status": "completed",
  "decision": "approved",
  "document": { "type": "passport", "number": "…", "expirationDate": "2033-09-30" },
  "person": { "firstName": "…", "lastName": "…", "dateOfBirth": "1988-03-04" },
  "checks": [
    { "name": "document_not_expired", "status": "passed", "group": "document", "severity": "critical", "detail": "…" },
    { "name": "face_match", "status": "passed", "group": "selfie", "severity": "high", "detail": "similarity vs threshold 90.0" }
  ],
  "provider": "inyo",
  "trustIndex": 100
}

O payload completo e as regras para interpretá-lo estão em Verificações e Decisões.

Padrão de Arquitetura

Suas credenciais OAuth são exclusivas do servidor. Crie sessões a partir do seu backend e entregue ao cliente apenas o widgetUrl retornado — ele carrega um código de uso único e com prazo limitado, e não concede acesso a nada além daquela única verificação.

flowchart TB
    subgraph browser["Dispositivo do cliente"]
        C["Navegador /<br/>webview"]
    end
    subgraph yours["Sua infraestrutura"]
        S["Seu servidor<br/>guarda as credenciais OAuth"]
    end
    subgraph inyo["Inyo"]
        W["Widget hospedado"]
        A["API do tenant"]
    end
    S -->|"POST /v1/sessions<br/>token Bearer"| A
    A -->|"widgetUrl"| S
    S -->|"apenas o widgetUrl"| C
    C -->|"documento + selfie"| W
    W --> A
    A -->|"resultado assinado"| S

Ambientes

As URLs base, as credenciais de cliente OAuth e a lista de IPs permitidos são emitidas pela Inyo durante o onboarding. As credenciais de sandbox e produção não são intercambiáveis.

Próximos Passos