XIP

Documentos institucionais  /  Sistemas de Onboarding e Screening

Descrição técnica

Sistemas de Onboarding e Screening

Descrição técnica das camadas que compõem o cadastro, a verificação de identidade e o screening de usuários do XIP, com telas e demonstração em vídeo do processo.

Documento DES-01
Versão 1.0
Vigente desde 29/07/2026
Última revisão 29/07/2026
Classificação Público
Resumo em uma linha

O onboarding do XIP tem quatro camadas: o aplicativo coleta, a API orquestra e encaminha, o prestador contratado verifica e faz o screening, e o painel administrativo permite acompanhamento. A habilitação para transacionar é decidida na API, a cada operação, e não pode ser contornada pelo cliente.

Objetivo e escopo

Este documento descreve tecnicamente os sistemas que executam o cadastro, a verificação de identidade e o screening de usuários do XIP. Serve como material de referência para diligência técnica de parceiros, auditores e autoridades.

Ele complementa, no plano da implementação, as regras estabelecidas em:

Visão geral da arquitetura

Camada Componente Tecnologia Responsabilidade no onboarding
1 Aplicativo móvel Android nativo (Kotlin, Jetpack Compose) Coleta de dados e imagens, validação local, compressão, apresentação do estado do cadastro.
2 API Go, arquitetura em camadas (controlador → serviço → repositório), PostgreSQL, Redis Autenticação, validação no servidor, criação do cadastro, encaminhamento das imagens, registro do resultado e decisão de habilitação.
3 Prestador contratado Instituição autorizada, integrada por API Análise documental, prova de vida, screening de listas restritivas e de pessoa exposta politicamente, decisão de verificação, guarda dos documentos.
4 Painel administrativo Aplicação web (React/Next), com perfis e permissões Consulta de usuários e operações para atendimento e conformidade, sob controle de acesso granular.

A comunicação entre todas as camadas é cifrada em trânsito por TLS. A camada 2 é o único ponto por onde dados de verificação transitam, e ela não delega ao cliente nenhuma decisão de controle.

Camada 1 — Aplicativo móvel

O módulo de verificação do aplicativo é organizado em uma máquina de estados de navegação, com um modelo de visão que mantém o formulário e a situação do cadastro, e telas dedicadas por etapa.

Telas do fluxo

Etapa Tela Função
Aviso de exigência Aviso de verificação pendente Informa que a operação pretendida exige verificação e conduz ao fluxo. Apresentado nas configurações, na tela de depósito e na tela de saque.
1 Dados pessoais Coleta de nome completo, CPF, telefone e e-mail, com máscaras de entrada e validação em tempo real.
2 Documento de identificação Escolha entre RG e CNH e captura das imagens correspondentes, com pré-visualização e substituição.
3 Imagem facial Captura da selfie com orientação de enquadramento, para prova de vida.
4 Revisão Conferência consolidada de dados e imagens antes do envio definitivo.
Enviado / Em análise Confirma o recebimento e informa que a análise está em curso.
Aprovado Informa a habilitação e libera o acesso às operações.
Recusado Apresenta o motivo registrado pelo prestador contratado e oferece a reapresentação.
Erro Informa falhas de comunicação de forma legível, sem perder o formulário preenchido.

Controles executados no aplicativo

  • Validação estrutural do CPF pelo algoritmo módulo 11, com rejeição de sequências repetidas — CPF inválido não chega a ser transmitido;
  • Validação de telefone quanto a DDD e formato nacional, e de e-mail quanto ao formato;
  • Bloqueio de avanço por etapa incompleta: cada etapa exige que suas validações passem;
  • Consistência do conjunto documental: a troca de modalidade descarta imagens de documento incompatíveis, preservando a imagem facial;
  • Compressão das imagens no dispositivo para JPEG, com orçamento de tamanho distribuído entre as imagens e piso mínimo por imagem para preservar legibilidade;
  • Mascaramento em registros de diagnóstico: identificadores sensíveis aparecem truncados nos registros técnicos do aplicativo — o CPF, por exemplo, é registrado apenas pelos últimos dígitos;
  • Preenchimento automático do e-mail a partir da conta já confirmada, reduzindo divergência cadastral.
