Operating consultancy for financial data

In financial data, the pipeline is the product. Everything else is interface.

The dashboard is not the business

Sit in enough steering meetings at a financial data vendor and you notice the same pattern. The roadmap slide is full of UI work: a new dashboard, a redesigned export flow, a cleaner API docs portal. Meanwhile the thing customers actually pay for, a feed that reconciles overnight, corporate actions applied correctly, prices that match the exchange, gets a single line item: "maintenance."

That line item is the business. The dashboard is a window onto it. Sell an asset manager a beautiful UI sitting on top of a pipeline that silently drops a rebalancing event once a quarter, and you will lose that client the day their compliance team finds the gap, not the day the UI looks dated.

This is the founding mistake in how these businesses get run. Leadership teams, often staffed by people who came up through product or growth, treat the interface layer as the product because it is the layer they can see, demo, and iterate quickly. The substrate, the actual data engineering, gets treated as infrastructure: necessary, unglamorous, someone else's problem. Read the org chart and you'll usually find the data engineering lead reporting two levels below the CPO, sometimes into the CTO, sometimes into ops. Nobody owns the substrate as a business function. Everybody owns it as a cost centre.

Treat the substrate as the product

Flip that framing and the whole operating system snaps into focus. If the pipeline is the product, data engineering is the product organisation. Governance becomes the quality-control line. Customer trust follows as the measurable output of both doing their job.

This is not an abstract reframe. It changes concrete decisions:

• Roadmap prioritisation. A pipeline reliability fix that prevents one bad data day per quarter outranks a UI polish sprint, every time, in a business where the data is the product. Most roadmaps get this backwards because reliability work doesn't demo well.
• Where the money goes. Headcount and budget follow whichever team leadership believes is "the business." If that's still the front-end team by a factor of three, the substrate will keep degrading no matter how many all-hands talk about data quality.
• Who sits in the executive review. If the person who owns pipeline reliability isn't in the room where commercial decisions get made, the substrate optimises for whatever the engineering team can measure internally, not for what the business actually needs from it.

That last point is the one that catches people out. A pipeline owner will optimise ruthlessly for uptime, latency, throughput, because those are the numbers on their dashboard. None of those numbers tell you whether the output serves the business outcome the client is actually paying for. A feed can be 99.99% available and still be commercially useless if it's reconciling against the wrong reference data, or if it's fast but wrong on the one field the client's risk model depends on. Reliability without business context is a vanity metric wearing an engineering costume.

Reliability belongs in the boardroom, not the standup

Most financial data businesses track reliability as an engineering KPI: uptime percentage, mean time to recovery, ticket volume. Useful numbers, wrong altitude. They get discussed in the engineering standup, reported up as a green dot on a dashboard, and rarely make it into the conversation where the CEO is deciding where to invest next quarter.

That's backwards. Reliability metrics are commercial metrics in this sector. A data outage doesn't just cost engineering hours, it costs renewal risk, it costs the sales team's next pitch, it costs the reference-ability of your biggest logo. When a hedge fund's ops team catches a stale price feed feeding into an overnight NAV calculation, that incident report doesn't stay in Jira. It goes to their CFO, and eventually to yours.

Put reliability on the executive review agenda with the same seriousness as revenue and churn. Give it a line item with commercial consequences attached. What did the last incident cost in renewal risk. What's the trend line on data quality escapes. Which clients are exposed to which pipeline dependencies, and what happens to the relationship if that dependency breaks. If your leadership team can't answer these questions from memory, reliability is still being treated as an engineering concern rather than a business one.

The order matters: engineering, governance, trust

The grain in this sector runs in a specific sequence: data engineering first, governance second, customer trust third. Most teams either invert this or try to run all three in parallel, and both approaches fail for the same reason. You cannot govern a pipeline you haven't built to a defensible standard, and you cannot earn trust with governance that isn't backed by engineering that actually works.

Data engineering first means the pipeline has to be correct and observable before anything else gets layered on top. Not perfect, correct: you know what "correct" means for this specific feed, you can detect when it drifts from correct, and you can trace why. Skip this and governance becomes theatre, a policy document describing a process nobody can actually verify is happening.

Governance second means once the pipeline is observable, you build the control layer: audit trails, lineage, sign-off gates on schema changes, a documented answer to "how do we know this number is right" that survives a client's due diligence questionnaire. This is where most financial data vendors either over-invest too early (building SOC 2 theatre around a pipeline that still breaks monthly) or under-invest permanently (treating governance as a checkbox for the sales deck rather than an operating discipline).

Customer trust third is the output. You cannot manufacture it directly, and you cannot market your way to trust in this sector. A client who has been burned once by a data quality incident will discount every subsequent claim you make about reliability, no matter how polished the pitch. Trust here is rebuilt slowly, through a visible track record, and lost in a single afternoon when the wrong number reaches a client's model. Operate every decision, especially the ones about where to cut corners under deadline pressure, with that asymmetry in mind.

What this looks like when it's working

The financial data businesses that get this right share a pattern: the pipeline owner sits close enough to commercial decisions to describe, in one sentence, which client relationship depends on which part of the substrate. Ask them "what breaks if this feed goes down for four hours" and they don't need to check with sales, they already know it's the three asset managers running end-of-day valuations against it, and they know what that costs.

That's the test worth running on any financial data operation you're assessing, your own or a client's. Find the person closest to the pipeline and ask them to name the business outcome it serves. If the answer is fluent, the operating system is aligned. If the answer is a shrug and a reference to an SLA document, the substrate is optimising for the wrong thing, and no amount of dashboard polish will fix it.