Skip to content
Platform · Regulatory

Regulatory.trustCompliance & Evidence

This is the module the whole platform exists to feed. Obligations map to controls, controls map to data, and when the examiner asks, the evidence pack generates from the sealed record instead of being assembled by hand.

The product, at a glance

What Regulatory is made of.

6 capabilities, and the part of the mechanism this product carries. Every box opens right here, with its full story one tap deeper.

tap any box, or any circle in the mechanism, and it answers right hereprove what happened
What changes

What changes when this is running.

Not promises of speed, but mechanisms: each of these happens because of how the product works, not because we say so.

01

Exam preparation stops being a scramble, because evidence packs generate from live lineage and the sealed record on demand.

02

Coverage gaps surface before the examiner finds them, because control-to-data mapping is a live join, not an assertion.

03

Who signed and what they saw stops being debatable, because attestations are sealed like every other decision.

who lives hereCompliance officersSecond line riskInternal auditRegulatory reporting teamsanswers toBCBS 239
The product

Comply. Prove. Submit. With confidence.

Regulatory complexity turned into a governed, automated and auditable process. From interpreting the regulation to filing-ready reports, evidence packs and the supervisory conversation afterwards.

Trust and Scale

Business outcomes

Lower compliance cost and effort

Faster regulatory reporting

Higher accuracy

Stronger audit and exam outcomes

Real-time regulatory readiness

Reduced risk and penalties

At a glance

Meet regulatory obligations with precision, speed and the evidence behind every figure.

Interpret

Convert regulations into obligations, data and controls.

Map

Link requirements to data, systems, owners and policies.

Build

Model, calculate and generate filing-ready reports.

Validate

Automate quality, consistency and regulatory checks.

Prove

Create immutable evidence and audit trails.

Engage

Manage regulator interactions and supervisory requests.

Trigger events

When an institution reaches for this.

A filing that takes a quarter to build and cannot be traced back to the ruleA supervisory question nobody can answer without three weeks of archaeologyThe same figure arriving differently in two returnsA regulatory change with no way to size what it touchesAn exam request that turns into a fire drill every time

What it does

Seven stages from a rule somebody has to read to a filing somebody has to defend.

01 · Regulation intakeCapture, interpret and track regulatory change.
  • Regulation library and updates
  • Interpretation and instructions
  • Taxonomy ingestion
  • Change tracking

Hover, click or use the arrow keys to walk the lifecycle.

The regulatory execution and reporting engine

Five stages, and the discipline is that a figure cannot skip one. A number in a submission resolves back through the calculation that produced it, the data it consumed, the obligation that required it and the regulation that created the obligation. There is no path from a source system straight to a filing.

01 · RegulationRegulation and requirements
  • FR 2052a, liquidity
  • BCBS 239
  • CCAR and DFAST
  • Basel III and IV
  • OSFI E-23
  • SOX and SEC
  • PIPEDA and privacy
  • AML and KYC

Where the data starts, and the only layer nobody governs.

Evidence is captured at every stage rather than assembled at the end, which is what makes the golden thread below a by-product rather than a report.

The regulatory golden thread

Every figure in a filing resolves back to the rule that required it. This is one worked chain, from a Basel principle to a schedule in a return, with the artefact at each link named.

01 · RegulationBCBS 239

The rule itself, ingested with its instructions and its taxonomy.

A chain is a conjunction. Take one link out and see what is left.
  • Verified and active
  • Inferred, awaiting an owner
  • Planned, not in use

An illustrative chain. The obligation, control and element identifiers are the shape of a real record rather than one of yours.

One filing, built end to end

A worked FR 2052a build. This is the journey the engine compresses, and every stage leaves the artefact the next one needs. The colour says who does the work: most of this is machine work, and you can see exactly where a person signs.

01 · Regulation interpretationAI-assisted

Understand the requirements, the taxonomy and the instructions.

A chain is a conjunction. Take one link out and see what is left.
  • Automated
  • AI-assisted
  • Human approval

The two human links are not a gap in the automation. They are the point: a filing is somebody's signature, and the platform's job is to make sure that signature is standing on something reconstructable.

Key capabilities

Regulatory ontology and knowledge

  • Regulations, standards, instructions and guidance
  • Obligations, rules and definitions
  • Taxonomies: XBRL, DPM
  • Interpretation history

Obligation and policy management

  • Obligation library
  • Policy mapping
  • Control library
  • Change tracking

Reporting workbench

  • Templates and schedules
  • Dynamic parameters
  • What-if and scenario
  • Multi-entity consolidation

