Esta es una traducción de cortesía. La versión en portugués es el texto auténtico y prevalece en caso de divergencia.
El onboarding de XIP tiene cuatro capas: la aplicación recoge, la API orquesta y encamina, el prestador contratado verifica y realiza el screening, y el panel administrativo permite el seguimiento. La habilitación para transaccionar se decide en la API, en cada operación, y no puede ser eludida por el cliente.
Objetivo y alcance
Este documento describe técnicamente los sistemas que ejecutan el registro, la verificación de identidad y el screening de los usuarios de XIP. Sirve como material de referencia para la diligencia técnica de socios, auditores y autoridades.
Complementa, en el plano de la implementación, las reglas establecidas en:
- Políticas y Procedimientos de KYC y EDD — qué se exige y por qué;
- Política de PBC/FT y Procedimientos Internos — los controles de prevención y el reparto de responsabilidades;
- Evidencia de Registros de KYC — la comprobación verificable de lo que se registra y del bloqueo transaccional.
Visión general de la arquitectura
| Capa | Componente | Tecnología | Responsabilidad en el onboarding |
|---|---|---|---|
| 1 | Aplicación móvil | Android nativo (Kotlin, Jetpack Compose) | Recogida de datos e imágenes, validación local, compresión, presentación del estado del registro. |
| 2 | API | Go, arquitectura en capas (controlador → servicio → repositorio), PostgreSQL, Redis | Autenticación, validación en el servidor, creación del registro, encaminamiento de las imágenes, registro del resultado y decisión de habilitación. |
| 3 | Prestador contratado | Institución autorizada, integrada por API | Análisis documental, prueba de vida, screening de listas restrictivas y de persona expuesta políticamente (PEP), decisión de verificación, custodia de los documentos. |
| 4 | Panel administrativo | Aplicación web (React/Next), con perfiles y permisos | Consulta de usuarios y operaciones para atención y conformidad, bajo control de acceso granular. |
La comunicación entre todas las capas está cifrada en tránsito mediante TLS. La capa 2 es el único punto por el que transitan los datos de verificación, y no delega en el cliente ninguna decisión de control.
Capa 1 — Aplicación móvil
El módulo de verificación de la aplicación se organiza en una máquina de estados de navegación, con un modelo de vista que mantiene el formulario y la situación del registro, y pantallas dedicadas por etapa.
Pantallas del flujo
| Etapa | Pantalla | Función |
|---|---|---|
| Aviso de exigencia | Aviso de verificación pendiente | Informa de que la operación pretendida exige verificación y conduce al flujo. Se presenta en la configuración, en la pantalla de depósito y en la pantalla de retiro. |
| 1 | Datos personales | Recogida de nombre completo, CPF (número de identificación fiscal de personas físicas en Brasil), teléfono y correo electrónico, con máscaras de entrada y validación en tiempo real. |
| 2 | Documento de identificación | Elección entre RG (documento de identidad brasileño) y CNH (licencia de conducir brasileña) y captura de las imágenes correspondientes, con previsualización y sustitución. |
| 3 | Imagen facial | Captura de la selfie con orientación de encuadre, para la prueba de vida. |
| 4 | Revisión | Comprobación consolidada de datos e imágenes antes del envío definitivo. |
| — | Enviado / En análisis | Confirma la recepción e informa de que el análisis está en curso. |
| — | Aprobado | Informa de la habilitación y libera el acceso a las operaciones. |
| — | Rechazado | Presenta el motivo registrado por el prestador contratado y ofrece la nueva presentación. |
| — | Error | Informa de los fallos de comunicación de forma legible, sin perder el formulario ya rellenado. |
Controles ejecutados en la aplicación
- Validación estructural del CPF mediante el algoritmo de módulo 11, con rechazo de secuencias repetidas — un CPF inválido no llega a transmitirse;
- Validación del teléfono en cuanto al código de área (DDD) y al formato nacional, y del correo electrónico en cuanto al formato;
- Bloqueo del avance por etapa incompleta: cada etapa exige que sus validaciones se cumplan;
- Consistencia del conjunto documental: el cambio de modalidad descarta las imágenes de documento incompatibles, preservando la imagen facial;
- Compresión de las imágenes en el dispositivo a JPEG, con un presupuesto de tamaño distribuido entre las imágenes y un mínimo por imagen para preservar la legibilidad;
- Enmascaramiento en los registros de diagnóstico: los identificadores sensibles aparecen truncados en los registros técnicos de la aplicación — el CPF, por ejemplo, se registra solo por los últimos dígitos;
- Relleno automático del correo electrónico a partir de la cuenta ya confirmada, lo que reduce la divergencia en los datos de registro.
Las validaciones de la aplicación existen para dar retorno inmediato al usuario y reducir envíos inútiles. Ninguna de ellas se trata como garantía. Todas las reglas se reaplican en el servidor, que es la única autoridad sobre la aceptación de los datos y sobre la habilitación para transaccionar.
Capa 2 — API
La API expone cuatro operaciones de verificación, todas autenticadas y sometidas a los controles de seguridad de la plataforma:
| Operación | Endpoint | Función |
|---|---|---|
| Iniciar la verificación | POST /api/kyc | Crea el registro del usuario ante el prestador contratado, a partir del nombre, el CPF, el correo electrónico de la cuenta y la dirección de la cartera. Idempotente. |
| Enviar documentos | POST /api/kyc/documents | Recibe las imágenes en multipart/form-data y las encamina al prestador contratado. Nada se graba. |
| Actualizar la identificación | PATCH /api/kyc | Actualiza el nombre, el correo electrónico y el teléfono. Se rechaza después de la aprobación. El CPF no es actualizable por esta vía. |
| Consultar la situación | GET /api/kyc | Devuelve el estado de la verificación, el estado del registro y el motivo del rechazo. Se actualiza contra el prestador cuando el estado no es terminal. |
Comportamientos relevantes de la capa de servicio
| Comportamiento | Implementación | Riesgo mitigado |
|---|---|---|
| Idempotencia de la creación | Consulta previa del registro existente; en caso de ausencia, la creación ocurre bajo bloqueo de exclusión mutua en la base de datos, con nueva comprobación dentro del bloqueo. | Un toque doble en la aplicación o solicitudes concurrentes crearían registros duplicados en el prestador y violarían la restricción de unicidad local. |
| Sellado tras la aprobación | Los intentos de actualizar la identificación o de reenviar documentos en un registro aprobado se rechazan con un error específico. | Alteración de datos verificados sin un nuevo análisis. |
| Actualización condicionada del estado | La consulta al prestador solo ocurre cuando el estado es pendiente, enviado o en análisis. Los estados terminales no generan consulta. | Tráfico innecesario hacia el prestador y reapertura indebida de decisiones definitivas. |
| Degradación segura | El fallo en la consulta al prestador se registra y se devuelve el estado conocido, sin alteración. | Que una indisponibilidad momentánea altere indebidamente el estado del registro del usuario. |
| Pista de auditoría | La respuesta íntegra del prestador se conserva en formato estructurado en cada evento del ciclo de vida. | Imposibilidad de conciliar, posteriormente, lo que el prestador informó. |
| Decisión de habilitación | Verificación de la conjunción «verificación aprobada y registro activo» antes de cualquier cotización u operación. | Operación por parte de un usuario no verificado, suspendido o bloqueado. |
Capa 3 — Prestador contratado
La verificación de identidad propiamente dicha y el screening los ejecuta el prestador contratado, institución autorizada y sujeta a la regulación y a la supervisión competentes. La integración se realiza mediante una API autenticada por credenciales propias de XIP, transmitidas en cabeceras y mantenidas en una configuración protegida, fuera del código fuente.
Compete al prestador contratado, conforme a lo establecido en el contrato:
- el análisis de las imágenes del documento de identificación, en cuanto a autenticidad, legibilidad e integridad;
- la prueba de vida y la comparación entre la imagen facial y la fotografía del documento;
- la validación del CPF y la comprobación de los datos de identificación en bases oficiales;
- el screening de listas restrictivas y de sanciones — sanciones de las Naciones Unidas, sanciones internacionales aplicables y listas nacionales de restricción;
- la calificación como persona expuesta políticamente, incluidos representantes, familiares y colaboradores estrechos;
- la decisión de verificación, con registro del motivo en caso de rechazo;
- la custodia de los documentos de identificación durante los plazos legales;
- la monitorización de las operaciones liquidadas y el análisis de alertas;
- la comunicación de operaciones sospechosas a las autoridades competentes.
XIP recibe del prestador el resultado de esas verificaciones, no sus insumos: ni las imágenes analizadas ni el detalle de la consulta a las listas retornan para su almacenamiento en XIP.
Capa 4 — Panel administrativo
El panel administrativo lo utiliza personal autorizado de XIP para atención y conformidad. Sus características de control:
- autenticación propia, distinta de la de los usuarios finales, con restablecimiento de contraseña mediante un flujo dedicado;
- perfiles y permisos granulares: el acceso se atribuye por función, con aplicación del principio de mínimo privilegio, y se verifica en el servidor en cada solicitud;
- consulta de usuarios y de operaciones con fines de atención, sin capacidad de alterar el resultado de una verificación de identidad;
- ausencia de acceso a los documentos de identificación: como las imágenes no son almacenadas por XIP, no existe pantalla, exportación ni consulta que las muestre a operadores internos.
Ningún colaborador de XIP — en ningún nivel de acceso — puede visualizar la imagen del documento ni la imagen facial de un usuario. El riesgo de acceso interno indebido a esos datos se elimina en el origen, y no se mitiga mediante control de permisos.
Flujo de extremo a extremo
Creación de cuenta
El usuario crea la cuenta con correo electrónico, nombre de usuario y contraseña, y confirma el correo electrónico. La cartera no custodial se genera en el dispositivo, con claves que nunca salen de él. En esta etapa no hay verificación de identidad.
Aplicación · APIExigencia de la verificación
Al intentar depositar o retirar, el usuario encuentra el aviso de verificación pendiente y es conducido al flujo.
AplicaciónRecogida y validación local
Recorrido de las cuatro etapas, con validación en cada avance y compresión de las imágenes en el dispositivo.
AplicaciónCreación del registro
La API valida los datos, crea el registro en el prestador contratado bajo bloqueo de concurrencia y persiste el registro local con el identificador externo devuelto.
API · prestador contratadoEncaminamiento de las imágenes
Las imágenes llegan a la API, permanecen únicamente en memoria durante el tiempo de la solicitud y son recompuestas y transmitidas al prestador contratado. No ocurre ninguna grabación.
APIAnálisis y screening
El prestador contratado analiza los documentos, ejecuta la prueba de vida y el screening de listas restrictivas y de persona expuesta políticamente, y decide.
Prestador contratadoRegistro del resultado
La API registra el estado de la verificación, el estado del registro, el motivo en caso de rechazo, la fecha del análisis y la respuesta en bruto como pista de auditoría.
APIHabilitación o rechazo
Aprobado y activo, el registro pasa a permitir operaciones. En cualquier otro estado, la API rechaza toda cotización y toda operación, sin excepción.
APISeguimiento continuo
El prestador contratado monitoriza las operaciones liquidadas; la API registra los eventos recibidos, verificados mediante firma criptográfica, manteniendo la pista completa.
Prestador contratado · APIScreening: qué se consulta y dónde
| Verificación | Ejecutor | Momento | Efecto en XIP |
|---|---|---|---|
| Autenticidad y legibilidad del documento | Prestador contratado | En el análisis, tras el envío | Rechazo con motivo registrado y mostrado al usuario. |
| Prueba de vida y comparación facial | Prestador contratado | En el análisis | Rechazo con motivo registrado. |
| Validación del CPF en base oficial | Prestador contratado | En el análisis | Rechazo con motivo registrado. |
| Estructura del CPF (módulo 11) | XIP | En la recogida, antes de cualquier envío | Impedimento del avance en la etapa 1. |
| Listas de sanciones de las Naciones Unidas | Prestador contratado | Antes de la aprobación y en reevaluaciones | Registro no aprobado o bloqueado; suspensión inmediata en la plataforma. |
| Sanciones internacionales aplicables y listas nacionales de restricción | Prestador contratado | Antes de la aprobación y en reevaluaciones | Registro no aprobado o bloqueado. |
| Calificación como persona expuesta políticamente | Prestador contratado | Antes de la aprobación y en reevaluaciones | Clasificación de riesgo alto, con diligencia reforzada y aprobación en instancia superior. |
| Monitorización de operaciones y generación de alertas | Prestador contratado | Continuo, tras la habilitación | Suspensión o bloqueo del registro, con efecto inmediato sobre nuevas operaciones. |
| Verificación de la habilitación en cada operación | XIP | En cada cotización y en cada operación | Rechazo de la operación antes de cualquier efecto externo. |
Controles de seguridad del pipeline
| Control | Aplicación |
|---|---|
| Autenticación por token firmado | Todas las operaciones de verificación exigen una sesión válida del usuario; una credencial inválida invalida la sesión en el cliente. |
| Autenticación en dos etapas | Disponible mediante aplicación autenticadora, con códigos de recuperación de un solo uso. |
| Limitación de tráfico en capas | Techo global por origen para toda la API, techo por cuenta autenticada y techos específicos en los endpoints de credenciales y de operaciones. |
| Filtros de solicitud | Detección de anomalías de cabecera, de intentos de inyección de SQL y de contenido malicioso, aplicados a toda la superficie de la API. |
| Cifrado en tránsito | TLS entre la aplicación, la API y el prestador contratado. |
| Verificación de la firma de las notificaciones | HMAC-SHA256 sobre el cuerpo en bruto de los mensajes recibidos del prestador; los mensajes no firmados son rechazados, sin modo de elusión. |
| Bloqueos de concurrencia | Exclusión mutua en la base de datos en las operaciones de creación de registro y de operación. |
| Restricciones de integridad en la base de datos | Unicidad de registro por usuario y por prestador, unicidad del identificador externo, clave foránea obligatoria para la cuenta, prohibición de eliminación de registros financieros. |
| Minimización en los registros técnicos | Identificadores sensibles enmascarados en los registros de aplicación, en el cliente y en el servidor. |
| Credenciales fuera del código | Credenciales de integración mantenidas en una configuración de entorno protegida, nunca versionadas. |
| Segregación de entornos | Entornos distintos de desarrollo, homologación y producción, con credenciales y bases separadas. |
| Pruebas automatizadas | Suite ejecutada en cada modificación, que cubre el flujo de verificación, la idempotencia de la creación, el sellado tras la aprobación y el rechazo de operaciones para registros no habilitados. |
Pantallas del proceso de onboarding
Las capturas siguientes documentan las pantallas efectivamente presentadas al usuario durante el flujo de verificación. Los datos mostrados corresponden a un entorno de demostración.
Demostración en vídeo
Las grabaciones siguientes demuestran el proceso real de extremo a extremo, en un entorno de demostración, lo que permite verificar el comportamiento del sistema sin necesidad de acceso a la plataforma.
Disponible en: https://xip.cash/media/onboarding/register.mp4
Disponible en: https://xip.cash/media/onboarding/kyc.mp4
Disponible en: https://xip.cash/media/onboarding/block.mp4
Pueden solicitarse grabaciones adicionales y demostraciones asistidas en entorno controlado a compliance@xip.cash.
Entornos y disponibilidad
| Ítem | Situación |
|---|---|
| Plataforma de la aplicación | Android. Distribución por el canal oficial de aplicaciones. |
| Idioma del flujo de verificación | Portugués de Brasil. |
| Tipo de usuario admitido | Persona física, residente en Brasil, de 18 años o más. El registro de persona jurídica no se admite actualmente. |
| Documentos aceptados | RG (anverso y reverso) o CNH, siempre acompañados de imagen facial. |
| Entornos | Desarrollo, homologación y producción segregados, con credenciales y bases de datos independientes. |
| Documentación técnica de la API | Especificación OpenAPI mantenida en el repositorio del proyecto, disponible para socios mediante solicitud. |
Historial de versiones
| Versión | Fecha | Cambios |
|---|---|---|
| 1.0 | 29/07/2026 | Publicación inicial. Capturas de pantalla y vídeos pendientes de inclusión. |