Implementing XBRL Formulas 
11 
Table 4 ExistingOf and ExistingNonEmpty Functions 
3.4  Dependencies 
Certain formula functions depend on the results of other formulas and are primarily used in processing 
characteristic data. For example, RR0002 is considered a variable in Example B. If RR0002 is true and 
RCFD0074 exists, then the formula processor proceeds to the next formula; if RR0002 is false, then the 
formula processor returns an error message. XBRL does not provide any guidance on processing 
formulas or data with dependencies from other sources. The agencies developed their own formula 
process model to accommodate business-specific functions and processing. 
3.5  Processing 
Characteristic formulas are expressed to handle two processing models, pre and post. Then agencies 
developed a custom formula processor to handle both pre- and post-processing of XBRL formulas. 
These processing requirements were implemented using custom functions, such as ExistingNonNil. 
Characteristic and consistency formulas follow different processing models. Consistency expressions 
are defined to process data and provide a result. Characteristic expressions are defined to process data, 
provide a result, process the result, and provide a second and final result. This type of “cascading” data 
processing is a critical step to understand how financial data are processed in CDR. Validation must 
follow a fixed order of execution to provide a proper result. Figures 5 and 6 illustrate an overview of 
the cascading formula pipeline used by CDR. 
Figure 5 Cascading Formula Pipeline – Consistency 
Consistency formulas follow a basic process: formulas applied to input data produce result messages 
(see Figure 5). Starting with input data, the processor applies a formula and returns a result message 
only if the formula returns the value “false.”  
Convert pdf to tiff - control Library platform:C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net, ASP.NET MVC, Ajax, WinForms, WPF
Online C# Tutorial for How to Convert PDF File to Tiff Image File
www.rasteredge.com
Convert pdf to tiff - control Library platform:VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.net, ASP.NET MVC, Ajax, WinForms, WPF
Free VB.NET Guide to Render and Convert PDF Document to TIFF
www.rasteredge.com
Implementing XBRL Formulas 
12 
1.  Set of reportability questions proposed to financial institution 
2.  Institution answers reportability questions (a process creates data for 
answers) 
3.  (Rules applied to reportability instance) 
4.  (Intermediate result is returned) 
5.  (Edits are applied to the intermediate result) 
6.  List of required variables are returned 
7.  (Software may “gray-out” or not include certain variables in financial 
report software.) 
8.  Report data filled out by financial institution 
9.  (Report instance created and consistency formulas are applied) 
10. Validation results are provided to financial institution (via software) 
Figure 6 Cascading Formula Pipeline – Characteristic 
By contrast, characteristic formulas are designed to execute in a fixed order with a processor executing 
a “starter” set of formulas called “reportability rules.” Reportability rules are applied to financial 
institution reportability data which return an intermediate result. A second set of “filter” formulas, 
called “reportability edits,” are applied to the intermediate data, which return a result such as “Bank 
Has Domestic Offices Only with Trading Accounts.” The result is a list of variables a financial 
institution must report for a given Call Report period. 
3.5.1  Pre-Submission Processing Model 
Figure 7 details the pre-submission model with parentheses delineating a process in vendor software 
not visible to a financial institution.  
Figure 7 Pre-Submission of Formulas 
In pre-submission, the overall outcome is to provide a list of variables that must be reported by a 
financial institution. Vendor software used by the financial institution then has the option of presenting 
only the variables that must be reported based on reportability edit results. The financial institution 
inputs data into the software and then applies consistency formulas which result in failure messages if 
data validation fails. 
3.5.2  Post-Submission Processing Model 
Validation performed by the agencies before data are stored in CDR  based on the post-submission 
model. The input document to start validation is reported data, as opposed to a reportability instance. 
Steps to produce data validation are slightly different, but the processing of formulas is the same and 
must follow a set order to provide the correct result. Figure 8 describes the post-submission model with 
parentheses delineating a process in CDR. 
control Library platform:Online Convert PDF file to Tiff. Best free online PDF Tif
Using this .NET PDF to TIFF conversion control, C# developers can render and convert PDF document to TIFF image file with no loss in original file quality.
www.rasteredge.com
control Library platform:Online Convert PDF file to Word. Best free online PDF Conversion
Download Free Trial. Convert a Tiff/Tif File to PDF. Easy converting! We try to make it as easy as possible to convert your Tiff/Tif files to PDF.
www.rasteredge.com
Implementing XBRL Formulas 
13 
Figure 8 Post-Submission of Formulas 
In post-submission, the result is to provide a notification to the financial institution with possible errors. 
When the CDR receives a report instance, a process identifies the reporting institution and retrieves 
prior-period reportability data. CDR creates a composite instance of the reported data and reportability 
data. Characteristic and consistency formulas are applied sequentially to the composite instance (first 
characteristic then consistency). 
3.6  Processing Reduction 
The CDR formula processor applies consistency formulas only to data reported in a report instance. 
That is, if a financial institution does not report a set of variables, the processor does not execute 
formulas that contain the missing variables.  
Characteristic formulas are designed to ensure that a financial institution is reporting its minimum 
requirements, but these formulas do not preclude a financial institution from reporting more 
information than is required. If a reporting institution reports more data than is required, by 
reportability rule standards, those data are subject to additional consistency formula processing. Figure 
9 sets forth the execution process of formulas and data. Formulas 1, 2, and 4 are applied to the report 
instance, and Formula 3 is ignored.  
Figure 9 Application of Formula Processor 
 Implementing XBRL Formulas 