Validation and QA engine

  • Taxonomy validation
  • Cross-field validations
  • Error and exception management
  • Data reconciliation

Exam and regulator engagement

  • Request tracking
  • Question and answer workspace
  • Evidence packs
  • Audit trail and logs

Evidence and audit vault

  • Immutable storage
  • Versioning and lineage
  • Retention and access
  • Export and attestations

Where the platform proposes

AI-powered, and every one of them a recommendation rather than a decision.

Regulation ingestion and summarisation
Obligation extraction from the text
Auto mapping from source to report, with confidence
Anomaly and variance detection across schedules
Evidence gap identification before an examiner finds it
Draft narratives and disclosures

Manual and AI-assisted

The same work, split. Everything on the left is something a person does; everything on the right is something the platform proposes, with evidence, for a person to accept. Nothing crosses the line on its own.

Manual

A person does this.

  • Interpret the regulation and set what is required
  • Own the obligation, the control and the definition
  • Review and accept a proposed mapping
  • Approve, attest and sign the filing
  • Answer the supervisory question
  • Decide a resubmission

AI-assisted

The platform proposes. A person accepts.

  • Ingest regulations and track change
  • Extract obligations and propose control mappings
  • Map source to report with a confidence score
  • Generate validations and reconciliations
  • Detect variances and unexplained movements
  • Assemble the evidence pack

Regulatory reporting supported

Liquidity and capital

  • FR 2052a, liquidity
  • LCR and NSFR
  • CCAR and DFAST
  • Basel III and IV, Pillar 3

Reporting and disclosure

  • FR Y-9C call report
  • SOX and SEC financial reporting
  • FINREP and COREP, Europe

Canada and beyond

  • OSFI E-23
  • Multi-jurisdiction: US, Canada, EU, UK

Financial crime

  • AML and KYC regulatory reporting

Common use cases

Where institutions start

  • Build filing-ready FR 2052a reports end to end
  • Automate BCBS 239 data aggregation and lineage
  • CCAR and DFAST submissions with full evidence
  • Generate regulatory disclosures and narratives
  • Multi-jurisdiction reporting across US, Canada, EU and UK
  • XBRL taxonomy mapping and validation
  • Regulatory change impact analysis
  • Exam management and response automation
  • Control and data certification workflows

End-to-end workflow

  1. 01Regulation intake
  2. 02Obligation mapping
  3. 03Control design
  4. 04Data and lineage mapping
  5. 05Calculation
  6. 06Validation and reconciliation
  7. 07Report generation
  8. 08Review and certification
  9. 09Submission
  10. 10Exam response

What gets measured

Against your own baseline.

Regulatory readiness scoreReport accuracyReporting cycle timeHigh-risk gaps openControl effectivenessEvidence artefacts heldTime to resolve a regulatory issue

Who it is for

Regulatory reporting teamsRisk, finance and treasuryData owners and stewardsCompliance and legalInternal auditBusiness linesThose managing the supervisory relationship

Integrations

OntaVera CatalogOntaVera GovernanceOntaVera LineageOntaVera QualityOntaVera Reference DataOntaVera Data ProductsOntaVera Trust IntelligenceCore banking and treasuryGeneral ledger and financeDatabricks, SnowflakeWorkiva, DiligentServiceNow, JiraEmail, Teams, Slack

Built on the OntaVera platform

Shared by every product in the suite.

Financial ontology and knowledge graph

Metadata fabric and connectors

Policy and rules engine

Workflow and approvals

Security and access: RBAC, ABAC

Audit and evidence, immutable

AI and ML services, and copilots

Why OntaVera

  • Regulation-aware, data-driven and AI-augmented
  • End to end from requirement to submission, with the evidence attached
  • Real-time visibility, risk detection and change impact
  • Reusable and scalable, built for enterprise and global compliance
  • Built for the people who own the filing: data, finance, risk and compliance

Regulatory confidence.Operational efficiency.Complete evidence.Every time.

Try it yourself

See Regulatory do real work.

Regulation
BCBS 239 · P3
Policy
liquidity data
Control
CTRL-LCR-03
Critical data
deposit balance
Quality rule
DQ-ADB-201
Report
FR 2052a
Test result
pass · 12 May
Evidence
EV-LCR-2026-05

every link is a live connection you can query · change any one and the platform shows what else moves · illustrative, ABC Bank

This is the chain your examiner walks. Take one piece of evidence away and every dependent state falls; put it back and the packet seals again.

