7 EGR consolidation process ESTP Training on EGR 6-7 September 2016

EGR - Consolidation process All the data from the different data providers have to be combined to create groups This process is called consolidation and includes priorities and rules Steps of the consolidation process Consolidation of legal units Consolidation of relationships Consolidation of cluster of control Consolidation of groups and enterprises

Data in processing Source area Transformation area Data as received from the data providers Transformation area Data after transformation Redundant information from one source removed Consolidation process Consolidation area Final picture on the entities for a reference year

Authentic store rules (1) The authentic store principal means that in EGR 2.0 the NSI business register sources are categorised as exclusive or non-exclusive sources for information on specific entities The authentic store setting in EGR 2.0 can be full - being a full authentic store implies that there are no other possible sources permitted partial - the partial authentic store implies that additional sources are permitted, however data of the partial authentic store have always preference over the additionally defined sources

Authentic store rules (2) Authentic store is applicable for various EGR IS and EGR CORE units some of them are set by default some others can be set by action In EGR IS NSI register can become authentic store for resident legal units (set by an action) 28 NSI are authentic store No CDP legal units can be added for them Legal units of CDPs are only linked to NSI data, their data are only accepted (e.g. their relationships) if linking was successful

Authentic store settings (1) In EGR CORE an NSI register can become authentic store for the following units/items: Resident legal units Resident relationships (between two resident legal units) Cross-border relationships (between a resident legal unit and a foreign legal unit) Resident enterprises Default settings in EGR for 2015 cycle: All NSIs are partially authentic store for cross-border relationships All NSIs are authentic store for resident ENTs

Authentic store settings (2) Settings are defined by action in EGR CORE for 2014 cycle for: Resident legal units Resident relationships (between two resident legal units)

Authentic store settings (3) EGR IS and EGR CORE combinations on resident legal units: EGR IS partial / EGR CORE partial: sources other than NSA can provide information for that country EGR IS full / EGR CORE partial: sources other than NSA can provide information for that country in EGR CORE (subject that the LEU is provided by NSA in EGR IS) EGR IS full / EGR CORE full: only NSA data will be acceptable in EGR EGR IS partial / EGR CORE full: sources other than NSA can provide information for that country in EGR IS

Authentic store settings (4) EGR relationships between two resident legal units Authentic store for resident RELs CDP relationships cannot be added to EGR between two resident legal units Only NSA data can be the source of domestic relationships Partially authentic store for the resident RELs CDP relationships can be added to EGR between two resident legal units Both the NSA and the CDP relationship data will be used in EGR for domestic relationships In conflicting cases preference will be given to NSA data

Further reading EGR wiki Details on the EGR methodology / Authentic store principle in EGR 2.0

Processing of data The authentic store settings and the predefined order of data sources and will define in EGR 2.0 how groups will be created from the received pairwise relationships of NSIs and CDPs Priority order of data sources EGR NSI of the subsidiary NSI of the parent BvD DnB NSI other than 2 and 3

Information to EGR from one NSI LEU BE222 AT REL data LEU AT111 ENT ATENT111 AT ENT data AT LEU data AT LEL data

Information to EGR from multiple sources BE REL data LEU BE222 ENT BEENT222 BvD REL data BE LEU data BE ENT data BvD LEU data BE LEL data BE REL data AT REL data LEU AT111 ENT ATENT111 BvD REL data AT LEU data AT ENT data BvD LEU data AT LEL data DnB REL data

Consolidation of legal units Source Transformed Consolidated NSA(3) LEID X NSA(3) LEID X NSA(1) LEID X NSA(2) LEID X DnB(1) LEID X BvD(2) LEID X BvD(1) LEID X WITHIN ONE FRAME YEAR Priority NSA BvD DnB Prioritize Update

Consolidation of relationships (1) Process started from scratch per subsidiary Collect all direct RELs on the same subsidiary Determine highest percentage per parent Create direct relationships in order of priority Check for no violation (for example, no more than 100% in total) Collect indirect RELs on the same subsidiary Discard superfluous indirect (if there is direct control) Discard lower priority (if more than 1 parent) Establish indirect relationship

Consolidation of relationships (2) LEU BE2 LEU NL3 NSI_AT AT1-BE2 A C D 89% NSI_AT AT1-NL3 A C D 11% BvD AT1-BE2 A C D 50% BvD AT1-NL3 A C D 50% NSI_NL AT1-NL3 A C D 51% LEU AT1 NSI_AT AT1-BE2 A C D 89% BvD AT1-BE2 A C D 50% NSI_AT AT1-NL3 A C D 11% NSI_NL AT1-NL3 A C D 51% BvD AT1-NL3 A C D 50% Priority EGR NSI of the subsidiary NSI of the parent BvD DnB NSI other than 2 and 3

Consolidation of cluster of control The cluster of control defines legal units that are involved in (control) relationships with each other, ultimately all being under control of the defined topmost legal unit (the head of the group) A legal unit can have control with a single relationship in two cases: Type of ownership = I (indirect) or Type of ownership = D (direct) and voting power >50% Combine clusters with cumulative direct control >50%!