Sobre a confiança no cliente

As validações do aplicativo existem para dar retorno imediato ao usuário e reduzir envios inúteis. Nenhuma delas é tratada como garantia. Todas as regras são reaplicadas no servidor, que é a única autoridade sobre a aceitação dos dados e sobre a habilitação para transacionar.

Camada 2 — API

A API expõe quatro operações de verificação, todas autenticadas e submetidas aos controles de segurança da plataforma:

Operação Endpoint Função
Iniciar verificação POST /api/kyc Cria o cadastro do usuário junto ao prestador contratado, a partir de nome, CPF, e-mail da conta e endereço de carteira. Idempotente.
Enviar documentos POST /api/kyc/documents Recebe as imagens em multipart/form-data e as encaminha ao prestador contratado. Nada é gravado.
Atualizar identificação PATCH /api/kyc Atualiza nome, e-mail e telefone. Recusado após a aprovação. O CPF não é atualizável por esta via.
Consultar situação GET /api/kyc Retorna o estado da verificação, o estado do cadastro e o motivo de recusa. Atualiza contra o prestador quando o estado é não terminal.

Comportamentos relevantes da camada de serviço

Comportamento Implementação Risco mitigado
Idempotência da criação Consulta prévia do cadastro existente; em caso de ausência, a criação ocorre sob trava de exclusão mútua no banco de dados, com reconferência dentro da trava. Toque duplo no aplicativo ou requisições concorrentes criariam cadastros duplicados no prestador e violariam a restrição de unicidade local.
Selagem após aprovação Tentativas de atualizar identificação ou reenviar documentos em cadastro aprovado são recusadas com erro específico. Alteração de dados verificados sem nova análise.
Atualização condicionada do estado A consulta ao prestador só ocorre quando o estado é pendente, enviado ou em análise. Estados terminais não geram consulta. Tráfego desnecessário ao prestador e reabertura indevida de decisões definitivas.
Degradação segura Falha na consulta ao prestador é registrada e o estado conhecido é retornado, sem alteração. Uma indisponibilidade momentânea alterar indevidamente o estado do cadastro do usuário.
Trilha de auditoria A resposta íntegra do prestador é conservada em formato estruturado a cada evento do ciclo de vida. Impossibilidade de conciliar, posteriormente, o que o prestador informou.
Decisão de habilitação Verificação da conjunção "verificação aprovada e cadastro ativo" antes de qualquer cotação ou operação. Operação por usuário não verificado, suspenso ou bloqueado.

Camada 3 — Prestador contratado

A verificação de identidade propriamente dita e o screening são executados pelo prestador contratado, instituição autorizada e sujeita à regulação e à supervisão competentes. A integração se dá por API autenticada por credenciais próprias do XIP, transmitidas em cabeçalhos e mantidas em configuração protegida, fora do código-fonte.

Compete ao prestador contratado, conforme estabelecido em contrato:

  • a análise das imagens do documento de identificação, quanto a autenticidade, legibilidade e integridade;
  • a prova de vida e a comparação entre a imagem facial e a fotografia do documento;
  • a validação do CPF e a conferência dos dados de identificação em bases oficiais;
  • o screening de listas restritivas — sanções das Nações Unidas, sanções internacionais aplicáveis e listas nacionais de restrição;
  • o enquadramento como pessoa exposta politicamente, incluindo representantes, familiares e estreitos colaboradores;
  • a decisão de verificação, com registro do motivo em caso de recusa;
  • a guarda dos documentos de identificação pelos prazos legais;
  • o monitoramento das operações liquidadas e a análise de alertas;
  • a comunicação de operações suspeitas às autoridades competentes.

O XIP recebe do prestador o resultado dessas verificações, não os seus insumos: nem as imagens analisadas, nem o detalhe da consulta às listas retornam para armazenamento no XIP.

Camada 4 — Painel administrativo

