Cómo un corporativo financiero LATAM habilitó su expansión regional sin refactorizar

Contexto

El cliente es un corporativo de servicios financieros no bancario con presencia en México, Colombia, Perú y Chile. Cada operación local había crecido por adquisición o greenfield en momentos distintos, con sistemas transaccionales propios, definiciones locales de producto y equipos de datos independientes. El comité directivo aprobó un plan estratégico para entrar a dos mercados adicionales en Sudamérica dentro de 18 meses.

El problema real

La expansión iba a chocar con la realidad tecnológica. Los intentos previos de consolidar información regional habían fracasado: un cliente definido como “activo” en México no significaba lo mismo que en Colombia, un producto de crédito estructurado en Perú no se mapeaba con nada equivalente en Chile, y los reportes regulatorios se producían con equipos locales que interpretaban las mismas cifras con criterios diferentes.

Más profundo que el problema técnico estaba el problema regulatorio. Cada país tenía su propia autoridad supervisora con requerimientos específicos: la CNBV en México, la SBS en Perú, la SFC en Colombia y la SBIF en Chile. Añadir dos jurisdicciones nuevas sin una arquitectura común implicaba multiplicar el número de reportes específicos, de controles locales y de riesgos de incumplimiento.

Cada expansión previa había tomado entre 9 y 12 meses solo para tener los tableros básicos de dirección funcionando. Con esa cadencia, el plan de expansión era inviable.

La arquitectura implementada

Wave Design partió del principio de que un modelo canónico regional debe ser lo suficientemente abstracto para acomodar diferencias locales sin fracturarse. Diseñamos un modelo de datos maestros con tres entidades núcleo — cliente, producto, transacción — donde cada entidad tiene atributos globales invariantes y una zona extensible por jurisdicción.

Sobre ese modelo construimos una capa de gobierno con cuatro componentes. Un catálogo de datos unificado con linaje visible desde el reporte regulatorio hasta el sistema origen. Un motor de políticas configurable donde cada regla de compliance por país se declara como configuración, no como código. Un flujo formal de aprobación de cambios al modelo con representación de los cuatro países. Y un tablero de calidad de datos con umbrales por dominio.

La capa de compliance regional fue la más delicada. Cada supervisor tiene requerimientos distintos sobre reserva mínima, clasificación de cartera, reporte de operaciones inusuales y protección de datos personales. Codificamos esas reglas como políticas versionadas, con casos de prueba automatizados, de forma que agregar una jurisdicción nueva se convierte en escribir un nuevo perfil de políticas en lugar de rediseñar el modelo.

Los resultados

La expansión a los dos países planeados se ejecutó dentro del plazo comprometido, sin refactor del modelo de datos. El tiempo promedio de integración de una nueva geografía bajó de 11 a 4 meses. Los reportes regulatorios que antes tomaban entre 3 y 5 semanas por país ahora se producen en menos de 5 días, con una reducción global de 73% en horas hombre. La primera auditoría de compliance posterior a la implementación cerró sin hallazgos materiales, algo que la organización no había logrado antes.

El resultado con más impacto de negocio fue la vista consolidada de cliente. Por primera vez la dirección regional puede identificar en minutos qué clientes tienen relación con el grupo en más de un país, qué productos consumen y cuál es la exposición agregada. Eso habilitó una estrategia de cross-sell regional que en los primeros dos trimestres generó nuevos ingresos por más de $80 millones de pesos.

Lecciones

Tres puntos que vale registrar. Primero, en operaciones multi-país la trampa clásica es tratar de imponer un modelo único que ignora diferencias regulatorias reales; el modelo tiene que ser extensible por diseño. Segundo, el compliance se resuelve mejor como capa de configuración que como código, porque los reguladores cambian sus requerimientos más rápido que los ciclos de release. Y tercero, un plan de expansión sin arquitectura habilitante es un compromiso comercial contra la ingeniería, y la ingeniería siempre gana.