Fencore DataHub

Who DataHub is for

DataHub is built for the buy-side: asset managers, wealth managers and family offices, asset owners, service providers and fund administrators, and alternative investment managers. It is designed for firms that must combine vendor feeds, internal books, administrator and custodian files, and unstructured private-markets documents into something operations, investment, and client teams can trust.

It sits between upstream sources and downstream consumers. Typical connected systems include market-data vendors, portfolio and order management systems, IBOR and ABOR platforms, fund administrators, custodians, accounting engines, and reporting or analytics warehouses. DataHub does not replace a portfolio management system, an order management system, or an investment accounting package. It makes those systems consistent with each other and with a governed golden store.

The platform covers public and private markets and the usual buy-side asset classes: equities, fixed income, cash, derivatives, OTC, and alternatives. Packaged workflows exist for operational data stores, product and fund masters, sustainability data, public/private look-through, and investment accounting integration. Buy-side segment pages describe how those patterns apply to each buyer type.

The operating loop

DataHub is organised around a repeatable loop rather than a one-off ETL project. The same no-code environment is used to connect sources, raise the quality of what arrives, produce a golden record, keep other systems in sync, govern change, and publish results to people and machines.

1. Connect: onboard files, APIs, databases, message queues, email, and cloud or FTP locations through reusable connectors.
2. Validate: apply business and technical checks as data lands, and raise alerts when rules fail.
3. Master: match and merge competing sources into a golden record with source priority and field-level control.
4. Transform: filter, derive, and reshape data into the structures your processes actually use.
5. Reconcile: compare books, administrators, custodians, and warehouses, and manage breaks as exceptions.
6. Govern: cell-level lineage, audit trail, access control, multi-eye approval, ownership, and a business glossary.
7. Serve: dashboards, report designer, look-through, natural-language query via Cori, and FenWarehouse for analytics and AI.

Work is organised in workspaces. Configuration is versioned and deployable. Scheduled and file-driven events keep pipelines running without a separate operations toolchain. Business users work in end-user dashboards for data, alerts, approvals, and tasks; configuration users design pipelines and the data dictionary in the same product family.

Cori: the in-product assistant

Cori is Fencore’s named AI assistant inside DataHub. It is not a generic chatbot bolted onto a help site. It works against the client’s workspace: the documentation that explains the product, the configuration that defines how that workspace runs, the metadata that describes the data model, the data itself, and the alerts that tell operations what broke.

Teams use Cori in the same interface they already use for configuration and operations. Questions stay in context. Answers are meant to shorten the time between “I need to know” or “I need to build this pipeline” and a usable result, without handing the keys of production change to an ungoverned agent.

• Query product documentation

  Ask how DataHub features work, what a workflow is for, or how a buy-side pattern is meant to be configured, using Fencore product documentation rather than generic web search.

• Query and explain configuration

  Ask what exists in this workspace: pipelines, connections, rules, schedules, and related configuration. Cori can explain how pieces fit together so new joiners and auditors are not dependent on tribal knowledge.

• Query metadata

  Ask about the data dictionary: tables, fields, ownership, and cell-level lineage questions such as where a value is defined and what depends on it.

• Build pipelines from natural language

  Describe the pipeline you need in plain language. Cori drafts configuration for DataHub component types so users start from an assembled pipeline rather than an empty canvas. Users review, adjust, and save through the same no-code editors and approval paths they already use.

• Query data

  Ask questions of the data in the workspace (positions, reference data, valuations, or other mastered sets you are authorised to see) instead of waiting on a specialist to write an ad hoc extract.

• Query alerts

  Ask Cori to find, summarise, and explain data-quality and operational alerts: what failed, where it came from, and what is still open, so exception queues are searchable in English as well as in filters.

• Guided setup from files and examples

  When onboarding a new feed, users can work from sample files such as CSV, Excel, or PDF. Cori helps turn that example into a starting pipeline, still subject to human review before it runs in production.

Cori governance and data boundary

Cori uses the same access controls as the rest of DataHub. It can only see what the signed-in user is allowed to see. It assists configuration and operations; it does not replace four-eye approval, override workflows, or audit requirements. Production still moves through the controls the firm already defined.

