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

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

SIGD XBRL format de reporting SGCB 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 its: QName ( = prefixe + element name)

SIGD XBRL format de reporting SGCB 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.

SIGD XBRL format de reporting SGCB 5

SIGD XBRL format de reporting SGCB 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.

SIGD XBRL format de reporting SGCB 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

SIGD XBRL format de reporting SGCB 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?)

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

SIGD XBRL format de reporting SGCB 10 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.