Blockchain en seguros e insurtech para coordinar siniestros y pagos

El seguro comienza antes del siniestro. La entidad identifica al cliente y al interés asegurado, estima frecuencia y severidad, fija condiciones, cobra una prima y reserva capital. Si ocurre un evento, debe comprobar vigencia, cobertura, causalidad, daño y posible fraude antes de pagar. Después recupera importes cuando existe subrogación y comparte parte del riesgo con reaseguradores.

Cada fase utiliza registros y participantes distintos. Intervienen mediadores, peritos, talleres, hospitales, proveedores de datos, aseguradoras y reaseguradoras. Una misma pérdida puede afectar a varias pólizas o capas de cobertura. El reto operativo está en relacionar identidad, contrato, evidencia y responsabilidad sin duplicar información ni adelantar una conclusión que todavía requiere juicio.

Blockchain encaja cuando varias entidades necesitan observar el mismo estado contractual o conciliar la misma exposición. Su aportación potencial es un historial compartido y reglas ejecutables. La obligación jurídica sigue naciendo de la póliza y de la normativa. El código no puede ampliar una cobertura, resolver una cláusula ambigua ni decidir por sí solo si una declaración fue fraudulenta.

En seguros, blockchain funciona como una capa de estado y ejecución, no como la póliza completa. El contrato legal define derechos y excepciones; el smart contract representa únicamente las condiciones que pueden expresarse de forma determinista. Cuando recibe datos suficientes, puede registrar el evento, calcular una cantidad y ordenar o ejecutar el pago conforme a los controles establecidos.

Para conocer el mundo exterior necesita un oráculo, una fuente o conjunto de fuentes que informa de lluvia, vuelo, índice, ubicación o cualquier otro parámetro. La automatización es tan fiable como la definición del índice, la calidad de esas fuentes y el procedimiento para resolver una lectura errónea. En productos no paramétricos, la investigación y la valoración del daño siguen siendo esenciales.

El modelo más defendible combina código y proceso. La red conserva versiones y evidencias compartidas; la aseguradora mantiene sus controles de sanciones, fraude, solvencia y atención al cliente; y una vía de excepción permite revisar el resultado. El objetivo es automatizar lo inequívoco y hacer trazable lo discutible, no fingir que todo siniestro es una condición binaria.

Un seguro paramétrico no indemniza necesariamente el daño observado. Paga la cantidad acordada cuando un índice supera un umbral, como precipitación en una estación, intensidad de un ciclón, rendimiento regional o retraso certificado. Esa objetividad reduce peritación y permite desembolsar pronto, algo valioso cuando el asegurado necesita liquidez inmediata.

La contrapartida es el riesgo de base. El cliente puede sufrir una pérdida y que el índice no active el pago, o recibirlo sin una pérdida equivalente. La calidad del producto depende de que el parámetro se relacione bien con el riesgo, de que el área y el periodo sean adecuados y de que la explicación comercial no confunda pago paramétrico con indemnización del daño real.

Blockchain automatiza la ejecución y hace verificable qué dato y qué versión de la regla se utilizaron. No mejora por sí sola el índice. Debe existir una política para fuentes ausentes, revisiones oficiales, desacuerdo entre oracles y eventos extremos fuera del modelo. Cuanto más irreversible sea el pago, más robusta debe ser la gobernanza del dato.

Compartir pólizas, facturas o eventos puede dificultar reclamaciones duplicadas y alteraciones posteriores. También permite demostrar qué información estaba disponible cuando se tomó una decisión. Pero gran parte del fraude ocurre antes de que el dato llegue al registro mediante identidad sintética, daño provocado, documento falso o connivencia entre proveedores.

Si una fuente falsa firma un evento, blockchain conserva la falsedad con excelente trazabilidad. La prevención sigue requiriendo validación de identidad, análisis, investigación y cooperación bajo límites de privacidad y competencia. La red puede aportar evidencia y evitar que cada entidad reconstruya el mismo expediente; no debe presentarse como un detector automático de intención.

Blockchain aporta un estado común cuando aseguradoras, distribuidores, proveedores, clientes y reaseguradores deben verificar la misma póliza o evento. Las reglas pueden coordinar cobertura, evidencia, reservas y pago, mientras cada entidad conserva sus sistemas. La utilidad aumenta cuando la condición es objetiva y disminuye cuando causalidad, daño o conducta requieren juicio profesional.

