Skip to content
Platform · Reference Data

Reference Data.scalearrivingMaster & Reference Data Management

Small drift in reference data becomes big misstatements in reports. This module keeps one golden record per counterparty, one version of every code set, and a countersigned history behind each merge, on the same graph as everything else. It is arriving: the design is public now so you can judge it before the release.

The product, at a glance

What Reference Data 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 hereknow what matters
What changes

What changes when this is running.

This product is arriving, so these read as commitments, stated the way we will be held to them.

01

Counterparty disputes will shrink, because one golden record per entity will be assembled under survivorship rules anyone can read.

02

Bad merges will stop being permanent, because sources will never be overwritten and every merge will unwind from history.

03

Reference drift will stop reaching reports, because every consumer will read the same versioned code sets on the same date.

who lives hereData officeDomains
The product

Trusted. Standardised. Contextual. Everywhere.

Consistent, accurate and contextual reference data across the enterprise. One authoritative source for the entities, codes and hierarchies that data quality, operational efficiency and regulatory compliance all rest on.

Trust

Business outcomes

Consistent, trusted data

Lower risk and fewer regulatory findings

Improved data quality and decisions

Faster integration and time to market

Operational efficiency and cost savings

Stronger governance and accountability

At a glance

A single, authoritative source of trusted reference data for the critical business entities and the relationships between them.

Standardise

Define and maintain reference data with global standards and hierarchies.

Centralise

Create a single source of truth across all systems.

Enrich

Add context, relationships and external data for deeper value.

Govern

Apply policies, workflows, controls and approvals.

Share

Distribute trusted reference data securely across the enterprise and to partners.

Monitor

Continuously monitor quality, usage and changes.

Prove

Deliver audit-ready evidence and lineage for compliance.

Trigger events

When an institution reaches for this.

Two systems that disagree about who a counterparty isA regulatory filing rejected because a code set was staleAn acquisition that doubles the number of customer identifiers overnightReference data maintained by hand in a spreadsheet somebody owns personallyAn examiner asking where a legal entity identifier came from

What it does

Seven stages from finding reference data nobody has inventoried to watching what happens after it is published.

01 · DiscoverFind and profile reference data from internal and external sources.

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

The reference data architecture

Many sources converge on one hub, and every consumer reads the same record out of it. That shape is the product: without the single middle, core banking and the regulatory filing are reading two copies that happen to agree today.

Sources

Consumers

OntaVera reference data hub

Integration and delivery services

  • Batch processing
  • Real-time APIs
  • Change data capture
  • Event streaming
  • Message queues
  • Files and feeds

Many sources converge on one hub, and every consumer reads the same record out of it. That shape is the product: without the single middle, core banking and the regulatory filing are reading two copies that happen to agree today.

Worked instance: a legal entity arrives from GLEIF and from the onboarding system, is resolved to one golden record in the hub, and is distributed to core banking, treasury, the risk platform and the reporting layer, where it lands in FR 2052a, BCBS 239 and CCAR. One record, four systems, three filings.

One customer record, followed all the way through

The golden thread for a single reference record, from the moment it is created or acquired to the moment somebody notices it has drifted. Every link leaves the artefact the next one needs.

01 · Create or acquireAutomated

The record arrives, from an internal system or an external authority.

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

What the thread yields at the end: complete lineage, change history, quality evidence, access and usage, and an audit trail. None of those is a report you run afterwards; each is a by-product of having been built this way.

Key capabilities

Core reference entities

  • Customers and counterparties
  • Legal entities: LEI, D-U-N-S
  • Accounts: GL, subsidiary
  • Products and services
  • Employees
  • Vendors and suppliers
  • Instruments and securities

Codes and classifications

  • Global code sets
  • Regulatory codes: FR, BCBS, IFRS
  • Industry classifications: NAICS, GICS
  • Status, reason and type codes
  • Currency and country codes
  • Risk and rating codes

Hierarchies and relationships

  • Organisation hierarchies: legal, operational, management
  • Account hierarchies: natural, rollup
  • Product hierarchies
  • Location hierarchies
  • Cross-entity relationships
  • Graph-based connectivity