O painel administrativo é utilizado por pessoal autorizado do XIP para atendimento e conformidade. Suas características de controle:

  • autenticação própria, distinta da dos usuários finais, com redefinição de senha por fluxo dedicado;
  • perfis e permissões granulares: o acesso é atribuído por função, com aplicação do princípio do menor privilégio, e verificado no servidor em cada requisição;
  • consulta de usuários e de operações para fins de atendimento, sem capacidade de alterar o resultado de uma verificação de identidade;
  • ausência de acesso a documentos de identificação: como as imagens não são armazenadas pelo XIP, não há tela, exportação ou consulta que as exiba a operadores internos.
Consequência de projeto

Nenhum colaborador do XIP — em qualquer nível de acesso — pode visualizar a imagem do documento ou a imagem facial de um usuário. O risco de acesso interno indevido a esses dados é eliminado na origem, e não mitigado por controle de permissão.

Fluxo ponta a ponta

Criação de conta

O usuário cria a conta com e-mail, nome de usuário e senha, e confirma o e-mail. A carteira não-custodial é gerada no dispositivo, com chaves que nunca saem dele. Nesta etapa não há verificação de identidade.

Aplicativo · API

Exigência da verificação

Ao tentar depositar ou sacar, o usuário encontra o aviso de verificação pendente e é conduzido ao fluxo.

Aplicativo

Coleta e validação local

Percurso das quatro etapas, com validação a cada avanço e compressão das imagens no dispositivo.

Aplicativo

Criação do cadastro

A API valida os dados, cria o cadastro no prestador contratado sob trava de concorrência e persiste o registro local com o identificador externo retornado.

API · prestador contratado

Encaminhamento das imagens

As imagens chegam à API, permanecem apenas em memória pelo tempo da requisição e são remontadas e transmitidas ao prestador contratado. Nenhuma gravação ocorre.

API

Análise e screening

O prestador contratado analisa os documentos, executa a prova de vida e o screening de listas restritivas e de pessoa exposta politicamente, e decide.

Prestador contratado

Registro do resultado

A API registra o estado da verificação, o estado do cadastro, o motivo em caso de recusa, a data da análise e a resposta bruta como trilha de auditoria.

API

Habilitação ou recusa

Aprovado e ativo, o cadastro passa a permitir operações. Em qualquer outro estado, a API recusa toda cotação e toda operação, sem exceção.

API

Acompanhamento contínuo

O prestador contratado monitora as operações liquidadas; a API registra os eventos recebidos, verificados por assinatura criptográfica, mantendo a trilha completa.

Prestador contratado · API

Screening: o que é consultado e onde

Verificação Executor Momento Efeito no XIP
Autenticidade e legibilidade do documento Prestador contratado Na análise, após o envio Recusa com motivo registrado e exibido ao usuário.
Prova de vida e comparação facial Prestador contratado Na análise Recusa com motivo registrado.
Validação do CPF em base oficial Prestador contratado Na análise Recusa com motivo registrado.
Estrutura do CPF (módulo 11) XIP Na coleta, antes de qualquer envio Impedimento de avanço na etapa 1.
Listas de sanções das Nações Unidas Prestador contratado Antes da aprovação e em reavaliações Cadastro não aprovado ou bloqueado; suspensão imediata na plataforma.
Sanções internacionais aplicáveis e listas nacionais de restrição Prestador contratado Antes da aprovação e em reavaliações Cadastro não aprovado ou bloqueado.
Enquadramento como pessoa exposta politicamente Prestador contratado Antes da aprovação e em reavaliações Classificação de risco alto, com diligência ampliada e aprovação em instância superior.
Monitoramento de operações e geração de alertas Prestador contratado Contínuo, após a habilitação Suspensão ou bloqueio do cadastro, com efeito imediato sobre novas operações.
Verificação de habilitação a cada operação XIP A cada cotação e a cada operação Recusa da operação antes de qualquer efeito externo.

Controles de segurança do pipeline

