Fintech onboarding in LATAM: Odoo and a crypto VASP case study

Fintech onboarding in LATAM is no longer a UX problem

In Peru, the average fintech loses 64% of users between "started KYC" and "first transaction." In Mexico, after the 2018 Ley Fintech, that number drops to 38%. The regulator locked in account tiers and forced operators to design onboarding as a funnel, not a single long window. The revenue gap for a mid-size VASP: USD 2–4M per year. This is no longer UX work. It is compliance engineering with specific rules in every jurisdiction, specific fines, and specific go-live dates.

This pillar is for CTOs, compliance officers, and founders of fintech, crypto, and lending platforms in LATAM that run Odoo as the backbone and discover that the KYC flow is not in the box — and the regulator does not wait. Inside: a regulator map for PE/MX/CL/CO/AR through 2025–2026, a six-layer onboarding architecture on Odoo, common mistakes, and an anonymized case from a crypto exchange where drop-off fell from 71% to 43% in 9 weeks.

One-minute summary

• The regulatory window is closing. Peru, Chile, and Colombia close their PLAFT/VASP frameworks in 2025–2026. After three years of transition, fines stop being theoretical — up to 100 UIT in Peru (≈ USD 135k), up to 150,000 UMA in Mexico (≈ USD 1M).
• Onboarding is five sub-problems, not one. Identification, verification, risk scoring, sanctions screening, ongoing monitoring. Most teams solve the first two — which is why drop-off lands above 60%.
• Odoo covers about 70% of the work with a correct configuration of res.partner + documents + queue.job + a custom kyc.review module. The remaining 30% is integrations with KYC vendors (Truora, MetaMap, Veriff, Sumsub), sanctions lists, and biometrics.
• Tiered onboarding is mandatory in Mexico and recommended everywhere else. Different requirements per limit means less friction for the mass segment and more compliance work on high-risk profiles.
• Anonymous case (Peruvian VASP): drop-off from 71% to 43% in 9 weeks after rebuilding the onboarding flow on Odoo + Truora + async compliance review. Time-to-first-trade: from 47 hours to 6.

Five regulators, one job

From 2018 to 2026, LATAM rolled out a wave of fintech regulation. Each country at its own pace, but the framework is the same: KYC (Know Your Customer), AML/CFT (anti-money-laundering / counter-terrorism financing), suspicious activity reports, and record retention of 5–10 years.

Mexico moved first. The Ley para Regular las Instituciones de Tecnología Financiera (March 9, 2018) introduced four account tiers:

• Tier 1: simplified account, no ID, limit ~3,000 UDI/month (≈ MXN 24,000)
• Tier 2: basic identification, limit 3,000 UDI/month
• Tier 3: full identification, limit 10,000 UDI/month
• Tier 4: enhanced due diligence, no limit

That gradation is the lesson from Mexico. Drop-off shrinks mathematically: 70% of users open a Tier 1 account in two minutes, and the rest only do full KYC when they want a higher limit. CNBV publishes the General Provisions for ITF, and in March 2026 biometric matching becomes mandatory for Tier 3 and above.

Peru caught up with Decreto Supremo N° 006-2023-JUS (January 2023), which created the VASP registry under SBS-UIF supervision. Registration deadline: 90 days from start of operations. Penalties under the UIF Sanctions Regulation: 1 to 100 UIT (1 UIT in 2024 = S/. 5,150; up to about USD 135,000 for serious breaches).

Chile passed Ley Fintech 21.521 on January 4, 2023, along with the CMF general rule. The transition period is 18 months, with extensions per service type. A Chilean twist: open finance interoperability is mandatory — a fintech must accept customer data from other regulated operators.

Colombia moved through Decreto 1745 (2022) and a series of external circulars from the SFC on virtual assets and open finance. The SFC requires customer due diligence proportional to risk and publishes quarterly risk profiles for the sector.

Argentina: triple regulation. CNV General Resolution N° 994/2024 created the registry of Virtual Asset Service Providers. In parallel, UIF Resolution 49/2024 sets KYC requirements for VASPs. CNV + BCRA + UIF, each with its own forms.

Common thread: LATAM regulators rejected the "single KYC window." They want tiers, a risk-based approach, asynchronous processes, and an audit trail with minimum five-year retention. Anyone who designs onboarding as a monolith breaks the regulatory frame and loses money long before the supervisor files the violation.

Timeline 2025–2026: what goes live

The window to refactor onboarding is the last two quarters of 2025 and the first quarter of 2026. After that, the fines stop being hypothetical.

Onboarding architecture on Odoo: six layers

Odoo 17/18 ships no native KYC module, but it ships every block needed to build one. A minimum viable configuration runs in six layers.

#1. Customer model with compliance fields