Creation of control clusters In the consolidation process EGR is looking for: Direct control - A legal unit directly owns more than 50 % of the voting rights of another legal unit Consolidated control - A legal unit fully consolidates the accounts of another legal unit (through accounts) Indirect control - A legal unit indirectly owns more than 50 % of the voting rights of another legal unit, through subsidiaries One control cluster can include One to many legal units From one or more countries

From % values…

…to control clusters

Consolidation of groups From clusters to enterprise groups Each new cluster is a new group For already existing groups (data of previous EGR cycle) the identification (continuity) of the enterprise groups is determined By looking at the overlapping enterprises and the number of persons employed of them Where overlap is found on enterprises and employment, the group ID is kept, continuity of groups exists

Processing of data The authentic store settings and the predefined order of data sources and will define in EGR 2.0 how groups will be created from the received pairwise relationships of NSIs and CDPs Priority order of data sources EGR NSI of the subsidiary NSI of the parent BvD DnB NSI other than 2 and 3

Processing of data - Examples (1) Complementary REL data of NSI and CDP NSI SK LEU1 (SK) – LEU2 (LU) – cross border relationship CDP LEU2 (LU) – LEU3 (LU) – resident relationship As LU is PA for resident REL: CDP data accepted, cluster will be: LEU1(SK) – LEU2 (LU) – LEU3 (LU) NSI SK LEU1 (SK) – LEU2 (DK) – cross border relationship CDP LEU2 (DK) – LEU3 (DK) – resident relationship As DK is A for resident REL: CDP data not accepted, cluster will be: LEU1(SK) – LEU2 (DK)

Processing of data - Examples (2) Complementary REL data of NSI and CDP NSI SK LEU1 (SK) – LEU2 (DK) – cross border relationship CDP LEU2 (DK) – LEU3 (US) – cross border relationship Complementary CDP data always accepted for cross-border REL, cluster will be: LEU1(SK) – LEU2 (DK) – LEU3 (US)

Processing of data - Examples (3) Conflicting cases of NSI and CDP REL data NSI SK LEU1 (SK) – LEU2 (LU) – cross border relationship CDP LEU1 (SK) – LEU3 (CZ) – cross border relationship NSI is stronger than CDP, cluster will be: LEU1(SK) – LEU2 (LU) NSI SK LEU 1 (SK) – LEU 2 (LU) – cross border relationship NSI CZ LEU1 (SK) – LEU 3 (CZ) – cross border relationship Two NSI sources, bottom-up REL is stronger than top-down, cluster will be: LEU 1 (SK) – LEU 2 (LU)

Processing of data - Examples (4) Conflicting cases of NSI and CDP REL data CDP1 LEU1 (SK) – LEU2 (CZ) – cross border relationship CDP2 LEU1 (SK) – LEU3 (GI) – cross border relationship Two CDP sources, CDP1 is stronger, cluster will be: LEU1 (SK) – LEU2 (CZ)

Processing of data - Examples (5) Complex case of NSI and CDP REL data NSI SK LEU1 (SK) – LEU2 (LU) – cross border relationship NSI CZ LEU1 (SK) – LEU3 (CZ) – cross border relationship CDP1 LEU2 (LU) – LEU4 (LU) – resident relationship CDP2 LEU2 (LU) – LEU5 (IE) – cross border relationship CDP2 LEU5 (IE) – LEU6 (IE) – resident relationship

Processing of data - Examples (6) LEU 6 IE NSI SK: LEU1(SK)–LEU2(LU) NSI CZ: LEU1(SK)–LEU3(CZ) CDP1: LEU2(LU)–LEU4(LU) CDP2: LEU2(LU)–LEU5(IE) CDP2: LEU5(IE)–LEU6(IE) CDP2 data LEU 4 LU LEU 5 IE CDP1 data CDP2 data Priority EGR NSI of the subsidiary NSI of the parent BvD DnB NSI other than 2 and 3 LEU 2 LU LEU 3 CZ SK data LEU 1 SK CZ data

Processing of data - Examples (7) Complex case of NSI and CDP REL data Bottom-up REL is stronger than top-down: NSI SK data accepted, NSI CZ data not accepted As LU is PA for resident REL: CDP1 data accepted CDP2 data on LEU2 not accepted, CDP1 data are stronger As IE is PA for resident REL: CDP2 data for LEU5 resident REL accepted Clusters will be: LEU1(SK) – LEU2 (LU) – LEU4 (LU) LEU5 (IE) – LEU6 (IE) (domestic group, will be excluded from the EGR frame)

Identification numbers in EGR 2.0 EGR IS LEUs are identified with LEID numbers EGR CORE input files ENTs: ENT_NSA_ID, groups: GEG_EGR_ID EGR CORE system and output LEUs are identified with LEU_EGR_ID No continuity of EGR 1.0 identifiers (EU_LEU_ID, GLOBAL_EG_ID)

Further reading EGR wiki Details on the EGR methodology

Notes