PREGUNTAS Y RESPUESTAS FRECUENTES RELATIVAS A LA DOCUMENTACIÓN CUANTITATIVA ANUAL FASE PREPARATORIA SOLVENCIA II

Transcripción

1 PREGUNTAS Y RESPUESTAS FRECUENTES RELATIVAS A LA DOCUMENTACIÓN CUANTITATIVA ANUAL FASE PREPARATORIA SOLVENCIA II 1

2 Tabla de contenido I.- CUESTIONES RELATIVAS A LA INFORMACIÓN ANUAL INDIVIDUAL: INTRODUCCIÓN MODELO 2: MODELO 6 y 8: MODELO MODELO MODELO 25 Y ANUAL GRUPOS

3 I.- CUESTIONES RELATIVAS A LA INFORMACIÓN ANUAL INDIVIDUAL: 1. INTRODUCCIÓN P: Podrían por favor indicarnos en qué formato vamos a poder reportar los QRTs en fase definitiva?. En fase preparatoria ya sabemos que serán en formato Access, al igual que ahora la DEC. Pero nos gustaría que nos confirmaran si definitivamente no vamos a reportar en XBRL los QRTs definitivos. R: La aplicación de captura desarrollada al efecto por la DGSFP en fase preparatoria permite la importación de datos en formato ACCESS, que será implementada de forma similar para la fase definitiva. No obstante, en la medida que los recursos lo permitan, el módulo de importación, se irá ampliando a otros formatos (incluido el XBRL) P: Aparecen dos datachecks (VTO_DS1201_01t_9_1 y VTO_DS1701_04t_2_1) cuya descripción es Anidada. Nos podéis indicar qué validación se debe realizar? R: En general, con el término anidadas nos referimos a validaciones que se activan en función del cumplimiento de determinadas condiciones anteriores. En este caso si el resultado de la suma de los campos del pasivo del modelo S L6B+L7+L10<>0 debe ser cumplimentado el modelo 12 de provisiones técnicas, y de igual modo si la suma de L1+L4<>0, el modelo 17 para no vida debe ser cumplimentado. P: Analizándolo, parece que estén refiriéndose a comprobaciones diferentes. o En la primera parece que hayas de tomar todos los importes de derivados y sumarlos. Después tomarías este número si es positivo. o En la segunda parece que hayas de tomar únicamente los importes positivos y los sumes. R: Como resultado de la prueba piloto, se ha constatado inconsistencias en esta validaciones que han sido corregidas en la aplicación definitiva. Lo que deben evaluar ambas es la relación que existe entre el valor declarado en balance en relación al importe de la suma del importe de solvencia II de todos y cada uno de los derivados declarados individualmente. P: Qué versión de Access está esperando la DGSFP (2010, 2007, 2003, 2000)? Lo queremos saber para evitar posibles incompatibilidades entre versiones. La versión esperada es Access P: Existen algunas discrepancias entre el ACCESS de la DGSFP, el Modelo de Datos de la DGSFP y las plantillas Excel de EIOPA. Adjuntamos Excel con la relación de dichas celdas de cada QRT. R: Examinados todos los casos planteados, entendemos que todas las discrepancias manifestadas están implementadas y explicadas en el documento denominado Diccionario de datos que en su primera parte explica el proceso de equivalencias desarrollado por la DGSFP a la hora de trasponer los distintos QRT s en la aplicación diseñada.

