Tecnología financiera:
Pagos / finanzas reguladas

El libro mayor existente del cliente se había injertado en la instancia PostgreSQL operativa desde el primer día. Liquidaciones, reembolsos, pagos a partners y saldos de clientes escribían todos en las mismas tablas que servían a la aplicación, sin invariantes de solo anexado y sin un rastro de auditoría separado. La auditoría del regulador señaló cuatro fallos concretos: las transiciones de estado no se registraban sistemáticamente con el actor que las había iniciado, los cálculos de saldo dependían de un join que podía perder filas en silencio bajo carga, los periodos de conservación eran incoherentes de una tabla a otra, y la postura de recuperación a partir de un snapshot corrupto no se había probado.

Peor aún, el equipo que había construido el libro mayor se había marchado desde entonces. El conocimiento institucional sobre la razón de ser de cada atajo se fue con él. PLACEHOLDER: confirmar el calendario de transición del equipo con el cliente antes de cualquier publicación externa.

La postura de SDEN sobre los libros mayores financieros es explícita: de solo anexado por construcción, de partida doble por principio contable, aislado de la base de datos operativa, y diseñado para la auditoría antes de que la auditoría esté programada. La migración se desarrolló en cuatro fases, cada una con un punto de validación controlado que el cliente podía vetar.

1. Fase 1: Encuadre y modelo de amenazas

   Dos semanas. Cartografiamos cada transición de estado que el libro mayor existente producía, identificamos las siete que el regulador trataría como críticas para la auditoría, y redactamos el modelo de amenazas en torno a ellas. Resultado: una taxonomía de eventos tipada, un esquema objetivo, y un registro de riesgos que el director financiero del cliente firmó.

2. Fase 2: Construcción del libro mayor de solo anexado

   Ocho semanas. Nuevo libro mayor en un clúster PostgreSQL separado con invariantes estrictas de solo anexado impuestas en la base de datos y en la capa de aplicación, contabilidad de partida doble, registro de auditoría inmutable difundido a un destino aislado, y claves de cifrado por inquilino para las cuentas de alto valor.

3. Fase 3: Migración a doble escritura

   Diez semanas. Cada escritura hacia el libro mayor existente se duplicaba hacia el nuevo, con una conciliación continua. Las discrepancias se investigaban y corregían en la fuente, no se parcheaban. La ventana de doble escritura se mantuvo abierta el tiempo suficiente para absorber el ciclo completo de conciliación que el cliente ejecuta mensualmente con sus partners bancarios.

4. Fase 4: Conmutación y ensayo de auditoría

   Seis semanas. Los caminos de lectura migraron al nuevo libro mayor tras feature flags. La conmutación de las escrituras tuvo lugar un sábado con el equipo de operaciones en una sala de crisis dedicada. El ensayo de auditoría ejecutó las consultas esperadas del regulador contra el nuevo libro mayor y produjo el dosier de pruebas exacto que el equipo de auditoría reclamó el mes siguiente.

La auditoría pasó a la primera. PLACEHOLDER: confirmar el organismo de auditoría y el marco regulatorio antes de cualquier publicación externa: el proyecto estaba encuadrado según las expectativas de una autoridad de supervisión financiera europea equivalentes a la CNMV / el Banco de España / la ESMA.

En el plano operativo, el ciclo de conciliación que el equipo ejecutaba manualmente cada mes se convirtió en un proceso diario automatizado. El factor autobús sobre el conocimiento del libro mayor pasó de un ingeniero a cuatro. La base de código está en los repositorios del cliente con documentación escrita para el siguiente ingeniero que se incorpora al equipo, no para el jefe de proyecto que encuadró el proyecto.