“preguntas y respuestas frecuentes relativas a … · la explicación es que en la prueba piloto...

Preguntas y respuestas frecuentes: Información ANUAL

Versión 1.1

Fecha: 30/03/2015

1

“PREGUNTAS Y RESPUESTAS FRECUENTES

RELATIVAS A LA DOCUMENTACIÓN

CUANTITATIVA ANUAL FASE

PREPARATORIA SOLVENCIA II”


Versión 1.1

Fecha: 30/03/2015

2

Tabla de contenido

I.‐ CUESTIONES RELATIVAS A LA INFORMACIÓN ANUAL INDIVIDUAL: ................................................ 3

1. INTRODUCCIÓN ........................................................................................................................... 3

2. MODELO 2: .................................................................................................................................. 5

3. MODELO 6 y 8: ............................................................................................................................ 8

4. MODELO 17 ............................................................................................................................... 10

5. MODELO 23 ............................................................................................................................... 10

6. MODELO 25 Y 26 ....................................................................................................................... 12


Versión 1.1

Fecha: 30/03/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.1

Fecha: 30/03/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.


Versión 1.1

Fecha: 30/03/2015

5

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

Fecha: 30/03/2015

6

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

Fecha: 30/03/2015

7


Versión 1.1

Fecha: 30/03/2015

8

__________________________________________

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

Fecha: 30/03/2015

9

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

modellingCell

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

Fecha: 30/03/2015

10

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.

4. MODELO 17

P: No existe la tabla RDS1701_04t donde se deben introducir los datos de "Total Non‐Life

obligation"

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


Versión 1.1

Fecha: 30/03/2015

11

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.

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


Versión 1.1

Fecha: 30/03/2015

12

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

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?


Versión 1.1

Fecha: 30/03/2015

13

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 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_


Versión 1.1

Fecha: 30/03/2015

14

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.

“preguntas y respuestas frecuentes relativas a … · la explicación es que en la prueba piloto...

Documents