Monolithic vs modular decision required Modular Advantage ease

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 »

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”

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

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

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

Otherwise … Max-tax Country 1 Country 2

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 mappingoriented system – Keep it simple (& keep requirements low)

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

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

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

Min-Max Risk (Corep) Tn-max Tn-min Tn-country 1 Tn-country 2 Tn-countryn

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

Finrep structure t 1 t 2 BS … tn t 1 P&L t 2 … tn

Corep structure T 1 -max T 1 -min Ca-sro … Tn-max Tn-min

Finrep-Corep 2012 structure Tn-min formulas Main Import Tn-max formulas Main formulas Taxonomy-nmin with formulas Taxonomy-nmax imports Taxonomy-nmin and adds its own formulas

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?