Workiva (Wdesk)Layer 5 · Disclosure
A closer view of the disclosure layer — the platform that turns the consolidated group position into the filed annual report
Position & Purpose Layer 5 · external & statutory · the last mile
Workiva (NYSE: WK) is the connected-reporting and disclosure-management platform at the top of the stack; where the companion gives it a single paragraph, this note opens the box. It sits in Layer 5, owning the annual report and the statutory accounts, alongside CCH Tagetik for regulatory and liquidity returns and Power BI for management information. It keeps no ledger and measures nothing: its work is the last mile, where the consolidated group position — drawn here from Oracle FCCS — becomes a filed, tagged, audit-ready document. Originating as Wdesk in 2008 and now used by several thousand listed and regulated organisations, it is the market reference for disclosure management, and the platform on which the first Inline XBRL report accepted by the US SEC was filed.
The Linked-Data Model one source · change once · no re-keying
The platform’s defining mechanism is linking. A figure is held once, at source, and linked to every place it appears — the primary statements, the notes, the narrative, the board pack, the results announcement — so that changing it at source updates every linked instance, across hundreds or thousands of locations, in seconds; both data points and narrative may be linked in this way. Numbers are not re-typed from spreadsheets of uncertain vintage but pulled, on a schedule, from the systems that own them: through the platform’s data layer and its connectors, balances flow from the general ledger and the consolidation — the Oracle estate and FCCS here — and refresh in place. This is precisely the discipline the companion describes: the report is bound to the consolidation, not to re-keyed extracts, so a late change reaches every output without manual restatement.
Control, Version & Audit permissions · history · trace to source
Because the report is a single living document rather than a chain of emailed files, control is intrinsic. Many authors work at once — finance on the statements, legal on the risk factors, investor relations on the narrative — within one version, with permissions set as finely as a page, a section or a single data point, so that segregation of duties holds within the drafting itself. Every change is captured with full version history and blacklines for comparison, and a complete audit trail lets a reviewer, an auditor or a regulator trace any figure to its source inside the platform rather than chase evidence by hand. A configurable workflow carries the document through its states — draft, in review, ready to file — recording review and sign-off as they occur.
Tagging & Filing — The UK Context iXBRL · UKSEF / ESEF · FCA NSM
For a UK-listed group the binding requirement is structured digital filing. Under the FCA’s Disclosure Guidance and Transparency Rules (DTR 4.1), issuers with securities admitted to trading on UK-regulated markets must prepare the annual financial report in XHTML and tag it in Inline XBRL — the primary statements and the notes — and file it to the FCA’s National Storage Mechanism; this has been mandatory for financial years beginning on or after 1 January 2021. Workiva tags in the same environment in which the report is drafted, designed and reviewed, so the data never leaves the platform, and it supports both the ESEF taxonomy and the FRC’s UKSEF extension, which adds the UK-specific items — Streamlined Energy and Carbon Reporting among them — required by the FCA and Companies House. It also produces the iXBRL needed for HMRC corporation-tax returns, mandatory since 2011, with the validation, roll-forward and taxonomy-update routines that keep tagging consistent from one period to the next.
Adoption & Assurance scale · auditor familiarity · adviser ecosystem
Beyond its features, the platform’s incumbency is itself part of the case. It is the most widely adopted disclosure-management tool among large listed companies, so auditors and advisers already work within it, and a mature alliance ecosystem — PwC and the other major firms among them — supports statutory, sustainability and transaction reporting on the platform. Because assurance providers trace evidence directly in the same environment in which the report is built, review is quicker and audit friction lower. For a regulated insurer whose filing obligations change little from year to year, that assurance-readiness, and the breadth of expertise available in the market, are practical advantages a less-established tool could not match.
Beyond the Annual Report sustainability · controls · AI · the architectural fit
The same platform reaches past the statutory accounts. It hosts sustainability and integrated reporting against the CSRD and ISSB regimes — strengthened by the 2024 acquisition of the Sustain.Life carbon-accounting engine — so that financial and non-financial disclosure can share one governed source and one assurance trail; it supports SOX-style controls and internal-audit work; and generative AI is now embedded for drafting, benchmarking and summarising narrative such as the management commentary. Read against the eight principles, Workiva is a specialist admitted at the edge of the reporting layer, doing one thing well and leaving measurement and consolidation to the layers below. Its contribution to lineage is decisive: it is where capture, ledger and consolidation finally become a filed document, bound to FCCS rather than to a parallel set of spreadsheets — a report and a statutory filing that are auditable by construction. One caveat of placement: in this architecture the Solvency II Quantitative Reporting Templates sit deliberately with CCH Tagetik, not here.
Sources: FCA, Disclosure Guidance and Transparency Rules DTR 4.1 and Filing structured annual financial reports (National Storage Mechanism); FRC, UKSEF taxonomy; HMRC, Inline XBRL for Company Tax Returns; Workiva product documentation and ESEF/UKSEF solution pages; corporate facts per Workiva Inc. (NYSE: WK).
CCH TagetikLayer 5 · Regulatory
A closer view of Layer 5 — the regulatory, liquidity and Solvency II engine for a regulated insurer
Position & Purpose Layer 5 · regulatory · a specialist at the edge
CCH Tagetik (Wolters Kluwer) carries the regulatory half of Layer 5: it produces the Solvency II returns, the SFCR, the IFRS 17 disclosures and the liquidity reporting a regulated insurer must file. It sits alongside Workiva, which owns the annual report and statutory accounts, and Power BI, which owns management information, and is admitted narrowly — a specialist at the edge even within the reporting layer, rather than a second general platform competing with the Oracle estate. Its purpose is to take the consolidated group position from Oracle FCCS and render it into the dense, rules-bound regulatory templates that prudential supervision requires, with the calculations and disclosures those standards demand.
Pre-Built Regulatory Content starter kits · templates · rules
The reason a specialist is chosen here is content. CCH Tagetik ships pre-built regulatory starter kits that encode the templates, taxonomies and calculation rules — for Solvency II, IFRS 17 and related regimes — so they need not be built from scratch or maintained by hand as rules change. The Solvency II Quantitative Reporting Templates, the SFCR narrative and the supervisory returns are delivered as governed, repeatable processes rather than bespoke spreadsheets, and the vendor maintains them as regulation evolves. For a regulated insurer this turns a perennial, high-risk reporting burden into the configuration of a maintained platform.
A Finance Platform Beneath CPM · data · workflow · audit
Beneath the regulatory content sits a full corporate-performance-management platform: a governed data layer, a calculation engine, workflow with ownership and review, and an audit trail across the process. Numbers are drawn from the same governed source as the rest of the estate rather than re-keyed, transformations are transparent, and the returns carry the version history and sign-off that supervision expects. The platform also offers IFRS 17 measurement and disclosure content, but in this architecture that measurement is owned upstream — RAFM and the Accounting Hub — and CCH Tagetik is deployed specifically for the regulatory and liquidity output.
Solvency II & The UK Regime PRA · QRTs · SFCR · liquidity
For a UK insurer the regulatory perimeter is the PRA’s Solvency II regime — now diverging from the EU as Solvency UK — together with the SFCR, the regular supervisory return and liquidity reporting. CCH Tagetik’s value is that these are pre-modelled and kept current: the QRTs, the disclosures and the returns are produced from the consolidated figures to the supervisor’s templates, with the tagging and validation the filing requires. As the UK rules move away from the inherited EU text, a maintained regulatory platform absorbs the change as a content update rather than a rebuild — which is precisely why the burden was given to a specialist.
Drawn From One Source FCCS · governed data · no re-keying
What unites CCH Tagetik with the rest of the layer is that every regulatory number traces back to the same consolidated source. It draws the templates from the governed data produced by FCCS rather than from re-keyed extracts, so the regulatory return, the annual report in Workiva and the management view in Power BI all rest on one group position. A late change in the numbers flows through to the returns without manual restatement, and the supervisor sees figures that reconcile to the accounts by construction. The specialist is admitted at the edge, but it is wired to the same single source of truth.
Why It Earns Its Place a maintained specialist, narrowly deployed
Read against the eight principles, CCH Tagetik is a specialist admitted only where the domain demands it: regulatory and liquidity reporting is a content-heavy, fast-changing problem that a generalist platform would serve poorly. It owns one capability, draws from the single consolidated source, and keeps measurement upstream. Its contribution is that the most template-bound, rule-driven outputs in the group — the Solvency II QRTs and the SFCR — are produced from maintained content rather than hand-built each cycle. A new return or a changed rule becomes a configuration of CCH Tagetik rather than a new system, which is what keeps the estate maintainable.
Sources: CCH Tagetik / Wolters Kluwer documentation (regulatory starter kits; Solvency II and IFRS 17 content; the underlying CPM platform); the CCH — Wolters Kluwer portfolio reference; Solvency II / Solvency UK, the SFCR and supervisory returns (PRA); consolidated source per Oracle FCCS.
Microsoft Power BILayer 5 · Management Information
A closer view of Layer 5 — management information and self-service analytics from a single governed source
Position & Purpose Layer 5 · internal readers · the MI view
Microsoft Power BI completes Layer 5 with management information and self-service business intelligence. Where Workiva serves statutory readers and CCH Tagetik serves regulators, Power BI serves the internal audience — the board, the executive and the business — with dashboards and analysis. It closes the Microsoft-for-data axis that begins with the Azure results store in the actuarial pipeline, drawing on the same governed data the rest of the estate produces rather than on private extracts. Its purpose is not to be a book of record but to present what the records hold, so leadership steers from the same numbers that reach the accounts and the regulator.
Semantic Model & Self-Service model · measures · drill · refresh
Power BI’s strength is the governed semantic model: a defined layer of measures, relationships and hierarchies over which many users build their own reports without re-deriving the logic. Calculations are written once in the model and reused, so a metric means the same thing wherever it appears; reports refresh on a schedule against the source; and readers drill from a summary to the detail behind it. Self-service is therefore bounded by governance — business users explore freely, but on a curated model — which is what separates trustworthy management information from a proliferation of inconsistent spreadsheets.
Governance & Distribution workspaces · row-level security · lineage
Distribution is controlled. Content is published to workspaces and apps with role-based access; row-level security restricts what each reader sees; and certified or endorsed datasets mark the governed sources teams should build on. Lineage views show where a report’s data originates, and sensitivity labels travel with exported content. For a regulated group this matters: management information is widely shared but must remain consistent and access-appropriate, and Power BI’s governance — shared models, security and lineage — keeps a self-service estate from fragmenting into private, unreconcilable versions of the truth.
The Microsoft-for-Data Axis Azure · Fabric · one platform
Power BI is the visible end of the group’s Microsoft data platform. It reads from the governed enterprise data — including the Azure results store in the actuarial pipeline — and sits within the wider Microsoft Fabric and Azure estate the group runs for data, so the analytics layer shares the security and data foundation of everything beneath it. Concentrating management information on the same data platform avoids a separate BI silo with its own copies and its own definitions, and keeps the MI view connected, by construction, to the consolidated figures produced by FCCS and the source systems below.
One Source, Many Views FCCS · governed datasets · consistency
What ties Power BI to the rest of the layer is that it reports from the governed source rather than from extracts of unknown vintage. It draws on the consolidated position and the source-system data the estate already produces, so the dashboard, the annual report and the regulatory return rest on one set of numbers. Management can slice and explore — by entity, product, channel or period — but on data that reconciles to the accounts. The result is an MI layer that is rich and self-service yet consistent with statutory and regulatory output, because all three read from the same place.
Why It Earns Its Place self-service, without the sprawl
Read against the eight principles, Power BI is the management-information specialist that delivers self-service without sacrificing a single source of truth. It owns the internal-reporting view, governed by shared models and security, and reports from the consolidated data rather than re-deriving it. Its contribution is to give leadership fast, flexible insight while keeping that insight tied to the same governed numbers as every external output — the antidote to the spreadsheet sprawl a finance function defaults to. A new dashboard or metric is built on the curated model, not on a fresh extract, which is what keeps management information trustworthy at scale.
Sources: Microsoft Power BI documentation (semantic model and measures, row-level security, workspaces and apps, data lineage, sensitivity labels); Microsoft Fabric / Azure data platform; the Azure results store and the Microsoft-for-data axis per the architecture; consolidated source per Oracle FCCS.
Oracle FCCS — ConsolidationLayer 4 · Consolidation
A closer view of Layer 4 — where the group is consolidated and the close is brought to a head
Position & Purpose Layer 4 · elimination · group view
Oracle Financial Consolidation and Close Cloud Service (FCCS) carries Layer 4: it turns the balances of many legal entities into a single group position. It provides the machinery a multi-entity insurer needs and a ledger should not hold — intercompany elimination, currency translation under IAS 21, minority interests and group statutory output. It sits on top of the thin Fusion GL, takes its balances from the same Oracle estate that produces them, and supplies the consolidated group result to the disclosure layer above. The division of labour is deliberate: true consolidation — eliminations and cross-border restatement beyond what ledger translation offers — belongs in the EPM family, not in the general ledger.
The Consolidation Engine eliminations · IAS 21 · ownership
At its core FCCS applies a consistent set of group rules period on period. Intercompany balances and transactions are eliminated against an ownership and entity structure; foreign-currency results are translated under IAS 21 with the cumulative translation adjustment carried correctly; minority (non-controlling) interests are calculated; and acquisitions and disposals are handled within the model. Supplemental, non-transactional data — the disclosures and notes that do not originate as journals — are collected here too, so that the consolidated picture is complete rather than merely arithmetic. The same governed chart and hierarchies, owned in Oracle EDM, ensure every entity consolidates in one language.
The Group Close calendar · tasks · sign-off
Consolidation is also where the close is brought to a head. FCCS carries the group reporting calendar — tasks, dependencies, owners and status — and applies the elimination and ownership rules consistently each period, so the close runs to a governed schedule rather than a set of spreadsheets. It is the counterpart, at group level, to the entity close run in the Fusion GL and orchestrated by EPM Task Manager. The effect is a single, repeatable path from local books to a signed group result, with the supporting evidence captured as the close proceeds rather than reconstructed afterwards.
One Number, Many Audiences statutory · regulatory · management
What FCCS produces is one consolidated position that serves every external reader. From it, a single group number flows upward into Workiva for the annual report and statutory accounts, into CCH Tagetik for the Solvency II and regulatory returns, and into Power BI for management information — rather than being assembled differently for each audience. For a regulated insurer, that single source is the foundation of consistency: the figure the regulator sees, the figure in the accounts and the figure on the board dashboard are the same figure, built once under governance and reused.
One Estate, Built Once native EPM · shared data · reuse
FCCS is part of the Oracle EPM stack, alongside Planning, PCMCS and TRCS, and shares its data, security and master data rather than being interfaced to them. The consolidation reads the ledger that produced the balances, applies group rules once, and hands the result to disclosure — no re-keying, no parallel consolidation in spreadsheets. Running consolidation on the same estate as the ledger and the plan keeps the interface count low and the upgrade path single, which is what lets the group absorb a new entity or a changed ownership structure as a configuration of FCCS rather than as a new system.
Why It Earns Its Place the group view, owned once
Read against the eight principles, FCCS is the single owner of the group view: the one place eliminations, translation and minority interests are applied, sitting above a thin ledger and feeding every external output. Its value is that the consolidated position is built once and reused, with auditable lineage from the local books beneath it to the disclosures above. Measurement stays out of it — it consolidates consequence, it does not model — and a new book or a new rule is absorbed by the consolidation layer rather than by re-cutting the ledger. It is the hinge between record-keeping and reporting.
Sources: Oracle FCCS documentation (eliminations, IAS 21 currency translation, minority interests, the close calendar); the General Ledger briefing (consolidation belongs in EPM, not the ledger); IAS 21 The Effects of Changes in Foreign Exchange Rates (IASB); group outputs to Workiva and CCH Tagetik per the architecture.
Oracle EPM PlanningLayer 3 · Planning
A closer view of Layer 3 — the forward-looking plan that connects strategy to the ledger
Position & Purpose Layer 3 · forward-looking · internal view
Oracle EPM Planning carries Layer 3: the forward-looking, internal view of the business — budgets, forecasts and the financial plan. Where the ledger records what happened and consolidation reports it, Planning models what is expected to happen, and does so on the same Oracle estate so that plan and actual are drawn from one source. It is the group’s core financial planning platform, sitting alongside Oracle PCMCS for cost allocation and transfer pricing, and feeding management information rather than the statutory accounts. Its purpose is to make the plan a governed, connected artefact — not a sprawl of disconnected spreadsheets — that ties directly back to the chart of accounts and the actuals beneath it.
Driver-Based Modelling drivers · scenarios · rolling forecast
Planning is built around driver-based models rather than static line entry. Assumptions and business drivers feed calculations that build the financial plan; multiple scenarios and versions can be held and compared; and rolling forecasts are maintained against actuals as the year unfolds. The platform supports the specialised plans a group needs — workforce and headcount, capital and project spend — and reconciles them into the financial plan. Because it shares the governed chart of accounts and hierarchies held in Oracle EDM, the plan is built in the same dimensions as the ledger, so a planned number and an actual number are directly comparable without mapping.
Plan Versus Actual one chart · variance · drill-back
The value of running Planning on the Oracle estate is the closed loop with actuals. Actuals flow from the Fusion GL into Planning in the same dimensions, so budget-versus-actual variance is produced without reconciliation, and a variance can be drilled back to the ledger detail behind it. People cost flows in from Workday across the Finance–HR boundary; investment and fund results inform the asset side. The plan is therefore not a parallel universe but a forward extension of the same governed data, which is what makes a re-forecast a controlled update rather than a fresh round of spreadsheet collection.
The Insurer’s Plan capital · new business · stress
For a life and asset-management group, planning is more than a cost budget. It carries new-business and volume assumptions, expense and cost-allocation plans, and the capital and balance-sheet projections a regulated insurer must steer by. It connects to the actuarial and investment views that drive the group’s economics, and supports the scenario and stress analysis that planning under uncertainty demands. Held in one governed platform, these plans roll up consistently and feed management reporting through Power BI, so leadership steers from a forward view that is built on the same numbers as the accounts.
One Estate, One Model native EPM · shared data · governance
EPM Planning is part of the same Oracle EPM stack as FCCS, PCMCS and TRCS, sharing security, data and master data rather than being interfaced to them. Concentration on one estate keeps the plan, the consolidation and the ledger speaking the same language, with one upgrade path and one set of hierarchies. It replaces the classic failure mode of finance — a forest of linked workbooks with no governance — with a single, controlled planning system whose lineage is demonstrable. A new cost centre, product or scenario is a configuration of the model, not a new spreadsheet.
Why It Earns Its Place the forward view, governed
Read against the eight principles, Planning is the single owner of the forward view, kept in governed dimensions and tied to the actuals beneath it. Its contribution is that the plan and the accounts are one continuous data set rather than two, so management and statutory views reconcile by construction and a re-forecast flows through cleanly. Measurement of the balance sheet stays in the specialist engines; Planning consumes and projects rather than re-deriving. It completes the EPM layer above the ledger — plan, consolidate, disclose — on a single estate built to absorb change as configuration.
Sources: Oracle EPM Planning (Planning and Budgeting Cloud) documentation (driver-based planning, scenarios and versions, workforce and capital planning); chart-of-accounts governance per Oracle EDM; plan-to-actual integration with Oracle Fusion GL; cost allocation per Oracle PCMCS.
Oracle Fusion ERP — General LedgerLayer 2 · Core Ledger
A closer view of Layer 2 — the thin, durable ledger that records consequence, not detail
Position & Purpose Layer 2 · system of record · record-to-report
Oracle Fusion Cloud ERP carries Layer 2: the general ledger and the record-to-report spine on which the whole estate rests. It is the system of record — the single, governed book in which every entity’s accounting consequence is held — and it is deliberately kept thin. Measurement and granular detail live upstream, in the sub-ledgers and the actuarial pipeline; the ledger receives only the summarised journals those systems post, so it records consequence rather than transaction-level detail. That discipline is what lets one ledger absorb a new fund, a new legal entity or IFRS 17 without re-platforming. Around it sit the Fusion modules — Payables, Receivables, Procurement, Payments, Projects, Intercompany, Tax — but the ledger itself is the anchor of the design.
A Thin, Multi-Ledger Core primary · secondary · reporting ledgers
The ledger is multi-dimensional and multi-ledger by construction. A primary ledger holds the group’s IFRS books, while secondary and reporting ledgers carry statutory or local-GAAP views and alternate currencies, each maintained in parallel and reconcilable by design. A single, governed chart of accounts — owned upstream in Oracle EDM — gives every entity the same account and hierarchy structure, so consolidation and disclosure read one language. An in-built Essbase cube sits over the ledger, allowing real-time, multi-dimensional reporting and full drill-down from a balance to the originating journal. The result is a ledger that is at once thin in what it stores and rich in how it can be queried.
The Close & Its Controls period close · journals · audit trail
Day to day, the ledger runs the financial close. Journals are captured, validated and approved through controlled workflow, with an audit trail on every entry and segregation of duties enforced by role. Period-end is orchestrated — open and close status by ledger and entity, with the close calendar carried in Oracle EPM Task Manager — so the group closes to a governed schedule rather than a set of manual checklists. Allocations, revaluations and translations run within the ledger to defined rules. Because the GL takes summarised postings through controlled bridges rather than re-keyed entries, the numbers in the accounts are traceable, by construction, to the systems that produced them.
One Estate, One Upgrade Path concentration · cloud · fewer interfaces
The choice of Fusion ERP is a choice for concentration. Running the ledger, the EPM stack (Planning, FCCS, PCMCS, TRCS) and the Accounting Hub on a single Oracle estate keeps the interface count low and the upgrade path single: quarterly cloud updates apply across the suite, and the components share master data and security rather than being stitched together. For a regulated group, that coherence is a control in itself — fewer hand-offs, fewer reconciliations, and one place where the chart of accounts, the calendar and the security model are defined. It is the practical expression of the architecture’s first principle: a handful of platforms doing most of the work.
The Bridges Into the Ledger Accounting Hub · sub-ledgers · one-way flow
What protects the thin ledger is the way things enter it. The investment, fund-accounting and treasury books — Aladdin, InvestOne, Kyriba — post their summarised accounting effect upward; the actuarial results reach the ledger through Oracle Accounting Hub, which turns measured IFRS 17 outputs into balanced, audited journals. Data moves one way, from capture to ledger to consolidation to disclosure, and enters the books only through these controlled bridges. The ledger therefore never holds the underlying policy, position or instrument detail — it holds the consequence — and every figure in it carries a link back to the source that generated it.
Why It Earns Its Place the anchor of the estate
Read against the eight principles, the general ledger is the anchor: the one system of record for the group’s accounting, kept thin so that it endures. Its contribution is not breadth of function but durability and lineage — it records the consequence of everything measured elsewhere, in one governed structure, on one estate, through controlled bridges. Consolidation, planning and disclosure all draw from it; the sub-ledgers and the actuarial pipeline all feed it. A new book, a new entity or a new standard is absorbed as configuration of the ledger and its bridges rather than as a re-build, which is exactly what a long-lived finance core must be able to do.
Sources: Oracle Fusion Cloud ERP and General Ledger documentation (multi-ledger, period close, embedded Essbase reporting); the General Ledger briefing (record-to-report; the thin-ledger principle); IFRS 17 effective 1 January 2023 (IASB); chart-of-accounts governance per Oracle EDM.
Oracle Accounting Hub (IFRS 17)IFRS 17 Bridge
A closer view of the IFRS 17 bridge — where measured results become posted, auditable journals
Position & Purpose the bridge · actuarial results › ledger
Oracle Accounting Hub sits at the single most sensitive join in the estate: the point where the actuarial measurement of insurance liabilities becomes accounting. The plate splits IFRS 17 deliberately — WTW RAFM measures, and the Accounting Hub posts — so that modelling and book-keeping are owned separately. Its job is to take the results of the IFRS 17 calculation (the contractual service margin, the fulfilment cash flows, the loss component) and turn them into balanced, audited journals in the Oracle GL. It is not a calculation engine and not a ledger; it is the controlled bridge that lets a third-party measurement system behave, to the general ledger, exactly like a native sub-ledger such as Payables.
An Accounting-Rules Engine sources · rules · balanced journals
The Hub works by rules, not by re-keying. Business users define accounting rules against the source system’s own data items — its sources — so that a journal’s account, currency, debit or credit and description are derived from the contract group, cohort or transaction attribute. The engine then applies those rules to each incoming result and generates complete, balanced journal entries, processing primary, secondary and reporting ledgers in parallel and creating valid accounting for all or none. Because the rules live in finance and reference the source data directly, the mapping from a measured number to a posted journal is explicit, maintainable and owned by accountants rather than buried in code.
Lineage & Audit Trail drill-back · reconciliation · evidence
What makes the bridge defensible is the trail it keeps. Every posted journal retains a tight link to the originating transaction — distribution links, supporting references and source attributes carried onto the journal line — so a balance can be drilled back through the Hub to the actuarial result that produced it. Reconciliation and exception reporting let finance prove that what was measured equals what was posted before anything reaches the ledger of record. For a standard whose numbers are modelled, granular and assumption-driven, that visibility — measured input, applied rule, posted output, with exceptions surfaced for action — is the difference between an auditable IFRS 17 result and a black box.
IFRS 17 in the UK Insurer CSM · GMM / VFA / PAA · one standard
For a UK life and pensions group, IFRS 17 — effective 1 January 2023 — is the standard that reshaped the insurance balance sheet, replacing IFRS 4 and introducing the contractual service margin and a uniform measurement of insurance contracts. The Accounting Hub is where that standard meets the books: it receives RAFM’s measurement under the general measurement model, the variable fee approach or the premium allocation approach, and renders it into the new presentation — liability for remaining coverage, liability for incurred claims, insurance revenue — without the gross-written-premium and unearned-premium lines IFRS 4 once carried. One bridge, configured to the group’s rules, serves every entity and every product.
One Estate, One Flow native to Oracle · EDM · FCCS
Because the Hub is part of the Oracle estate, the IFRS 17 posting is not a bolt-on. It shares the chart of accounts and hierarchies governed in Oracle EDM, posts into the same Fusion GL that carries the rest of the group, and feeds the consolidated result upward into FCCS for the group view and into Workiva and CCH Tagetik for disclosure. The measurement detail stays in the actuarial pipeline; only the summarised, audited journals cross into the ledger. This is the architecture’s one-way flow made concrete at its hardest point — the place where, in many insurers, actuarial and accounting fall out of step.
Why It Earns Its Place measurement out of the ledger
Read against the eight principles, the Accounting Hub embodies two of them: measurement held outside the ledger, and a one-way flow through controlled bridges. By owning the translation from modelled result to posted journal — and only that — it keeps the general ledger thin and the actuarial engine free to model, while guaranteeing that the two reconcile by construction. It is a small component with outsized importance: get this join wrong and the IFRS 17 numbers are indefensible; get it right, as this design does, and the most complex measurement in the group flows to the accounts with full lineage and no manual restatement.
Sources: Oracle Accounting Hub Cloud Service documentation (accounting rules, sub-ledger journals, distribution links and supporting references); Oracle Financial Services IFRS 17 materials (CSM sub-ledger, productised interface to the Accounting Hub); IFRS 17 Insurance Contracts, effective 1 January 2023 (IASB); measurement engine per WTW RAFM.
BlackRock AladdinLayer 1 · Source Systems
A closer view of Layer 1 — the investment book of record for the group’s invested assets
Position & Purpose Layer 1 · the largest balance-sheet driver
BlackRock Aladdin serves as the investment book of record for the group’s asset portfolios. For a life and asset-management group the invested-asset base is the single largest driver of the balance sheet, so the choice of a dedicated, institution-grade investment platform rather than a ledger asset module is deliberate and material. Aladdin maintains positions, market and model valuations, income, accruals and corporate actions across asset classes, and posts only the summarised accounting consequence upward to the ledger. It captures the full granularity of the investment domain — the detail a general ledger should never absorb — and surfaces to the GL and the actuarial pipeline the results that matter downstream.
One Investment Book of Record positions · IBOR · common data
Aladdin’s defining idea is a single, integrated investment book of record. Trades, cash movements, corporate actions and everything else that affects a position are captured in one place, in a common data language, across front, middle and back office. That integrated IBOR is what makes consistent valuation, exposure and accounting possible: positions and their economics are held once and used everywhere, rather than reconciled across fragmented systems. Through eFront, the same platform extends to private and alternative assets, giving a whole-portfolio view across public and private markets on one data model — important for an insurer whose asset mix spans both.
Risk, Valuation & Analytics risk models · scenarios · stress
Aladdin is best known for its risk analytics, and these matter as much to an insurer as the accounting. Proprietary multi-asset risk models, scenario analysis and stress testing run on the same governed position data, so risk, performance and valuation are read from one source rather than from separate tools. For a regulated balance sheet that must be steered through market volatility and assessed under prudential scenarios, that unified analytic layer — daily positions and exposures alongside model valuations and stress results — is a core capability, not an add-on, and it underpins the asset-side numbers that flow into measurement and reporting.
Asset–Liability & the Insurer ALM · SAA · climate · oversight
For a life and pensions group the asset side cannot be read in isolation from the liabilities. Aladdin’s investments in strategic asset allocation and asset–liability management support exactly that, and its climate analytics bring scenario-based climate risk onto the same platform — relevant as climate disclosure becomes part of the regulatory picture. Where a fund’s NAV is struck by an administrator, Aladdin commonly provides the investment oversight and the analytic view over those records rather than replacing them. It is the institution-grade lens through which the group understands, values and governs the assets that dominate its balance sheet.
Into the Ledger & the Pipeline summarised postings · feeds · oversight
Aladdin sits in Layer 1 and feeds the layers above. It holds the investment detail and posts the summarised accounting effect into the Oracle GL, while supplying positions, valuations and income into the actuarial pipeline that measures the liabilities they back. The discipline is the architecture’s: the ledger receives consequence, not the underlying instrument detail, and the asset numbers in the accounts and in the regulatory returns trace back to the investment book of record that produced them. It is admitted as a specialist because the domain — institutional, multi-asset, risk-intensive — genuinely demands one.
Why It Earns Its Place a specialist where the balance sheet lives
Read against the eight principles, Aladdin is the single book of record for the capability that most drives the group’s balance sheet, admitted at the edge because the investment domain demands a best-in-class system. It keeps the granular position, valuation and risk detail out of the ledger and surfaces only the consequence, with lineage from the accounts back to the source. Its contribution is decisive precisely because, for a life and asset-management group, the assets are the business: getting their book of record, valuation and risk right is the foundation on which the ledger, the measurement and the disclosures all stand.
Sources: BlackRock Aladdin documentation (investment book of record / IBOR; multi-asset risk models, scenario and stress analysis; eFront for private markets; strategic asset allocation, ALM and climate analytics for insurers); industry recognition (best buy-side IBOR; insurance asset-risk technology); investment-book role per the architecture companion.
FIS InvestOneLayer 1 · Source Systems
A closer view of Layer 1 — the fund-accounting and NAV authority for pooled and unit-linked funds
Position & Purpose Layer 1 · fund books · NAV authority
FIS InvestOne (Asset Arena InvestOne) is the fund-accounting and NAV engine in Layer 1. It strikes daily and periodic valuations and maintains fund-level books of record for the group’s pooled, unitised and unit-linked funds. It sits beside BlackRock Aladdin — Aladdin the investment book of record, InvestOne the fund-accounting and NAV authority — the two complementary rather than overlapping. Its purpose is the fund-accounting discipline an asset manager cannot do without: an accurate, controlled net asset value per fund, struck to a deadline, on which investors transact and from which the fund’s books of record are kept.
Striking the NAV valuation · trial balance · pricing
InvestOne’s core work is the daily NAV. It values each fund’s holdings, accrues income and expenses, processes corporate actions, and produces the fund trial balance from which the net asset value is calculated — for funds that price daily, every business day, to deadline. It handles the instrument types a diversified fund range demands and supports the multi-stage review by which fund accountants check valuations before release. The output is a defensible NAV and a complete fund book of record, which is the number investors deal on and the basis of the fund’s own reporting.
Control & Reconciliation reconciliation · exceptions · oversight
Fund accounting is a control discipline as much as a calculation. InvestOne reconciles fund records to custodian, transfer-agent and portfolio data, surfaces exceptions for resolution, and supports the oversight and peer review that minimise the risk of a mis-struck NAV. It manages many funds on a single database with a large library of standard reports plus customisation, so a fund range is run consistently rather than fund by fund. For pooled and unit-linked business the accuracy and timeliness of these controls is what protects both the investor and the insurer from contingent liability.
Unit-Linked & the Insurer unit pricing · funds · the asset manager
For a life and asset-management group, fund accounting is doubly important. The unit-linked books that sit behind many life policies depend on accurate fund valuation and unit pricing, and the asset-management arm depends on a dependable NAV for its pooled vehicles. InvestOne provides the fund-accounting authority beneath both, feeding the fund-level numbers that the ledger and the actuarial pipeline consume. Whether the NAV is used to price units for policyholders or to report to fund investors, it is struck once, under control, in the system that owns fund accounting — not re-derived elsewhere.
Into the Ledger & the Pipeline summarised postings · feeds · one source
InvestOne sits in Layer 1 and feeds upward. It holds the fund-accounting detail and posts the summarised accounting effect into the Oracle GL, while supplying fund-level valuations and unit prices into the actuarial and reporting flows that need them. As with the other sub-ledgers, the ledger receives consequence rather than the underlying fund detail, and the fund numbers in the accounts trace back to the NAV authority that produced them. It is admitted as a specialist because daily, deadline-driven fund accounting and NAV are a domain a general ledger cannot serve.
Why It Earns Its Place the NAV, owned in one place
Read against the eight principles, InvestOne is the single owner of fund accounting and NAV, admitted at the edge because the domain demands a dedicated engine. It keeps the granular fund detail out of the ledger and surfaces only the consequence, with lineage from the accounts back to the struck NAV. Its contribution is the integrity of a number on which both policyholders and fund investors rely — the net asset value — produced to deadline, under control, in one place. A new fund or share class is onboarded into the same engine rather than spawning a new spreadsheet, which is what keeps the fund estate governed.
Sources: FIS Asset Arena InvestOne materials and practitioner references (daily NAV, fund trial balance, many funds on a single database, 300+ standard reports, reconciliation and exceptions management); fund-administration practice (custodian / transfer-agent reconciliation and NAV oversight); fund-accounting role per the architecture companion.
KyribaLayer 1 · Source Systems
A closer view of Layer 1 — the treasury and cash-management platform that keeps the ledger thin
Position & Purpose Layer 1 · treasury · cash & liquidity
Kyriba is the treasury and cash-management platform in Layer 1: a cloud liquidity-performance platform that owns cash visibility, forecasting, payments and financial-risk management for the group. It sits among the source systems beside Aladdin and InvestOne, holding the intraday and bank-level detail of the group’s cash that a general ledger has no business carrying. Its purpose is to give the office of the CFO and the treasurer a single, real-time view of cash across accounts, entities, countries and currencies, and to surface to the ledger only the summarised accounting effect — keeping the GL thin while the operational detail of treasury lives where it belongs.
Cash, Forecasting & Payments visibility · forecast · payments factory
Kyriba unifies the treasury cycle on one platform. It delivers real-time cash-position dashboards from prior-day and intraday bank reporting; it forecasts cash and liquidity — increasingly with AI — across multiple scenarios and horizons; and it runs a payments factory that standardises and controls outbound payments from any ERP, with fraud screening on the flow. Cash pooling and in-house banking give real-time intercompany positions and interest calculation. These are the operational mechanics of treasury, run in one governed system rather than across a patchwork of bank portals and spreadsheets, which is what makes the group’s cash both visible and controllable.
Reconciliation & Accounting bank-to-book · journals · audit
Kyriba is also where treasury meets the books. It performs bank-to-book (GL) reconciliation — matching bank transactions against booked entries imported from the general ledger — and generates journal entries for its cash and liquidity models, tracking treasury financial transactions (investments, debt, risk instruments) end to end. So the bridge into the ledger is clean: Kyriba holds the bank-level detail and the treasury accounting, then posts the summarised consequence into the Oracle GL with an audit trail. The ledger sees the cash and accounting effect, not every bank line — exactly the discipline the architecture applies to every sub-ledger.
Risk & the Regulated Group FX · interest rate · controls
For a regulated group, treasury is a risk function as much as a cash function. Kyriba supports exposure management, hedging, valuation and compliance for FX and interest-rate risk on the same platform, helping protect cash flows and earnings from market volatility — material for an insurer whose balance sheet is rate-sensitive. Its controls matter too: real-time payment-fraud screening, segregation of duties on the payments flow, and recognised security and assurance (ISO 27001, SOC 1 and SOC 2). Treasury risk and payment control are run as governed processes, which is what a regulated firm requires of the system that moves its money.
Connected to Banks & ERP around 10,000 banks · Oracle · one source
Kyriba’s reach is its connectivity. It connects out of the box to thousands of banks — the platform cites in the order of 10,000 — and to the major ERPs, with pre-built connectors for Oracle Cloud, SAP, Workday and others, carrying payments, statements, cash management, GL export and reconciliation. In this estate that means Kyriba sits between the banks and the Oracle GL, unifying bank and ERP data into one cash picture and posting the accounting effect upward. The group gets one real-time source for cash, wired to both its banks and its ledger, rather than a separate, manually reconciled treasury silo.
Why It Earns Its Place the cash detail, owned at the edge
Read against the eight principles, Kyriba is the single owner of treasury and cash, admitted at the edge because real-time, multi-bank cash and payments are a domain a general ledger cannot serve. It keeps the intraday, bank-level detail out of the ledger and posts only the consequence, with reconciliation and lineage back to the bank. Its contribution is control over the group’s liquidity and the integrity of its payments, run as governed processes and surfaced to the books through a clean bridge. New banks or accounts are onboarded into the same platform rather than a new spreadsheet, which is what keeps cash visible and the ledger thin.
Sources: Kyriba documentation (liquidity-performance platform; cash visibility and forecasting; payments factory; bank-to-book / GL reconciliation; connectivity to around 10,000 banks and major ERPs; ISO 27001, SOC 1 and SOC 2); industry recognition (treasury management system of the year, 2025); treasury role per the architecture companion.
WTW RAFMLayer 1 · Insurance
A closer view of the actuarial domain — the engine that measures the insurance liabilities
Position & Purpose Layer 1 · insurance · the measurement engine
WTW RAFM (RiskAgility Financial Modeller) is the actuarial modelling engine in the insurance pipeline of Layer 1: the system that measures the group’s insurance liabilities. It is where the economics of long-dated life and pensions business are computed — projected cash flows, reserves and the IFRS 17 measurement that the accounting then reflects. It sits within the actuarial domain alongside the policy-data systems (BaNCS, Sonata) that feed it and the in-house Azure results store that holds its output. Its purpose is singular and central: to produce the measured liability numbers on which the insurance balance sheet depends, before any of them become accounting.
Modelling the Liabilities cash flows · reserves · assumptions
RAFM’s core work is actuarial projection. It models the future cash flows of insurance and reinsurance contracts under defined assumptions — mortality, persistency, expenses, economic scenarios — and computes the reserves and liability measures the business requires. These are not ledger entries but modelled results: the output of a calculation engine run over policy data and assumption sets, at the granularity the standard and the business demand. This is the measurement the architecture deliberately keeps out of the general ledger; it is heavy, assumption-driven and iterative, and it belongs in a specialist actuarial engine, not in an accounting system.
IFRS 17 Measurement CSM · fulfilment cash flows · the split
Under IFRS 17, RAFM performs the measurement half of the standard. It computes the fulfilment cash flows, the risk adjustment and the contractual service margin — the CSM that spreads profit over the life of the coverage — for each group of contracts. This is the architecture’s deliberate split: RAFM measures, and Oracle Accounting Hub posts. The actuarial engine produces the numbers the standard requires; the accounting bridge turns them into balanced journals. Keeping the two apart means the modelling can be as sophisticated as the business needs while the ledger stays thin and the postings stay auditable — the modelled result and the booked result reconciling by design.
Orchestration & Control Unify · runs · governance
At enterprise scale, actuarial modelling is as much about control as calculation. RAFM is orchestrated within WTW’s wider environment — the Unify framework that automates and governs the end-to-end actuarial process: data in, model runs, results out, with version control and an audit trail over the runs. This matters because IFRS 17 and prudential reporting demand that a measured number be reproducible and explicable, not the product of an untracked model run. Governed orchestration is what turns a powerful actuarial engine into a defensible measurement process, with results that can be traced from a posted journal back to the run that produced them.
In the Pipeline policy data › RAFM › Azure › Accounting Hub
RAFM sits in a clear pipeline. Policy and contract data flow in from the administration systems (BaNCS, Sonata), which remain business-owned; RAFM measures; the results land in the in-house Azure results store; and the measured outputs cross into the Oracle GL through the Accounting Hub as IFRS 17 journals. Data moves one way, from policy data through measurement to accounting, and the liability numbers in the accounts and the regulatory returns trace back through this chain to the actuarial run. RAFM is the measurement heart of that pipeline — the specialist the insurance domain genuinely requires.
Why It Earns Its Place measurement, owned by the actuaries
Read against the eight principles, RAFM is the single owner of insurance measurement, admitted because the actuarial domain demands a dedicated engine and because measurement is deliberately held outside the ledger. It computes the liabilities — including the IFRS 17 CSM — and hands them to the accounting bridge, keeping the modelling sophisticated and the ledger thin. Its contribution is foundational for a life insurer: the largest and most complex numbers on the balance sheet are produced here, under governance, with lineage to the accounts. The split between measuring and posting is what makes those numbers both rigorous and auditable.
Sources: WTW RiskAgility Financial Modeller and WTW Unify materials (actuarial projection; IFRS 17 measurement — fulfilment cash flows, risk adjustment and CSM; orchestration and governance of model runs); the WTW reference briefing; the IFRS 17 measure / post split per the architecture plate and companion; IFRS 17 (IASB).
WorkdayFinance / HR Boundary
A closer view of the Finance–HR boundary — the people estate that feeds Finance for cost
Position & Purpose the boundary · HR-owned · feeds Finance
Workday is the people estate at the Finance–HR boundary: the single book of record for the workforce, owned by HR and consumed by Finance for cost. It is deliberately placed on the boundary rather than inside the finance stack — HR runs it, but it feeds Finance the people-cost numbers the plan and the ledger need. It carries payroll, expenses, compensation and workforce reporting on one unified data model. Its purpose, from Finance’s point of view, is to be the authoritative source of what the workforce costs, posting that cost to the ledger through controlled interfaces while HR retains ownership of the underlying people data.
Payroll & the Pay Cycle gross-to-net · HMRC RTI · accruals
Workday Payroll runs the UK pay cycle: gross-to-net calculation, statutory deductions, and Real Time Information (RTI) reporting to HMRC on or before each payment. It is the engine that turns employment into a paid, reported and accounted cost. The payroll result posts to the Oracle GL as summarised journals through a controlled interface — the ledger receives the cost, not every payslip line — and accruals are carried where the standard requires. For Finance, payroll is one of the largest and most sensitive cost lines, and Workday is where it is calculated, reported to the revenue authority and rendered into accounting.
Expenses & Compensation expenses · travel · advanced comp
Around payroll sit the other people-cost processes. Workday Expenses captures and controls employee expense — with travel booked through Egencia and flowing in — so that travel and expense cost is governed rather than collected ad hoc. Workday Advanced Compensation runs the merit, bonus and equity cycles, holding the compensation decisions that drive a large part of future cost. Each feeds Finance the numbers it needs: expense to the ledger, compensation to both the ledger and the workforce plan. These are the components that, with payroll, make Workday the complete people-cost picture rather than a payroll engine alone.
IR35 & the UK Context off-payroll · workforce · compliance
For a UK employer the people estate carries specific compliance. Off-payroll working (IR35) determinations — who is genuinely outside payroll and who must be taxed as an employee — are handled on the HR side, within the workforce and payroll processes Workday governs, before cost reaches Finance. RTI keeps payroll reporting current with HMRC, and the workforce records support the headcount and cost reporting the group runs. Keeping these obligations with HR, on the system that owns the people data, is the right placement: Finance consumes a compliant, governed people-cost number rather than trying to administer employment itself.
At the Boundary single people record › GL & plan
Workday’s place in the architecture is the boundary it occupies. It is the single book of record for people — one model spanning HCM, payroll, expenses, compensation and workforce reporting — and it feeds across the boundary into Finance: cost to the Oracle GL through controlled interfaces, and people cost and headcount into EPM Planning for the workforce plan. HR owns the data; Finance receives the consequence. This is the architecture’s discipline applied to the people domain: a clear owner, a clear boundary, and a one-way flow of governed cost from the people system into the ledger and the plan.
Why It Earns Its Place people, owned once, costed cleanly
Read against the eight principles, Workday is the single book of record for the workforce, placed on the boundary because people data is HR-owned but people cost is a Finance input. It keeps the detailed people data out of the ledger and feeds across only the cost, through controlled interfaces, with the UK’s payroll and off-payroll obligations handled where they belong. Its contribution is a clean, compliant people-cost number for both the ledger and the plan — no parallel HR spreadsheets, no re-keyed payroll. A new role, grade or pay cycle is configured in Workday and flows through, which is what keeps people cost governed.
Sources: Workday documentation (HCM, Payroll, Expenses, Advanced Compensation and workforce reporting on a unified data model); HMRC Real Time Information (RTI) and off-payroll working (IR35) rules; the Workday reference briefing; the Finance–HR boundary and plan integration per the architecture companion.
Oracle EDMFoundation
A closer view of the foundation — the governed master data on which clean lineage depends
Position & Purpose foundation · master data · shared by all
Oracle EDM (Enterprise Data Management) is a foundation platform: the system that governs the group’s financial master data — chiefly the chart of accounts and the entity, cost-centre and other hierarchies on which every other system depends. It does not produce numbers or reports; it produces the structures the numbers are recorded and aggregated in. It sits beneath the stack rather than in a layer, shared by the Fusion GL, FCCS, EPM Planning and the Accounting Hub alike. Its purpose is to make master data a single, governed asset — defined once, under control — rather than a set of locally maintained, slowly diverging code lists.
One Governed Chart CoA · hierarchies · single definition
EDM’s core is a single, authoritative definition of the group’s reference structures. The chart of accounts, the legal-entity and management hierarchies, the cost-centre and segment structures are mastered here, with their relationships and alternate roll-ups maintained in one place. Because every consuming system draws the same structures, an account or a hierarchy means the same thing in the ledger, the consolidation, the plan and the regulatory return. This is what lets the estate read one language: the consistency that makes consolidation arithmetic clean and disclosure comparable begins with a chart that is defined once and shared, not reconciled.
Change Under Governance request · approve · version
Master data changes constantly — new accounts, new cost centres, reorganised hierarchies — and EDM governs that change. Requests are made, reviewed and approved through workflow, with validation against rules and a full history of what changed, when and by whom. A change is modelled and checked before it is released, not made directly in each system and reconciled afterwards. For a regulated group this governance is itself a control: the structures that determine how every figure is classified and aggregated are altered only through an auditable, approved process, which keeps the foundation stable and the change trail defensible.
Propagate, Don’t Diverge change once · distribute · alignment
The principle EDM enforces is change once and propagate. An approved change to the chart or a hierarchy is distributed from EDM to every subscribing system — the GL, FCCS, Planning, the Accounting Hub — so they stay aligned by design rather than drifting apart and being reconciled. This is the direct antidote to the most corrosive failure in a large finance estate: the same account or cost centre meaning subtly different things in different systems. By mastering the structures centrally and pushing change outward, EDM keeps the whole estate consistent without the endless mapping that divergence would otherwise demand.
Beneath the Estate Oracle-native · subscribers · clean lineage
EDM is part of the Oracle EPM stack and integrates natively with the GL, the consolidation, planning and the Accounting Hub, which subscribe to its structures. Its position beneath the estate is the point: lineage is only as clean as the master data the systems share, so a balance can be traced and aggregated consistently from source to disclosure precisely because every system was built on the same governed chart and hierarchies. The foundation is invisible in the outputs but present in all of them — the reason the numbers reconcile and aggregate the way they should.
Why It Earns Its Place the structures, governed centrally
Read against the eight principles, EDM is the embodiment of governed master data: the structures changed once, under control, and propagated to all. It is admitted as a foundation because consistency and lineage across the estate depend on it — without a single governed chart, every other principle is harder to keep. Its contribution is quiet but pervasive: it is why the ledger, the consolidation, the plan and the returns speak one language, and why change does not fragment the estate. A new account or hierarchy is governed and distributed, not locally invented, which is what makes the whole architecture maintainable.
Sources: Oracle Enterprise Data Management (Cloud) documentation (mastering the chart of accounts and hierarchies; request-and-approve workflow; versioning; distribution to subscribing applications); the master-data governance principle — change once, propagate — per the architecture companion; native integration with Oracle GL, FCCS, Planning and the Accounting Hub.
MetricStreamFoundation
A closer view of the foundation — the controls and attestation that make the estate auditable
Position & Purpose foundation · GRC · controls & attestation
MetricStream is a foundation platform for governance, risk and compliance: the system in which the group’s financial controls, risk registers and attestations are managed. It does not hold the numbers; it holds the evidence that the processes producing the numbers are controlled. It runs as a single connected GRC platform across enterprise and operational risk, compliance, internal audit and financial controls, beneath the finance stack rather than in a reporting layer. Its purpose is to make control demonstrable — to turn the claim that controls operate from an assertion into evidenced, tested, signed-off fact across the estate.
Financial Controls & SOX RCM · testing · assertions · evidence
At its core for finance, MetricStream runs the controls-over-financial-reporting programme. It holds the framework of processes, risks, controls, financial accounts, assertions, evidence and tests — organised in a Risk and Control Matrix — and manages the planning, scheduling and execution of control tests for design and operating effectiveness. Owners, reviewers and approvers are assigned; results, certifications and remediation are tracked; and the whole is held in one place with a relational model linking risks to controls to accounts. This is the machinery that makes financial control a managed, evidenced discipline rather than a spreadsheet exercise reconstructed at year-end.
Attestation & Certification sign-off · workflow · audit trail
Attestation is where control becomes accountability. MetricStream runs the surveys, certifications and sign-offs by which control and process owners attest that controls have operated, through structured workflow with notifications and a complete audit trail. Internal audit works on the same platform — risk-based planning, fieldwork, findings and follow-up — so assurance and the controls it tests share one source of evidence. For a regulated group this is the difference between asserting that controls work and being able to prove it, with the certifications and evidence an auditor or supervisor expects held in one governed system.
UK SOX & the Regime internal controls · UK reform · frameworks
For a UK group the control environment is moving. The UK’s corporate-governance reforms have raised expectations for internal controls over financial reporting — a UK analogue to SOX — and MetricStream offers a dedicated capability for exactly this, providing a uniform, integrated approach to risk and control data across financial processes, with control testing, certification and evidence. It maps controls across multiple frameworks so one control can satisfy several regimes, rationalising the control set rather than multiplying it. As UK internal-controls expectations firm up, a maintained GRC platform absorbs them as configuration rather than a new programme.
Connected, Not Siloed shared libraries · board view · rationalised
MetricStream’s value as a foundation is that it is connected. Shared libraries of risks, controls and regulations span the GRC domains, so a regulatory change can flow to the controls and risks it affects, and a single control can be tested once against several frameworks. Role-based dashboards give the board and the executive a real-time view of top risks, control status and audit findings — increasingly with risk expressed in financial terms. Rather than separate, siloed tools for SOX, audit and risk, the group runs one platform whose connections keep the control picture coherent across the estate.
Why It Earns Its Place control, evidenced across the estate
Read against the eight principles, MetricStream is the foundation that makes the estate auditable: evidenced control and attestation, owned in one connected platform. It admits no measurement and produces no accounts; it governs the controls and the evidence that everything else is produced under control. Its contribution is the assurance layer a regulated finance function cannot do without — tested controls, recorded attestations, an audit trail — held centrally and rationalised across frameworks. A new control or regulation is added to the shared library and tested, not tracked in a private spreadsheet, which is what keeps the whole architecture not just consistent but demonstrably controlled.
Sources: MetricStream documentation (Connected GRC; financial controls and SOX — Risk and Control Matrix, control testing, assertions, evidence, certifications, remediation; internal audit; the UK SOX solution; shared libraries and control rationalisation; board dashboards and risk quantification); UK internal-controls / corporate-governance reform context; the evidenced-control principle per the architecture companion.