Index

Information Systems and Processes

XBRL at the Bank of Spain

Experiences, problems and challenges

Ángeles Lozano

Víctor Morilla

1st Technical Meeting of European XBRL implemented projects

MADRID

5/10/2006

2INFORMATION SYSTEMS AND PROCESSES

Index

Good practices and considerations

Problems

Future challenges


Good practices and considerations


Taxonomy driven model

XBRL taxonomies define:–Business concepts–Relations between business concepts–Relations between business concepts and other resources

XBRL is a comprehensive language to express business metadata

Changes in the taxonomy should not impact on the system

Taxonomies as an input


Taxonomy driven model example

XBRLDocume

nt

HTMLDocume

nt

XSLTProcess

or

XSLT XSLTProducer

Taxonomy


Taxonomy driven model

Benefits:–More flexible design–Reduce errors–Only structural changes need development

Let the taxonomy be your guide !


Taxonomies and data models

Avoid designing taxonomies based on specific views of the dataAnalysts should see the data model behind



Total incomes by country should be equal to total incomes by product

–We need one rule:•TotalIncomes = IncomesByProduct

Calculate total benefits and benefits by country–We need four new formulas:

•TotalBenefits = TotalIncomes – TotalExpenses•BenefitsInSpain = TotalIncomesSpain – ExpensesInSpain•...

Add 3 new countries:–We need 9 new concepts–We need 3 new calculation rules



With a good design:–Two items:

•Incomes•Expenses

–Two dimensiones:•Country dimension (Spain, Italy, France...)•Product dimension (TVs, Radios, Fridges...)

items

countries

products



Total incomes by country should be equal to total incomes by product

–This rule is implicit to the modelCalculate total benefits and benefits by country

–We need to add one formula:•Benefits = Incomes –Expenses

Add 3 new countries:–We just need to add 3 new countries


Taxonomies based on data models

Benefits–Reduce redundancy–Improve consistency–Improve maintainability–Improve flexibility

The team that develops a taxonomy needs:–Business analysts–IT analysts


Reporting process

The reporting process is defined by:–Communication channel–XBRL Taxonomy–Instance documents–Additional data


Reporting process: taxonomy entry points

Every instance document must refer to:–At least, one schema file–Any number of linkbase files

High number of possible combinations !Taxonomy entry points constrain the number of combinationsEmpty schemas that refer to predefined combinations of taxonomy files



COREP and FINREP define a multidimensional data model:

–A set of primary items–A set of dimensions (and its members)–The set of possible combinations of primary items and dimensions (facts)

COREP templates define subsets of the whole data modelSome COREP templates overlap COREP

multidimensionaldata model



Entry points reduce redundancy on instance documents:–XBRL representation of data does not depend on the template–Information does not have to be filed twice

Entry points reduce complexity of the reporting process

Entry points help improving the consistency of data–Entry points join together highly coupled templates


Reporting process: constrains on instance documents

Monetary unitPrecisionNumber of entities and time periods reported in one single instance document

Bank of Spain:–Monetary unit must be Euro–Precision must be of at least thousands–One entity and one period per instance document


Reporting process: additional data

Taxonomies define business dataReporting process need additional data

–Who is the sender of the information?–When the information was extracted?

It is important to differentiate process data from business data

Spanish project will use a taxonomy, common to every entry point, for this data:

–Sender of the information–Time period reported–Entity reported–List of templates submitted–List of templates not submitted because don’t apply

We have avoided to include this information as part of the context


Reporting process: group and individual information

Holdings of company groups report information:

–Individual: as a single company–Consolidated: as a group of companies

Two alternatives:–Including one additional dimension: individual / consolidated–Considering the group as a different entity

•Single company has code 0456•The group has code 0-0456

ACME Corp

ACME Electronics ACME pharmacs ACME books


General project considerations

XBRL as the only format available to file data?

–XBRL scares people–Several choices:

•Allow more than one format–Easiest for financial entities–Two formats must be maintained

National Bank

Financialentity Financial

entity

Financialentity

xml xbrlxbrl





•Allow more than one format•Only XBRL

–Key: establish a fluent relationship with bank’s software providers

National Bank


entity

Financialentity

xbrl xbrlxbrl





•Allow more than one format•Only XBRL•XBRL is the only format allowed, but providing a translation tool

–Very similar to German solution–Entities to consider providing XBRL directly–Translation tool must be maintained

National Bank

Financialentity

Financialentity

Financialentity

xbrl xbrlxbrl

txt



Error management–Expect information with errors–Design carefully how errors and exceptions are handled

•Don’t impose constrains that are not needed•Notify errors with clear user messages and suggested corrections•Budget support resources•Use log files to store errors and warnings



Providing helper services– Instance validation tool– Instance visualizing tool–Taxonomy dictionary–Taxonomy browser

Or relying on third parties to provide this services



Software platform: –Validation–Visualization–Instance creation (e-forms)–ETL

XBRL market tools vs. in-house development

Spanish COREP:–Commercial XBRL engine for validation–Visualization and ETL based on XSLT, but using the API of the XBRL engine



Project deployment–Communication plan

•Appoint meetings with financial entities•Appoint meeting with software providers

–Real data for testing•System implementation•Taxonomy implementation•Adequacy of business rules•Performance

–Support•Budget support resources


Problems


Closed and open reporting models

The closed model constrains the data to be filed:–What MUST be filed–What CAN be filed–Any other information cannot be filed–Regulators following a closed reporting model don’t allow extra information to be sent

The open model just establishes a set of guidelines–Entities can extend the information


Closed and open reporting models

XBRL does not support some basic constrains required by a closed reporting model:

–Data that must be filed•An empty instance document is valid

It will be possible to express these constrains with the future formula linkbase:

–Possible = adequate ?


