Implementing XBRL Formulas
2001. It was an early adopter of the XBRL specification and started taxonomy development work using
XBRL v1. The first taxonomies developed using XBRL v1 were the FRB Micro Data Reference
Manual (concepts.xsd) and the FRB National Information Center (NIC), which contains reportability
data for all financial institutions. These early taxonomies defined metadata and concept relationships
successfully but did not provide a good solution for XBRL formulas. Early drafts of the taxonomy
frameworks included a template for XBRL formulas with formula names and definitions. However,
formula expressions were not included. XBRL v1 schema and calculations did not provide the
functionality needed for formulas.
The release of XBRL v2, which included XML technology for linking schema resources, provided the
agencies with the functionality to create a formula taxonomy. The new XBRL v2 specification
provided a better taxonomy design model that enabled the agencies to create a modular taxonomy
framework with a common taxonomy schema. The Federal Reserve’s MDRM, a dictionary of shared
data names, has become the foundation for all other FFIEC report taxonomies. XBRL v2 linkbases
allowed the agencies to create custom linkbase files for report instructions and formula messages
(based on the label linkbase). XBRL v2 enabled the agencies to create a presentation solution for
representing a financial reporting form with rows and columns (a combination of presentation and
reference linkbases). Most importantly, XBRL v2 provided functionality to design and create XBRL-
The FDIC conducted a pilot project that provided the foundation for the current CDR system. The pilot
project included a proof of concept (POC) that was essentially CDR in a nutshell. The POC included a
working demo of a Call Report processing application that resided in an Access database. The demo
application included six processes: Legacy Data Import, Taxonomy Creation/Distribution, Software
Vendor Simulation, XBRL Instance Submission, XBRL Instance Validation/Store, and Data
Distribution. An XBRL v2 Call Report taxonomy, which included a formula taxonomy, was developed
for the POC demo. The report and formula taxonomies were fully functional and successfully validated
Call Report instances with formula result messages. The POC formula taxonomy consisted of a
formula schema which defined certain formula expression attributes such as formulaLink and
formulaArc. The formula taxonomy included a formula taxonomy schema which defined FFIEC-
specific attributes, such as formula names and formula message enumerations. The formula taxonomy
included two linkbase files, one for formula expressions and one for formula messages. The formula
expressions linkbase used XPath syntax to express consistency formulas and included global
declarations, such as “P0” for the current period and “-Q1” or “-PY1” for prior-period offsets. The
formula messages linkbase included text messages for formula failure messages, such as “Assets this
quarter must be greater that last quarter. Please review data and resubmit.” In addition, XSL style
sheets were used to validate Call Report instances with formulas.
The FDIC developed and enhanced the FFIEC taxonomy framework and initiated development on the
XBRL Business Analyst Tool (xBAT). This tool marked the beginning of a full CDR implementation
using XBRL as the exchange mechanism and brought the POC demo into reality. The Call Report and
formula taxonomy design remained virtually the same but included absolute and relative context
Implementing XBRL Formulas
references. Call Report taxonomies are published on a calendar quarter. However, formula expressions
reference prior period data, and a formula processor will need a point of reference when processing
data with formulas. The xBAT formula taxonomy included absolute context definitions, such as “P0”
for current period or “P1” for one period prior. The xBAT formula taxonomy also included relative
contexts, such as “–P1Y” for the prior year or “–P1Q” for the prior year quarter. The xBAT formula
taxonomy was a simple implementation of XBRL formulas and did not contain any special functions or
processes, such as reportability. The xBAT formulas followed a simplistic implementation of cascading
data validation where formulas process report data and provide a result message. Formula expressions
did not require a special or custom processor to process formulas with data, but the final release of
xBAT did provide a mechanism to validate report or formula taxonomies with instance data. The
formula design was sufficiently simple so that any off-the-shelf XML processor could be used to
process the formulas with instance data. Also, xBAT provided Call Report formulas in a separate
formula taxonomy. This allowed a software vendor to process formulas with data without having to
consider the report taxonomy based on financial reporting forms.
Building on the foundation work produced by the POC demo and xBAT, the Metadata Management
Tool (MMT) was developed to maintain and publish Call report taxonomies for CDR. MMT
introduced major changes to the existing FFIEC taxonomy framework. The taxonomies were updated
from XBRL v2 to v2.1 and introduced taxonomy design changes. The FFIEC taxonomy framework
included report taxonomy with formulas and characteristics taxonomy with formulas. The most
important changes were the removal of a formula taxonomy and the inclusion of a formula linkbase in
the report taxonomy. These changes placed the formulas at the level of report presentation, and formula
definitions are now included with financial report presentation variables. MMT also introduced a
characteristics taxonomy which allowed the agencies to verify that a financial institution is reporting
the correct data.
4.4 Software Vendors
In 2004, the agencies began exchanging XBRL taxonomies with Call Report software vendors. Call
Report software vendors became the first non-XBRL software companies to consume and develop
software based on XBRL taxonomies. The agencies started weekly communication with software
vendors and provided ongoing assistance. As development continued, vendor questions became more
focused in the areas of schema validation, reporting null variables, whether multiple instances could be
submitted as one, and if numbers should be reported whole or in thousands. The XML and XBRL
specifications did not provide guidance in certain situations, and other situations did not match agency
business practices. The agencies created the CDR Interchange Specification which provided additional
guidance for software vendors and added a business-specific layer to the XBRL 2.1 specification to
address agency technical and business requirements.
XBRL formulas can be used successfully in government and corporate projects to ensure data
consistency and improve business processes and transparency through increased pre-validation of
reported data. However, certain issues arise when implementing XBRL formulas on a large-scale
enterprise project. Although it is not the purpose of this paper to discuss implementation issues, four
Implementing XBRL Formulas
areas of concern have been identified that must be considered for a system using XBRL formulas.
Areas of concern may be classified as project specific, and some can have an adverse effect on a
formula implementation. The agencies are more advanced than other U.S. organizations in
implementing XBRL, and consequently agencies’ experience is strongly influencing the XBRL draft
specifications. In both cases, XBRL formulas work and must be considered for any financial regulatory
entity or auditor that ensures consistency for financial data. Each issue was either an effect of, or had an
effect on, the formula decision and design. Issues encountered include: (1) performance, (2) taxonomy
design, and (3) migrating to new formula specifications.
The agencies have implemented an Internet-based system for collecting and processing financial
regulatory reports submitted by approximately 7,900 financial institutions. Financial data submitted to
the system are validated with XBRL formulas immediately upon receipt, and an e-mail notification
with possible validation failures is sent to the submitter. The CDR system does not translate the XBRL
formula expressions into another format, such as SQL or Java script. Instead, the CDR system uses an
XBRL processor (UBMatrix Automator) to process XBRL formula expressions with financial data.
The natural state of using XBRL and not SQL code came into question when CDR experienced slow
data processing response time.
Formula processing using XBRL is slower than when using mainframe or SQL code. This became
evident when the FDIC moved from a Call Report processing mainframe environment to the new
Internet-based environment. CDR experienced performance problems in late pre-production tests. Pre-
production performance problems were based on taxonomy design, particularly when the formula was
included in the report taxonomy as opposed to a separate formula taxonomy. XBRL-aware processors
follow Discovery Taxonomy Set (DTS) rules which follow a set path when processing a taxonomy
That is, the DTS will discover any schema or linkbase references defined in a given instance and
proceed to load the information in memory. When an instance is processed in CDR, the processor then
loads the report taxonomy which includes not only the formula but also report instructions and the
report presentation. The discovery of a complete report taxonomy during formula processing adds time,
resulting in slow performance. The issue was compounded if multiple prior-period amendments were
resubmitted or a single prior-period validation occurred. The issue was addressed by caching current-
period and prior-period taxonomies.
Performance issues have been substantially addressed and improved and should not be a significant
issue for similar future implementations. Additionally, the benefits of having sophisticated rules
abstracted from specific systems improve the portability and transparency of the metadata as well as
the maintainability of the system.
5.2 Taxonomy Design
The FFIEC taxonomy design has been through many development iterations, but only two designs have
been available for public use. The first taxonomy framework included a report taxonomy and a formula
“Overview of XBRL Instances” http://www.xbrl.org/SpecRecommendations/
Implementing XBRL Formulas
taxonomy. The report taxonomy captured Call Report form attributes such as rows/columns, line-
number labels, and reporting instructions. The report taxonomy was designed to preserve the layout of
a paper-based financial report. The formula taxonomy captured consistency formulas for a particular
data series, such as the Call Report or the Bank Holding Company Report. Formula attributes included
formula name identifiers, such as “031/041” or “Y9C/Y9B,” and error message enumerations and
global constants, such as absolute and relative contexts. The framework design separated report
presentation from data validation and allowed a processor to validate data without the overhead
contained in a report taxonomy.
The current taxonomy framework design includes a report taxonomy and a characteristics taxonomy.
The formula taxonomy has been subsumed within the report taxonomy. With the exception of the
formulas, the report taxonomy includes all previous Call Report form attributes. Formula definitions
have been moved to the report taxonomy, and formula expressions and error messages are captured in
linkbase files. A characteristic taxonomy captures reportability rules and edits for a particular data
series. The CDR kept each XBRL instance associated permanently with a single discoverable
taxonomy set consisting of schemas and linkbases. XBRL assumes a single validation, processing, and
display step; therefore, a multi-step process applied to instances with a single fixed DTS has
consequences for performance:
1. Formulas are directly associated with a presentation.
o When validating Call Report data with formulas, the processor consumes all report
presentation metadata along with the formulas.
2. Data validation time is increased.
o As stated in 1 above, since a processor must first consume the report taxonomy before
starting the process of applying a formula with Call report data, processing time is
3. A formula linkbase includes formulas for whole data series (or two related data series).
o A formula linkbase contains remnants of the formula taxonomy which contains all formulas
for a particular data series. Report taxonomies are essentially a filtered context of a data
series. That is, the Call Report data series consists of two contexts, a 031-report taxonomy
and a 041-report taxonomy. Formulas in a 031-report contain formulas belonging to a 041-
4. A special process requires custom functions and a processor.
o The formula processor must understand business logic and have a cascading formula model
which is prevalent in both consistency and characteristic formulas. At this time, additional
syntax, custom formulas, and processing are needed in the formula processor to
5.3 Migrating to a New Formula Specification
The agencies have devoted many hours to the design and testing of XBRL formulas. Most of the
development time focused on implementing a formula expression language in a new system using an
XBRL formula processor. The initial formula design was simplistic and included consistency formulas
only. Initial drafts of the agencies’ formulas used the xPATH language to express the formulas and did
Implementing XBRL Formulas
not include special functions. The formula design successfully captured consistency formulas,
processed them with Call Report data, and provided a result message. This process was accomplished
using off-the-shelf tools such as MSXML and XSLT style sheets.
The initial formula design was developed and reviewed by Call Report software vendors, XII members,
and agency staff until the development of CDR. The primary driver behind changing the initial formula
design from xPATH to the current design using a proprietary formula language was the need for
advanced functions and a processor that could process these functions. Consistency formulas expressed
using XPath successfully processed Call Report data, but xPATH could not capture business logic
defined in special functions such as ExistingNonEmpty. The agencies needed a more robust formula
language to express characteristic formulas and a processor that could understand the processing model
defined by characteristic formulas. The agencies discussed the possibility of using another formula
standard, such as SQL or Java, but decided to use an XBRL processor with a functions library. The
second formula design included these special functions and a data model for processing characteristic
Agency developers spent considerable time developing an XBRL formula language for use with CDR,
including the design and testing of new formula logic to ensure the production of correct results. Many
hours of training were provided to agency staff and software vendors about how to understand and
work with a new formula language. These efforts can be leveraged in the future. However, this
assumes the final XBRL formula specification continues (as the public working draft version does) to
express the same language, similar functions, and linkbase syntax as found in the Call Report
This paper presents the federal banking regulatory agencies’ design and implementation of XBRL-
based formulas which are likely to strongly influence the final formula recommendation from XBRL
International. This paper also illustrates the classifications of formulas and how formulas are managed
and exchanged with stakeholders. The need was defined for XBRL-based formulas and the
requirements used in developing XBRL formulas; detailed examples of a new data validation model,
“cascading formula pipeline,” were presented. This paper provides a short CDR “lessons learned” and
discusses some areas of consideration when implementing XBRL formulas.
Finally, the federal banking regulatory agencies’ experience with implementing an XBRL solution is
much broader than the contents of this paper. However, this paper identifies some key observations for
implementing XBRL formulas:
Data must be structured and metadata must be well defined to successfully implement XBRL
Differences in processing XBRL formulas as opposed to database code must be considered.
XBRL formulas must be in an XML language that provides the following requirements:
o Ability to define functions
o Ability to define business-layer functions
o Must provide an XML Info Set or processing model
XBRL formulas must support transparency for exchange with other government agencies.
Participate in and influence XBRL groups—voice your requirements and share your experience
Implementing XBRL Formulas
for the benefit of all.
6.1 Future Direction
The federal banking regulatory agencies have taken XBRL to the next level with its implementation of
XBRL formulas. The agencies have defined a formula process model that uses XBRL formulas to
produce different data views. The influence of this model is evident in the consistency and
characteristic formulas. Consistency formulas, when applied to data, produce a result message.
Characteristic formulas, when applied to data, follow a sequential process of producing “filtered”
results. The model followed by characteristic formulas is called “cascading formula pipeline.” The
model can be applied to produce unique results in financial reporting and address some common
The agencies continue to struggle with a shift away from the collection of data based on a financial
reporting form. Similar to many government agencies, the federal banking regulatory agencies collect
data, and the mechanism of collecting data has traditionally been a paper-based financial form. All data
must have a context that assigns meaning, and the financial report form provides this context. The
financial report form does not assist in the paper reduction act, nor does it reduce reporting burden. The
agencies attempted to address this issue by creating two separate taxonomies, a report taxonomy and a
formula taxonomy. The report taxonomy maintains the financial report form and provides a context in
which a reporter can understand the data. The formula taxonomy provides expressions used for the
validation of financial institution data. The solution was only partial and did not reduce reporting
burden. Characteristic formulas were introduced to address the issue of collecting data based on a
financial report form.
Characteristic formulas provide a financial institution with a list of required financial variables. The
list does not contain all financial variables on the Call Report, but instead includes a filtered set. The
processing model followed by characteristic formulas does not have to be limited to required financial
variables but can be extended to include presentation variables as well. Characteristic formulas can be
expressed to return a report presentation based on the list of required financial variables. Processing
XBRL formulas will allow for “dynamic” report presentations based on financial data characteristics.
The agencies will pursue dynamic report presentations in future releases of its taxonomy framework.
The use of XBRL formulas to define and capture business rules is a major step toward achieving data
transparency across the U.S. government. XBRL formulas can be applied to various aspects of data
reporting and collections. In addition to the processes presented herein, XBRL formulas can also be use
Mapping financial variables between two government agencies.
Extending base or industry taxonomies.
Filtering a taxonomy to a “light” version.
The federal banking regulatory agencies’ implementation of XBRL could not have been successful
without the collaborative efforts and business decisions of multiple participants who influenced the
Implementing XBRL Formulas
final XBRL formula solution. The agencies would like to thank XBRL US and International for
supporting the Call Modernization project. Special thanks to Charlie Hoffman, David Vun Kannon,
Phillip Engle, Yufei Wang, Geoff Shuetrim, Phil Walenga, Steve Hord, and Sunil Matte for all of the
late night discussions and sanity checks. We would also like to thank Matasomo Goto, Herman Fischer,
Esteban Castorena, Giancarlo Aguilera, and Oxygen for various taxonomy comments and reviews.
Finally, we acknowledge and commend the efforts of the seven Call Report software vendors that
helped make this project a success: Jack Henry, Fidelity, DBI, IDOM, FRS Global, ITI, and Financial
Engel, Phillip W., Walter Hamscher, Geoffrey Shuetrim, David vun Kannon and Hugh Wallis.
Extensible Business Reporting Language (XBRL) 2.1. (2006).
World Wide Web Consortium. XML Schema. (2008).
World Wide Web Consortium. W3C XML Pointer, XML Base and XML Linking. (2008).
Micro Data Reference Manual
The Federal Reserve Board. Micro Data Reference Manual. (2008).
CDR Interchange Specification
Montoya, Mark A. and Sunil Matte. CDR Interchange Specification. (2007).
Improved Business Process Through XBRL
Federal Financial Institutions Examination Council. Improved Business Process Through XBRL: A Use
Case for Business Reporting. (2006).
Documents you may be interested
Documents you may be interested