Question ID: 2981
Regulation Reference: (EU) 2023/894 - ITS with regard to the templates for the submission of information necessary for supervision
Topic: Reporting Templates
Template: S.14.01
Status: Final
Date of submission: 12 Feb 2024
Question
While reviewing the EIOPA Q&A responses, we observed a specific clarification in Q&A 2748. The response explicitly confirm the older answer for the Q&A 1074, which allows for the addition of more than one row for each Product ID code in the Portfolio table, referring to the possibility to report a product with different country codes (C0080). This practice was accurate up to Taxonomy 2.7.0, where the XH dimension (line identification) was present in the Portfolio Table. However, with Taxonomy 2.8.0, the only available dimension is now IP (ID code of the product) in the Portfolio table (S.14.01.01.01). From a technical standpoint, both tables S.14.01.01.01 and S.14.01.01.02 (Characteristics of product) should have the same number of rows since they share the same dimension. We presume that the reason for the unique dimension in table S.14.01.01.01 is due to the modified C0080 (Country) that allows for the inclusion of more than one country. Could you kindly confirm whether, with these dimensions, tables S.14.01.01.02 and S.14.01.01.01 should indeed have the same number of rows? If not, the inclusion of more than one country in each line of C0080, along with the removal of the XH dimension in the 2.8.0 taxonomy, appears to lack coherence. If you agree with our interpretation, could Q&A 2748 be reconsidered? Otherwise, we would need further clarification.
EIOPA answer
Adding more than one row for each Product ID code in S.14.01.01.01, where required, is still valid.
While it is true that by reporting one row in S.14.01.01.01 a corresponding row will be available to be reported in S.14.01.01.02 (and vice versa), the reporting entity doesn't have to fill in the additional row(s) in S.14.01.01.01 (stemming from S.14.01.01.02), nor the additional row(s) in S.14.01.01.02 (stemming from S.14.01.01.01).
Practical example
A reporting entity would like to report as follows :
• 3 rows in S.14.01.01.01:
- Product ID code (C0010): ABC123/+/1
- Product ID code(C0010): ABC123/+/2
- Product ID code(C0010): ABC123/+/3
• 1 row in S.14.01.01.02:
- Product ID code (C0090): ABC123
In both templates, the reporting entity may see four rows given that they share the same dimension (the visualisation may differ between tools).
However, the reporting entity:
• Does not have to fill in the row 'ABC123' in S.14.01.01.01.
• Does not have to fill in the rows 'ABC123/+/1', 'ABC123/+/2', 'ABC123/+/3' in S.14.01.01.02.
Please note that the source of the issue seems to be using exact the same dimension and describing the S.14.01.01.01 as 'foreign key to S.14.01.01.02'. This may indicate the values for this field should be taken directly from S.14.01.01.02. However, due the particular nature of the Product ID code, i.e. the fact that each code can be provided multiple times with version number, .02 and .01 tables may differ in terms of number of rows reported.
However, the modelling can be indeed confusing and will be corrected in the next release. EIOPA added it to the “List of Known Issues" file and state that the foreign key comment may not be specific and that there is a linkage between these tables (but not always 1:1).