S2aaS - Informes de Solvencia II en la nube

En el anterior artículo se habló de la posibilidad del uso de la "nube" para que una entidad aseguradora se prepare para la entrada en vigor de las normativas de Solvencia II, de obligado cumplimiento a partir de enero de 2014.

En él comentamos la situación de las compañías a día de hoy, respecto a la necesidad de disponer de modelos internos de cuantificación de los riesgos –a través del Pilar I, pero también a través del Pilar II, bajo el concepto ORSA– que han de proporcionar una visión de la situación futura de la compañía, en función de los riesgos a que está expuesta.

Asimismo, y como se explicó en el artículo "Exprésalo en XBRL" del pasado mes de julio, se ha elegido la taxonomía XBRL, ya utilizada en el sector financiero, como el estándar de presentación de informes para Solvencia II. Las entidades aseguradoras, por tanto, deben ser capaces de presentar sus informes al Regulador –Pilar II– y al Mercado –Pilar III– bajo dicho estándar.

Todo lo anterior refuerza aún más la posibilidad de centralizar la generación de los informes en la nube, sobre todo para aquellas compañías a las que les resulta complicado invertir en la creación de los equipos de trabajo y la infraestructura tecnológica necesaria para cubrir con los tres pilares de Solvencia II:

• Herramientas estadísticas para generar los modelos internos, junto con un equipo para generarlos.
• Desarrollos internos e implantación de motores de cálculo para diseñar y aplicar los modelos en todo el proceso operativo de la compañía.
• Procesos para extraer los datos de sus fuentes y transformarlos a los diferentes formatos necesarios:
• Herramientas para mantener los metadatos y los mappings entre las diferentes fuentes y destinos.
• Herramientas ETL para:
• Cargar las herramientas estadísticas.
• Cargar el repositorio desde donde se generarán los informes regulatorios en
XBRL.
• Gestión de los posibles cambios a realizar en los informes a presentar al Regulador, y más considerando que no es un proceso maduro.

¿Es necesaria una inversión interna de estas características para cumplir con la regulación?

Lógicamente esto tiene unas consideraciones, tales como tamaño de la empresa y el que ya dispongan de herramientas y procesos que den soporte a esta nueva necesidad; para muchas compañías, y bajo nuestro punto de vista, no es necesario. Teniendo en cuenta que muchos procesos no se van a ejecutar diariamente (reporting al Regulador, por ejemplo, o incluso la revisión periódica de los modelos internos), la idea del "pago por uso" representa un ahorro de costes considerable. Si a ello le añadimos el ahorro en costes de licencia, hardware, etc. la externalización empieza a ser una opción a considerar.

Desde Insare proponemos el siguiente esquema:

Cada compañía se conecta y envía los datos periódicamente, en el formato utilizado habitualmente para extraer la información de los sistemas transaccionales, a una ubicación nombrada Staging (es importante preservar esa área para posibles auditorias futuras).

A través del mapa creado entre la compañía e Insare, el cual indica cuáles son los datos de origen para cada uno de los atributos XBRL de destino, se ejecuta el proceso de transformación y generación de informes.

En ese momento la Entidad Reguladora dispondrá de la información, en el formato deseado, de cada una de las compañías.

A raíz de los comentarios recibidos del artículo anterior, hemos detectado dos preocupaciones relativas a la aplicación de un modelo de estas características:

• Posibles problemas con la seguridad de la información.
• La consideración de los procesos relacionados con la modelización, la revisión y el reporting como estratégicos para las compañías y, por tanto, no externalizables.

Sobre el primer punto, hay que tener en cuenta que, por un lado, la información no contiene datos personales que puedan ser motivo de incumplimiento de la LOPD y, por otro lado, todo Cloud privado no deja de ser una extensión de la infraestructura de la compañía, es decir, la seguridad no viene por el hecho de que los servidores de información estén físicamente en la sede de la compañía o en cualquier otro lugar habilitado para tal fin.

Sobre el segundo punto, y para establecer en cierta medida los que es estratégico y lo que no lo es respecto al control interno y la gestión de riesgos, basta con remitirse a los artículos 110 y 110bis del ROSSP, donde se establece todo aquello que es responsabilidad del Consejo de Administración (y, por tanto, estratégico y no externalizable)

• Establecer, mantener y mejorar los procedimientos de control interno.
• Establecer el marco de gestión de riesgos, que deberá incluir el mapa de riesgos y la definición del "apetito de riesgo" de la compañía (es decir, el riesgo que se está dispuesto a asumir, en cada tipología de riesgo definida en el mapa)

Por tanto, deberíamos preguntarnos lo siguiente:

• ¿Es estratégico que una compañía pequeña o mediana tenga en nómina a un especialista en XBRL para que le diseñe y mantenga el reporting trimestral? Al ser XBRL un estándar, ¿No habrá ya en el mercado profesionales cualificados que puedan hacer las tareas de una forma más eficaz?
• ¿Es estratégico que una entidad mediana tenga en propiedad licencias de herramientas de modelización y análisis de datos que revisará una vez al año? ¿No sería más eficiente que alguien que ya dispone de las licencias hiciera el trabajo, por supuesto bajo la supervisión de la entidad?

Por supuesto, no se trata de que todas las compañías que ya tengan estos procesos en marcha, y hayan decidido recorrer el camino de Solvencia II con medios propios, deban externalizar los procesos referidos. Pero aquellas entidades que estén empezando, cuya dimensión no les permita disponer de herramientas propias, o que simplemente crean que hay valor en la reducción de costes, deberían contemplar la externalización de dichos procesos como una opción a estudiar. Además, en el caso de entidades que todavía no hayan iniciado el proceso de modelización y preparación de informes, puede ser una buena opción externalizar los servicios de análisis de datos y creación de modelos, así como el mapping entre los datos a reportar, extraídos de los sistemas operacionales, al formato XBRL.