4 P: En la Resolución Aparecen las QRTs correspondientes a RFF, en cambio en el ACCESS no vemos ningún modelo. Deben informarse? R: La respuesta es sí. La explicación es que en la prueba piloto realizada, como se indicó en el correo de presentación, no se incluía el módulo referente a los RFF, que sí será implementado en la aplicación definitiva de la fase preparatoria. P: Existirá una aplicación de captura de para los modelos anuales?, en caso de ser así, Podrían indicarnos fechas aproximadas de publicación? R: Si, todos los requerimientos de información cuantitativa van a ser reportados mediante aplicaciones específicas desarrolladas al efecto. La fecha estimada para la puesta a disposición de la aplicación será a finales de abril de P: Cómo se trata a nivel de reporting la utilización de parámetros específicos en los cálculos de requerimiento de capital? R: En la fase preparatoria no aplica, puesto que para su uso primero deben ser aprobados por la autoridad supervisora competente. Pero no hay que olvidar, que se enmarcan dentro del tipo de modelo interno Formula estándar (x3) En segundo lugar, en fase definitiva tienen un tratamiento determinado, que empieza en una declaración previa en el modelo de información básica y continua con una descripción pormenorizada de cada uno de ellos en sus respectivos módulos de riesgo usados. P: Tengo una pequeña incidencia al cargar un formulario. Si al meter el dato, (comprobado en varias filas), doy Enter después de introducido, el valor desaparece. Y al pasar con tabulador, aparece. Es como que con Enter no pasa de registro. R: Este es el comportamiento estándar de la aplicación. La tecla Enter se utiliza para insertar nuevas líneas cuando sea necesario. Para moverse de un campo a otro, debe utilizarse la tecla tabulador. 4 P: En el 'Anexo I. Relación de Tablas Auxiliares' del 'MODELO DE DATOS DEC ANUAL INDIVIDUAL FASE PREPARATORIA SOLVENCIA II' se indica que el campo A6 de la Tabla DS0102_01t se rellena con alguno de los valores de la tabla auxiliar "Aux_ES_Escenarios" de la DGSFP con filtro 3. Y en el Modelo, también se indica la la siguiente validación: VCI_DS0102_01t_A6_1 - A6(Tipo de modelo interno) debe existir en la tabla "Aux_ES_Escenarios" cuando filtro sea igual a 3 Sin embargo, en la tabla "Aux_ES_Escenarios" de la versión de 09/12/2014 del Access no se tiene el filtro 3. En principio entendemos que se debería realizar con el filtro 1. Podrían confirmarnos que es así? R: Este problema es debido a la diferencia entre las versiones utilizadas para la documentación y la base de datos. Deben compararse siempre documentos con la misma versión.

