Skip to content

Product rules

Seven rules shape every screen in Risk Core. Each is enforced in the database, not only in the interface: a screen hides what a role cannot do, and the database refuses it regardless.

The seven product rulesThree rules govern what companies in a group see, two govern who may act, and two apply to every record.Down-Only VisibilityA parent reads what is beneath itsiblings never see each otherReport-Up-OnlyThe only link between companieseach company reports to its parentReported-Then-VisibleThe parent sees a record onlyonce the company has validated itSubsidiary-IndependenceA parent reads but never acts on a subsidiary's recordsthe database refuses, not only the screenGroup advisory is display-onlyShown beside the subsidiary's own BCP levelnever changes it, never pushes to its staffComputed, never typedScores, tiers, bands and statuses are deriveda user cannot type themWho-filed is stampedEvery record and step carries author and timehistory is append-onlyBETWEEN COMPANIES · WHAT THEY SEEBETWEEN COMPANIES · WHO MAY ACTEVERY RECORD
Three rules govern what companies in a group see, two govern who may act, and two apply to every record.

Definition. 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.

Why. Each company in a group is a separate business, often a separately licensed one. Oversight runs down the ownership line and nowhere else.

What you see. The company switch in the header and the group roll-up list only your own company and the companies beneath it. A sister company does not appear anywhere.

What the database refuses. Any read of a company outside your own branch of the tree returns nothing.

Definition. A parent reads a subsidiary’s reported records and never acts on them. No parent user can create, edit, approve, validate or close a subsidiary’s risk, loss event, KRI, BIA or action.

Why. The subsidiary holds its own licence, has its own RMC and answers to its own regulator. Its second line carries its own liability and its own regulatory independence, and a group process cannot stand in for it. The parent oversees; it does not operate.

What you see. On a subsidiary’s records, a parent user sees read-only views with no action buttons. Reopening, validating and approving are acts of the subsidiary’s own Entity Risk Manager and approvers.

What the database refuses. Every write by a user whose role is granted above the entity that owns the record. The parent holds only what was reported up and has no access to the subsidiary’s records.

Definition. The only link between companies is report-up: each company runs its own identification, assessment, evaluation and reporting, and sends upward what it has validated or approved.

Why. It keeps each company’s process its own while the group still consolidates. Every subsidiary is treated alike; there are no exceptions for licensed or unlicensed companies.

What you see. The parent’s group roll-up and group monthly report are assembled from what each company has reported up, on one shared template.

What the database refuses. Any flow sideways between companies, and any flow from a parent down into a subsidiary’s records.

Definition. A parent sees a subsidiary’s record only after that subsidiary has validated or approved it. A loss event, for example, reaches the parent once the subsidiary’s Entity Risk Manager has validated it.

Why. The parent consolidates confirmed information. A draft, or an event still under review, belongs to the company that is working on it.

What you see. In the group roll-up, figures count validated and approved records only. Sensitive loss events are seen only along the reporting line.

What the database refuses. A parent’s read of a record that has not been validated or approved.

Definition. A parent may publish a group advisory in BCP Core — a hazard, a recommended BCP level, a time and a note. A subsidiary sees it beside its own BCP level.

Why. The BCP level of a company is that company’s own decision, ordered by its own BCP head. The group can advise; it cannot decide for the subsidiary or reach its staff.

What you see. The advisory appears beside your company’s own level. Your level changes only when your own BCP head orders it.

What the database refuses. Any change to a subsidiary’s BCP level from a group advisory, any push to a subsidiary’s staff, and any draft prepared for the subsidiary.

Definition. Scores, tiers, rating bands and statuses are derived by the system from the inputs. A user cannot type them.

Why. A rating that can be typed can be negotiated. Deriving it from the criteria set, the thresholds and the MTPD bands keeps every company in the group on the same scale.

What you see. Inherent and residual scores, the tier and band of a risk, the materiality tier of a loss event, the KRI band and the criticality tier of a BIA activity appear as results, not as input fields. Residual risk can never be higher than inherent risk. Codes such as CM-RISK-2026-001 are issued by the system.

What the database refuses. A write that sets a derived value directly, or a residual score above the inherent score.

Definition. Every record and every step carries its author and time. The reporter of a loss event, the validator, the reviewer and the approver are stamped automatically, and history is append-only.

Why. Accountability in a risk function depends on knowing who did what and when, and on a history that cannot be rewritten.

What you see. Each record shows who created it and each step it has passed through, with the time and a snapshot of what was approved. Valuation history, submissions and the audit log only grow.

What the database refuses. A change to a stamped author or time, and any edit or deletion of history.