Index - PowerPoint PPT Presentation

slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Index PowerPoint Presentation
play fullscreen
1 / 55
Index
170 Views
Download Presentation
orien
Download Presentation

Index

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Index Good practices and considerations Problems Future challenges

  2. Good practices and considerations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  25. Problems

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

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

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

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

  30. 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)

  31. COREP dependencies graph of t-mi template

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

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

  34. Challenges

  35. <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)

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

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

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

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

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

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

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

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

  44. 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 !

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

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

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

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