XBRL

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

• XBRL
• Taxonomy codification

Paris, October 1st, 2008

SGCB
2
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
  its
• 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.

5
(No Transcript)
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 CreditRiskCapitalRequiremen
  ts
• 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
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.