01
Tick & Order Book
Full-fidelity tick capture and L3 order book reconstruction across asset classes — backtests run on the same store powering live PnL.
Solutions · Financial servicesGENEDATA / 01
Bring every decisioninto balance.
Connect market, transaction, and risk data in a shared analytical foundation. Keep the route from source to reporting clear.
Shared context · Lineage · Governance
Connected
Your sources
Market data
Transactions
Risk positions
Connected intelligenceFinancial intelligence
Governance
Business impactRisk & reporting
Shared contextLineageGovernance
02
Risk Inputs You Can Trace
The governed inputs an IMA or SA calculation needs — a committed position store, column-level lineage, and version-pinned reference data — so a capital number can be traced back to the ticks behind it.
03
Reg Reporting
Each regime's report defined as a versioned view over one committed trade record, so a submission can be reproduced exactly as it was filed — with the lineage auditors ask for.
Built On
The products behind this solution.
A trading desk touches all four: GeneFlow captures the market feed, GeneCatalog proves the lineage a supervisor asks for, Cortex SQL serves risk and reporting, and Cortex AI runs surveillance.
GeneFlow
Captures venue feeds and executions with nanosecond timestamps, normalises symbology across 60+ venues, and lands committed state without an export step.
Learn moreGeneCatalog
Holds the lineage behind every capital number and regulatory field, with an immutable record of who saw which trade and when.
Learn moreCortex SQL
Feeds FRTB calculations, intraday risk, and the five regulatory reporting bases from one committed position store.
Learn moreCortex AI
Powers surveillance, anomaly triage, and the research environment that backtests on production capture.
Learn moreIndustry use-case map
Banking & Financial Services workflows across one governed operating model.
These reference workflows connect the business decision to the data, controls, platform surfaces, and people required to operate it in production.
Banking & Financial ServicesReference workflow
Credit risk decisioning
Build lending and portfolio decisions from governed customer, facility, collateral, bureau, and market features with independent model review.
How the work moves
- 01
Connect the signal
Core banking and lending systems · Market, credit, and reference data · Payments, transactions, and trades
- 02
Apply control
End-to-end lineage · Explainable decisions · Human approval
- 03
Build and deliver
Data Science & MLOps · GeneCatalog & Knowledge · Governance & Approvals
- 04
Decide and act
Consistent credit decisions with traceable features, policies, and overrides.
Participating roles
Platform surfaces
Business outcome
Consistent credit decisions with traceable features, policies, and overrides.
Explore the full industry solutionThe Challenge
Three offices, three versions of the same trade.
A single trade is represented differently in the execution system, the risk engine, the books and records, and the regulatory reporting stack — and reconciling those representations is what the close of business is mostly for.
The cost is not only the reconciliation headcount. It is that risk runs on a position snapshot taken hours ago, that a regulator's question about a trade from 2023 requires archaeology across four archives, and that a quant's backtest uses a different data vendor than the desk it is meant to inform.
Each system was a reasonable choice on its own. The problem is the joins between them — every hop loses lineage, and every reconciliation is an opportunity for two systems to disagree about a number that a regulator considers authoritative.
Consolidating onto one governed substrate removes the joins rather than automating them. Front office, risk, operations, and compliance read the same committed record, so agreement is structural instead of negotiated nightly.
- Separate data stores
- 6–9
- Typical front-to-back estate
- Risk view lag
- T+1
- Overnight batch aggregation
- Overlapping regimes
- 5+
- MiFID, EMIR, DFA, FRTB, BCBS 239
- Quant time on data prep
- ~40%
- Before any modelling begins
Reference Architecture
Capture once, serve every desk.
Market data, executions, and reference data land on one substrate. Risk, books and records, and regulatory reporting read from that committed state rather than from extracts taken at different times of day.
Every arrow is a query path inside one platform, not a file transfer between vendors. That is what keeps lineage intact from a venue timestamp through to a line in a regulatory submission.
Daily Volumes
Where the day's data actually goes.
A representative trading day on a mid-size multi-asset desk. The same captured records serve live risk, research, and the regulatory archive — which is the point: none of these consumers is reading a separate copy.
| Source | Target | Value |
|---|---|---|
| Equities | Live risk + PnL | 760 |
| Equities | Research / backtest | 780 |
| Equities | Regulatory archive | 300 |
| Fixed income | Live risk + PnL | 280 |
| Fixed income | Research / backtest | 220 |
| Fixed income | Regulatory archive | 120 |
| FX | Live risk + PnL | 420 |
| FX | Research / backtest | 340 |
| FX | Regulatory archive | 180 |
| Derivatives | Live risk + PnL | 160 |
| Derivatives | Research / backtest | 150 |
| Derivatives | Regulatory archive | 100 |
Trade Lifecycle
Who touches a trade, and when.
The same trade moves through four functions in a day. Historically each hop meant a handoff into another system; here each function reads and annotates the same record, so the lifecycle is a sequence of states rather than a series of copies.
Empty cells are deliberate: not every function acts at every stage. What matters is that all four read one record, so a compliance query at the reporting stage resolves against the same state the desk saw at execution.
Use Cases In Depth
Five problems, in the detail they actually have.
These are the workloads that justify a platform decision in financial services. Each one below covers the situation, what the platform does about it, the architecture involved, and what changes measurably.
Intraday risk on live positions, not last night's snapshot
Most desks manage intraday exposure against a position file produced overnight, adjusted by hand through the session. By mid-afternoon on a volatile day the number on the screen and the number in the risk system have diverged, and the desk is effectively trading against an estimate. The gap is widest exactly when it matters most.
What the platform does- Executions land in the position store as they are captured, so committed state reflects the session continuously rather than at a batch boundary.
- Risk measures recompute incrementally against the changed positions rather than re-running the full book, which is what makes a sub-ten-second refresh possible at all.
- Limit breaches evaluate in the same path, so a breach raises at the moment it occurs rather than in the overnight report.
- The desk view and the risk view read the same committed record, removing the reconciliation that previously explained the difference between them.
Architecture · Database (HTAP position store) + Data Engineering (streaming capture) + Observability (limit-breach alerting), reading one committed state.
| Continuous view | Overnight snapshot | |
|---|---|---|
| 09:30 | 42 | 42 |
| 10:30 | 48 | 42 |
| 11:30 | 61 | 42 |
| 12:30 | 58 | 42 |
| 13:30 | 74 | 42 |
| 14:30 | 88 | 42 |
| 15:30 | 79 | 42 |
| 16:00 | 71 | 42 |
- <8s
- Risk refresh
- Intraday
- Breach detection
- 0
- Position reconciliations
- 1
- Authoritative view
FRTB capital that can be traced back to a tick
Under FRTB, capital depends on whether a desk's risk factors pass modellability tests, and those tests depend on the observability of real transaction data. Firms routinely lose Internal Models Approach eligibility on desks not because the model is wrong but because they cannot evidence sufficient real price observations for a risk factor.
What the platform does- Every price observation is retained at capture fidelity with its venue and timestamp, which is the evidence the modellability test actually requires.
- Risk factor eligibility is evaluated continuously against that record, so a desk approaching non-modellable status is visible weeks ahead rather than at quarter-end.
- IMA and Standardised Approach engines run against the same inputs, making the capital difference between them an analysis rather than a migration project.
- Each capital number carries lineage to the specific observations behind it, so a supervisor's challenge resolves to a query.
Architecture · Data Warehousing (full-fidelity observation history) + Governance (lineage and evidence) + Data Science (version-pinned risk models).
| Step | Change | Running total |
|---|---|---|
| SA baseline | 240m | 240m |
| FX modellable | -38m | -38m |
| Rates modellable | -52m | -90m |
| Credit NMRF | +26m | -64m |
| Equity modellable | -31m | -95m |
| IMA result | 145m | 145m |
- <10s
- Full recalculation
- Continuous
- Modellability testing
- Tick-level
- Capital lineage
- 7+ yrs
- Evidence retention
One trade record, five regulatory regimes
MiFID II, EMIR, Dodd-Frank, SFTR, and BCBS 239 each want overlapping facts about the same trade, in different formats, on different deadlines. Most firms built a reporting pipeline per regime, which means five extraction paths that must each be independently reconciled back to books and records — and five places a field mapping can silently drift.
What the platform does- Each regime's report is defined as a view over the one committed trade record rather than as a separate extraction pipeline.
- Field mappings are versioned, so a report can be reproduced exactly as it was submitted on any past date, under the rules in force then.
- Submission and acknowledgement are recorded against the trade, making the reporting status of any trade a property of the record rather than a separate log.
- Late-reported and amended trades reconcile automatically against the original submission, so breaks surface as exceptions instead of at an audit.
Architecture · Governance (versioned mappings, immutable audit) + Business Intelligence (regulator-grade export) + Sharing (supervisor access with per-query audit).
| Category | Value | Note |
|---|---|---|
| MiFID II / MiFIR | 65 fields | |
| EMIR REFIT | 89 fields | |
| Dodd-Frank | 48 fields | |
| SFTR | 155 fields | |
| BCBS 239 | 34 fields |
- 5
- Regimes, one source
- Point-in-time
- Report reproduction
- Per-trade
- Submission status
- 1
- Reconciliation path
Backtests that resemble what the desk actually gets
Research typically runs on a historical vendor feed while execution runs on direct venue capture. The two differ in timestamp precision, book depth, and corporate-action handling, so a strategy that backtests well can underperform on deployment for reasons that have nothing to do with the strategy. Diagnosing that gap consumes quant capacity that should be going into research.
What the platform does- Research queries the same capture that production consumed, including full L3 book depth and venue sequence numbers.
- Corporate actions are applied consistently across the entire history, so long-horizon series stay continuous without a per-study adjustment.
- Simulated fills are evaluated against the book state that actually existed at that microsecond rather than against an interval snapshot.
- A strategy promoted to production inherits the same data path it was researched on, removing the discrepancy at the point it usually appears.
Architecture · Data Warehousing (full-fidelity history, time travel) + Data Science (notebooks on governed data) + Database (vector and time-series access paths).
| Category | Separate vendor history | Production capture |
|---|---|---|
| Momentum | 38bp | 9bp |
| Mean rev. | 44bp | 12bp |
| Stat arb | 51bp | 14bp |
| Basis | 29bp | 7bp |
- Same store
- Research and production
- L3
- Book depth in backtest
- ns
- Timestamp fidelity
- ~40%→
- Less time on data prep
Settlement breaks found during the session, not after it
Settlement breaks are typically discovered in an end-of-day sweep comparing internal records against custodian and CSD statements. By then the counterparty has gone home, the fail is booked, and resolution slips to the next day — with funding cost and, increasingly, a settlement discipline penalty attached.
What the platform does- Trade, position, and settlement feeds reconcile continuously against the same committed record rather than in a batch comparison.
- A mismatch raises into an exception queue at the moment it appears, with the underlying records attached rather than referenced.
- Root-cause categories are learned from history, so recurring break types are grouped and routed rather than triaged individually.
- Resolution is recorded against the trade, making break history a queryable property of the book rather than a spreadsheet.
Architecture · Data Engineering (continuous reconciliation) + Observability (exception alerting) + Governance (immutable resolution audit).
| Stage | Volume | % of entry | Note |
|---|---|---|---|
| Executed | 48.2k | 100% | Session total |
| Captured + enriched | 48.2k | 100% | 100% — no capture loss |
| Matched intraday | 47.4k | 98% | 98.4% matched |
| Affirmed | 47.2k | 98% | 790 exceptions raised intraday |
| Settled on T+1 | 47.1k | 98% | 0.2% reaching T+1 as breaks |
- Intraday
- Break detection
- −64%
- Breaks reaching T+1
- Attached
- Evidence per exception
- Queryable
- Resolution history
Framework Coverage
Which functions each regime actually touches.
Regulatory obligations rarely map cleanly onto one team, which is why per-regime pipelines fragment across departments. Darker cells indicate a heavier evidentiary burden on that function for that framework.
| Front office | Risk | Operations | Compliance | |
|---|---|---|---|---|
| MiFID II | 80% | 40% | 60% | 100% |
| EMIR REFIT | 40% | 60% | 100% | 80% |
| Dodd-Frank | 40% | 60% | 80% | 100% |
| FRTB | 60% | 100% | 20% | 60% |
| BCBS 239 | 40% | 100% | 60% | 80% |
| SFTR | 20% | 40% | 100% | 80% |
Because every framework reads the same committed record, adding a regime is a mapping exercise rather than a new pipeline with its own reconciliation.
Measured Change
What moves after consolidation.
Comparative figures from front-to-back consolidation programmes. The pattern is consistent: the largest gains are in the activities that existed only to reconcile systems against each other.
| Category | Before | After |
|---|---|---|
| Daily close | 6.5h | 1.5h |
| Recon effort | 9h | 1h |
| Reg report prep | 34h | 6h |
| Risk refresh | 14h | 0.1h |
Adoption Path
Nobody consolidates front-to-back in one step.
Every deployment we have run follows roughly this sequence. Each stage is independently valuable, which matters because a programme that only pays off at the end rarely survives a budget cycle.
- 1
Market data
Consolidate capture and normalisation first. Immediately removes duplicate vendor spend and gives research a production-fidelity history.
- 2
Position store
Move committed positions onto the platform. Intraday risk becomes possible and the first reconciliations disappear.
- 3
Risk + regulatory
Point FRTB and reporting at the shared record. Capital lineage and point-in-time report reproduction arrive together.
- 4
Front-to-back
Operations and surveillance join. The close becomes a review rather than a reconciliation, and the legacy estate can be retired with evidence.
Most firms are at stage one or two when they start. The ladder above marks stage two as the common entry point for a first production deployment.
Tick-level captureMarket Feed
IMA + SARisk Engines
7+ yearsAudit Retention
Versioned + reproducibleReport Definitions
The next step
The platform your front, middle, and back office can share.
Stop reconciling four data stores at the close of business. Genedata Financial Services gives traders, risk officers, and compliance teams the same governed, traceable view of every trade and exposure.
FAQ
Financial services, answered.
What risk, compliance, and front-office teams ask before consolidating.
Can this coexist with our existing OMS and risk vendors?
Yes. Most deployments start alongside the existing estate rather than replacing it — GeneFlow captures from the same venues and OMS in parallel, and the platform proves parity under production load before anything is decommissioned.
How is FRTB modellability evidenced?
Every price observation is retained at capture fidelity with venue and timestamp, which is exactly what the modellability test requires. Risk-factor eligibility is evaluated continuously, so a desk approaching non-modellable status is visible weeks ahead rather than at quarter-end.
Do we have to rebuild reporting per regime?
No. Each regime is a view over the one committed trade record rather than a separate extraction pipeline. Field mappings are versioned, so a report can be reproduced exactly as submitted under the rules in force at the time.
What about data residency for EU and UK entities?
The platform deploys per jurisdiction with residency enforced at the infrastructure boundary, under one control plane. Cross-border reporting operates on permitted aggregates rather than moving records.
How long is trade data retained?
Seven years and beyond, at capture fidelity, with the audit chain intact — so a supervisor's question about a 2023 trade resolves to a query rather than an archive restore.
Related content
Architecture
Financial Reference Architecture
Tick capture and reporting pipelines with traceable inputs.
ComplianceRegulatory Mapping
How each regime's fields map to one committed trade record.
GuideMarket Data Capture
Latency profile, sequence validation, and L3 book reconstruction.
RelatedInsurance
The same substrate applied to underwriting, claims, and reserving.
Take the next step
Bring one desk and see it end to end.
Walk a live trade from capture through risk, reporting, and audit with a solutions engineer.