5 P: En general el dato que debemos completar en la base de datos, cuando el campo hace referencia a una tabla auxiliar, entendemos que es el dato que en la tabla aparece como código (normalmente un número o un código ej. x2). Es así, no? Por ejemplo, en el campo A15_S2 (categoría CIC) dice que debe ser en mayúsculas. Eso significa que la base de datos debe completarse con el campo de Descripción? R: No, el valor a trasladar al campo es el correspondiente a la columna de Codigo, cuando se hace referencia a mayúsculas/minúsculas se refiere a la parte alfabética del código en el caso de campos alfanuméricos. Ponemos un ejemplo de la tabla auxiliar Subcategoría CIC: Instrucciones DGSFP Codigo Descripcion Filtro Orden 1 Deuda pública 4 1 En este caso, cuando los activos sean Deuda Pública, en la base de datos debemos completar 1 o DEUDA PUBLICA R: En concreto 1 P: Tabla DS0102_1t: Información Básica: o Campo A1: código identificación de la entidad: completar según la tabla de Códigos DGSFP. En diccionario DGSFP dice que se complete en formato Uri. Ibercaja Vida tiene código LEI. Significa que debemos completar este campo con el Comentario de la tabla de Códigos DGS que corresponde a la opción Código LEI (ej. )? R: Este campo debe ser interpretado conjuntamente con el A11_S, así pues: - CAMPOS A11_S y A1_S En la documentación técnica, EIOPA define una celda combinada A11/A1 de tipo clave ( *key* ) cuyo contenido será de tipo URI ( siendo en origen el campo A11 una lista de tipos de códigos de identificación, y el campo A1 el valor de dicho código. En las Reglas de Cumplimentación de EIOPA se ha simplificado el patrón en lugar de URI por un prefijo del tipo de código. Para esta celda combinada, la aplicación presenta un desplegable con los tipos de códigos de entidad (LEI, Pre-LEI, Código Local), guardando este valor del combo en el campo adicional A11_S y un campo de texto con el valor del código, guardado en el campo adicional A1_S. El campo con la URI requerida por EIOPA se mantiene como A1. 5

6 Por tanto se define un campo en la tabla de datos que será el que enlace con una tabla auxiliar (Campo tabla auxiliar) para guardar el tipo de código de identificación, otro campo que contendrá el valor especifico del código (Campo código) y el campo que tendrá la URI concatenando los dos anteriores (Campo Prefijo de las reglas de cumplimentación de EIOPA). Campo tabla auxiliar ( A11_S ). Obtendrá sus valores de la tabla auxiliar de tipos Aux_CD_Codigos_DGS con el filtro de jerarquía 3, en el orden establecido en la tabla. El campo comentario tomará la parte inicial de la URI a concatenar. Aux_CD_Codigos_DGS Código Descripción Filtro Orden Comentario x1 LEI 3 1 LEI/ x2 Pre-LEI 3 2 Pre-LEI/ x9 Código Local 3 3 SC/ Campo código ( A1_S ). Contendrá el valor del código. Será la parte final de la URI a concatenar. Campo concatenado ( A1 ). Para conformar la *key* y el dato de la plantilla de EIOPA se obtiene el contenido del valor de la columna Comentario en la tabla Aux_CD_Codigos_DGS con el filtro de jerarquía 3 que corresponde a la opción elegida en el campo A11_S, concatenándolo al contenido de la columna A1_S. Ejemplo: Para la entidad C9999 de tipo Código Local habría que reportar en estos campos la siguiente información: - Campo tabla auxiliar ( A11_S ) = x9.(comentario= SC/ ) - Campo código ( A1_S ) = C Campo concatenado ( A1 ) = SC/C9999 En la base de datos la información se almacenará de la siguiente forma: [...] A11_S [...] A1_S A1 [...] [...] x9 [...] C9999 SC/C9999 [...] 6

7 P: En todos los modelos que se refieren a nº de fondo Ring Fence Fund Qué numeración debemos usar? 1 y 2 por ejemplo? R: El número de Fondo de Disponibilidad Limitada es asignado localmente por la propia entidad por lo que sería admisible cualquiera, incluso los del ejemplo propuesto. 7

8 2. MODELO 2: P: En la tabla DS0202_04t se puede meter el EUR, que corresponde realmente a otra tabla. La aplicación lo que creo que hace es que no muestra el EUR en el formulario, pero si lo tiene en la tabla y lo suma. Con lo cual se duplica. Esto ocurre haciendo la carga a través de la BD, me imagino que el EUR no está en el desplegable de monedas y cargando a mano este error no se puede producir. R: Efectivamente, teóricamente desde el módulo de importación, la tabla DS0202_04t puede en el campo A1_S1 (divisa) tomar el EUR como moneda, pero no si se introducen los datos manualmente, por lo que con la lógica de cumplimentación se duplica en la tabla de TOTAL. Pero, en la práctica no debe pasar los controles implementados de coincidencias entre modelos aplicables entre el modelo S (balance) y el S (monedas), que afectan a los totales. La aplicación incluye una validación sobre el campo A1_S1 de forma que éste no puede tomar el valor EUR; dicha validación se muestra cuando se utiliza la opción Validar datos. El documento que recoge estas validaciones está siendo objeto de revisión por lo que no ha podido ser subido dentro de la documentación de la prueba piloto anual, pero en breve esperamos tenerlo terminado (y al igual que se hizo en la prueba trimestral) poder incorporarlo a la aplicación. P: Respecto al modelo del balance por monedas. DS0202, si en lugar de tener 4 tablas, una para Euro, otra para otras monedas, otra para resto y una de Total, se pudiera cargar todo en una única tabla, nos sería de gran ayuda. R: Esto supone un cambio importante en la aplicación por lo que en principio no cabe esta posibilidad. En cualquier caso, cabe la posibilidad de generar los datos de la entidad en una única tabla y luego separarlas directamente en Access ejecutando las correspondientes consultas. P: La primera partida de Provisiones técnicas no hace la suma en el formulario pero en la impresión aparece como una partida que no forma parte del balance contable. Tiene que ser así la presentación?. 8

9 R: le informamos que dicha partida solo forma parte del balance contable y no del de solvencia II, como se indica en los log s publicados: LS0 Provisiones técnicas - seguros distintos del seguro de vida Estas celdas consisten en líneas de puntos. O bien puede dividir sus provisiones técnicas entre seguros de vida y seguros distintos del seguro de vida y sus correspondientes actividades de seguros de salud asociadas, o bien no puede efectuar tal división y consigna directamente en la celda LS0 el valor total correcto. P: Seguimos teniendo problemas con el modelo 2, en la parte del pasivo de valor contable. Nos salen unos errores que no entendemos, ya que no hemos reportado nada en el pasivo de valor de solvencia II. Adjunto pantallazos. 9

10 10

11 R: El problema es que en el pasivo contable no está rellenando las partidas padre Provisiones técnicas seguros distintos del seguro de vida [LS0_S] y Provisiones técnicas seguros de vida (excluidos index-linked y unit-linked ) [L6F_S] pero sí introduciendo datos en algunos de las partidas hijas Provisiones técnicas seguros distintos del seguro de vida (Excluidos los de enfermedad) (L1_S) y Provisiones técnicas seguros de vida (excluidos los de salud y los index-linked y unit-linked ) [L7_S]. Por lo que tiene que revisar los datos y si las partidas hijas indicadas tienen valor distinto de cero, las partidas padres (que en el caso de tener valor las hijas, estas deben ser la suma de las mismas) deben coincidir. Es decir, cuando proceda a cumplimentar dichas partidas padre (totales) conforme a las indicaciones propuestas. 3. MODELO 6 y 8: P: Actualmente el campo código ID de los modelos 6 y 8 (anual y trimestral) solo recogen los tipos ISIN, Cusip, Bloomberg Ticker, Reuters RIC, Otros internacionalmente reconocidos y Código atribuido por la empresa, que se reporta de acuerdo con un formato determinado uri. En el borrador de documento de Filing Rules for Preparatory Phase Reporting de fecha 15/03/2015 se proponen para su discusión nuevos tipos con un formato específico: 11

12 For identification of an instrument based on code and type of code predefined pattern (one of the following) MUST be used: 1. ISIN/{code} for ISO 6166 for ISIN code 2. CUSIP/{code} for The Committee on Uniform Securities Identification Procedures number assigned by the CUSIP Service Bureau for U.S. and Canadian companies 3. SEDOL/{code} for Stock Exchange Daily Official List for the London Stock Exchange 4. WRT/{code} for Wertpapier Kenn-Number 5. BT/{code} for Bloomberg Ticker 6. BBGID/{code} for Bloomberg Global ID 7. RIC/{code} for Reuters instrument code 8. OCANNA/{code} for other code by members of the Association of National Numbering Agencies 9. CAU/{code} for code attributed by the undertaking The taxonomy follows an approach where code and type of code of an instrument is being merged defining a unique identifier. There are number of cases, where such an artefact is being used in the data model - a table below identifies those situations in the templates. Business table groups "Code" Cell Label of column "Type of code" Cell Label of column Purpose Part of the "key" Modelling approach Label of artefact used in modelling S (a,b,f) A4 ID Code A5 ID Code type Identification of instrument Yes Typed dimension URI S (a,b,f) A4 ID Code A5 ID Code type Identification of instrument Yes Typed dimension URI Cómo afecta al formato actual de la fase preparatoria? R: Se trata de un borrador que está sometido a consulta por lo que en este momento no son los códigos contemplados en la aplicación. No obstante, en función de la aceptación de los códigos planteados como definitivos en las especificaciones puede producirse un cambio en la tabla de códigos mencionada. P: En el documento Instrucciones Trimestral Individual - Fase Preparatoria.pdf, en la página 7 pone: CIC 72 (depósitos transferibles (equivalentes de efectivo)), solo deberá comunicarse una línea por par (banco, divisa); 12

13 Podéis por favor confirmarnos si se tiene que reportar el CIC 72 a nivel de entidad bancaria (agregado)? Según la información publicada por EIOPA habíamos entendido que era a nivel de cuenta corriente y nos gustaría aclarar esta duda para poder preparar correctamente la información de la QRT S a Lista de activos (antigua D1 R: La forma correcta de reportar la información referida es una línea por par (banco, divisa), por lo que debe ir agregada a nivel de banco, en lo que se refiere a los datos generales de la inversión (tabla DS602_01t). No obstante, para mejor análisis de la cuestión planteada sería de utilidad que nos enviara un ejemplo concreto del caso planteado detectado en su entidad. P: En la Resolución Aparecen los modelos S b y S b en los que se indica que son Autocumplimentables. Estos modelos se nutren de otras QRTs y se generan solos? R: Efectivamente, son cuadros resúmenes de las distintas fichas de activos y derivados por naturaleza. P: A15_S: País CIC: según las instrucciones este campo debe completarse con el País en el que está listado el activo. Sin embargo la información que está disponible en Bloomberg es, bien el país donde se ha emitido o bien el mercado en el que cotiza (no es un código de país). Podría completarse este campo con el país en el que se emitió? R: Como se define en el correspondiente Anexo V de la guía de información al supervisor: País ISO alpha-2 código de país Identificar el código ISO de país en el que figura listado el activo. Un activo se considera listado si está admitido a negociación en un mercado regulado o en un sistema de negociación multilateral, según se define en la Directiva 2004/39/CE. Si el activo está listado en varios países, el país en cuestión debe ser el utilizado como referencia a efectos de valoración. Por lo que siempre, en todo caso, debe adoptar un código correspondiente a la tabla auxiliar Aux_AG_Areas_Geograficas_Adicionales cuando filtro sea igual a 1 P: A31 (concatenación del A33_S y A31_S): Código del emisor se debe tomar de la tabla Códigos DGS que muestra: X1 LEI X2 Pre LEI En Bloomberg está disponible esta información pero cómo podemos diferenciar si es un código LEI o PreLei? R: Desde aquí no podemos dar solución a la cuestión de identificar el código facilitado por Bloomberg, puesto que entendemos que se debe requerir a dicho proveedor de servicios, pero dicho esto, si que el par A33_S y A31_S están vinculado por lo que si se pone el código se debe identificar el tipo. P: Por otra parte, para algunos emisores no aparece esta información (en concreto, toda la Deuda pública y algunos emisores privados). En este caso, puede quedar este campo vacío? R: Los campos citados no son obligatorios, por lo que si no se dispone de código se deja vacío. 13

14 P: Los datos A31-A33_S-A31_S y los datos A32-A33_S2-A32_S se refieren a los mismos códigos identificativos (Lei o PreLei) pero en un caso del emisor y en el otro caso del Grupo del Emisor. Siempre tenemos que completar los 6 campos? Cuando un emisor no pertenezca a un grupo dejamos en blanco los campos referidos al grupo?? R: Efectivamente P: Del mismo modo el campo A10 Grupo Emisor, lo dejamos en blanco cuando el emisor no pertenezca a un grupo o lo completamos con el mismo nombre del emisor?? R: Si el emisor no pertenece a un grupo, el campo se deja vacío. P: En todos los Modelos existe el campo 'regid' (y regid_fk_s) pero en la documentación no hemos visto ninguna explicación de cómo rellenarlo. Podrían indicarnos cómo rellenar este campo? Es simplemente un identificador/contador de los registros de la tabla que las entidades designamos libremente? Qué requisitos de formato debe cumplir este campo? R: Los campos regid (y regid_fk_s) que aparece en el anexo II del diccionario de datos son campos internos de la aplicación DEC y no deben incluirse en las tablas de la base de datos usada para importación / exportación de datos. P: RegID: entendemos que es un nº correlativo simplemente que indica el nº de cada activo? R: Efectivamente, es un campo alfanumérico que se genera aleatoriamente por el sistema para cada uno de los registros reportados de la tabla Lo debemos completar nosotros en la mdb? R: No R: Nada RegID_FK_S: según Diccionario DGSFP completarlo con Descripción. Qué tenemos que poner? A0_S: según Diccionario DGSFP hay que completarlo con Line ID? R: El campo A0_S se corresponde con el campo técnico denominado por EIOPA Line Identification en las plantillas anotadas de EIOPA y que se corresponde con el código PC0010 en el nuevo sistema de codificación empleado por esta. 4. MODELO 17 P: No existe la tabla RDS1701_04t donde se deben introducir los datos de "Total Non-Life obligation" 14

15 R: En la base de datos que se usa para la importación/exportación de la información, existe la tabla DS1701_04, que es la tabla en la que hay que introducir dichos datos. Es cierto que la mencionada tabla no existe en la base de datos de la aplicación, que es interna a la misma, lo cual es correcto al estar definida como consulta. 5. MODELO 23 Según el Anexo técnico II, OF-B1Q LOG-S a.b., el campo Q8 Exceso de activos sobre pasivos ha de ser el Q6 + Q7; siendo Q7 el exceso de los activos sobre los pasivos atribuible a las partidas de los fondos propios básicos (excluida la reserva de conciliación). Es decir, en el Q7 han de incluirse: Ordinary share capital (gross of own shares) / Capital social ordinario desembolsado (incluídas las acciones propias) Share premium account related to ordinary share capital / Prima de emisión de las acciones ordinarias Initial funds, members' contributions or the equivalent basic own - fund item for mutual and mutual-type undertakings / Fondo mutual inicial desembolsado, las aportaciones de los miembros de la mutua o el elemento equivalente de los fondos propios básicos para las mutuas y empresas similares Subordinated mutual member accounts / Cuentas de mutualistas subordinadas desembolsadas Surplus funds / Fondos excedentarios (Art. 91 Directiva) Preference shares / Acciones preferentes desembolsadas Share premium account related to preference shares / Prima de emisión de las acciones preferentes desembolsadas Subordinated liabilities / Pasivos subordinados desembolsados Other items approved by supervisory authority as basic own funds not specified above / Otros elementos autorizados como Fondos Propios Básicos por la autoridad supervisora no contenidos en otros conceptos anteriores An amount equal to the value of net deferred tax assets / Importe igual al valor de los activos por impuestos diferidos netos 15 Luego, dentro del cálculo del campo Q6 tengo como sumando el Q1, que es la diferencia entre activo de balance económico y activo de balance contable; en el que se incluye ya la diferencia de los activos por impuestos diferidos. Por lo tanto, el problema que tengo es que al hacer Q8 = Q6 + Q7 incorporo dos veces la cifra de activos por impuestos diferidos que surgen de la aplicación de Solvencia II.

16 Podéis aclararme la duda? R: En primer lugar, como se desprende de la taxonomía desarrollada al efecto, no todos los campos definidos en los modelos obligatoriamente forman parte de la información a remitir en la fase preparatoria. Concretamente, en el modelo aludido, los campos de referencia citados no forman parte de la información a remitir. Por otro lado, en relación a la cuestión planteada, por lo que afecta al cálculo de la conciliación a la que hace referencia los datos citados, entendemos que no se duplica ninguna partida en la medida que en Q1 y Q3 se computa el efecto neto de los impuestos diferidos y por lo tanto se netean las plusvalías/minusvalías del activo/pasivo, en tanto en cuanto en el campo Q7 Exceso de los activos sobre los pasivos atribuible a las partidas de los fondos propios básicos (excluida la reserva de conciliación) =B26 Otros elementos de los fondos propios básicos y por ende el importe del activo por impuesto diferidos solo se computa en este. Campo B27: según el diccionario DGS este campo recoge el Ajuste de elementos de Fondos Propios Restringidos respecto a los fondos de disponibilidad limitada (campo que aparece en el desglose de la reserva de reconciliación): A qué se refiere? A la parte de la reserva de reconciliación que cubre los RFF? En este caso estaría en línea con que los fondos propios que pueden cubrir el SCR de cada RFF sólo podían ser la diferencia entre sus activos y pasivos. Por tanto, debemos poner los componentes de la reserva de reconciliación de la Remaining Part y luego la parte de reserva de reconciliación que corresponde a la diferencia entre los activos y pasivos de los RFF? R: El campo B27 refleja el ajuste descrito en el artículo 81 de los Actos Delegados de Solvencia II. En concreto, supone minorar los fondos propios (reserva de reconciliación) de toda la entidad, es decir, incluyendo RFF y parte restante, por el excedente de fondos propios del RFF sobre el nscr del RFF. 6. MODELO 25 Y 26 P: "Con la finalidad de recibir información de modelos internos y su comparación con fórmula estándar se han desdoblado los modelos S.25 y S.26 para que las entidades con modelo interno parcial o total puedan enviar la información y así cumplir con la directriz 3 párrafos 1.23 y 1.24 de la guía de modelos internos" Se refieren a que por ejemplo si nosotros tenemos MI Longevidad, deberíamos reportar el modelo S (SCR - Life) y el modelo S dos veces, con datos con Fórmula Estándar y otro con datos con Modelo Interno? R: Los datos que se indican en la directriz 3 párrafos 1.23 y 1.24 de la guía de modelos internos deben introducirse a través de las pantallas correspondientes a Simulación Cálculo CSO según fórmula estándar. A nivel de base de datos, estos datos se almacenan en las mismas tablas de los modelos 25 y 26 con un valor diferente en el campo AO (ver Diccionario de Datos). 16

17 P: En la tabla DS2502_03t falta el campo B9 (Date of formal approval of partial internal model) En la base de datos reportada en el mes de diciembre venía este campo, pero ahora en la última versión ha desaparecido. Aunque en la fase preparatoria no se pide este campo. R: Este campo no debe ser reportado ni en preparatoria ni en la definitiva, como podrá comprobar. En el momento de diseño de las bases de datos en el mes de diciembre se incluía por error este campo B9 en la citada tabla. P: Por otra parte, vamos a informar por RFF y no tenemos claro cómo introducir los ajustes para llegar al SCR Total Según hemos entendido, debemos realizar un ajuste a todos los módulos para que una vez diversificados se llegue al SCR Total (RFF + Resto). Pero, qué pasa con los submódulos de ese módulo, también habría que realizarles un ajuste? Si no se le hace un ajuste a los submódulos, el dato de SCR de cada módulo calculado como la suma de RFF + RPB no va a cuadrar con el que hemos ajustado para llegar al SCR Total. En este caso, cómo se rellenarían los QRTs de cada módulo? Nos pueden indicar o pasar un ejemplo de cómo deberíamos hacerlo? R: En primer lugar, comentar que en esta fase piloto no se ha introducido la funcionalidad relacionada con el reporting de RFF. Otra cuestión a tener en cuenta, es que en la fase preparatoria solo se debe computar el RFF más significativo de los principales considerados por la entidad y el resto. En todo caso, en el supuesto de que haya RFF o carteras matching efectivamente hay que introducir un ajuste en en nscr de cada módulo de riesgo a nivel de entidad, de modo que al aplicar la matriz de correlaciones a los nscr agregados para el total de la entidad dé el mismo resultado que sumar el SCR de cada RFF, cartera matching y RP. Los nscr por módulo de riesgo de cada RFF, cartera matching y RP no deben ser ajustados individualmente, únicamente se ajustará el agregado para toda la entidad. Respecto al impacto de este ajuste a nivel de submódulo de riesgo, se ha considerado que su cálculo es demasiado complejo y de escaso valor añadido. Por lo tanto, en caso de que se deba realizar este 17

18 ajuste, es decir, en caso de que la entidad cuente con RFF o carteras matching significativas, no deberá reportar los modelos S.26.XX a nivel de entidad (variantes.b), si bien sí que deberá reportarlos a nivel de RFF, cartera matching y RP (variantes.l). Dado que el ajuste sólo afecta a nivel de entidad y los modelos S.26.XX.b (nivel entidad) no se requerirán, no será necesario calcular dicho ajuste a nivel de submódulo de riesgo. P: Entendemos que los errores se producen porque hemos rellenado ambos modelos 26 (el RSC y la simulación), pese a que en algunos casos los modelos son exactamente iguales. Estamos siguiendo el procedimiento correcto o solo hay que rellenar uno de los apartados si la compañía va por fórmula estandar? R: Evidentemente, si han saltado los errores señalados (aunque estamos trabajando en el literal de la descripción reportada por el error) es porque no es coherente con la información que contiene los modelos anteriores (posiblemente en lo declarado en el de información básica tipo de modelo interno ). En todo caso, hay que seguir lo indicado en el árbol de navegación que se encuentra en el documento de INSTRUCCIONES DEC ANUAL individual_v1. En líneas generales, solo se debe cumplimentar los modelos de simulación en el caso de utilización de modelos internos parciales o completos. No obstante, para verificar su correcta cumplimentación necesitaríamos nos enviase los datos concretos correspondientes a los modelos de información básica y los relativos a los modelos 25 y 26. P: Tras cumplimentar los modelos, en el QRT S b Simulación CSO: Riego de crédito, al validar datos, sale una lista de 20 errores que no conseguimos resolver a pesar de haber hecho comprobaciones R: A la vista de la información facilitada se desprende que los errores producidos se deben a dos factores_ 1. Cuando Código de la exposición a un emisor único distinto de blanco, el Tipo de código no puede estar en blanco (y solo admite los valores LEI o Pre-LEI). En consecuencia, si la exposición no tiene identificador LEI o Pre-LEI, el código debe estar en blanco. 2. Por otro lado, la probabilidad de impago es obligatorio cuando se cumplimenta algún campo del emisor, en consecuencia debe rellenarse con valor coherente con la naturaleza del dato solicitado. 18 P: En las 'VALIDACIONES DE TABLA - OBLIGATORIAS' del Modelo DS2501_01t se tiene: -VTO_DS2501_01t_1 AnidadaRFF_SI -VTO_DS2501_01t_1_1 Modelo obligatorio parar los FDL -VTO_DS2501_01t_1_2 FDL: Modelo de simulación (AO=x1) con datos y no debe ser cumplimentado. Parece que la validación significa que en caso de tener un RFF y de tener MIP, los datos del RFF se deberán reportar únicamente con Modelo Interno. Nos podían aclarar la validación que se realiza? Es que en caso de ser correcta nuestra interpretación, no vemos cómo encaja

19 esta validación con la explicación de la página 12 del documento de INSTRUCCIONES GENERALES PARA LA CUMPLIMENTACIÓN DE LA DOCUMENTACIÓN CUANTITATIVA ANUAL INDIVIDUAL FASE PREPARATORIA SOLVENCIA II, donde entendemos que en caso de MIP se debería remitir el modelo S sin simulación y simulado como fórmula estándar. (Esta pregunta también aplica a S2601, S2602, S2603, S2604, S2605 y S2606) R: En general, los modelos que configuran el grupo de con simulación CSO recogen los mismos datos que los designados sin simulación CSO. El objeto de los modelos con simulación CSO es recoger la información del requerimiento de capital resultante de la aplicación de la formula estándar, independientemente del modelo interno aplicado. En consecuencia, si la entidad utiliza modelos internos parciales deberá remitir el correspondiente modelo S y S (sin simulación) y el S con simulación (teniendo en cuenta únicamente los datos obtenidos por la entidad si hubiera utilizado la fórmula estándar). Respecto a los modelos 26, deberá rellenar los modelos sin simulación para aquellos riesgos no incluidos en el modelizado, y con simulación para el resto. Si se utiliza modelos internos completos solo deberá enviar un juego completo de modelos 26 con simulación P: En las 'VALIDACIONES DE TABLA - OBLIGATORIAS' del Modelo DS2502_01t se tiene: VTO_DS2502_01t_1 AnidadaRFF_SI -VTO_DS2502_01t_1_1 FDL: Modelo de simulación (AO=x1) con datos y no debe ser cumplimentado. Dado que en el Modelo DS2502_01t no existe el campo 'AO' puesto que es para MIP, cómo debemos interpretar esta validación? Debería ser como en el Modelo DS2502_02t en el que se tiene la validación 'Modelo por FDL con datos y no debe ser cumplimentado'? R: Efectivamente el mensaje de error es incorrecto y debe entenderse como Modelo por FDL con datos y no debe ser cumplimentado DS2501_01t: SCR fórmula estándar: o P: En los campos A1, A2 va pidiendo el dato de cada SCR bruto y neto de absorción de pérdidas. Posteriormente, para cada SCR se tienen que completar los campos AA01, AA02 Estos últimos campos exigen simplemente que se complete si se ha rellenado ese SCR o no? R: Los campos aludidos AAO1, AA02, responden a la pregunta: Cubre el modelo interno parcial los elementos de los submódulos de riesgo de la fórmula estándar?, por lo que estos campos se contestan (SI/NO) según si el riesgo es modelizado o no. o P: A14A: Efecto de la diversificación entre los RFF y entre los RFF y la Remaining Part: a qué se refiere este dato? 19

20 R: Importe del ajuste destinado a tener en cuenta el efecto de diversificación entre fondos de disponibilidad limitada, y entre los fondos de disponibilidad limitada y la parte restante, cuando el supervisor haya aprobado tal diversificación. Este elemento ha de consignarse en el informe únicamente cuando se refiera la estimación del CSO a escala de empresa, respecto a la empresa con fondos de disponibilidad limitada. Este elemento es APLICABLE ÚNICAMENTE cuando se refiera al cálculo del CSO a nivel de empresa. o P: Siempre hemos entendido que no existe diversificación ni entre los RFF entre sí, ni entre los RFF y la Remaining Part (de hecho se ha confirmado en el documento de respuesta de la DGSFP a las cuestiones de Unespa relativas a Matching y Medidas Transitorias). En la última versión del Diccionario de Datos habla de que, en el caso de que se esté informando de RFF, será cero. Esto supone que este campo sólo tendrá valor cuando se esté informando los datos totales (no los de las carteras parciales RFF/Remaining Part) y tendrá un valor negativo que refleja la pérdida de beneficios de diversificación por tener RFF? R: No tiene porque, ya que como ya se interpreta de las especificaciones de EIOPA estos modelos también se utilizan para recoger los datos correspondientes a los FDL y parte restante, en cuyo caso este campo tiene valor cero, que es a lo que se refiere la validación interactiva (VCI) en el diccionario de datos. En definitiva, este campo, de tener valor, solo es reportado para la parte de Entidad. DS2601_01t, DS2602_01t, DS2603_01t En general en todas las tablas referidas a datos de los diferentes SCR aparece un campo llamado A0 que en el diccionario DGS dice que se refiere al artículo 112: Las opciones que da la tabla auxiliar para completarlo son: X0: No X1: Si De qué norma? El art. 112 de la Directiva habla de modelos internos y el art. 112 de Actos delegados habla del cálculo simplificado del valor ajustado al riesgo de las garantías reales para tener en cuenta el efecto económico de las mismas. R: Este campo se ha configurado para recoger la diversidad que adicionalmente y con la finalidad de recibir información de modelos internos y su comparación con fórmula estándar, se desdoblan los modelos S.25 y S.26 para las entidades que con modelo interno parcial o total tengan que enviar la información, y así cumplir con la directriz 3 párrafos 1.23 y 1.24 de modelos internos. El CAMPO AO se define: Las plantillas anotadas de EIOPA incluyen en el modelo S la dimensión AO en todas sus tablas; esta dimensión toma los valores de la tabla auxiliar Aux_AO_Articulo_112, para su única jerarquía 1. La aplicación DEC define el campo AO para almacenar el valor de esta dimensión. 20

21 El valor de este campo AO debe estar entre los valores de la tabla auxiliar de tipo AUX_AO_Articulo_112 (x0=no, x1=sí) con filtro 1. R: No P: Puede referirse a mitigantes de riesgo? P: En nuestro caso únicamente nos aplican el mitigante de reaseguro en el cálculo del SCR Catastrófico. tenemos que informar de algo de esto? R: Si, en la medida que conceptualmente la entidad esté en modelos internos, por la parte correspondiente a los resultados derivados de la utilización de la fórmula estándar. 7. ANUAL GRUPOS P: En la documentación de los modelos de datos para la cumplimentación de los QRTs fase preparatoria, se tiene el MODELO DE DATOS ANUAL INDIVIDUAL. Está previsto que se disponga del MODELO DE DATOS ANUAL GRUPO?, en caso de ser así, Podrían indicarnos una fecha aproximada de publicación? R: Si, en la medida de su desarrollo y evolución. P: Igual que para los modelos anuales individuales, entendemos que existirá una aplicación de captura para los modelos anuales de grupo. Podrían indicarnos la fecha estimada en la que podremos disponer de la aplicación de captura? R: Actualmente está en fase de desarrollo, por lo que es poco recomendable aventurar fechas, pero si se pude garantizar que estará disponible con la suficiente antelación para su uso. 21