1 / 16

Monolithic vs Modular Approaches in Data Management and Reporting

The choice between monolithic and modular data management frameworks significantly impacts the efficiency of defining and delivering national datasets. Modular systems provide flexibility in selecting required instances for specific datasets, while monolithic systems facilitate streamlined formulas. However, monolithic frameworks face challenges related to unneeded national data, which complicates compatibility and data management. Effective strategies for rounding in data consumption and standard dataset definitions are crucial for regulatory compliance, transparency, and harmonization in financial reporting.

kaemon
Télécharger la présentation

Monolithic vs Modular Approaches in Data Management and Reporting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Monolithic vs modular: decision required • Modular • Advantage: ease of definition of a « national to be delivered dataset » (by selecting required instances) • Monolithic • Advantage: ease and efficiency of formulas • Disadvantage: problem of « nationally not required data » • deactivating  compatibility issues • not deactivating  how to politically deal with instances containing « too many data »

  2. Rounding • “The rounding should be done while consuming the data by the financial regulator” • “Correct rounding should be enforced by instance validation e.g. in the formula validation part”

  3. Instance « context » • Consolidation status • consolidated • non consolidated head & branches • non consolidated head only • non consolidated branch • Audit status • provisional • audited • Consolidation scope • CRD • Insurance • OtherEntities • IFRS

  4. Instance « context » • Materialisation alternatives • As dimensions ? • As part of some header ? • As part of some external « envelope »?

  5. Standard dataset • one single reporting entity • one single reporting period • one single capital currency (+ pure) • one single consolidation status • one single audit status • one single scope of consolidation

  6. Otherwise … Max-tax Country 1 Country 2

  7. Dimension defaults • Use of instances in a 2-step approach • first XBRL validation • then injection of values into DB (without taxonomy) • Issues: • Transparency of data • Reidentification of hypercubes in a mapping-oriented system • Keep it simple (& keep requirements low)

  8. In scope of Finrep 2012 • Atomic XBRL instances that are structurally compatible • Atomic XBRL instances that respect CEBS formula set • (Hopefully) no national formula sets required • In case of a monolithic taxonomy structure, a standard way of rejecting « nationally not required data » should be defined: take it and ignore it, or refuse it? • A « standard dataset » acceptable by all participating countries should be defined

  9. Out of scope of FINREP 2012 • To be determined by local supervisor (or within separate project) • File name convention • Transmission channel & encryption • Packaging and envelopes (XBRL pure, XBRL/XML mix, ZIP, ...)

  10. Obsolete • Nil • Nil values should be technically prohibited by instance validation • Period / instant harmonization ? • Can one single approach be defined for all data ? • both inacceptable for IFRS compatibility reasons

  11. Min-Max Risk (Corep) Tn-max Tn-min Tn-country1 Tn-country2 Tn-countryn

  12. Min-Max best practice • National extensions should either include min or max version of Tn, but not a mix of them

  13. Finrep structure t1 t2 BS … tn t1 t2 P&L … tn

  14. Corep structure T1-max T1-min Ca-sro … Tn-max Tn-min

  15. Finrep-Corep 2012 structure Tn-min Tn-min formulas Main Import Tn-max Tn-max formulas Main formulas Taxonomy-nmin with formulas Taxonomy-nmax imports Taxonomy-nminand adds its own formulas

  16. Discussion on requirements • Formulas have to work properly and efficiently cross-instance in all XBRL-tools • Access to all required instances in the same environment at the same time in the same place • Pre-defined file name convention for instances required?

More Related