Fintech onboarding en LATAM: Odoo y un caso PSAV de cripto

Fintech onboarding en LATAM dejó de ser problema de UX

En Perú, una fintech promedio pierde el 64% de usuarios entre "empezó KYC" y "primera transacción". En México, después de la Ley Fintech de 2018, esa cifra baja al 38%: el regulador fijó niveles de cuenta y obligó a diseñar el onboarding como embudo, no como una ventana larga. La diferencia en ingresos para un PSAV mediano: USD 2–4M al año. Esto ya no es UX, es ingeniería de compliance con normativas concretas en cada jurisdicción, multas concretas y fechas concretas de entrada en vigor.

Este pillar está dirigido a CTO, oficiales de cumplimiento y founders de fintech, crypto y lending en LATAM que tienen Odoo como backbone y se chocan con que "out of the box" no hay flujo KYC, y el regulador no espera. Adentro: mapa de reguladores PE/MX/CL/CO/AR para 2025–2026, arquitectura de onboarding en Odoo en seis capas, errores típicos, y un caso anónimo de exchange cripto donde el drop-off bajó del 71% al 43% en 9 semanas.

Resumen en un minuto

• La ventana regulatoria se cierra. Perú, Chile y Colombia cierran en 2025–2026 el marco PLAFT/PSAV — después de tres años de transición las multas dejan de ser teóricas (hasta 100 UIT en Perú ≈ USD 135 000; hasta 150 000 UMA en México ≈ USD 1M).
• Onboarding son cinco subtareas, no una. identification, verification, risk scoring, sanctions screening, ongoing monitoring. La mayoría resuelve las dos primeras — de ahí el 60%+ de drop-off.
• Odoo cubre cerca del 70% de las tareas con una configuración correcta de res.partner + documents + queue.job + un módulo a medida kyc.review. El 30% restante son integraciones con proveedores KYC (Truora, MetaMap, Veriff, Sumsub), listas de sanciones y biometría.
• El tiered onboarding es obligatorio en México y recomendable en todo el resto. Requisitos distintos por límite = menos fricción para el segmento masivo y más compliance para perfiles de alto riesgo.
• Caso anónimo (PSAV en Perú): drop-off del 71% al 43% en 9 semanas tras rehacer el flujo en Odoo + Truora + revisión asíncrona de compliance. Time-to-first-trade: de 47 horas a 6.

Cinco reguladores, una misma tarea

Entre 2018 y 2026, LATAM pasó por una ola de regulación fintech. Cada país a su ritmo, pero el marco es el mismo: KYC (Know Your Customer), PLD/FT (prevención de lavado de dinero / financiamiento al terrorismo), reporte de operaciones sospechosas y retención de records entre 5 y 10 años.

México arrancó primero. La Ley para Regular las Instituciones de Tecnología Financiera del 9 de marzo de 2018 introdujo cuatro niveles de cuenta:

• Nivel 1: cuenta simplificada, sin identificación, límite ~3 000 UDI/mes (≈ MXN 24 000)
• Nivel 2: identificación básica, límite 3 000 UDI/mes
• Nivel 3: identificación completa, límite 10 000 UDI/mes
• Nivel 4: enhanced due diligence, sin límite

Esa gradación es la lección principal del caso mexicano. Baja el drop-off de forma matemática: el 70% de usuarios abre cuenta nivel 1 en dos minutos, y el resto solo hace el KYC completo cuando quiere subir de límite. La CNBV publica las Disposiciones de Carácter General para ITF, y en marzo de 2026 entra en vigor el matching biométrico obligatorio para nivel 3 en adelante.

Perú alcanzó el ritmo con el Decreto Supremo N° 006-2023-JUS (enero 2023), que creó el registro de PSAV bajo supervisión de la SBS-UIF. Plazo de registro: 90 días desde el inicio de operaciones. Multas según el Reglamento de Infracciones y Sanciones de UIF: de 1 a 100 UIT (1 UIT en 2024 = S/. 5 150; hasta ~USD 135 000 por infracciones graves).

Chile aprobó la Ley Fintech 21.521 el 4 de enero de 2023 con la norma de carácter general de la CMF. Periodo de transición de 18 meses con prórrogas por tipo de servicio. Particularidad chilena: open finance interoperability obligatoria — la fintech debe aceptar datos del cliente provenientes de otros operadores regulados.