En el seguro tradicional, póliza, evidencia, decisión, pago y recuperación recorren sistemas y organizaciones distintos. Una red blockchain puede mantener estados compartidos y ejecutar reglas acordadas. No elimina investigación ni atención al cliente, pero reduce conciliación en procesos repetibles y deja un historial verificable de quién declaró, validó o autorizó cada paso.

La notificación abre un expediente, pero no determina el pago. La entidad verifica vigencia, identidad, cobertura, exclusiones y documentación; reserva una estimación; investiga cuando corresponde; calcula la prestación; paga; y puede recuperar frente a terceros. En salud, automóvil o responsabilidad civil, varios proveedores añaden evidencia y la causalidad rara vez es un simple dato.

DLT puede mantener un estado común, evitar solicitudes repetidas y registrar quién aportó cada documento. Los smart contracts pueden ejecutar pasos deterministas como comprobar plazo, detectar duplicidad, reservar fondos o distribuir un importe ya aprobado. La decisión que afecta al cliente debe conservar explicación, responsable y derecho de reclamación.

La mejor automatización no elimina todas las revisiones. Dirige los casos simples por una vía rápida y escala inconsistencias. El diseño incluye reversión contable, corrección de fuentes, fraude posterior al pago y continuidad si la red no está disponible. Un pago rápido que no puede explicarse o recurrirse traslada coste operativo a riesgo de conducta.

En reaseguro, cedente, corredor y reasegurador intercambian contratos, bordereaux, primas, siniestros y recuperaciones. La información llega en momentos y formatos distintos y puede requerir meses de conciliación. Un registro común puede vincular cada movimiento con la versión contractual aplicable y mostrar qué parte está aceptada o disputada.

La dificultad no es solo técnica. Los tratados contienen límites, agregados, reinstalaciones, divisas y cláusulas que requieren interpretación. Además, las carteras contienen información comercial y personal que no debe difundirse entre competidores. La arquitectura suele ser permisionada, con visibilidad selectiva y documentos detallados fuera de cadena.

La automatización es útil para cálculos y movimientos aceptados, mientras que controversias y cambios de estimación conservan intervención. El beneficio se mide en cierre más rápido, menos diferencias, mejor visión de acumulaciones y menor capital atrapado, no en reemplazar al reasegurador por código.

El fraude cuesta unos 308.600 millones de dólares al año solo en EE.UU., según la Coalition Against Insurance Fraud en 2022. La cifra explica el interés por compartir evidencia y detectar duplicidades. No demuestra que toda automatización reduzca fraude, porque identidad, causalidad y connivencia pueden fallar antes de que un evento llegue al registro.

Etherisc y ACRE Africa documentaron el uso de contratos inteligentes para seguro agrícola indexado en Kenia. La Ethereum Foundation describió en 2021 cómo el proyecto conectaba registro de agricultores, datos meteorológicos y pagos. Es un caso de implementación en un contexto específico. Evaluar su transferencia a otro mercado exige revisar distribución, calidad del índice, costes y acceso efectivo al dinero, sin asumir porcentajes universales de ahorro.

La adopción institucional, sin embargo, continúa en una fase temprana frente a tecnologías como analítica, IA o IoT. EIOPA señala que muchos desarrollos europeos siguen siendo pruebas de concepto o despliegues pequeños. La evidencia disponible demuestra viabilidad en procesos concretos, no una sustitución general de los sistemas de pólizas y siniestros.

No todos los seguros se comportan igual. Un retraso de vuelo o un índice meteorológico pueden verificarse con una fuente acordada. Un daño de automóvil requiere relacionar accidente, piezas, reparación y posible responsabilidad. Una cobertura de salud incorpora necesidad médica y datos especialmente protegidos. Vida y responsabilidad civil pueden depender de documentación y decisiones jurídicas prolongadas.

La programación debe situarse en el punto correcto. En un producto paramétrico puede calcular toda la prestación; en un seguro indemnizatorio quizá solo valide póliza, recopile evidencia y distribuya un pago ya aprobado. En reaseguro puede calcular participaciones aceptadas sin decidir una cobertura controvertida. Presentar todos estos procesos como pago automático oculta la diferencia entre evento, pérdida y obligación.

