Index

2. Index Good practices and considerations Problems Future challenges

3. Good practices and considerations

4. 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

5. XSLT Processor XSLT XSLT Producer Taxonomy Taxonomy driven model example XBRL Document HTML Document

6. Taxonomy driven model • Benefits: • More flexible design • Reduce errors • Only structural changes need development Let the taxonomy be your guide !

7. Taxonomies and data models • Avoid designing taxonomies based on specific views of the data • Analysts should see the data model behind

8. Taxonomies and data models • 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

9. With a good design: Two items: Incomes Expenses Two dimensiones: Country dimension (Spain, Italy, France...) Product dimension (TVs, Radios, Fridges...) Taxonomies and data models countries items products

10. Taxonomies and data models • Total incomes by country should be equal to total incomes by product • This rule is implicit to the model • Calculate 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

11. 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

12. Reporting process • The reporting process is defined by: • Communication channel • XBRL Taxonomy • Instance documents • Additional data

13. 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 combinations • Empty schemas that refer to predefined combinations of taxonomy files

14. COREP multidimensional data model Reporting process: taxonomy entry points • 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 model • Some COREP templates overlap

15. Reporting process: taxonomy entry points • 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

16. Reporting process: constrains on instance documents • Monetary unit • Precision • Number 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

17. Reporting process: additional data • Taxonomies define business data • Reporting 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

18. 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

19. 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 xml xbrl xbrl Financial entity Financial entity Financial entity General project considerations

20. XBRL as the only format available to file data? XBRL scares people Several choices: Allow more than one format Only XBRL Key: establish a fluent relationship with bank’s software providers General project considerations National Bank xbrl xbrl xbrl Financial entity Financial entity Financial entity

21. XBRL as the only format available to file data? XBRL scares people Several choices: 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 General project considerations National Bank xbrl xbrl xbrl Financial entity Financial entity Financial entity txt

22. General project considerations • 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

23. General project considerations • Providing helper services • Instance validation tool • Instance visualizing tool • Taxonomy dictionary • Taxonomy browser • Or relying on third parties to provide this services

24. General project considerations • 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

25. General project considerations • 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

26. Problems

27. 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

28. 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 ?

29. Calculation linkbase allows definitions of summation items networks Other basic arithmetic operations are not allowed With formula linkbase will be possible Summation across dimension members is not possible With formula linkbase will be possible Possible = adequate ? Calculation linkbases are extensible Formulas linkbases will be But individual formulas won’t Calculation linkbase not enough

30. A=10 • B=5 • C=2 • D=3 • A=10 • B=5 • C=0 • D=0 • A=10 • B=5 OK Wrong! Wrong! 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

31. Modularization • Modularization should make easier reusing available taxonomies • Instead of importing the whole taxonomy, you just import a part • It 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)

32. COREP dependencies graph of t-mi template

33. COREP dependencies graph of t-mi template Spanish extension

34. 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

35. Challenges

36. <2005 Complex validations Financial statements (flat files) Complex validations 2005 Basic validations Basic validations Public statements (XBRL) Other statements (flat files) Other applications Complex validations 2007 Complex validations Complex validations PE, Basel II (XBRL) Other statements (flat files) Complex validations Complex validations 200? Complex validations Financial statements (XBRL) Complex validations Complex validations 20?? Financial statements (XBRL) Evolution of the SIIF project Bank of Spain Financial entities FIN (Mainframe) SIIF (XBRL)

37. 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

38. Inter-instance validation • Validations between different time periods • Validations between different statements • Validations with data from other systems • Current calculation and formula linkbases work on instance document level • Inter-instance validation is not considered

39. 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? Single instance validation Public Taxonomy XBRL Private Taxonomy XBRL Inter-instance validation Inter-instance validation Financial entities XBRL Instance builder

40. Inter-instance validation • Validation engine with storage integrated solutions • Taxonomy designers defines rules • XBRL engine knows where to get proper instance documents • State of the art of technology?

41. XBRL Storage and operation • Which is the best solution to store XBRL data? • Relational databases? • XML databases? • Mixed solutions?

42. 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?

43. Link role registry • XBRL taxonomies define: • Business concepts • Relations between concepts • There is a set of standard relations: • Calculation linkbase • Reference linkbase • Presentation linkbase ... • But XBRL allows user-defined arc-roles: user-defined relations • XBRL International’s Link Role Registry to include user-defined arc-roles • Efficient way to extend XBRL without touching core specification • Should we promote to the link role registry arc-roles that cover our common needs?

45. Design stage: business rules • Current XBRL specification has limited validation capabilities • XBRL Formula will not be available in short time • Possible 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

46. 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 system • Taxonomies as an input: • More flexible • Reduce errors • Only structural changes need development Let the taxonomy be your guide !

47. Due data Due data Submission period Submission period Design stage: cache issues • High number of documents in short time • XBRL validation can be a heavy process • But, loading XBRL taxonomies is the more expensive one • Cache mechanisms • Entry points simplify the problem Number of documents received

48. 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. Reporting process

49. 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 xml xbrl xbrl Financial entity Financial entity Financial entity General project considerations

50. XBRL as the only format available to file data? XBRL scares people Several choices: Allow more than one format Only XBRL Key: establish a fluent relationship with bank’s software providers General project considerations National Bank xbrl xbrl xbrl Financial entity Financial entity Financial entity