Colombia avanzó vía el Decreto 1745 (2022) y una serie de circulares externas de la SFC sobre activos virtuales y open finance. La SFC exige customer due diligence proporcional al riesgo y publica trimestralmente perfiles de riesgo del sector.

Argentina, regulación triple. La Resolución General CNV N° 994/2024 creó el Registro de Proveedores de Servicios de Activos Virtuales. En paralelo, la Resolución 49/2024 de la UIF fija requisitos KYC para los VASP. CNV + BCRA + UIF, cada uno con sus formularios.

Denominador común: los reguladores de LATAM descartaron la "única ventana KYC". Quieren tiers, risk-based approach, procesos asíncronos y auditoría con retención mínima de 5 años. Quien diseñe el onboarding como monolito viola el marco regulatorio y pierde dinero antes de que el supervisor levante el acta.

Timeline 2025–2026: qué entra en vigor

La ventana de refactor del onboarding son los dos últimos trimestres de 2025 y el primero de 2026. Después de esa fecha las multas dejan de ser hipotéticas.

Arquitectura de onboarding en Odoo: seis capas

Odoo 17/18 no trae módulo KYC nativo, pero sí trae todas las piezas como cubos. La configuración mínima viable son seis capas.

#1. Modelo de cliente con campos de compliance

res.partner se extiende con un módulo a medida (por convención l10n_xx_kyc). Campos a sumar:

• kyc_tier (selection: 1/2/3/4)
• kyc_status (draft/pending/approved/rejected/expired)
• kyc_risk_score (computed, 0–100, según política PLAFT)
• pld_screening_last_run (datetime)
• beneficial_owner_ids (one2many — UBO, beneficiarios finales)
• politically_exposed_person (boolean + razón)
• source_of_funds (selection + texto libre)

El módulo OCA partner_identification cubre una parte, pero el risk scoring y la lógica PEP siempre se escriben a medida. Este no es lugar para "solución universal de GitHub".

#2. Integración con proveedor KYC

Proveedores realistas en LATAM:

• Truora (Colombia, activo en toda la región) — biometría, ID verification, sanctions
• MetaMap (México) — biometría, liveness, verificación documental
• Veriff (global, con soporte LATAM)
• Sumsub (global, fuerte en cripto)
• Jumio (enterprise)

La integración es un endpoint webhook sobre Odoo (controller con @http.route('/kyc/webhook', auth='public', csrf=False)), firma HMAC para verificación y cola asíncrona vía queue.job para procesar el resultado. Una llamada síncrona equivale a timeout y pérdida del lead en una conexión móvil inestable de provincia.

#3. Workflow PLD con revisión asíncrona

mail.activity + documents + un modelo a medida kyc.review: con eso alcanza para un pipeline de compliance de tamaño medio. Regla principal: ningún review manual en el camino crítico del usuario. El usuario pasa la verificación automática → recibe un nivel 1 temporal → el oficial de cumplimiento aprueba el nivel 2+ en asíncrono.

El efecto es doble: el drop-off baja entre 30% y 40%, y el equipo de compliance deja de ser cuello de botella en horas pico.

#4. Sanctions y PEP screening

OFAC, ONU, lista consolidada UE, GAFI, listas locales (México — Listas SAT/SHCP; Perú — Listas UIF; Argentina — Resolución 70 UIF; Colombia — listas vinculantes SFC). El error grande es chequear solo al onboarding. El regulador exige ongoing monitoring: mínimo mensual; para perfiles high-risk, semanal. Eso es un ir.cron + almacenamiento de cada resultado en kyc.screening.log con retención de 10 años.

La PEP es historia aparte. WorldCheck o Dow Jones Risk son caros; Sumsub y Truora la incluyen en sus paquetes, pero la calidad de las bases PEP locales en LATAM es irregular. Conviene complementar con fuentes locales (Perú: declaraciones juradas SUNAT; México: SIPOT).

#5. Auditoría documental con retención