Cori is a governed assistant, not an open-ended agent. It can use only the allow-listed DataHub tools exposed for its profile, within the signed-in user’s workspace and permissions. It can draft queries and configuration, but users review proposals and existing approval controls govern production changes.

Your deployment determines which model provider handles each request. DataHub supports a Fencore internal model as well as customer-configured providers. Ask us about model hosting, retention, and regional processing for your deployment.

Cori is grounded in authorised workspace evidence and controlled tools. It is designed to cite available results and decline when evidence is insufficient. Model settings can reduce variability, but they are not a substitute for grounding, permissions, and human review.

Cori is licensed as part of the DataHub family. FenDQ, FenRecon, and FenWarehouse benefit from the same assistant when they are used inside a DataHub workspace. DataHub is where Cori is delivered, so the sections below cover its full capability set.

Connect and ingest

DataHub is designed to replace the legacy EDM and hard-coded integration layer. During transition, it connects to the stack you already have, including webservice and API feeds, message queues, direct database connections, Excel, email, CSV, JSON, XML, and file movement over FTP or cloud object storage. New vendor or internal sources are configured in the UI.

Fencore already connects widely used buy-side sources, including Bloomberg, LSEG (Refinitiv), FactSet, ICE, SIX, IHS Markit, MSCI, RIMES, and Aladdin, among others, across 75+ integrations with data vendors and systems. If a preferred vendor or internal system is not already on the list, the same connector framework is used to add it with the client. Most source and validation requirements stay visible in no-code configuration; versioned source connectors and step plugins provide a bounded extension point for genuinely firm-specific edge cases.

Ingestion is not limited to tidy vendor files. Private-markets and wealth workflows regularly need document-borne data (for example financial statements and investment reports) alongside standardised public-market feeds. DataHub is designed so both land in the same operational store and the same governance model.

Quality, mastering, and reconciliation

Three related jobs are easy to conflate and should not be. Data quality asks whether a dataset is complete, timely, and internally consistent. Mastering builds a golden record when several sources describe the same instrument, product, or entity. Reconciliation compares two (or more) independently maintained sets (IBOR versus ABOR, administrator versus internal book, custodian versus warehouse) and highlights breaks.

Inside DataHub, quality rules are configured no-code: validations, filters, derivations, and reference lookups as data moves through pipelines. Alerts can be assigned by field ownership, prioritised, commented, and closed under optional approval. FenDQ is the same quality discipline as a standalone product when the firm is not ready to replace its existing store. FenDQ covers standalone packaging and governance in more detail.

Mastering uses matching and source priority so the operational store is not “whichever file arrived last.” Field-level steps can transform, validate, and derive values as the golden record is built. That is how DataHub supports security reference, issuer, product, and similar masters without encoding one vendor’s model as a hard-coded industry standard.

FenRecon is the reconciliation engine: it ships with DataHub and is also licensed standalone. It is for keeping books aligned, not for collapsing sources into one master. Thresholds, exception workflows, and traceability are FenRecon’s remit. FenRecon covers standalone licensing and break management in more detail.

Model and governance

The data dictionary is the living model: tables, fields, relationships, and which attributes participate in mastering and in FenWarehouse. It is configured in the UI, not hidden in undocumented scripts. Metadata management, a business glossary, and ownership sit next to the model so stewardship is not a separate spreadsheet.

• Granular access control over data and user interfaces
• Multi-eye (including four-eye) approval for sensitive changes and overrides
• Automated cell-level data lineage from source through validations, transformations, and targets
• Audit trail of who changed what, and when
• Alert workflows with assignment, comments, custom statuses, and optional approval on status changes
• Kanban-style tasks and deadline notifications for reporting calendars and operational work

These controls are the reason DataHub can be used as the operational system of record for data even when downstream analytics or client reporting live somewhere else. Cori reads the same model and the same permissions; it does not bypass them.

Serve data to the business

Once data is mastered and governed, DataHub is meant to shorten the path to an answer. Investment and client teams can look through hierarchies (security and market data, valuations, revenues, exposure, performance contribution and attribution) without a separate extract for every request.

