XBRL Versioning: A user centered approach

XBRL Versioning:A user centered approach César Pérez-Chirinos Secretary of Development & Training Working Group (GTDF) of XBRL Spain

About the Development & Training Working Group (GTDF) of XBRL Spain • The Development & Training Working Group of XBRL Spain was set up as part of the initial design of the Spanish Jurisdiction. It was chartered to contribute to XBRL success in Spain acting as a risk reduction tool for XBRL early adopters • GTDF is the Spanish acronym of this group, just in case you spot it in XBRL Spain’s papers • Our role is to identify best (or bad!) practices to be adopted (or avoided!) in XBRL-intensive projects. Focus on training was expected to be a major risk reduction activity

About this presentation • It reflects the author’s view on XBRL versioning, trying to convey the lessons learned working with the XBRL users, both business and technical experts at Banco de España (the Spanish central bank) along the last 18 months, and also with the international experts working in the COREP project. It is not a formal position of Banco de España on the subject • It was formally approved GTDF in November 2005, and it is an input document for further work on versioning by the GTDF, as part of the current effort to develop a life-cycle methodology for XBRL Value Chains

The “instant success” of XBRLin Spain • Since it was set up in April, 2004, the Spanish Jurisdiction has been pushing the adoption of XBRL with so much success that: • Since June, 2005, ALL the enterprises traded on Spanish stock market report their financial status to CNMV (the Spanish stock exchange regulator) using XBRL. The CNMV publish in its Web this reports as soon as the XBRL instances are validated • Since June, 2005, financial institutions legally operating in Spain can report to Banco de España their financial status using a taxonomy based on IASB-IFRS. This is the second taxonomy that Banco de España has delivered to production status in one year. And there are several in the pipeline… • The project COREP, leaded by Banco de España and aimed to define an European-wide base taxonomy for bank risk reporting to supervisors (in accordance with Basel II), encouraged XBRL community to standardize the usage of Dimensions • So, why are we so worried about versioning now?

Versioning is about keeping the XBRL promise • From business users perspective, XBRL was “bought in” as a solution to flexibility required by financial reporting: • Regulators, like CNMV and Banco de España, need to adapt the reporting laws and by-laws to catch up with business practices and new financial services that could impact on investor’s trust. And they need to do it without adversely impacting the investments on information systems of running companies • Organizations reporting their financial status to regulators need to be able to quickly adapt their reporting systems to changes in regulation • As we are already running XBRL reporting chains, the business users are beginning to ask: “Hey folks, how do we change this now?”

Expectations on XBRL Versioning are high • Our business users expect that introducing a change to a XBRL-enabled reporting chain should be an easy (or, at least, fast) task: something that can be done in few days • And we, the XBRL community, need to satisfy this expectation that was created in the old times of Charlie Hoffmann, when we were writing taxonomies with a text editor, and it seemed that financial people and computers could read and write the same XML files so “future changes will be easy to do” • But… • What are the implications of a “business user change request” in an already running XBRL reporting chain? • What could happen if XBRL cannot fit the above expectation, no matter if this is a fair one?

An informal SWOT Analysis of XBRL Versioning • Strengths • XML is probably the best foundation for versioning available • Users expect XBRL value chains to be easily adaptable to business needs, and are betting on it • Weaknesses • Users expectations on XBRL adaptability could have gone beyond of what can be delivered in reasonable time • Opportunities • A practical solution to XBRL versioning will consolidate XBRL position, probably for many years • Threats • Failure to provide a good versioning solution would severely harm XBRL future • Regulators can be tempted return to pure XML solutions • The business potential of XBRL reporting chains will never realize if cost of versioning to third parties (analysts, rating agencies, …) is higher than current expectations due to complexity of solution

XBRL Versioning is not an obvious concept • Are we sure that a technical solution documenting some changes to be applied to an existing DTS to achieve the next one would solve the problem that business users call “versioning”?

XBRL Versioning is not an obvious concept • From business user point of view, XBRL versioning is ALL what is needed to run an improved version of a XBRL reporting chain: • New reporting needs (or problems in existing reporting chain, including performance related ones) have been identified and documented as change requirements • The identified needs have been reflected in an improved DTS • When required, the improved DTS has been approved by proper Jurisdiction, ideally after rigorous testing. In some cases, even enacting legally the changes should be done at same time • The automated systems in senders and receivers of XBRL instances have been adapted to, and/or can coexist with, the improved DTS. The time required to implement the adaptation should span few days • A technical solution to standardize the changes to be applied to an existing DTS to achieve the next one only address point 2 above. Point 3 calls for an improvement of our approval processes. • But if we can’t provide a good framework to allow Point 4 to be feasible, XBRL community will be at risk of being blamed by business users of not being able to solve “the versioning issue”