Módulo documents + reglas de retención. SBS Perú exige 10 años; CNBV México, 10; CMF Chile, 5; SFC Colombia, 10; CNV/UIF Argentina, 10. Los documentos se cifran at rest, los accesos se loggean (mail.message + access log) y existe almacenamiento inmutable (S3 Object Lock o equivalente) para documentos bajo investigación.

Conviene un bucket "activo" y otro "archivado" con lifecycle policy automática. El costo de almacenar PII es marginal comparado con la multa por eliminación temprana.

#6. Reporting al regulador

Cada regulador pide su formato. SBS Perú — Reporte de Operaciones Sospechosas (ROS) en XML por SUCAVE. CNBV México — XML por SITI. CMF Chile — XBRL. SFC Colombia — XBRL/JSON. AFIP/UIF Argentina — XML por PIA.

La buena noticia: el framework account.report de Odoo es lo bastante flexible para cubrir estos formatos vía templates. La mala: hace falta sincronización constante con las actualizaciones del regulador porque los esquemas XSD y los campos cambian todos los años. Hay algunos partners Odoo locales que mantienen estos módulos para PE/CL/CO, pero no todas las localizaciones tienen la misma cobertura.

Cuándo Odoo encaja y cuándo necesita refuerzo

Odoo no es bala de plata. La arquitectura funciona en algunos escenarios y se rompe en otros.

Funciona: PYME-fintech con hasta 50 000 onboardings al mes. Wallet digital, ahorro simplificado, lending con ticket promedio < USD 50k. La pila estándar Odoo + proveedor KYC alcanza. Postgres bastA, queue.job aguanta, un equipo de compliance de 1 a 3 personas resuelve el review en asíncrono.

Funciona: crypto exchange con tier-based limits. Es el caso anónimo que viene abajo. Odoo opera como CRM + backbone de compliance, y el motor de trading es un servicio aparte que llama a la API de Odoo para chequear el nivel del usuario antes de cada operación.

Funciona mal: payment processor con >500 TPS. Si procesás cientos de transacciones por segundo, Odoo no debe estar en el camino crítico. Arquitectura: Odoo para onboarding y compliance; un servicio low-latency (Go/Rust) aparte para autorizar pagos con caché in-memory del perfil.

No funciona: hub de open finance. Si sos un agregador open finance con decenas de bancos partner (modelo Belvo), Odoo no es para eso. Necesitás infraestructura de data engineering tier B — ClickHouse, Kafka, consent management en tiempo real. Aquí la combinación data engineering + Odoo como vitrina CRM funciona, pero no Odoo end-to-end.

Zona gris: insurtech con underwriting complejo. Microseguros — Odoo aguanta con workflow estándar. Salud/vida con underwriting médico — hace falta un engine de underwriting aparte y Odoo queda para policy administration y vitrina de compliance.

Cinco errores típicos del fintech onboarding

#1. Flujo KYC monolítico sin tiers

Todos los usuarios pasan el proceso de 12 pasos con biometría, comprobante de domicilio y proof of funds — incluso quien quiere depositar USD 50. Resultado: 70%+ de drop-off en los pasos 4–5. Fix: tiered onboarding. Nivel 1 — email + teléfono + nombre (60 segundos). Nivel 2 — ID. Nivel 3 — biometría y domicilio. Los reguladores PE/MX/CL/CO/AR validan el enfoque; en México está formalizado en la Ley Fintech.

#2. Proveedor KYC síncrono en el camino crítico

El usuario toma la selfie, el frontend bloquea la UI y espera 30+ segundos la respuesta de Truora. Si el proveedor demora, el usuario se va. Fix: arquitectura asíncrona. El usuario sube los datos → ve "estamos verificando, te avisamos" → sigue en el producto con nivel 1 → recibe push al aprobarse el nivel 2.

#3. Sanctions y PEP solo al onboarding

El regulador exige ongoing monitoring. Un usuario puede entrar en la lista de sanciones 6 meses después de registrarse. Si no relees tu base contra listas actualizadas — es incumplimiento PLAFT. La SBS Perú multa por eso; la CNBV México, más todavía. Fix: ir.cron mensual para todos, semanal para high-risk, con resultado guardado en kyc.screening.log.

#4. Documentos KYC sin cifrado ni retención

