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:
- Políticas e Procedimentos de KYC e EDD — o que é exigido e por quê;
- Política de PLD/CTF e Procedimentos Internos — os controles de prevenção e a divisão de responsabilidades;
- Evidência de Registros de KYC — a comprovação verificável do que é registrado e do bloqueio transacional.
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.
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.
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 · APIExigência da verificação
Ao tentar depositar ou sacar, o usuário encontra o aviso de verificação pendente e é conduzido ao fluxo.
AplicativoColeta e validação local
Percurso das quatro etapas, com validação a cada avanço e compressão das imagens no dispositivo.
AplicativoCriaçã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 contratadoEncaminhamento 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.
APIAná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 contratadoRegistro 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.
APIHabilitaçã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.
APIAcompanhamento 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 · APIScreening: 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.
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.
Disponível em: https://xip.cash/media/onboarding/register.mp4
Disponível em: https://xip.cash/media/onboarding/kyc.mp4
Disponível em: https://xip.cash/media/onboarding/block.mp4
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. |