Reportability Rules in the FIEC taxonomy are defined as formulas representing FFIEC business rules that govern reporting requirements. These rules evaluate to 'true' or 'false'.
Examples of Reportability Rules are as follows:
Concept representing the answer
Reportability Rule Name
|Did This Institution Ever Qualify As A Large Bank?
||C592 = ‘true’
|Did The Institution Acquire Another Bank Or Is The Institution A Denovo Insured Bank During The Calendar Quarter?
||A901 = ‘true’
One or more Reportability Rules are combined by the logical operator OR to form Reportability Edits. Reportability Edit follows the same syntax as that of validity and quality edits. Reportability edits are expressed using the 'If' statement. Reportability edits would be expressed using a 'formula' resource element with the role type 'http://www.ffiec.gov/xbrl/rule/ruleType4'
Reportability Rule/Edit Name
||cc:RCONB867[P0] = 1
||MonthOf(Context.PeriodEndDate) = 12
||(cc:RCONB894[-P1Y/12-end] + cc:RCONB895[-P1Y/12-end])>100000000
||If (RR1 OR RR2 OR RR3, ExistsNonNil(cc:RCFDB868) , TRUE)
To illustrate, using the previous table, RCFDB868--Personal trust and agency accounts MUST be reported if Reportability Rules RR1 or RR2 or RR3 are true (Reportability Edit RE50).
Reportability Edits are used to programmatically determine which concepts a FI MUST report in an instance document. Reportability Edits follow the same format and structure as the Validity/Quality Edits. The basic difference between Reportability Edits and Validity/Quality Edits is that Reportability Edits should be evaluated before Validity/Quality Edits to determine which concepts need to be collected from the FI. Another difference is that Reportability Edits are not used to validate or verify FI data. Vendors should note that the CDR will use Reportability Rules to ensure that each FI submits the concepts (Call Report items) required by the FFIEC. There is no requirement that Call Report vendors use these taxonomies in their software. However, vendors are encouraged to use these Reportability Edits or other methods to ensure that instance documents submitted by FI's include all of the required concepts.
Note: Call Reports (instance documents) that do not contain all of the required concepts will be rejected. FI's will continue to be required to correct any missing data to comply with the FFIEC reporting requirements.
3.3.1 Taxonomy architecture
Call Report taxonomy architecture is separated into two parts - Report taxonomy and Reportability taxonomy (see section 1.3: Figure 1 - Call Report Taxonomy Architecture). These taxonomies are designed to function independently, thus Software Vendors/FI's who choose not to implement reportability rules can ignore the Reportability taxonomy.
Reportability taxonomy MUST contain the following schema and linkbases -
The Reportability schema imports the core XBRL and FFIEC schema files. It also imports the Concepts schema file. It contains definitions for all reportability edit concepts (of Boolean data type) and a definition for an abstract root concept. The namespace on this schema MUST be versioned using the period information and the version number. For example the namespace on a Reportability schema for the reporting period September 2003, version 1 would be:
Reportability Definition Linkbase
The Reportability definition linkbase contains definition links between root concept and reportability concepts. The arc role attribute on the 'definitionArc' element MUST have the following value:
The Reportability definition linkbase contains all reportability concepts that MUST be processed by an FI prior to executing reportabililty edits. An example of a reportability concept id RCONC587 - 'Did Institution Have An Active International Banking Facility During The Calendar Year?'
The contents of the reportability definition linkbase can be used to build a questionnaire for an FI, as shown in Figure 4:
|Figure 4: Sample Reportability Questionnaire
Reportability concepts are not reported to FFIEC, they are solely intended for the vendors to process reportability rules.
Reportability Captions Linkbase
The Reportability captions linkbase is expressed as an XBRL label linkbase. Reportability caption linkbase MUST contain one extended link that has all the captions and relationships between concepts and captions. A 'locator' element is used to point to the concepts in the concepts schema; a 'resource' element is used to contain the caption and a 'labelArc' to connect a concept to its caption. The arc role attribute on the 'labelArc' element MUST have the following value:
Reportability Formula Linkbase
The Reportability formula linkbase contains Reportability rules and Reportability edits. Reportability formula linkbase MUST contain a single extended link to contain all the rules and edits. A 'locator' element is used to point to the elements in the Call Report schema, a 'formula' resource element to express the formula, a 'formulaArc' to relate elements to the resource. The arc role attribute on the 'formulaArc' element MUST have the following value:
The 'xlink:role' attribute on the formula resource element MUST have either of the following two values depending on the type of formula.
Reportability Formula Messages Linkbase
The Reportability formula messages linkbase is expressed as an XBRL label linkbase. The linkbase has one extended link with locators to the edits involved, resources for the edit messages and arc's to connect the edit messages to the edits. The 'xlink:role' attribute on the label resource element MUST be
Every Reportability Edit (ruletype4) is associated with an Edit Message. This information is stored in a Reportability Edit Messages linkbase implemented as an XBRL label linkbase. A sample message could be "concept cc:RCFDB868- Personal trust and agency accounts, MUST be reported".
3.4.1 Pre Processing of Reportability Edits
Software vendors MAY pre-process the Reportability Edits to determine the set of concepts that a FI MUST report. This set of concepts can be used to determine which Validity and Quality edits to process before submitting the instance document.
3.4.2 Post Processing of Reportability Edits
Software vendors MAY post-process the Reportability Edits to determine if the FI has reported the complete and correct set of concepts. The CDR MUST process all Reportability Edits on instance document submission. An instance document cannot be submitted to the CDR if any of the Reportability Edits fail.