“preguntas y respuestas frecuentes … · preguntas y respuestas frecuentes: información anual...

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”


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


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.


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.


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.


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 [...]


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.


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?.


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.


Versión 1.2

Fecha: 23/04/2015

10


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:


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);


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.


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"


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.


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).


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


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


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?


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.


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.

“preguntas y respuestas frecuentes … · preguntas y respuestas frecuentes: información anual...

Documents