Transcript Mode d `emploi

Secrétariat général de la Commission bancaire
XBRL
Taxonomy codification
Paris, October 1st, 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
Instance
Document
Instance
Document
Instance
Document
Receipt Management
Taxonomy
Reception
Management
Taxonomies
Instance
Document
Databases
servers
Taxonomy
management
Data Mining
applications
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 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.
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
 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
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
Character position
1
COREP
FINREP
SURFI
2
3
Facts
C
CA_/CR_/MR_
Dimension
Dimension
value
C
XX
C
XX
Facts
F
Table code (1_1,1_2,31a,31b, 34_)
Dimension
Dimension
value
F
XX
F
XX
Facts
S
XXX
Dimension
Dimension
value
S
XX
S
XX
4
5
6
7
8
Auto-incremental
version number
Auto-incremental
version number
Auto-incremental
version number
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