Data quality and matching

  • Fuzzy matching and de-duplication
  • Golden record management
  • Completeness and validity checks
  • Conformity to standards
  • Data quality scorecards
  • Issue management and remediation

Stewardship and governance

  • Data ownership and stewardship
  • Change management
  • Approvals and certifications
  • Policy enforcement
  • Access control and segregation
  • Audit trail and lineage

Distribution and access

  • Real-time APIs
  • Batch files and feeds
  • Event notifications
  • Self-service access portal
  • Data subscriptions
  • External partner access

Monitoring and observability

  • Freshness and availability
  • Usage analytics
  • Change monitoring
  • Impact analysis
  • Data quality trends
  • Issue alerts and incidents

Where the platform proposes

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

Suggest standard values and codes
Auto-detect duplicates and propose matches
Recommend hierarchies from observed relationships
Resolve identifiers against external registers
Detect anomalies and issues
Predict data quality risk before it lands

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.

  • Define the entities, codes and hierarchies
  • Set the survivorship and validation rules
  • Approve a change, and own the golden record
  • Resolve an escalated data issue
  • Certify the record for a filing

AI-assisted

The platform proposes. A person accepts.

  • Discover and profile reference data across sources
  • Suggest standard values and codes
  • Auto-detect duplicates and propose matches
  • Recommend hierarchies and cross-references
  • Detect anomalies and predict quality risk
  • Draft the documentation

Common use cases

Where institutions start

  • Customer and counterparty standardisation: LEI, UTI
  • Product and instrument reference data management
  • Location and branch standardisation: ISO, BIC
  • Account and general ledger hierarchy management
  • Vendor and third-party reference data management
  • Regulatory code management: FR 2052a, BCBS
  • Currency and exchange rate reference data
  • Reference data synchronisation across systems
  • Merger, acquisition and new entity onboarding
  • Reference data quality monitoring and remediation

End-to-end workflow

  1. 01Discovery
  2. 02Modelling
  3. 03Standardisation
  4. 04Enrichment
  5. 05Change request
  6. 06Steward approval
  7. 07Publication
  8. 08Distribution
  9. 09Monitoring

What gets measured

Against your own baseline.

Reference data trust scoreTrusted reference data assetsHigh-risk reference items openCritical controls effectiveAverage data qualityReference data requests servedTime to resolve a reference data issue

Who it is for

Data owners and stewardsData governance teamsReference data managersData engineers and architectsApplication and integration teamsRisk, compliance and auditFinance and operationsPartners and external entities

Integrations

OntaVera CatalogOntaVera LineageOntaVera QualityOntaVera GovernanceOntaVera PrivacyOntaVera Data ProductsOntaVera Trust IntelligenceGLEIF, Bloomberg, SWIFTERP and core bankingCRM and sales systemsData warehouses and lakehousesETL and data pipelinesReporting and BI toolsAPIs and webhooks

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

  • Enterprise-grade reference data with full lifecycle governance
  • AI-powered mapping, matching and enrichment
  • Built-in quality, lineage and regulatory traceability
  • Scalable, real-time distribution across the enterprise
  • Secure, compliant and designed for global financial institutions

One trusted source.Every system.Every decision.Every day.

Try it yourself

What Reference Data will do, shown live.

Two systems hold the same customer. Watch the merge happen the governed way: a person signs, every surviving value names its source, and history is never overwritten.

setting the stage…
Inside Reference Data6 sub-modules

This capability is arriving. The design is public now so you can judge it before the release: one golden record per entity, assembled attribute by attribute under survivorship rules you can read, with the source of every surviving value on display and nothing overwritten.

What you get
01

One golden record per counterparty, instrument, or account, with the winning source named for every attribute.

02

Survivorship rules are versioned policy objects, so you can say why a value won on any date.

03

Sources are never overwritten: the golden record is derived, and the inputs stay on the graph.

How it works
1

Derive

Survivorship rules assemble the golden record from the source records, attribute by attribute.

2

Seal

The derivation and its rule version are sealed, so the record can be defended and rebuilt.

Questions buyers ask
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.

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. Reference Data is part of that first conversation.

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.