Two things a group needs at once
The holding company wants a consolidated view: risks by band, losses by category, open breaches, continuity readiness, across every company it owns. Each subsidiary that holds a licence — a securities company, a digital asset operator, a payment provider, an insurer — has its own risk management committee, its own second line and its own regulator, and its risk process must be its own. A group framework that lets the parent edit a subsidiary's register solves the first need by breaking the second.
The reconciliation is a small number of rules about who sets what and who may read what. COSO ERM calls the surrounding work governance and culture; in a regulated group it is also a licensing condition, because a subsidiary's second line carries its own liability and its own regulatory independence.
What the root sets once
- The reporting year. Only the group root opens a year; every company then works in that period, so every report consolidates.
- The criteria set. One set of likelihood and impact levels, one way of combining them, one set of bands, applied to every entity beneath the root.
- Materiality thresholds and MTPD bands. So a tier 3 loss or a tier 1 activity means the same thing in every company.
- The taxonomy. Eight risk categories, the Basel event types and the hazard types, so every company names things the same way.
Figure 14Group risk governance: each company runs its own, the parent reads upThe root sets what must be common — the year, the criteria set, the thresholds, the bands, the taxonomy. Each subsidiary runs its own identification, assessment, validation and approval with its own RMC. The only link between companies is report-up: the parent reads what was validated or approved and never acts on it; sister companies never see each other.
What every company runs for itself
- Its own registers and its own cycle. Risks, loss events, indicators and the BIA, scored, validated and approved inside the company by its own Risk Champions, reviewers, approvers and Entity Risk Manager.
- Its own acts. Reopening a filing, validating a loss event, calibrating a threshold, approving the BIA, filing the month — each is the act of the company's own role, never of a parent user.
- Its own continuity decisions. The group may publish an advisory — a hazard, a recommended level, a note — and the subsidiary sees it beside its own level. Its level changes only when its own continuity head orders it.
The only link is report-up
- Down-only visibility. A company sees its own records and what the companies beneath it have reported up. It never sees a sibling, and a subsidiary never sees its parent's records.
- Reported, then visible. The parent sees a subsidiary's record only after that subsidiary has validated or approved it. Drafts and events under review belong to the company working on them.
- Read, never act. A parent reads a subsidiary's reported records and cannot create, edit, approve, validate or close any of them.
- One template. The group roll-up and the group monthly report are assembled from what each company has reported up, on one shared template, with each entity's figures and the totals of everything beneath it.
Where it usually breaks
- Group risk edits the subsidiary's register. It is faster, and it ends the subsidiary's independence the day the regulator asks who approved the filing.
- Consolidation by email. Each company sends a spreadsheet; group risk re-keys them into one. Figures are a month old and the links to the underlying records are gone.
- Sister companies see each other. A shared workbook, one tab per company. Commercially sensitive loss events are visible across the group.
- Rules in a policy, not in the system. The policy says the parent only reads. The system lets anyone with the file edit it.
In Risk Core
Risk Core — powered by Qirin X · ComplyWise. Risk Core models a group as a tree — group root, subsidiary, division, team — and grants every role at a node of that tree: the role acts only at the entity where it is granted and reads the levels beneath it. One person can hold several roles at several levels under one sign-in. Seven product rules shape every screen, and each is enforced in the database rather than only in the interface: a screen hides what a role cannot do, and the database refuses it regardless.
The rules are Down-Only Visibility, Subsidiary-Independence, Report-Up-Only, Reported-Then-Visible, Group advisory is display-only, Computed never typed, and Who-filed is stamped. In practice: a read of a company outside your own branch of the tree returns nothing; every write by a user whose role is granted above the entity that owns the record is refused; the group roll-up and the group monthly report count validated and approved records only, on one template set at the root; and an advisory from the parent never changes a subsidiary's BCP level or reaches its staff. Every subsidiary is treated alike, licensed or not.
Platform summary and the ComplyWise services around it: Risk Core. Product documentation: Product rules, Key concepts and Group roll-up on Risk Core Docs.
The series
Six articles, one stage at a time. Each one explains the framework first and ends with how Risk Core implements it.
- 1
Enterprise risk management in practice: the six-stage risk life cycle
- 2
RCSA in practice: a risk score nobody can type
- 3
Loss events in practice: the tier is computed, the month is always filed
- 4
Key risk indicators in practice: three bands, versioned thresholds, every Red is an action
- 5
From the business impact analysis to the continuity plan: how a recovery time becomes a call-tree order
- 6
Group risk governance in practice: each company runs its own, the parent reads up
Frequently asked questions
- Can a parent company manage risk for its licensed subsidiary?
- It can set common standards — the criteria set, thresholds, taxonomy and reporting calendar — and it can read what the subsidiary reports up. The subsidiary's own risk function must identify, assess, validate and approve its own records, because it holds its own licence, its own risk committee and its own regulatory accountability.
- What does report-up-only mean?
- That the only flow of records between companies in a group is upward, from each company to its parent, and only for records the company has validated or approved. Nothing flows sideways between sister companies, and nothing flows down from a parent into a subsidiary's records.
- Why should group rules be enforced in the database rather than in a policy?
- A policy describes what should happen; a database constraint decides what can happen. When a parent user's write to a subsidiary's record is refused by the database, the rule holds whatever the screen shows, whoever the user is and whatever the policy says.
- How does a group get one consolidated risk report?
- By setting one template and one scale at the root and assembling the report from what each company has reported up. Each entity appears with its own figures and the totals of everything beneath it; nothing is re-keyed and the links to the underlying records are kept.
Sources
- Risk Core Docs — Product rules: the seven rules Risk Core enforces in the database
- Risk Core Docs — Key concepts: the entity tree, roles granted at a level, reporting periods
- Risk Core Docs — Group roll-up: built only from what was reported up; read-only by rule
- Risk Core Docs — Dashboards and reporting: executive summary, group roll-up, loss pack, group monthly report, management review
- Risk Core Docs — ERM Core overview: the risk life cycle and how RCSA, Loss Event, KRI and BIA feed each other
- COSO — Enterprise Risk Management: Integrating with Strategy and Performance (2017), guidance page
Accessed and last reviewed . Each figure and table cell is traced to a source above.