La selfie con pasaporte queda en un bucket S3 sin cifrar. La retención no está configurada — los documentos o se eliminan antes (incumplimiento) o se guardan para siempre (riesgo PII y posibles pedidos de erasure bajo leyes locales — Ley 29733 Perú, LGPD Brasil, LFPDPPP México). Fix: AES-256 at rest, claves administradas por KMS, lifecycle policy a 5/10 años según país, almacenamiento inmutable para documentos bajo investigación.

#5. Falta de audit trail en decisiones de compliance

El oficial aprueba al cliente pero no queda registro de quién, cuándo y con qué documentos. Cuando llega la auditoría SBS/CNBV/CMF — no hay nada que mostrar. Fix: cada decisión KYC = registro en kyc.review.decision con autor, timestamp, links a documentos y razonamiento textual. mail.message para el timeline nativo de Odoo. Log inmutable a nivel DB (trigger que prohíbe UPDATE/DELETE sobre decisions).

Caso anónimo: PSAV peruano — drop-off del 71% al 43%

Contexto. PSAV en Perú, registro SBS completado a comienzos de 2024. Volumen ~12 000 onboardings/mes al iniciar el proyecto. Flujo de onboarding: 14 pasos, todo síncrono, KYC-review de 24 a 72 horas. Drop-off en "selfie + ID": 71%. Equipo de compliance de 2 personas, cuello de botella en horas pico.

Qué se hizo (9 semanas). Se rehizo la arquitectura del onboarding en cuatro niveles:

1. Tiered structure. Tres tiers. Tier 1 (email + teléfono): operaciones read-only y hold hasta S/. 1 000. Tier 2 (ID + biometría): operaciones hasta S/. 30 000. Tier 3 (proof of funds + UBO): sin límite.
2. KYC asíncrono. Truora integrado vía webhook. El usuario obtiene Tier 1 al instante; Tier 2 llega en 1 a 4 horas.
3. Workflow PLD en Odoo. Módulo custom sobre partner + documents + queue.job. Sanctions screening — cron diario. PEP — onboarding + cambio de perfil + mensual.
4. Dashboard de compliance. BI dashboard en Odoo para oficiales: cola de review, SLA timers y distribución del risk score.

Resultado a 6 meses.

• Drop-off: 71% → 43% en cohort tier-2+
• Avg time-to-first-trade: 47 horas → 6 horas
• Carga de compliance por oficial: −58% de tiempo por solicitud
• Sanctions screening: de ad-hoc a cron diario, cero casos perdidos en los primeros 6 meses
• Retención (D30): +18 puntos en nuevas cohorts

El return típico de un proyecto así no viene del "proveedor KYC más caro" sino de dos decisiones: tiered approach y revisión asíncrona. Es replicable en cualquier jurisdicción LATAM con la localización compliance adecuada.

Checklist y plantilla

Tenemos preparado un checklist de 47 puntos: tiers de cuenta por país (PE/MX/CL/CO/AR), campos KYC obligatorios, política de retención, formatos de reporte regulatorio, workflow PLD y factores de riesgo para el scoring. Se entrega por correo — dejá tu dirección en el formulario al pie de la página.

En paralelo, una plantilla del módulo kyc.review para Odoo 17/18 (BSL-licensed). Adaptable a PE/MX/CL/CO/AR — las diferencias son solo los campos fiscales y el formato del reporte al regulador.

Siguiente: materiales relacionados

El onboarding es la primera ficha del dominó. Después vienen transaction monitoring, fraud detection y regulatory reporting. Cada capa tiene su material:

• Implementación de Odoo para industrias reguladas — cómo pasar los primeros 90 días sin romper el ROI
• Auditoría de un Odoo existente con foco en deuda de compliance
• Pricing intelligence para fintech con comisiones dinámicas
• Odoo en Perú — pillar de país con desglose de SBS, SUNAT y PSAV locales
• Data engineering para fintech LATAM — cuándo sale del stack Odoo

Si tenés una fintech en alguna jurisdicción LATAM y el drop-off de onboarding supera el 50% — no es problema de UX, es arquitectura de compliance. Treinta minutos de conversación alcanzan para identificar qué arreglar primero.

Preguntas frecuentes