Tarificación con fórmulas: del Excel actuarial a producción

En casi todas las compañías, la tarifa nace en una planilla. Es la herramienta que el equipo actuarial domina, permite iterar rápido y deja ver cada paso del cálculo. El problema aparece cuando esa planilla tiene que convertirse en el precio que ve un cliente en una web, en un broker o en el checkout de un partner.

Lo habitual es que alguien de IT reciba el archivo, lo interprete y reescriba la lógica en código. A partir de ese momento hay dos tarifas: la de la planilla y la de producción. Cada ajuste obliga a repetir la traducción, y cada traducción es una oportunidad de que las dos versiones dejen de coincidir.

Fórmulas que se leen como la planilla

La alternativa es expresar la tarifa directamente como fórmulas que la plataforma ejecuta, con una sintaxis lo bastante simple como para que un actuario la lea y la valide sin depender de un desarrollador. Algo como:

suma_asegurada * tasa_base * factor_edad

Cada cobertura tiene su fórmula, construida a partir de las variables del producto. Si la planilla dice que la prima de robo es la suma asegurada por una tasa que depende de la zona, la fórmula dice exactamente eso. No hay una capa intermedia que interpretar.

Esto tiene un efecto secundario importante: la tarifa pasa a ser auditable. Cualquiera con acceso puede ver cómo se calcula cada cobertura, y una revisión deja de requerir leer código.

Tablas de búsqueda en lugar de condiciones anidadas

Gran parte de una tarifa no son fórmulas, sino tablas: tasas por zona, factores por rango de edad, valores por plan. En una planilla se resuelven con búsquedas entre hojas. Traducidas a código, suelen terminar como largas cadenas de condiciones difíciles de mantener.

Es mejor mantenerlas como tablas y consultarlas desde la fórmula. En quore, una función de búsqueda toma el nombre de la tabla, la variable que define la fila y la columna que quieres leer:

suma_asegurada * lookup(tasas_zona, zona, 'robo')

Cuando la tasa de una zona cambia, actualizas la tabla y la fórmula sigue igual. Si varias líneas de producto comparten la misma tabla, por ejemplo un listado de zonas o un tarifario de vehículos, puedes guardarla una sola vez en una biblioteca compartida y usarla desde todos los productos.

Probar antes de publicar

Una fórmula legible no garantiza una fórmula correcta. Antes de que una tarifa llegue a producción, conviene probarla con casos concretos y comparar el resultado con el que da la planilla.

Un simulador sirve justamente para eso: cargas los datos de un cliente de ejemplo y ves el detalle completo del cálculo, cobertura por cobertura, con impuestos y cuotas. La práctica que mejor funciona es armar un set de casos de referencia junto con el área actuarial:

• Casos típicos, que representan la mayoría de las cotizaciones.
• Casos en los extremos de cada rango: edad mínima y máxima, suma asegurada más baja y más alta.
• Una combinación por cada fila relevante de las tablas de búsqueda.
• Casos que deberían rechazarse, para confirmar que las validaciones funcionan.

Si todos coinciden con la planilla, la tarifa está lista. Si alguno no coincide, encontraste el error antes que el cliente.

Borradores y versiones publicadas

Una tarifa en producción no se edita en caliente. Los cambios se hacen sobre un borrador, se prueban en el simulador y solo pasan a producción cuando alguien publica una nueva versión. Hasta ese momento, los canales siguen cotizando con la versión vigente.

Este esquema resuelve dos problemas a la vez. Permite trabajar en un ajuste de tarifa durante días sin afectar la operación, y deja trazabilidad: cada póliza emitida queda asociada a la versión con la que se cotizó, así que siempre puedes reconstruir por qué un cliente pagó lo que pagó.

Prima y premio no son lo mismo

Un error frecuente al llevar una tarifa a producción es mezclar conceptos que la planilla tiene bien separados. Conviene fijar el vocabulario desde el principio:

• Prima: el precio técnico neto del riesgo, el resultado de las fórmulas de cada cobertura.
• Premio: lo que efectivamente paga el cliente, es decir, la prima más impuestos, recargos y otros cargos.

Expresiones como "prima total" generan confusión, porque no queda claro si incluyen impuestos o no. Si las pantallas, los documentos y las integraciones distinguen siempre entre prima y premio, el cliente entiende qué paga y el área técnica sabe qué está midiendo. Por eso los impuestos y recargos conviene definirlos aparte, cada uno con su base de cálculo, y no mezclados dentro de la fórmula de la cobertura.

Llevar la tarifa del Excel a producción no tiene por qué ser una traducción. Si la fórmula es la tarifa, el actuario la puede leer, el simulador la puede probar y la versión publicada es exactamente lo que se aprobó.