1. Monolithic vs modular: decision required Modular –Advantage: ease of definition of a « national to be delivered dataset » (by selecting required instances) Monolithic –Advantage: ease and efficiency of formulas –Disadvantage: problem of « nationally not required data » deactivating compatibility issues not deactivating how to politically deal with instances containing « too many data »

2. Rounding The rounding should be done while consuming the data by the financial regulator Correct rounding should be enforced by instance validation e.g. in the formula validation part

3. Instance « context » Consolidation status –consolidated –non consolidated head & branches –non consolidated head only –non consolidated branch Audit status –provisional –audited Consolidation scope –CRD –Insurance –OtherEntities –IFRS

4. Instance « context » Materialisation alternatives –As dimensions ? –As part of some header ? –As part of some external « envelope »?

5. Standard dataset one single reporting entity one single reporting period one single capital currency (+ pure) one single consolidation status one single audit status one single scope of consolidation

6. Otherwise … Max-taxCountry 1Country 2

7. Dimension defaults Use of instances in a 2-step approach –first XBRL validation –then injection of values into DB (without taxonomy) Issues: –Transparency of data –Reidentification of hypercubes in a mapping- oriented system –Keep it simple (& keep requirements low)

8. In scope of Finrep 2012 Atomic XBRL instances that are structurally compatible Atomic XBRL instances that respect CEBS formula set (Hopefully) no national formula sets required In case of a monolithic taxonomy structure, a standard way of rejecting « nationally not required data » should be defined: take it and ignore it, or refuse it? A « standard dataset » acceptable by all participating countries should be defined

9. Out of scope of FINREP 2012 To be determined by local supervisor (or within separate project) –File name convention –Transmission channel & encryption –Packaging and envelopes (XBRL pure, XBRL/XML mix, ZIP,...)

10. Obsolete Nil –Nil values should be technically prohibited by instance validation Period / instant harmonization ? –Can one single approach be defined for all data ? both inacceptable for IFRS compatibility reasons

11. Min-Max Risk (Corep) Tn-max Tn-min Tn-country1Tn-country2Tn-countryn

12. Min-Max best practice National extensions should either include min or max version of Tn, but not a mix of them

13. Finrep structure P&L t1 t2 … tn BS t1 t2 … tn

14. Corep structure Ca-sro … T1-max T1-min Tn-max Tn-min

15. Finrep-Corep 2012 structure Main Main formulas Tn-max Tn-max formulas Tn-min Tn-min formulas Taxonomy-n min with formulas Taxonomy-n max imports Taxonomy-n min and adds its own formulas Import

16. Discussion on requirements Formulas have to work properly and efficiently cross-instance in all XBRL-tools Access to all required instances in the same environment at the same time in the same place Pre-defined file name convention for instances required?