Controle Aplicação
Autenticação por token assinado Todas as operações de verificação exigem sessão válida do usuário; credencial inválida invalida a sessão no cliente.
Autenticação em duas etapas Disponível por aplicativo autenticador, com códigos de recuperação de uso único.
Limitação de tráfego em camadas Teto global por origem para toda a API, teto por conta autenticada e tetos específicos nos endpoints de credenciais e de operações.
Filtros de requisição Detecção de anomalias de cabeçalho, de tentativas de injeção de SQL e de conteúdo malicioso, aplicados a toda a superfície da API.
Cifragem em trânsito TLS entre aplicativo, API e prestador contratado.
Verificação de assinatura de notificações HMAC-SHA256 sobre o corpo bruto das mensagens recebidas do prestador; mensagens não assinadas são rejeitadas, sem modo de contorno.
Travas de concorrência Exclusão mútua no banco de dados nas operações de criação de cadastro e de operação.
Restrições de integridade no banco Unicidade de cadastro por usuário e por prestador, unicidade de identificador externo, chave estrangeira obrigatória para a conta, vedação de exclusão de registros financeiros.
Minimização em registros técnicos Identificadores sensíveis mascarados nos registros de aplicação, no cliente e no servidor.
Credenciais fora do código Credenciais de integração mantidas em configuração de ambiente protegida, nunca versionadas.
Segregação de ambientes Ambientes distintos de desenvolvimento, homologação e produção, com credenciais e bases separadas.
Testes automatizados Suíte executada a cada alteração, cobrindo o fluxo de verificação, a idempotência da criação, a selagem após aprovação e a recusa de operações para cadastros não habilitados.

Telas do processo de onboarding

As capturas abaixo documentam as telas efetivamente apresentadas ao usuário durante o fluxo de verificação. Os dados exibidos são de ambiente de demonstração.

Aviso de verificação pendente
Aviso de verificação pendente. Apresentado quando o usuário tenta depositar ou sacar sem cadastro habilitado, com acesso direto ao fluxo.
Coleta de dados pessoais
Coleta de dados pessoais. Nome completo, CPF, telefone e e-mail, com máscaras de entrada e validação em tempo real.
Escolha e captura do documento
Escolha e captura do documento. Seleção entre RG e CNH, com captura das imagens correspondentes e pré-visualização.
Captura da imagem facial
Captura da imagem facial. Prova de vida, com orientação de enquadramento e iluminação.
Revisão final
Revisão final. Conferência consolidada de dados e imagens antes do envio definitivo.
Confirmação de envio
Confirmação de envio. Informa que os documentos foram recebidos e que a análise está em curso.
Verificação aprovada
Verificação aprovada. Cadastro habilitado; as operações em moeda nacional passam a estar disponíveis.
Verificação recusada
Verificação recusada. Exibe o motivo registrado pelo prestador contratado e oferece a reapresentação dos documentos.

Demonstração em vídeo

As gravações abaixo demonstram o processo real de ponta a ponta, em ambiente de demonstração, permitindo verificar o comportamento do sistema sem necessidade de acesso à plataforma.

Onboarding completo. Criação de conta, confirmação de e-mail, geração da carteira no dispositivo e percurso integral do fluxo de verificação até a decisão.
Fluxo de verificação em detalhe. As quatro etapas de coleta, as validações aplicadas a cada avanço, a captura do documento e da imagem facial, e a tela de revisão.
Bloqueio transacional. Tentativa de depósito e de saque por usuário sem cadastro habilitado, evidenciando a recusa da operação e o encaminhamento ao fluxo de verificação.

Gravações adicionais e demonstrações assistidas em ambiente controlado podem ser solicitadas a compliance@xip.cash.

Ambientes e disponibilidade

Item Situação
Plataforma do aplicativo Android. Distribuição por canal oficial de aplicativos.
Idioma do fluxo de verificação Português do Brasil.
Tipo de usuário admitido Pessoa natural, residente no Brasil, com 18 anos ou mais. Cadastro de pessoa jurídica não é admitido atualmente.
Documentos aceitos RG (frente e verso) ou CNH, sempre acompanhados de imagem facial.
Ambientes Desenvolvimento, homologação e produção segregados, com credenciais e bases de dados independentes.
Documentação técnica da API Especificação OpenAPI mantida no repositório do projeto, disponível a parceiros mediante solicitação.

Histórico de versões

Versão Data Alterações
1.0 29/07/2026 Publicação inicial. Capturas de tela e vídeos pendentes de inclusão.