“PREGUNTAS Y RESPUESTAS FRECUENTES RELATIVAS A … · La explicación es que en la prueba piloto...
Transcript of “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”
Preguntas y respuestas frecuentes: Información ANUAL
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
Preguntas y respuestas frecuentes: Información ANUAL
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.
Preguntas y respuestas frecuentes: Información ANUAL
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.
Preguntas y respuestas frecuentes: Información ANUAL
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?.
Preguntas y respuestas frecuentes: Información ANUAL
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.
Preguntas y respuestas frecuentes: Información ANUAL
Versión 1.1
Fecha: 30/03/2015
7
Preguntas y respuestas frecuentes: Información ANUAL
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:
Preguntas y respuestas frecuentes: Información ANUAL
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);
Preguntas y respuestas frecuentes: Información ANUAL
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
Preguntas y respuestas frecuentes: Información ANUAL
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.
Preguntas y respuestas frecuentes: Información ANUAL
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?
Preguntas y respuestas frecuentes: Información ANUAL
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_
Preguntas y respuestas frecuentes: Información ANUAL
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.