res.partner gets extended with a custom module (conventionally l10n_xx_kyc). Fields to add:

• kyc_tier (selection: 1/2/3/4)
• kyc_status (draft/pending/approved/rejected/expired)
• kyc_risk_score (computed, 0–100, against the PLAFT policy)
• pld_screening_last_run (datetime)
• beneficial_owner_ids (one2many — UBOs, ultimate beneficial owners)
• politically_exposed_person (boolean + reason)
• source_of_funds (selection + free text)

The OCA partner_identification module covers part of this, but risk scoring and PEP logic always get written in-house. This is not the place for a "universal GitHub solution."

#2. KYC vendor integration

Realistic vendors in LATAM:

• Truora (Colombia, active across the region) — biometrics, ID verification, sanctions
• MetaMap (Mexico) — biometrics, liveness, document verification
• Veriff (global, with LATAM support)
• Sumsub (global, strong in crypto)
• Jumio (enterprise)

The integration is a webhook endpoint on Odoo (a controller with @http.route('/kyc/webhook', auth='public', csrf=False)), HMAC signature for verification, and an async queue via queue.job to process the result. A synchronous call means a timeout — and a lost lead on a flaky mobile connection in a provincial town.

#3. AML workflow with async review

mail.activity + documents + a custom kyc.review model is enough for a mid-size compliance pipeline. Core rule: no manual review on the user's critical path. The user clears the automated check → gets a temporary Tier 1 → the compliance officer approves Tier 2+ asynchronously.

The effect cuts both ways: drop-off falls 30–40%, and the compliance team stops being a bottleneck during peak hours.

#4. Sanctions and PEP screening

OFAC, UN, EU consolidated list, FATF, plus local lists (Mexico — Listas SAT/SHCP; Peru — Listas UIF; Argentina — UIF Resolution 70; Colombia — SFC binding lists). The big mistake is screening only at onboarding. Regulators require ongoing monitoring: monthly at minimum, weekly for high-risk profiles. That means an ir.cron job plus storage of every result in kyc.screening.log with 10-year retention.

PEP is a separate story. WorldCheck or Dow Jones Risk run expensive; Sumsub and Truora bundle PEP into their packages, but local PEP database quality in LATAM is uneven. A complementary check against local sources (Peru: SUNAT sworn declarations; Mexico: SIPOT) is recommended.

#5. Document audit with retention

The documents module plus retention rules. SBS Peru requires 10 years; CNBV Mexico, 10; CMF Chile, 5; SFC Colombia, 10; CNV/UIF Argentina, 10. Documents are encrypted at rest, access is logged (mail.message + access log), and immutable storage (S3 Object Lock or equivalent) holds documents under investigation.

Run two buckets: one "active," one "archived," with automatic lifecycle transfer. PII storage cost is trivial against the fine for early deletion.

#6. Regulatory reporting

Each regulator wants a different format. SBS Peru — Suspicious Activity Reports (ROS) in XML via SUCAVE. CNBV Mexico — XML via SITI. CMF Chile — XBRL. SFC Colombia — XBRL/JSON. AFIP/UIF Argentina — XML via PIA.

Good news: the Odoo account.report framework is flexible enough to cover these formats through templates. Bad news: it needs constant sync with regulator updates because XSD schemas and fields change every year. A handful of local Odoo partners maintain these modules for PE/CL/CO, but not every localization has equal coverage.

When Odoo fits — and when it needs reinforcement

Odoo is not a silver bullet. The architecture works in some scenarios and breaks in others.

Works: SMB fintech up to 50,000 onboardings/month. Digital wallet, simplified savings, lending with average ticket under USD 50k. The standard Odoo + KYC vendor stack is enough. Postgres holds, queue.job handles the load, and a compliance team of 1–3 people processes reviews asynchronously.

Works: crypto exchange with tier-based limits. The anonymized case below fits here. Odoo runs as CRM + compliance backbone; the trading engine is a separate service that calls the Odoo API to check the user's tier before each operation.

Works poorly: payment processor over 500 TPS. When you process hundreds of transactions per second, Odoo cannot sit on the critical path. The architecture: Odoo for onboarding and compliance, a separate low-latency service (Go/Rust) for payment authorization with an in-memory profile cache.

Does not work: open finance hub. If you are an open-finance aggregator with dozens of partner banks (Belvo-style model), Odoo is not the right tool. You need tier-B data engineering infrastructure — ClickHouse, Kafka, real-time consent management. Here the data engineering stack + Odoo as a CRM front works, but not Odoo end-to-end.

Gray zone: insurtech with complex underwriting. Micro-insurance — Odoo handles it through standard workflow. Health/life insurance with medical underwriting — you need a separate underwriting engine; Odoo stays as policy administration and the compliance front.

Five common fintech onboarding mistakes