• Report designer for client and regulatory documents, refreshed from latest data
• Pivot-style dashboards for analysis without exporting to a desktop tool first
• Natural-language questions via Cori against authorised data and metadata
• FenWarehouse as the analytical plane (Snowflake by default) for BI, look-through, and AI that should not query the operational store directly. FenWarehouse covers the analytical plane and licensing.
• Authenticated APIs, exports, and connectors so Python, BI, and internal applications can consume authorised mastered data rather than raw vendor files

Use cases

DataHub is flexible, but Fencore ships opinionated workflows so firms do not start from a blank model. Each workflow below has a dedicated use case, including metrics and (where published) client commentary such as First Degree on operational data management.

• Operational Data Store

  Enterprise-wide single source of truth across front-to-back investment data: security, market, issuer, trades, fees, positions, valuation, exposure, and performance. Operational Data Store use case.

• Product Master

  Golden source for product and fund data from launch to liquidation, including document production patterns such as PRIIPs and UCITS KIDs where those workflows are in scope. Product Master use case.

• Sustainability Master

  ESG and sustainability data gathered, validated, and served from one place rather than scattered vendor files. Sustainability Master use case.

• Public and private markets

  Standardised public-market feeds alongside tools for infrequent and unstructured private-markets data, with a consolidated view across the investment universe. Public and Private Markets use case.

• Investment accounting

  Data flows between portfolio and order management on one side and in-house or outsourced accounting on the other, with shared market and reference data. Investment Accounting use case.

Beyond the warehouse: the data operating system

Snowflake, Fabric, and Databricks move and store data. They do not give you a data operating system: approvals desks, alert triage, config promotion between environments, mastering into golden records, pipeline designers, and governance that follows the business (role-based access to data in a UI operators can use, and cell-level lineage that tracks values through transforms, not just tables), plus Cori inside the same access model. DataHub provides that operating layer. It is what teams underestimate when they budget “a warehouse project.”

• Approvals and alerts

  Multi-eye governance and a single desk for data-quality and process exceptions (typically months to handcraft in-house even with AI coding help).

• Configuration deployment

  Promote no-code configuration Dev → UAT → Prod with history and rollback (often 9–15 weeks of happy-path build to production parity alone).

• Governance that follows the business

  Role-based access to data in a UI operators can use, and cell-level lineage that tracks values through transforms (not just tables), plus impact analysis and stewardship on the live model. Another multi-month bundle before pipelines or mastering.

• Pipeline and mastering designers

  Visual FenDataFlow, FenMaster, FenRecon, and FenSolution configuration with governed runners: a credible happy-path suite is often 6–9 months to replicate.

• Cori

  Natural-language access to docs, config, metadata, data, alerts, and pipeline build, inside the same controls as the rest of the platform.

Read The Data Operating System for Fencore’s full capability-and-effort analysis (happy-path ops and governance build of roughly 10–15 months, often closer to 20–30 months to a used-in-production system once requirements and first-use change are included), why configuration remains necessary after go-live, and what you lose if you hard-code ETL instead of a configurable platform. The Build Trap reports survey evidence on why in-house builds fail in practice.

Deployment and interoperability

DataHub is cloud-native. Clients can run in public cloud or private cloud. Fencore’s published position is that an environment is up in hours rather than days or weeks, with a managed-services option for IT and business-process outsourcing. The architecture is containerised and built to scale with volume; it is compatible with common public and private cloud providers.

DataHub is designed to replace the legacy EDM and hard-coded integration layer, not the portfolio, order-management, or accounting systems that run the firm. It can work alongside existing data-management systems during transition, allowing firms to migrate workflow by workflow and retire redundant mapping, reconciliation, and exception tooling as confidence grows. Proof-of-concept projects use the same no-code configuration that runs in production, reducing the risk of a larger data programme. The Build Trap documents why many buy-side in-house platforms fail that test.

The Fencore suite

DataHub is the hub. FenDQ, FenRecon, and FenWarehouse are focused products available within DataHub, as standalone products, or as an analytical add-on. Cori is the assistant for DataHub workspaces.

Explore FenDQ, FenRecon, and FenWarehouse in full. Shorter product summaries: DataHub, FenDQ, FenRecon, and FenWarehouse.