La tecnología y los seguros de Personas

Gustavo Bresba, Director de DC Sistemas, analizó el soporte tecnológico que requieren las aseguradoras para los Seguros de Personas, y abogó por la implementación de un protocolo estandarizado de comunicación que reduzca la posibilidad de error en la carga de datos.

Para su análisis, el profesional dividió a los productos en categorías, detallando el nivel de complejidad de cada caso, siempre desde el punto de vista del soporte informático que requieren dichas operaciones.

En primera instancia, se refirió a los seguros de vida masivos, e indicó las diferencias entre los de tipo individual y colectivo. Bresba dividió estos últimos en privados voluntarios o obligatorios vinculados a obligaciones patronales.

Bresba explicó: “Respecto a los individuales, sea individual o grupo familiar, su  venta es individual. Muchas veces interviene el productor que sale a vender de forma directa, o entra a una empresa y vende desde ahí.

A grandes rasgos, tiene la misma complejidad que las pólizas de combinado familiar. Suelen venderse ‘enlatados’, y circunscriptos a un negocio puntual”.

Distinguió cuatro posibles situaciones de emisión de póliza llevadas a cabo por un productor o vendedor: “Que el vendedor venda y te envíe los datos para una carga manual.

Que el vendedor entre a la web de la compañía, cotice y gestione el alta en la web de la compañía.

Que el vendedor o productor tenga su propio sistema y se comunique con la compañía para cotizar y emitir vía API.

O que el vendedor mande a la compañía listados -en excel o formato .txt- para que la misma lo importe y genere la póliza”.

Además, aseguró: “En cualquiera de estos casos, hay una balanza de poderes. ¿Quién se adapta a quién? Si una compañía pequeña quiere trabajar con un bróker grande, probablemente tenga que adaptarse al formato de los archivos, a las APIs o a lo que sea que el bróker tenga.

Si el productor es chico y sale a vender dentro de una compañía, la compañía puede poner condiciones de algún modo”.

Colectivos Voluntarios

Prosiguió con los seguros de vida colectivos voluntarios, y para ello puso como ejemplo  una compañía que contrata un seguro de vida para todos sus empleados, o una empresa de tarjeta de crédito que contrata una póliza de saldo deudor para sus clientes. “De vuelta surge la situación de la balanza de poderes -manifestó-. Normalmente, la compañía define el formato a trabajar.

En la mayoría de los casos, es en excel, con archivos en algún formato de lista, porque se van actualizando. Todos los meses se pasa la nómina consolidada y sobre ella, la compañía da de alta, baja y refactura, cíclicamente.

Con las pólizas colectivas también existen casos donde el contratante no da nombres y va avisando. La carga es bastante manual, porque es difícil que los datos vengan ‘limpios’. Por lo general, llegan datos que no existen, documentos duplicados, etc. En Vida es crucial el dato de la fecha de nacimiento, porque la mayoría de las tarifas de vida van por edad. Sin ese dato, no se puede calcular la tasa correcta de la persona.

A veces tiene consecuencias, porque te los mandan mal y vos creaste toda una base que no era, y tenes que rectificar. Por eso, hay un trabajo manual importante para depurar esos datos y poder importarlos. Es bastante laborioso, no está muy automatizado ni tecnologizado”.

Colectivos Obligatorios

Por último, en cuanto a los seguros colectivos obligatorios, indicó que la situación es similar. La diferencia es que quien se adapta es la compañía. Bresba aseguró que difícilmente un municipio, por caso, acceda a enviar los datos de la manera en que la compañía necesita, porque tienen nóminas muy activas que muchos quieren captar.

Siendo así, la compañía debe adaptarse “desarrollando una importación de nómina para el formato que mandan”, o asignando a personas para que adapten lo que envían en un archivo que el sistema soporte. Este trabajo manual parece inevitable, pero hay que considerar que implica un margen de error humano.

A continuación, señaló: “Mandar un archivo ida y vuelta nunca es perfecto y siempre está sujeto a que alguien se olvide, cometa errores, ponga un archivo del mes pasado, etcétera”.

En este panorama,  el sector de vida individual sería el más tecnologizado, al vender seguros por una app, por una red o por medio de APIs.

Podría haber una API de nómina de empleados, pero nunca ocurrió. Siempre te encontrás con entidades muy rústicas. Siguen apostando a ‘que va, que viene’, y cada uno tiene su librito”.

Front end y back end

Luego, el profesional mencionó las particularidades de cada punto del sistema, donde back end sería el sistema de la compañía, y front end, lo que ve el usuario final.

En cuanto al front end, afirmó que usar la web de la compañía es lo mismo que hacerlo en el sistema core. El intermediario ve lo mismo en ambos sistemas y los datos disponibles, campos que carga, etc., tienen la misma validez porque van a la misma base de datos. Del mismo modo ocurre con la API.

“El problema está cuando el front end es un excel, ya que en este no se aplica ningún control. No tiene validaciones que obligue a cargar con datos veraces y pertinentes.

Se barajó una solución mediante la habilitación de una consulta con RENAPER, sin embargo presenta varias dificultades”, señaló. “Implementarla en la nómina masiva es muy costoso en términos de procesamiento. Por otro lado, la compañía no podría obviar, por decisión unilateral, los datos que el contratante envío, sólo porque no coincide con lo que responde AFIP o RENAPER. Y por último, aún sin los inconvenientes anteriores, es el contratante quien carga el excel en su pc, por lo que el control recién puede realizarse cuando llega ese excel enviado. Para validar desde el origen, el contratante debería tener automatizado en su pc el control que tiene la compañía”.

Nuevamente, indicó un ejemplo: “Viene una nómina de 5.000 personas y 10 no van. Podés aceptar 4.990 o rebotar los 5.000. Pero ya es un ida y vuelta manual. No hay forma de automatizar eso, excepto que lo hagan en la página web. Si entran al portal web de la compañía y lo tratan de cargar, ahí sí el sistema controla la existencia o no de los datos. Sin embargo, esto sólo funcionaría con seguros individuales o colectivos de pocas personas, ya que AFIP o RENAPER no validarían un colectivo de cinco mil personas”.

Con miras al futuro

En vista de lo expresado anteriormente, Bresba concluyó expresando su deseo de crear un protocolo consensuado y estándar de intercambio de información: “Los datos de la nómina de vida son diez datos, pero hay que ordenar, poner, quitar cada uno.

Si de a poco, todos empiezan a tener un formato estandarizado, los sistemas van a controlar siguiendo ese estándar. La carga de datos va a ser controlada. Vas a tener 10 ó 15 importaciones todas iguales. Y eso se aplica a Vida, Cobranzas, Siniestro, todo”.

Ver más