Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
1
“PREGUNTAS Y RESPUESTAS FRECUENTES
RELATIVAS A LA DOCUMENTACIÓN
CUANTITATIVA ANUAL FASE
PREPARATORIA SOLVENCIA II”
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
2
Tabla de contenido
I.- CUESTIONES RELATIVAS A LA INFORMACIÓN ANUAL INDIVIDUAL: ................................................ 3
1. INTRODUCCIÓN ........................................................................................................................... 3
2. MODELO 2: .................................................................................................................................. 8
3. MODELO 6 y 8: .......................................................................................................................... 11
4. MODELO 17 ............................................................................................................................... 14
5. MODELO 23 ............................................................................................................................... 15
6. MODELO 25 Y 26 ....................................................................................................................... 16
7. ANUAL GRUPOS ........................................................................................................................ 21
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.02.01 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 2003
� 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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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 2015.
� 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.
� 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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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. http:/…)?
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 (http://www.example.com/xxxxx), 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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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”) = “C9999” - 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 [...]
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.02.01 (balance) y el S.02.02 (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?.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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:
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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" "Type of code"
Purpose
Part of
the
"key"
Modelling
approach
Label of
artefact
used in
modelling Cell
Label of
column Cell
Label of
column
S.06.02.(a,b,f) A4 ID Code A5
ID Code
type
Identification
of
instrument
Yes Typed
dimension URI
S.08.01.(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);
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.06.02.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.06.02.b y S.08.01.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
3166-1-
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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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
� RegID_FK_S: según Diccionario DGSFP completarlo con “Descripción”. ¿Qué tenemos que
poner?
R: Nada
� 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"
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.23.01.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
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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.26.03 (SCR - Life) y el modelo S.25.01 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).
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.26.02.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.
� 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
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.25.01 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.25.01 y S.25.02 (sin simulación) y el S.25.01 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?
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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 S25.01.03 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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.2
Fecha: 23/04/2015
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.
� P: ¿Puede referirse a mitigantes de riesgo?
R: No
� 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.