Secrtariat gnral de la Commission bancaire XBRL Taxonomy

Secrétariat général de la Commission bancaire XBRL Taxonomy codification Paris, October 1 st, 2008 SGCB SIGD XBRL format de reporting

Introduction: XBRL consumptions for data Mining/Statistiques in back office applications Financials institutions (submitters) BACKEND - Taxonomy creation - Instance management Instance Document Receipt Management Taxonomy Reception Management Taxonomies Instance Document Data Mining applications Databases servers Taxonomy management Taxonomy control Corporate Directory Server: BAFI … Taxonomy Mistakes/Errors Habilitations Reference data management SGCB Reporting synthesis • Conception • Reporting calculation Control and storage Amounts ctrl. BAFI/COFINREP Comparision Reporting Extraction COFINREPReporting Errors Reporting synthesis SIGD XBRL format de reporting 2

I. A short unique ID There is a need for a unique ID in order to select XBRL facts, dimension or dimension value for data mining IT : • For XQuery expressions on XBRL instances, XML files, XML databases • For SQL queries in databases, XML databases… • Through user friendly interfaces The unique ID should be short for feasibility (max queries string size) and for performance enhancement (speed and size). The most obvious and simple unique ID in XBRL to find a facts, dimension or dimension value, is by it’s: QName ( = prefixe + element name) 3 SGCB SIGD XBRL format de reporting

II. Current taxonomy element names In the latest taxonomies, element names are: • Self explanatory and human understandable: A user can determine exactly the business meaning of an the element. • Follows the FRTA recommendation and uses LC 3 convention (Label Camel Case Concatenation) : Element meaningful label trimmed and without special characters. The consequence : up to 250 characters long string difficult to remember and to manipulate. 4 SGCB SIGD XBRL format de reporting

5 SGCB SIGD XBRL format de reporting

III. Smaller code alternative Alternative codes were studied: • Hash of the element name, fixed size: complex and require collision detection algorithms. But would be automatic. • Direct code, fixed size: A unique compact code, as meaningful as possible for each Xbrli item (fact, dimension and value of dimension). But not self explanatory and human understandable. • Combination code, fixed size : A unique compact code, as meaningful as possible for each possible combination of an Xbrl item fact + couples of( dimension and value of dimension). But not self explanatory and human understandable. Is very complex, and would require the versioning specification dimensional Infoset model which is not available yet. In the end: • We used the direct code (10 characters string). • The Its can concatenate the code of fact with the codes of dimension/values of dimensions to create a single longer code if needed. • The business and technical needs were easily met with a simple code. 6 SGCB SIGD XBRL format de reporting

VI. Example with dimensions v Primary item p-cm-ca : Credit. Risk. Capital. Requirements v With the dimension Credit. Risk. Dimension v And dimension value Credit. Risk. SASecuritization Would become: - Hash : f 590 d 6 fc (21 d 249 c 5, 2 f 7035 e 7) - Direct code : CCCA_024 (CTCR_0001 , CDCR_0002) - Combination Code : CCCA_024_0011 7 SGCB SIGD XBRL format de reporting

IV. Where should they be added? They should be added with all other metadata concerning the reporting facts: in the taxonomy: • As new labels, in the label linkbase. With a different role and/Or a different language. • In the generic linkbase, by defining new arcs, arcroles, resources… • Used as element names. The choice was made to use the label linkbase given the current taxonomies are extensions of European taxonomies. But to use short code as element names would have appeared to be the best option: • More compact instances (40% size gain, mostly with contexts) • No need for a conversion tables between element name and code in back end data mining ITs consuming only XBRL instances. • Easier code to remember and use for business people. • Instances are harder to read with no XBRL Tools. (I. e. notepad users? ) 8 SGCB SIGD XBRL format de reporting

V. The french COREP, FINREP and SURFI codification Help document for non XBRL business people : 9 SGCB SIGD XBRL format de reporting

Conclusion • Very simple short codes are needed for technical and business people whether they are reporting entities or receiving entity (the French banks have been asking for a codification). • These codes should be in the taxonomy, preferably as element names for technical reasons. • They should be included in reference (IFRS, US-GAAP, European FINREP and COREP) taxonomies so they are common to extended taxonomies users. 10 SGCB SIGD XBRL format de reporting