Stop Letting the Vendor Define Your Data Model

Whoever owns the shape of your data owns your firm's future optionality. Right now, that is probably a software vendor.

Whoever owns the shape of your data owns your firm's future optionality. Right now, that is probably a software vendor.

Your firm has a data model. You did not design it. A software vendor did — as a side effect of building their product — and every system you buy next will be bent to fit it.

It happens without a decision ever being made. A firm implements a platform, and the platform's import schema — the way that particular product happens to structure clients, entities, accounts and relationships — quietly becomes the way the firm thinks about its own data. The next system inherits that shape. So does the one after. Nobody chose it. It accreted, one implementation at a time, until the firm's enterprise data structure is simply whichever vendor got there first.

This is one of the most consequential architecture decisions a regulated firm makes, and it is almost always made by default. The firms that get it right make the opposite move deliberately: they design their own canonical data model first, and treat every vendor's schema as a connector requirement — something to map to — rather than the definition of the firm's source of truth.

Your data model is your firm's grammar

A data model is not a technical artefact buried in a database. It is the grammar the firm uses to describe reality — what a client is, how an entity relates to a beneficiary, what counts as one account versus two, how a relationship is recorded over time. When that grammar is dictated by an application's import format, the firm has outsourced something far more important than a piece of software. It has outsourced the structure of its own institutional knowledge.

The pattern I see most often is that this only becomes visible at the second system. The first platform goes in and everything is fine. Then a second system is needed — a new custody platform, a reporting layer, an MI capability — and the firm discovers that its data only makes sense in the shape the first vendor imposed. Everything now has to be translated out of that shape and into the next one, and each translation loses fidelity, introduces re-keying, and adds cost.

A firm's data model should not be an accident of procurement order. It is an asset the firm designs and owns — and a vendor's schema is a downstream transformation of it, not the other way round.

Design the canonical model first, then connect to it

The alternative is not exotic, and it does not require a data-engineering department. It requires a decision, made early: the firm defines a cleansed, canonical enterprise dataset that represents how the firm understands its clients and their relationships, and then transforms that dataset into whatever format each downstream platform requires. The direction of travel is firm-to-vendor, not vendor-to-firm.

This maps directly onto the layered approach many firms now recognise: raw data at the bottom; a cleansed and consolidated layer above it; a governed, trusted layer that serves as the single source of truth; and downstream systems and management information drawing from that trusted layer. The vendor's import schema sits at the very end of that chain — it is a delivery format, not a definition. When a platform is replaced, only the final transformation changes. The canonical model, and everything built on it, survives.

Table 1 contrasts the two architectures and what each one costs the firm over time.

Table 1 — Who defines the data model: two architectures and their long-run consequences

This is a lock-in decision before it is a data decision

The commercial dimension is where this argument earns its place at board level. A firm whose data is shaped like its vendor's product is a firm with almost no leverage. Switching costs are enormous, not because the new system is worse but because the firm's entire data estate has to be reconstructed to leave. The vendor knows this. It shapes every renewal conversation, whether or not anyone says it out loud.

Owning the canonical model inverts that. When the firm's data lives in a shape the firm defined, replacing a vendor becomes a question of building one new outbound mapping rather than re-architecting the enterprise. Multi-platform strategies become possible — using the best custody platform and the best reporting layer and the best CRM, rather than whatever one suite happens to bundle — because they all connect to the same trusted core. Optionality, in other words, is a direct output of who owns the data model.

Why this is now an AI decision too

Everything that makes a firm-owned model good architecture makes it good AI foundation. Retrieval, analytics, and any agentic workflow all depend on data that is consistent, governed, and semantically coherent across the firm. A firm-owned canonical layer provides exactly that. Application-specific data silos, each shaped by a different vendor's assumptions, provide the opposite — and no amount of model sophistication compensates for a foundation where the same client is represented three different ways in three different systems.

There is a governance dimension too, and it is not incidental. The JFSC guidance asks firms to be able to describe the main factors driving an outcome and to keep records sufficient for audit and challenge. That is far easier when the firm's data has one authoritative representation than when the same client exists in incompatible forms across several vendor-shaped stores, and reconciling them is itself a source of error. Explainability is not only a model property; it is a data-architecture property. A firm that cannot say which version of a record is authoritative cannot fully explain a decision built on it.

The Jersey AI Playbook names connected systems — permissions hygiene, retention rules, named data ownership — as a board-level dependency rather than an IT backlog item, and this is what that principle looks like when taken seriously. Deciding who defines the data model is the connected-systems decision. Make it deliberately, and the firm builds on ground it controls. Leave it to default, and the firm builds on ground a vendor happens to own.

If you replaced your core platform tomorrow, would your data leave in a shape you designed — or in a shape your outgoing vendor imposed on you years ago, without anyone ever choosing it?

Next: why aggregate availability is the wrong resilience metric — Operational Resilience Is Predictability, Not Uptime.

Sources: Government of Jersey et al., Jersey AI Playbook (2026) — 'connected systems' principle (permissions, retention, named data ownership as board dependencies); JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 2 (data quality) and Principle 5 (explainability foundations).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com