What it is
A data-aggregation layer is the part of the stack that collects data from every custodian, broker and market source a manager uses and turns it into one consistent format the rest of the systems can consume. finnerve's aggregation layer does that across 80+ feeds — normalising them to a single schema, reconciling them against each other the same day, and keeping full provenance on every field so any number can be traced back to the exact source it came from.
The difference is that the aggregation layer treats provenance and reconciliation as the product, not the by-product. Where most integration layers hand you a merged file and hope, the aggregation layer carries an explicit override hierarchy — the custodian is the source of truth for a position, the pricing source is the source of truth for a price — and it shows its work: which feed set each field, when, and what it overrode. Because it is the source layer for the whole finnerve stack, the reconciliation is done once, upstream, instead of six times in six systems that each parse the custodian a little differently.
Who it's for
The aggregation layer runs in production wherever data arrives from more sources than any one system should have to parse — from a manager reconciling four custodians by hand to a platform serving a thousand end-investors off one layer.
- Fund administrators — dozens of vehicles across many custodians, collapsed into one normalised position-and-transaction record.
- Multi-custodian asset managers & funds — books spread across 4+ custodians that shouldn't be reconciled by hand every morning.
- Wealth managers — one consistent data layer sitting behind every client-facing and reporting tool.
- Family & multi-family offices — fragmented global holdings across custodians and asset classes brought into a single schema.
- Wealth-tech platforms & BI teams — a documented REST/GraphQL surface to build on, instead of hand-written custodian parsers that break on every format change.
What it covers
The aggregation layer owns the source layer: connecting the feeds, homogenising them, reconciling them, and exposing one clean surface.
- 80+ source connectors — custody, broker, market and banking feeds; custom feeds added on demand and generalised into the library once the pattern repeats.
- Normalisation to one schema, with provenance — every feed mapped to a single model, with the source, feed and timestamp kept on every field.
- Same-day reconciliation with an override hierarchy — automated break detection across feeds; the custodian wins position, the pricing source wins price, and the resolution is recorded.
- REST + GraphQL delivery — a modern API surface for every downstream system, with backwards-compatible schema versioning — no breaking changes on an upgrade.
- Operational observability — a live view of feed health, latency, breaks and SLA adherence, with alerts that fire before a downstream system notices.
How it fits your stack
The aggregation layer is the upstream source layer — the first thing data hits and the last place a custodian format is ever parsed. Feeds come in from custodians, brokers and market-data providers; the aggregation layer normalises them to one schema, reconciles them same-day with provenance kept on every field, and serves that single layer to everything downstream. Adopt it on its own under an existing stack, or as the foundation the rest of the finnerve operating layer is built on.
Days to a feed the library knows
The aggregation layer is managed infrastructure — you consume the layer, finnerve runs the pipeline that keeps it clean. There's no parser to maintain, no reconciliation job to babysit, and no on-call rotation for a custodian that changed its file format overnight.
Implementations are led by operators and accelerated by our own assets: pre-built connectors for the dominant regional custodians and global market-data sources, a normalisation engine that maps a new feed to the shared schema instead of authoring a parser from scratch, and break-detection agents that clear the routine reconciliation exceptions and escalate only the ones that need a person. That's the deliberate split — the machine reconciles the clean flow and surfaces the genuine breaks; finnerve's operations team owns feed health and the SLAs; your team consumes one schema over REST or GraphQL and builds features instead of pipelines. A feed the library already knows can be live in days; a genuinely new source is added on demand and generalised into the library once the pattern repeats. Bring us two of your custodians and we'll stand up a sample layer so you can query it.
Frequently asked questions
We already have integrations to our custodians. Why add a layer?
Because you're maintaining that integration six times, once per system that reads a custodian — and each one parses the format a little differently, which is where the numbers stop agreeing. The aggregation layer does the parsing, normalising and reconciliation once, upstream, and serves one schema to everything downstream. Your PMS, OMS and BI stop each carrying their own custodian logic, and the day a custodian changes its file, one team fixes it once. Bring us your two messiest feeds and we'll show you a single normalised layer over both in a working session.
Our custodian isn't in your 80+. What then?
It gets added — that's the normal case, not the exception. A new feed is mapped to the shared schema on demand, and once the pattern is generalised it goes into the connector library, so the next manager on that custodian inherits it. You're not paying to build a bespoke parser that only you will ever use.
"Provenance on every field" sounds nice — what does it actually buy us in an audit?
It means any number in any downstream report can be traced back to the exact source, feed and timestamp it came from, and you can show what it overrode and why. When an examiner asks where a position or a price came from, you answer from the record instead of reconstructing it from six systems after the fact. That's the difference between a merged file you have to trust and a reconciled layer that shows its work. We'll pull a field's full provenance in front of your compliance lead in a demo.
Won't a schema change break the systems we build on top of it?
No — schema versioning is backwards-compatible by design, so an upgrade adds without removing and existing consumers keep working untouched. That's a hard rule, not a best-effort: downstream systems don't break on an aggregation-layer release. It's why platforms are comfortable building investor apps and BI directly on the GraphQL surface.
Who operates this — do we run the pipeline?
You don't. The aggregation layer is managed infrastructure: finnerve runs the feed connections, the reconciliation and the SLAs, and your team consumes one clean layer over REST or GraphQL. The break-detection agents clear the routine reconciliation exceptions automatically and escalate only the genuine breaks to our operations team — so nobody on your side is on-call for a custodian that changed its format at 2am. We'll show you the observability dashboard and the SLA model in a working session.
How would we know a feed is late or broken before our clients do?
That's exactly what the observability layer is for: it tracks feed health, latency, breaks and SLA adherence live, and alerts before a downstream system — or an investor — notices anything. A missing custodian file surfaces as an alert with the break attached, not as a wrong number in a client report. You find out first, and you find out with the context to act. Bring us a real feed and we'll show you the health view and the alerting in a demo.