Recuperación de Datos en el Sector Seguros y Servicios Financieros
Las entidades bancarias, aseguradoras y empresas de servicios financieros gestionan datos de un valor incalculable: registros de pólizas, posiciones de trading, historiales de reclamaciones y bases actuariales. Cuando un fallo de almacenamiento amenaza estos sistemas, cada minuto cuenta. La recuperación de datos en este sector exige experiencia técnica especializada y pleno cumplimiento normativo.
Por qué el Sector Financiero es especialmente vulnerable
Las instituciones financieras operan con infraestructuras de almacenamiento enormemente complejas: arrays de discos SAN, sistemas NAS de alta disponibilidad, servidores de bases de datos Oracle y SQL Server con terabytes de datos transaccionales, y entornos híbridos que combinan hardware heredado con plataformas cloud. Esta complejidad multiplica los vectores de fallo.
A diferencia de otros sectores, los fallos de datos en banca y seguros generan consecuencias en cascada. Un fallo en el sistema de core banking durante el cierre del día puede impedir la conciliación de miles de transacciones, generar descuadres contables y activar alertas regulatorias. La pérdida de una base de datos de reclamaciones puede paralizar la liquidación de siniestros y exponer a la entidad a penalizaciones por incumplimiento de plazos legales.
Además, el sector está sometido a normativas estrictas en materia de integridad y disponibilidad de datos. MiFID II exige que las empresas de inversión conserven registros completos de órdenes y transacciones durante al menos cinco años, con acceso inmediato en los dos primeros. Solvencia II impone a las aseguradoras la obligación de mantener datos actuariales y de riesgo con la máxima integridad. Un fallo de almacenamiento sin recuperación documentada puede suponer sanciones millonarias por parte de la CNMV o la Dirección General de Seguros.
Sistemas críticos: qué datos están en juego
Para entender la magnitud del problema, conviene repasar los principales sistemas de información del sector y los datos que alojan:
Core Banking Systems
Plataformas como Temenos T24, Finastra Fusion o Mambu gestionan el núcleo operativo de un banco: cuentas corrientes, préstamos, depósitos, transferencias y posiciones en tiempo real. Estos sistemas suelen correr sobre bases de datos Oracle RAC o IBM Db2 en servidores físicos de gama alta con redundancia RAID. Un fallo en el almacenamiento subyacente —cabezal dañado, controlador RAID corrupto o fallo eléctrico durante una escritura— puede corromper los ficheros de datos y los redo logs de Oracle, dejando la base de datos en un estado inconsistente imposible de arrancar.
Plataformas de Trading
Los sistemas de negociación algorítmica y las plataformas de gestión de órdenes (OMS) generan millones de registros diarios: ticks de mercado, órdenes ejecutadas, posiciones abiertas, P&L intradiario. Estos datos se almacenan frecuentemente en bases de datos columnar de alto rendimiento (kdb+, TimescaleDB) o en ficheros de log propietarios. La recuperación requiere no solo restaurar los ficheros sino también verificar la integridad secuencial de los registros de tiempo para cumplir con los requisitos de MiFID II.
Bases de Datos Actuariales
Las aseguradoras mantienen modelos actuariales con décadas de datos históricos de siniestralidad, tablas de mortalidad, modelos de riesgo y proyecciones financieras. Estos modelos, desarrollados frecuentemente en SAS, R o herramientas propietarias, se almacenan en ficheros de gran tamaño que en algunos casos llevan años sin ser completamente respaldados por su aparente estabilidad. Un fallo de disco en el servidor que los aloja puede suponer la pérdida de modelos imposibles de reconstruir.
Sistemas de Gestión de Reclamaciones y Pólizas
Las plataformas de policy administration (Guidewire, Duck Creek, soluciones propias) almacenan el historial completo de cada póliza: coberturas, primas, renovaciones, reclamaciones abiertas y cerradas, documentación adjunta. La corrupción de estas bases de datos afecta directamente a la capacidad de la aseguradora para operar y puede generar litigios con asegurados que reclamen coberturas que el sistema no puede acreditar.
Escenario típico: fallo de servidor durante el cierre del día bancario
Imaginemos que son las 22:47 de un martes. El proceso nocturno de batch del core banking está ejecutando el cierre del día —conciliación de transacciones, cálculo de intereses, generación de extractos— cuando uno de los discos del array de almacenamiento sufre un fallo mecánico. El controlador RAID detecta el error e inicia la degradación, pero un segundo disco del mismo grupo de paridad, ya con sectores inestables, falla minutos después. El RAID se rompe. El servidor Oracle no puede continuar escribiendo y entra en estado de espera indefinida.
El equipo de IT detecta el problema al cabo de veinte minutos. El array está en modo de solo lectura parcial. Los datos de varios tablespaces de Oracle están inconsistentes: los redo logs del último checkpoint no se han aplicado, y algunos bloques de datos presentan checksums incorrectos. El último backup completo es de 36 horas antes. Hay transacciones del día que no están respaldadas en ningún otro lugar.
En este escenario, la recuperación requiere varios pasos simultáneos: extracción de datos de los discos físicos en laboratorio (uno presenta ruido de cabezal), reconstrucción de la lógica RAID mediante herramientas forenses, y posterior aplicación de técnicas de recuperación de bases de datos Oracle a nivel de bloque para extraer los datos de los tablespaces corruptos. El objetivo no es solo recuperar los ficheros, sino obtener los datos transaccionales en un estado coherente que permita reconstruir el cierre del día.
Escenario típico: corrupción de base de datos de reclamaciones de seguro
Imaginemos que una aseguradora mediana gestiona más de 80.000 expedientes de siniestros activos en una base de datos SQL Server. Durante una actualización del sistema operativo del servidor, el administrador reinicia el equipo sin detener correctamente el servicio de SQL Server. Al arrancar, SQL Server detecta que varios ficheros de datos (.mdf) presentan páginas corruptas. El proceso de recuperación automática (CHECKDB) falla para dos de las bases de datos. Miles de expedientes de siniestros resultarían inaccesibles.
La recuperación en este caso pasa por la extracción directa de las páginas de datos de SQL Server usando herramientas especializadas que leen los ficheros MDF byte a byte, identificando las páginas corruptas e intentando reconstruir los registros a partir de las páginas adyacentes y del transaction log. Este proceso, denominado habitualmente page-level recovery, permite recuperar entre el 90% y el 99% de los registros incluso cuando DBCC CHECKDB declara la base de datos irrecuperable.
Cumplimiento normativo durante y después de la recuperación
En el sector financiero, el proceso de recuperación debe estar documentado con el mismo rigor que cualquier otro proceso auditado. Esto implica:
WhatsApp