Development of XBRL Formulae and Business Rules for Intermediate Document Processing

2. XBRL Formulae development Business rules document Initial Analysis Document reference numbers and EU / SP classification Development Formulae intermediate formula Test instance documents + corrected linkbase Instance generation and testing Formulae linkbase Linkbase generation

3. Business rules document

4. Business FORM

5. Business rules with references and European / Spanish classification

6. Intermediate formula format • Not convenient formula editors available when we started • Intermediate XML format as temporal alternative to graphical editor • Properties of the intermediate XML format: • - Based on a XML Schema definition • Uses only a subset of the Formulae specification • Simplifies Xlink Syntax • We designed an intermediate XML format and developed XSLT transformations to obtain the final linkbase: • - Isolates us from changes in the syntax of the specification • Takes care of default values • Takes care of style guide issues • But: • It doesn’t check Xpath expressions • It doesn’t check missing variables or name mistakes • Error detection quite limited • We used Fujitsu’s taxonomy editor to help debugging

7. Intermediate formula format

8. Intermediate formula format

9. Resources • About 400 XBRL Formulae for 3.400 business rules • About 120 working days • = 5,5 months / one person • (2 months with 4 people part time) • In a stable environment, we estimate 36 working days (including both development and tests)

10. Firing subsets of assertions • Each solvency statement has different frequency requirements • CA: half-yearly for groups and individual companies and yearly for subsidiaries • Operational risk: yearly • We generally assume that not reported data is zero What happens to a rule like this? Addition of operational requirements by method (OR template) must be equal to total operational requirements (CA template) We need a way to select which assertions must be applied depending on the data reported

11. Firing subsets of assertions • Each assertion set represents the assertions to be applied to a statement • A set of items in the instance document are used to claim which statements are reported (a manifest) • Fujitsu’s processor asks the calling application before processing each assertion set • Our application obtains the reference of the assertion set and checks whether the that statement is in the manifest AssertionSet Reference: Statement 3010 Assertion 1 Assertion 2 Assertion 3

12. How errors are communicated • Each assertion has: • A reference number • A label that describes the error • When an assertion is not satisfied the following information is sent to the user: • The reference number • The label describing the error • The expression that failed • The value of each input variable • In the case of consistency assertion: • The calculated value • The reported value Assertion Reference: 3010-sv-1 Label: “Operational risk capital requirements not consistent with its breakdown by method applied”

13. Future plans: Validation against information in a database XBRL Instance document • Test = “abs(($assets - $prevAssets) / $assets) lt 2.00” • Fact variable • $assets : Concept filter • General variable • $prevAssets: “db:fact-from-period($assets, -1)” | (Assets – Assets last year) / Assets| < 200% XBRL processor Xpath external functions

14. Conclusions • XBRL Formulae covers perfectly our needs • Powerful • Extensible • Maintainable • Intuitive and easy to use • In spite the lack of homogeneity, it is possible to reuse formulae across different countries • Market tools are promising but...

15. COREP Stands for common reporting

16. Are we using XBRL properly? 0501 + 0502 d-mr:MRiskSAEQUExchangeTradedStockIndexFuturesBroadlyDiversifiedSubjectParticularApproach + d-mr:MRiskSAEQUOtherEquitiesThanExchangeTradedStockIndexFuturesBroadlyDiversified