SIGD XBRL format de reporting

SGCB

XBRL Taxonomy codification

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

SGCB

Paris, October 1st, 2008

2

SIGD XBRL format de reporting

SGCB

Introduction: XBRL consumptions for data Mining/Statistiques in back office applications

- Taxonomy creation

- Instance management InstanceDocument

BACKEND

Taxonomy

Financials institutions (submitters)

Databasesservers

Corporate Directory Server: BAFI …

InstanceDocument

InstanceDocument

InstanceDocument

InstanceDocument

Receipt Management Reception

ManagementTaxonomies

Taxonomy control

TaxonomyMistakes/Errors

Taxonomy management Control and

storageAmounts ctrl.

BAFI/COFINREPComparision

Reporting synthesis

• Conception• Reporting

calculation

ReportingExtraction

COFINREPReportingErrors

Reporting synthesisReference data management

Habilitations

Data Mining applications

3

SIGD XBRL format de reporting

SGCB

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

SIGD XBRL format de reporting

SGCB

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

SIGD XBRL format de reporting

SGCB

6

SIGD XBRL format de reporting

SGCB

III. Smaller code alternativeAlternative 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

SIGD XBRL format de reporting

SGCB

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

SIGD XBRL format de reporting

SGCB

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

SIGD XBRL format de reporting

SGCB

V. The french COREP, FINREP and SURFI codification

Feuille de calcul Microsoft Excel

Help document for non XBRL business people :

1 3 4 5 8

COREP Facts C version number

Dimension CDimension value C

FINREP Facts F version number

Dimension FDimension value F

SURFI Facts S version number

Dimension SDimension value S

XX

XX

XX

XX

XX

XX

XXX Auto-incremental

Table code (1_1,1_2,31a,31b, 34_) Auto-incremental

Character position

2 6 7

CA_/CR_/MR_ Auto-incremental

10

SIGD XBRL format de reporting

SGCB

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.