setting the stage…

What an examiner actually receives.

An evidence pack is self-contained: the report's scope, its lineage with a declared denominator, the quality results, the control conclusions, the attestations, and every sealed decision with who decided and on what evidence. It re-verifies offline, without access to us.

WHAT THE PACK CONTAINS

seven parts, one packet · pick any part to read what an examiner actually receives

We will not claim exam precedent we do not have. What we will show you in a working session is the pack itself: every decision sealed, every gap named. Bring your last first-day letter and we will map the pack to it, line by line.

Inside Regulatory6 sub-modules

Regulations arrive as prose, and your controls need something concrete to attach to. The obligation library breaks each framework, including BCBS 239, SOX, CCAR, GDPR, and the EU AI Act, into discrete obligations. When an examiner asks how you meet a requirement, you point to the obligation, the control behind it, and the data behind that.

What you get
01

Pre-built obligation packs cover the frameworks banks actually face. Each framework is decomposed into obligations you can map controls to, not chapter summaries you can only cite.

02

Your own obligations sit alongside the pre-built ones. House policy, supervisory letters, and local rules are versioned and governed the same way.

03

Your existing compliance matrix imports as claims and is reconciled against the live control mappings, so inherited coverage is checked rather than assumed.

04

Every obligation shows its mapped controls, and an obligation with none reads as a gap on the board. Absence is failure, so nothing looks covered by default.

05

When a regulation is updated, the obligation is versioned and every control mapped to it is flagged for review, and the review itself is sealed on the ledger.

06

Coverage rolls up by framework and principle, so your second line can see which parts of BCBS 239 have controls behind them and which are still assertions.

How it works
1

Load

Start from the pre-built packs for your frameworks and import your existing compliance matrix. It lands as claims to be checked, never as settled truth.

2

Decompose

Each regulation is broken into discrete, versioned obligations that a control can actually attach to.

3

Map

Controls attach to obligations through the one decision door: each mapping is proposed, reviewed by someone else, and sealed.

4

Watch

Coverage is derived from the live mappings, so an unmapped obligation or a stale mapping surfaces on its own.

Questions buyers ask

Asked about Regulatory

5 questions

A GRC tool holds coverage as assertions that someone maintains by hand, so coverage drifts quietly between reviews. Here coverage is computed as a live join between controls and actual lineage, which means nobody can prop it up manually and a break flags the same day it happens. Your existing compliance matrix imports as claims and is reconciled against the live mappings, so you keep what you have and find out where it no longer matches reality.

Control-to-data traceability →

It runs on the record the platform already keeps: live lineage from the other modules, plus the control mappings and attestations you build up here, all sealed on the ledger. Where an input is not in place yet, you see a named gap rather than a blank, so partial coverage is still honest coverage while you build out. Only metadata is involved, and your data stays in your own systems.

How the platform fits together →

Stewards and data owners keep the control mappings current through maker-checker, because they sit closest to the data. Your second line reviews coverage and signs packs before anything goes out. When an exam is running, the workspace gives every request a named owner and a deadline, so the response effort is tracked work rather than a scramble.

Exam workspace →

Every artifact in a pack carries provenance to a sealed ledger entry, the pack is reproducible on demand, and the chain verifies end to end, which is a stronger position than a binder assembled by hand. Exports arrive in the formats auditors already work in, and your second line reviews and signs each pack before anyone external sees it.

Evidence packs →

The hole appears in the pack as a named gap instead of being papered over, so you find it before the examiner does. The same rule runs through the whole module: an unmapped obligation reads as a gap and a lapsed attestation reads as lapsed, so nothing looks covered by default.

Stronger together

One shared record, so products compound.

Every product you add makes this one smarter, because they read and write the same governed record. Start where it hurts most; nothing you adopt later starts from zero.

Regulatory + Lineage

Add lineage and evidence packs generate from parsed code rather than screenshots and hand-built binders.

Regulatory + Governance

Add critical data elements and every obligation maps to the tiered, owned fields it actually depends on.

Getting started

Start small, and prove it on your own systems.

Most banks start with one priority report and five source systems, live in 90 days, then bring in more of the platform behind exit gates they approve. Regulatory is part of that first conversation.

Keep exploring
← Privacyavailable nowData Products →available nowThe engines underneatharchitectureHow decisions workframework
The next step

Start with proof, not a promise.

There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.

01

A 60-minute working session

Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.

02

A two-week guided sandbox

Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.

03

A six-week proof on your systems

We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.

Book a working sessionSee the adoption path