La tabla de decisión combina objetividad del disparador, calidad de la fuente, posibilidad de corrección, impacto para el cliente y necesidad de juicio. Cuanto mayor sea la ambigüedad, más útil es blockchain como pista compartida y menos apropiado como ejecutor irreversible. La madurez no consiste en eliminar personas, sino en reservar su intervención para excepciones que realmente requieren criterio.

Un smart contract puede determinar que existe una obligación y enviar una instrucción a un sistema de pagos convencional. También puede transferir dinero tokenizado si el producto, la entidad y la jurisdicción lo permiten. En el primer modelo, la red y el banco reconcilian el resultado. En el segundo, el activo incorpora riesgo de emisor, custodia, liquidez y reembolso.

Las primas y prestaciones están sujetas a divisa, impuestos, sanciones, prevención de blanqueo y protección del cliente. Una stablecoin no convierte automáticamente un pago internacional en dinero sin riesgo ni autoriza a la aseguradora a operar fuera de su licencia. El beneficiario puede necesitar moneda local y una vía de reclamación aunque el movimiento on-chain sea final.

La liquidación atómica resulta más relevante entre entidades que intercambian posiciones y efectivo, por ejemplo en determinados flujos de reaseguro. Para el cliente minorista suelen pesar más la disponibilidad, reversión ante error, coste y facilidad de acceso. La capa de pagos se elige después de diseñar el producto asegurador, no al revés.

Los usos con mayor fundamento comparten reglas objetivas, datos gobernados y varios participantes que necesitan comprobar el mismo estado. Seguros paramétricos, reaseguro, certificados de cobertura, subrogación y reclamaciones sencillas pueden beneficiarse. Los siniestros complejos siguen requiriendo investigación, peritación, atención al asegurado y una vía clara para corregir o recurrir decisiones.

Una arquitectura de producción conecta administración de pólizas, siniestros, pagos, identidad, proveedores y reporting. La DLT guarda estados o pruebas que varias partes deben verificar. Documentos, datos de salud, telemática y expedientes completos permanecen normalmente off-chain bajo permisos, retención y rectificación.

Los oracles requieren redundancia, control de cambios y trazabilidad. Debe conocerse quién publica, con qué frecuencia, qué ocurre ante discrepancia y si el dato puede revisarse después. Un contrato no debería ejecutar una obligación material basándose en una API sin procedimiento de contingencia. La fuente forma parte del producto y de su riesgo operativo.

Claves y wallets tampoco pueden bloquear derechos. El cliente necesita recuperación, representación y canales alternativos. En redes entre entidades, la gobernanza asigna alta de nodos, versiones, respuesta a incidentes, correcciones y salida. Distribuir validación no elimina al responsable del tratamiento ni a la aseguradora obligada frente al tomador.

Un piloto comienza con una regla objetiva, datos históricos suficientes y un grupo claro de asegurados. Compara tiempo de pago, coste de tramitación, tasa de error, riesgo de base y reclamaciones frente al proceso actual. También simula fuente ausente, dato corregido, sanción, fraude y caída tecnológica.

En reaseguro o procesos compartidos, importan conciliaciones eliminadas, velocidad de cierre, completitud y tiempo de incorporación de socios. Si la red exige duplicar todos los registros o las disputas siguen resolviéndose fuera sin reflejarse, el estado on-chain pierde autoridad operativa.

Escalar exige gobierno de producto, modelo actuarial, distribución, soporte y capital, no solo contratos auditados. Blockchain merece permanecer cuando reduce una fricción multilateral o permite un producto que no era viable. Si una API con firma y un operador reconocido ofrece el mismo resultado, suele ser una opción más sencilla.

En un seguro paramétrico, la prueba debe comparar el disparador con pérdidas conocidas para entender el riesgo de base. Puede haber daño sin activación o activación sin un daño equivalente. El objetivo no es eliminar por software esa diferencia, sino medirla y explicarla antes de contratar. El expediente debe conservar la fuente del índice, su versión y las reglas para datos ausentes o corregidos. También debe probarse qué ocurre cuando el proveedor de información deja de responder durante el periodo cubierto.