Calculation linkbase not enough

Calculation linkbase allows definitions of summation items networks

Other basic arithmetic operations are not allowedWith formula linkbase will be possible

Summation across dimension members is not possibleWith formula linkbase will be possible

–Possible = adequate ?–Calculation linkbases are extensible–Formulas linkbases will be–But individual formulas won’t


Calculation linkbase not enough

Summation checks are run when an instance document contains at least one value for each part of the equation:

–A = B + C + D

–A=10–B=5–C=2

–D=3

OK

–A=10–B=5–C=0

–D=0

Wrong!

–A=10–B=5

Wrong!


Modularization

Modularization should make easier reusing available taxonomiesInstead of importing the whole taxonomy, you just import a partIt is the author of the extended taxonomy the one that decides the criteria to split the taxonomy

COREP modular design:–One taxonomy per dimension (14)–One primary items taxonomy per business template (18)–Some common primary items taxonomies (3)–One template taxonomy per business template (18)


COREP dependencies graph of t-mi template


COREP dependencies graph of t-mi template Spanish extension


Modularization

Is modularization something users should be really care?

Should this “modularization” issue be solved by XBRL technology instead of taxonomy designers?

Have a look at the presentation “Large Taxonomies, Small Footprint” by the Fraunhofer Institute at the Madrid XBRL International Congress


Challenges


Evolution of the SIIF project

Financial entities Bank of Spain

SIIF (XBRL) FIN (Mainframe)

Financial statements (flat files)Complex

validations

<2005

2005Basic

validationsBasic

validations

Other statements (flat files)

Public statements (XBRL) Complex

validations

2007 Complexvalidations

Complexvalidations

Other statements (flat files)

PE, Basel II (XBRL)Complex

validations

200? Complexvalidations

Complexvalidations

Financial statements(XBRL)

Complex validations

20??Complex

validationsComplex

validationsFinancial statements

(XBRL)

Otherapplications


Evolution of the SIIF project

Improve the quality of data–Validation at the origin–Accurate definition of data

Flexibility (taxonomy driven model)Better data model: better analytical capabilities


Inter-instance validation

Validations between different time periodsValidations between different statementsValidations with data from other systemsCurrent calculation and formula linkbases work on instance document levelInter-instance validation is not considered



One possible solution:–Produce auxiliary instance documents that put together information from different time periods, statements, ...–Run validation on these instance documents–These instance documents would be defined by “internal taxonomies”

Performance?Maintainability?

Financial entities

XBRL

Instancebuilder

Single instancevalidation

XBRL

PublicTaxonomy

PrivateTaxonomy

Inter-instancevalidation

XBRL



Validation engine with storage integrated solutionsTaxonomy designers defines rulesXBRL engine knows where to get proper instance documentsState of the art of technology?


XBRL Storage and operation

Which is the best solution to store XBRL data?Relational databases?XML databases?Mixed solutions?


Versioning

How to minimize the impact of new versions on our systems?How to deal with new versions of taxonomies imported by our taxonomies?How to compare data defined by different versions of the same taxonomy?


Link role registry

XBRL taxonomies define:Business conceptsRelations between concepts

There is a set of standard relations:Calculation linkbaseReference linkbasePresentation linkbase ...

But XBRL allows user-defined arc-roles: user-defined relationsXBRL International’s Link Role Registry to include user-defined arc-rolesEfficient way to extend XBRL without touching core specification

Should we promote to the link role registry arc-roles that cover our common needs?

Information Systems and Processes

Thanks for your attention !Ángeles Lozano, Víctor Morilla


Design stage: business rules

Current XBRL specification has limited validation capabilitiesXBRL Formula will not be available in short timePossible solutions:

–Define our own implementation of formulas•XBRL allows user defined arc roles and attributes•Flexible, but expensive solution

–Use a propietary formula implementation•State of the art of formula and dimensions ?

–Develop specific code to solve your current needs


Design stage: taxonomy driven model

XBRL taxonomies define:–Business concepts–Relations between business concepts–Relations between business concepts and other resources

XBRL is a comprehensive language to express metadata

Changes in the taxonomy should not impact on the systemTaxonomies as an input:

–More flexible–Reduce errors–Only structural changes need development

Let the taxonomy be your guide !


Design stage: cache issues

High number of documents in short timeXBRL validation can be a heavy processBut, loading XBRL taxonomies is the more expensive oneCache mechanismsEntry points simplify the problem

Nu

mb

er

of

docu

men

tsre

ceiv

ed

Due data Due data

Submission period Submission period


Reporting process

COREP defines a closed reporting model:

–COREP templates reject facts not expected–But XBRL (using standard arc roles) cannot check data that MUST be sent.





•Allow more than one format–Easiest for financial entities–Two formats must be maintained

National Bank


entity

Financialentity

xml xbrlxbrl





•Allow more than one format•Only XBRL

–Key: establish a fluent relationship with bank’s software providers

National Bank


entity

Financialentity

xbrl xbrlxbrl





•Allow more than one format•Only XBRL•XBRL is the only format allowed, but providing a translation tool

–Very similar to German solution–Entities to consider providing XBRL directly–Translation tool must be maintained

National Bank

Financialentity

Financialentity

Financialentity

xbrl xbrlxbrl

txt


Design stage: visualization service example

Front-end

Financialentity

XBRL HTML

XBRL HTML

XBRL Services

XBRL engineAPI

Taxonomy


COMPILE TIME

RUN TIME


Front-end

Financialentity

XBRL HTML

XBRL engineAPI

XSLTXSLTProcessor

Taxonmy

XSLT


Financial Entity


Front-end

XSLT

XSLT

Javascript

Javascript

XSLTProcessorXBRL XSLT

HTML


Reporting process: extending the European taxonomy

Documents

Index