1. NOMBRE DEL DEPARTAMENTO DATA DICTIONARY Primary items One single schema Credit / debit attribute: to discuss with business users To take into account IFRS-GP approach Formula patterns could benefit from this information Data type: Light constrains (sign wont be constrained) But still we want to have that information for communication purposes Substitution groups best of both worlds Instant / Duration: no special requirements (duration for changes) Two different primary items in movement tables Nillable attribute: no special requirements Codification 1

2. NOMBRE DEL DEPARTAMENTO DATA DICTIONARY Dimensions A schema for each dimension and its domain members. Domains => standard extended link role Subdomains => additional extended link roles Hypercubes pointing to subdomains: try a proof of concept Open hypercubes? => Most people against the use of open hypercubes 2

3. NOMBRE DEL DEPARTAMENTO IFRS-GP COMPATIBILITY Common concepts Common concepts with different sign Common concepts with different labels Codification issues? 3

4. NOMBRE DEL DEPARTAMENTO LABELS Labels independent of the context? Statement specific labels? Both? FINREP network was receptive to use a unique label for each concept. Thou using two different labels is not a technical issue, it simplifies the maintenance and its clearer for credit institutions Use of arc roles: beginning of period, … 4

5. NOMBRE DEL DEPARTAMENTO REFERENCES Template specific references: to be solved using template specific extended link roles 5

6. NOMBRE DEL DEPARTAMENTO PRESENTATION Connection between facts and layout in business templates Presentation linkbase? Rendering linkbase? Should we just follow the normalized version proposed by BRAG? Marco will check 6

7. NOMBRE DEL DEPARTAMENTO DATA SUBSETS - Postpone until a clearer approach to rendering / dimensions 7

8. NOMBRE DEL DEPARTAMENTO ADDITIONAL DATA / ADDITIONAL DIMENSIONS Should scope of consolidation be a standard dimension? -Header of the instance document? -Dimensions? -Open hypercubes or closed hypercubes? Complexity of dimensional information Solo / Consolidated information Additional information from DGI? Impact on instance document reporting FINREP network: do we want a consensus on auxiliary data? 8

9. NOMBRE DEL DEPARTAMENTO CONSTRAINS ON DIMENSIONAL COMBINATIONS Too many constrains on COREP? Light approach to the new taxonomy? Mix – modular approach (some countries already using dimensional constrains, but some countries wish to use formula and better error reporting) We need more information on grey areas from FINREP network => already in templates: criss-crossed cells dont have a business meaning; grey cells are just not required. 9

10. NOMBRE DEL DEPARTAMENTO CONSTRAINS ON THE CONTENT Modularity: -Pattern approach -Tree walk functions / filters (FWG) -Bazaar model -Assertion sets -Assumptions about non-reported data Error reporting: -Identification of the failed assertion -Error description -Identification of facts involved (reported values) -Expected value 10

11. NOMBRE DEL DEPARTAMENTO EXTENSIONS No extensions at all? No content extensions… 11

12. NOMBRE DEL DEPARTAMENTO VERSIONING Versioning report It wont be possible for the new version Could be use to show differences between extensions Identification of the version Follow convention used in current COREP / FINREP To be proposed to the best practices board / taxonomy architecture WG Identification of the tool and its version To be proposed to the best practices board / taxonomy architecture WG 12

13. NOMBRE DEL DEPARTAMENTO ATTRIBUTES AND DIMENSION We should use a convention for attributes and dimensions to cover the lack in the standard Formulae could impose additional constrains according to the idea of attribute But first, we should identify attributes in the model 13

14. NOMBRE DEL DEPARTAMENTO TYPED VS EXPLICIT DIMENSIONS Typed dimensions for enumerable dimensions that are likely to change. For instance, currency. 14

15. NOMBRE DEL DEPARTAMENTO CODIFICATION How data reported is identified in the instance document : Each concept / dimension / member has code This code is composed of two parts: a namespace and a local name XBRL provides ways to express additional information. Theres no need to overload this code: Labels Presentation linkbase … The most important requirements for this coding scheme are: Unique Stable 15

16. NOMBRE DEL DEPARTAMENTO MULTIDIMENSIONAL VIEW OF XBRL FACTS A value A concept: Incomes A set of dimensions – Standard Entity Time – User defined Titulizations Market Additional properties: unit and precision THE STATEMENT DOESNT EXIST XBRL IS NOT AN EXCEL SPREADSHEET 16 t Credit institution Concept 100 (prec 3) Dexia Dec 2007 Incomes

17. NOMBRE DEL DEPARTAMENTO CODIFICATION Codification scheme cannot depend on the presentation (statements) Foundations of data modelling Stability Redundancy of data Alignment with IFRS-GP and major taxonomies trend Should a change in the presentation have an impact on credit institutions? Compatibility with tools Easier for (some) filers of the data Codification should be based on the schema matrix and / or the normalized version of the statements 17

18. NOMBRE DEL DEPARTAMENTO CODIFICATION Is this just a technical issue? Shorter codes means smaller instance documents Easier to read by technical staff What about error messages? 18

19. NOMBRE DEL DEPARTAMENTO FORMULA MESSAGE REPORTING Implementation dependent Error reporting: -Identification of the failed assertion -Error description -Identification of facts involved (reported values) -Expected value There is no common agreement to identify facts involved To check, from a technical point of view, the feasibility of having a standard way to implement different fact codifications 19

20. NOMBRE DEL DEPARTAMENTO ERROR EXAMPLE 20 V133: Summation of the breakdown not equal to the total value reported The reported value for Total assets is 200,000 whereas the calculated value is 195,000 Table 26 Dimension I (Instrument) : i0 (Derivatives held for trading) Measure: i1200 (Assets) Reported value = 200,000 euros Measure: i1201 (Cash) Reported value = 40,000 euros Measure: i202 (Financial assets held for trading) Reported value = 75,000 euros Measure: i203 (Available for sale financial assets) ….

21. NOMBRE DEL DEPARTAMENTO ERROR EXAMPLE 21 T26 – V133: The following check is not valid i200 | s1 = i201 | s1 + i202 | s1 + i203 | s1 I200 | s1 : Cash | CDR Scope of consolidation I201 | s1 : … T2 V133: The following check is not valid i200 | s1 | i1: Cash | CRD Scope | Debt securities i201 | d1 | s1 + i202 | d1 | s1 + i203 | d1 | s1 T1 – T2 – V400: The following check is not valid i200 | s1 < i201 | s2 + i202 | s1 + i203 | s1

22. NOMBRE DEL DEPARTAMENTO LOCAL NAME CODIFICATION Approaches: -FRTA Approach (none seems to like it, but, do we have a better solution?) -Timestamp / hash: short, unique but doesnt make sense from a business point of view -Short nemotechnical name: to be decided by business network; but still language problem -Codification derivated of a main hierarchy (1.1, 1.2, 1.3, 1.4, …) -Enumeration: 1, 2, 3, … -No common approach accepted !!! 22

23. NOMBRE DEL DEPARTAMENTO LOCAL NAME CODIFICATION Not a technical requirement: but we need a clean way to communicate errors FRTA Approach: too verbose? Qname codification determines the data model, the data dictionary If presentation information is used for this codification, we are transforming the data model into a statement specific one. 23