La ejecución necesita confirmar que existe cobertura vigente, que la prima se ha tratado según el contrato y que el pago no se ha realizado ya. Después conecta el cálculo con fondos disponibles y un beneficiario verificado. Una instrucción repetida no debe generar otra indemnización. Si el pago falla, el asegurado conserva una vía de información y reclamación, y la obligación pendiente permanece visible. La rapidez se mide hasta la disponibilidad del dinero, incluyendo controles y excepciones, no solo hasta que el contrato emite un evento.

La brecha de protección de Swiss Re es una estimación modelizada de necesidades de cobertura, distinta de sumar las pérdidas no aseguradas observadas en un año. Del mismo modo, el escenario de automatización de McKinsey incluye tecnologías y cambios operativos más amplios que blockchain. Esas referencias sitúan el problema asegurador, pero el proyecto debe demostrar su propia mejora en cobertura, gestión y coste. La comparación ha de mantener la misma población asegurada y condiciones de póliza para resultar interpretable.

MiCA regula criptoactivos, no productos de seguro. Una aseguradora que adopta blockchain continúa sujeta al marco sectorial, incluida Solvencia II, y a las obligaciones de resiliencia digital de DORA bajo supervisión competente, además de protección de datos y conducta. MiCA entra en juego si la estructura incorpora un criptoactivo regulado.

MiCA solo entra en juego si la solución usa un cripto-activo, por ejemplo una stablecoin para pagar las primas o las indemnizaciones. Distinguir el producto asegurador del vehículo tecnológico, y aplicar a cada uno su norma, es el punto de partida de cualquier proyecto.

La automatización no reduce las obligaciones de información, idoneidad del producto, gestión de reclamaciones ni supervisión de proveedores. En la Unión Europea, DORA incluye a aseguradoras y reaseguradoras dentro de su marco de riesgo TIC y resiliencia. Operar nodos o depender de oracles y custodios exige inventario, contratos, pruebas, continuidad e incident reporting según corresponda.

Un producto paramétrico debe seguir siendo un seguro correctamente diseñado y distribuido. El cliente necesita comprender el índice y el riesgo de base. Si además se tokeniza una participación económica, se crea una mutualidad descentralizada o se emplean activos digitales, pueden añadirse normas de valores, criptoactivos, pagos y prevención de blanqueo. La clasificación se hace por funciones y derechos, no por llamar al código insurtech.

La mayoría de clientes no puede auditar un contrato inteligente, y aunque pudiera hacerlo, el código no contiene necesariamente toda la póliza. Condiciones, exclusiones, definición del índice, fuentes, comisiones y procedimiento de reclamación deben comunicarse en lenguaje comprensible antes de contratar. Una interfaz que oculta blockchain no puede ocultar las consecuencias del producto.

Toda decisión automatizada con efecto significativo necesita trazabilidad y supervisión conforme al marco aplicable. El asegurado debe saber qué dato activó o impidió la prestación, cómo corregirlo y quién responde. Si el oracle modifica una observación o dos fuentes discrepan, la plataforma debe conservar versiones y suspender o revisar la ejecución cuando proceda.

La inclusión financiera tampoco se presume. Un pago móvil rápido puede ser valioso en agricultura o catástrofes, pero el producto debe considerar conectividad, alfabetización, custodia, comisiones y conversión a moneda utilizable. La eficiencia solo es real si el cliente recibe una cobertura adecuada y puede ejercer sus derechos sin dominar wallets o redes.

La tecnología puede hacer una regla más rápida y auditable, pero no convierte una mala cobertura, un índice débil o una decisión injusta en un buen producto. Tampoco determina causalidad, valora daños complejos, evita una identidad falsa o garantiza que el dato del oráculo represente la pérdida real sufrida por el asegurado.

Estos conceptos distinguen cobertura contractual, evento medido, daño real, fuente de datos y mecanismo de pago. También separan automatización de decisión, paramétrico de indemnizatorio y registro compartido de dinero tokenizado. Esa precisión permite valorar una propuesta sin asumir que un smart contract sustituye la póliza, el perito o la supervisión aseguradora.