XBRL Versioning: Where are we targeting our effort? • Our feelings were mixed with regard to on going effort on Taxonomy Versioning requirements when we approved this presentation • The use cases seems very good from the conceptual point of view. Some of them even reflect real problems we face recently • But aren’t they assuming a hand-made approach to taxonomy writing and maintenance? This manual process is (should be?) almost gone • At that time, we were tempted to say that “the users” that the IWD was talking about were, in fact, the existing programs for taxonomy edition!!

Versioning XBRL: Does taxonomy versioning makes sense? • The impressive work conducted by IASCF XBRL Team, summarized in a huge Excel spreadsheet, raises even more doubts about if a versioning approach limited to the technical problem of how to document the changes to a DTS would be the right answer to XBRL versioning problem as business user perceives • How to avoid regression problems? • How to assure business coherence across versions? • How to assess the impact on preparers and receivers automated systems using existing version of a taxonomy?

Versioning XBRL: Two taxonomy versioning technologies competing to save the day • With so fuzzy scenario, the logical result is that we had to two competing approaches to solve the taxonomy versioning issue: • The syntactic oriented approach: Let’s DTS files speak by themselves, and use existing XML (or pure text –CVS like-) versioning tools to extract the textual differences • The semantic oriented approach: Let’s express the differences between two successive DTS, using something like RDF, to be able to understand the business meaning of differences • This conflict is now “frozen”, but not gone

XBRL Versioning: Can the business users requirements help to select one of the two? • Two years ago, what business users claimed was “When will we have a workable taxonomy editor?”. Now that they have several editors to choose from, taxonomies are quickly becoming for them “software artifacts” of their XBRL value chains: • Compliance of XBRL 2.1 Standard, and even most of FRTA specifications, are taken for granted and a tool’s responsibility • Most of them have the same interest about syntactic (or semantic) aspects of taxonomies than a typical Access user in digging into the SQL generated for the database server: none • What the business user would say us, if they could understand the question ;-), is “Do it as you want, as far I can do my changes with an easy to use tool, and my technical people can’t say me ‘We don’t know how to apply the changes that the tool introduced in the DTS to our systems’. And, please do it now”

XBRL Versioning: What are the current and future roles of taxonomies in value chains? • Surprisingly, this [lack of] answer can help us a lot: • We can expect that as soon as XBRL consolidates, only tools –and very few experts with naked eye- will be interested -and able- in reading XBRL taxonomies and instance files • Former role of taxonomy for business users as vehicle to document unambiguously conceptual models representing a group of related reports, is no longer visible to business users • DTS will become some kind of e-contracts, published through an XBRL Jurisdiction acting as QA and escrow body, expressing without any ambiguity a succession of agreements among the links of an XBRL value chain • The main role you can expect to be played in near future by DTS is the automated generation of instance visualization, adapter software (stubs) to existing systems, and as testing resource for the XBRL value chains • This implies that, to be useful to business user, XBRL versioning must be solved at value chain level

XBRL Versioning: An alternate approach • We believe that solving XBRL versioning problem at value chain level should be based on top of a metamodel of current standard, shared by any XBRL enabled tool, or process, required to build and maintain the value chain • The metamodel only need to extend the object model of current standard to provide explicit support of life cycle of DTS concepts • Tools based on this metamodel could exploit the advantages of semantic versioning, without RDF complexities, as minor changes to the standard could allow DTS to contain a log of changes in metamodel’s terms (perhaps in another linkbase needed only by versioning enabled tools, for backward compatibility) • And we shouldn’t forget to revise our approval processes to check if we are agile enough when dealing with corrective changes

XBRL Versioning: This alternate approach has additional advantages • In fact, currently exist some implementations of a metamodel of current standard: every taxonomy editor must have one inside! • An agreement on a common metamodel for versioning of XBRL 2.1 DTS, perhaps expressed in XMI, could cause some positive side effects: • If tools share the metamodel, the tools makers will send a clear sign of maturity to business users about securing their investment on tools and derivations from published taxonomies • If the metamodel were expressed in XMI, we will provide interoperability with UML tools. This should make life easier for technical users implementing the XBRL adapters to operational systems • Last, but not least, the metamodel would act as bridge to interoperability with what we call “adjacent standards” like SDMX. So, XBRL could play the role of “hub standard” for all the economy related standards, securing his current position

Thanks for your attention • ¿Questions? (shy people can mail to: cesar.perez-chirinos @ bde.es)

XBRL Versioning: A user centered approach