#1. Monolithic KYC flow without tiers

Every user runs the 12-step process with biometrics, proof of address, and proof of funds — even someone who wants to deposit USD 50. Result: 70%+ drop-off at steps 4–5. Fix: tiered onboarding. Tier 1 — email + phone + name (60 seconds). Tier 2 — add ID. Tier 3 — biometrics and address. PE/MX/CL/CO/AR regulators endorse the approach; Mexico formalized it in the Ley Fintech.

#2. Synchronous KYC vendor on the critical path

The user takes the selfie, the frontend blocks the UI, and waits 30+ seconds for the Truora response. If the vendor lags, the user leaves. Fix: async architecture. The user uploads data → sees "we're verifying, we'll notify you" → continues in the product at Tier 1 → gets a push when Tier 2 clears.

#3. Sanctions and PEP only at onboarding

The regulator requires ongoing monitoring. A user can land on a sanctions list six months after sign-up. If you don't rescreen against updated lists — that's a PLAFT breach. SBS Peru fines for it; CNBV Mexico does too. Fix: ir.cron monthly for everyone, weekly for high-risk, with results stored in kyc.screening.log.

#4. KYC documents without encryption or retention policy

The selfie-with-passport sits in an S3 bucket without encryption. Retention isn't configured — documents either get deleted too early (violation) or stay forever (PII risk and potential erasure requests under local data protection laws — Ley 29733 Peru, LGPD Brazil, LFPDPPP Mexico). Fix: AES-256 at rest, KMS-managed keys, lifecycle policy at 5/10 years depending on country, immutable storage for documents under investigation.

#5. No audit trail for compliance decisions

The compliance officer approves a customer, but no record exists of who, when, and based on which documents. When SBS, CNBV, or CMF show up for an audit, there's nothing to show. Fix: every KYC decision = a record in kyc.review.decision with author, timestamp, document links, and a written rationale. mail.message for the native Odoo timeline. An immutable log at the DB level (a trigger that blocks UPDATE/DELETE on decisions).

Anonymous case: a Peruvian VASP — drop-off from 71% to 43%

Context. A VASP in Peru, SBS registration completed in early 2024. Volume around 12,000 onboardings/month at project start. Onboarding flow: 14 steps, fully synchronous, KYC review took 24–72 hours. Drop-off at "selfie + ID": 71%. The compliance team of two people was the bottleneck at peak hours.

What we did (9 weeks). Rebuilt the onboarding architecture across four layers:

1. Tiered structure. Three tiers. Tier 1 (email + phone): read-only operations and holds up to S/. 1,000. Tier 2 (ID + biometrics): operations up to S/. 30,000. Tier 3 (proof of funds + UBO): no limit.
2. Async KYC. Truora integrated via webhook. The user gets Tier 1 immediately; Tier 2 lands in 1–4 hours.
3. AML workflow on Odoo. Custom module on top of partner + documents + queue.job. Sanctions screening — daily cron. PEP — at onboarding + on profile change + monthly.
4. Compliance dashboard. An Odoo BI dashboard for officers with the review queue, SLA timers, and risk-score distribution.

Result after 6 months.

• Drop-off: 71% → 43% on the Tier 2+ cohort
• Avg time-to-first-trade: 47 hours → 6 hours
• Compliance load per officer: −58% time per case
• Sanctions screening: from ad-hoc to daily cron, zero missed cases in the first 6 months
• D30 retention: +18 points on new cohorts

The typical return on a project like this comes not from "a more expensive KYC vendor" but from two calls: tiered approach and async review. It replicates in any LATAM jurisdiction with the right compliance localization.

Checklist and template

We prepared a 47-point checklist: account tiers per country (PE/MX/CL/CO/AR), required KYC fields, retention policy, regulatory reporting formats, AML workflow, and risk factors for scoring. Delivered by email — drop your address in the form at the bottom of the page.

In parallel: a kyc.review module template for Odoo 17/18 (BSL-licensed). Adaptable to PE/MX/CL/CO/AR — the differences are limited to fiscal fields and the regulator's reporting format.

Next: related material

Onboarding is the first domino. After it come transaction monitoring, fraud detection, and regulatory reporting. Every layer has its own piece:

• Odoo implementation for regulated industries — how to get through the first 90 days without breaking ROI
• Audit of an existing Odoo with focus on compliance debt
• Pricing intelligence for fintechs with dynamic fees
• Odoo in Peru — country pillar with SBS, SUNAT, and local VASP breakdown
• Data engineering for LATAM fintechs — when you outgrow the Odoo stack

If you run a fintech in any LATAM jurisdiction and your onboarding drop-off is above 50%, this is not a UX problem — it is a compliance architecture problem. Thirty minutes of conversation are enough to identify what to fix first.

FAQ