Secrétariat général de la Commission bancaire

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

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

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

4. 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 LC3 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.

6. 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.

7. VI. Example with dimensions • Primary item p-cm-ca :CreditRiskCapitalRequirements • With the dimension CreditRiskDimension • And dimension value CreditRiskSASecuritization • Would become: • Hash : f590d6fc (21d249c5, 2f7035e7) • Direct code : CCCA_024 (CTCR_0001 , CDCR_0002) • Combination Code : CCCA_024_0011

8. 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?)

9. V. The french COREP, FINREP and SURFI codification Help document for non XBRL business people :

10. 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. Conclusion