The FDIC has been involved with the XBRL consortium since 2000 and became an official member in 
1.  CDR receives a report instance from financial institution 
2.  (CDR identifies reporting institution and returns prior period reportability data) 
3.  (CDR creates composite of a report instance and a reportability instance) 
4.  (CDR applies characteristic and consistency formulas to composite instance) 
5.  Validation returns a list of required variables and any possible consistency failures 
control Library platform:Online Convert Excel to PDF file. Best free online export xlsx
Download Free Trial. Convert a Excel File to PDF. Easy converting! We try to make it as easy as possible to convert your xlsx/xls files to PDF.
www.rasteredge.com
control Library platform:C# Create PDF from Tiff Library to convert tif images to PDF in C#
filePath). Description: Convert to PDF/TIFF with specified zoom value and save it on the disk. Parameters: Name, Description, Valid Value.
www.rasteredge.com
Implementing XBRL Formulas 
14 
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-
based formulas. 
4.1  Vision 
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. 
4.2  Development 
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 
control Library platform:C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in C#.net
C# PDF - Convert PDF to JPEG in C#.NET. C#.NET PDF to JPEG Converting & Conversion Control. Convert PDF to JPEG Using C#.NET. Add necessary references:
www.rasteredge.com
control Library platform:VB.NET PDF Convert to HTML SDK: Convert PDF to html files in vb.
Convert PDF to HTML. |. Home ›› XDoc.PDF ›› VB.NET PDF: PDF to HTML. Convert PDF to HTML in VB.NET Demo Code. Add necessary references:
www.rasteredge.com
Implementing XBRL Formulas 
15 
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.  
4.3  Advancement 
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.  
 Discussion 
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 
control Library platform:C# PDF Convert to Word SDK: Convert PDF to Word library in C#.net
DocumentType.DOCX DocumentType.TIFF. zoomValue, The magnification of the original PDF page size. Description: Convert to DOCX/TIFF with specified resolution and
www.rasteredge.com
control Library platform:VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
PDF from RTF. Create PDF from Text. PDF Export. Convert PDF to Word (.docx). Convert PDF to Tiff. Convert PDF to HTML. Convert PDF to
www.rasteredge.com
Implementing XBRL Formulas 
16 
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. 
5.1 Performance 
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 
file.
9
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 
17 
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. 
 When validating Call Report data with formulas, the processor consumes all report 
presentation metadata along with the formulas.  
2.  Data validation time is increased. 
 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 
increased.  
3.  A formula linkbase includes formulas for whole data series (or two related data series). 
 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-
report. 
4.  A special process requires custom functions and a processor. 
 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 
accommodate these. 
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 
18 
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 
formulas.  
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 
taxonomies.  
 Conclusions 
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 
formulas. 
ɷ
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: 
 Ability to define functions 
 Ability to define business-layer functions 
 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 
19 
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 
business issues.   
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 
in:  
Mapping financial variables between two government agencies.  
Extending base or industry taxonomies. 
Filtering a taxonomy to a “light” version. 
 Acknowledgements 
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 
20 
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 
Architects. 
 References 
XBRL 
Engel, Phillip W., Walter Hamscher, Geoffrey Shuetrim, David vun Kannon and Hugh Wallis. 
Extensible Business Reporting Language (XBRL) 2.1. (2006).  
[http://xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2006-12-
18.htm] 
XML Schema 
World Wide Web Consortium. XML Schema. (2008).  
[http://www.w3.org/XML/Schema]  
XLink 
World Wide Web Consortium. W3C XML Pointer, XML Base and XML Linking. (2008). 
[http://www.w3.org/XML/Linking] 
Micro Data Reference Manual 
The Federal Reserve Board. Micro Data Reference Manual. (2008). 
[http://www.federalreserve.gov/reportforms/mdrm/] 
CDR Interchange Specification 
Montoya, Mark A. and Sunil Matte. CDR Interchange Specification. (2007).  
[http://www.ffiec.gov/find/taxonomy/index.html] 
Improved Business Process Through XBRL 
Federal Financial Institutions Examination Council. Improved Business Process Through XBRL: A Use 
Case for Business Reporting. (2006).  
[http://www.xbrl.org/us/us/FFIEC%20White%20Paper%2002Feb2006.pdf]  
Documents you may be interested
Documents you may be interested