Every vendor in trading technology now says some version of “you own your data.” The phrase costs nothing to print. Whether it is true is an architecture question, and architecture answers are checkable. Here are the five questions that separate the slogan from the substance — and what a serious answer to each looks like.
1. Tenancy: who else lives in the database?
In a multi-tenant platform your firm is a tenant_id column in a shared database. That model has real virtues — cost, speed of onboarding, operational simplicity for the vendor — and one structural consequence: isolation is a promise enforced by application code, not by physical or cryptographic boundaries. Your competitors’ data sits in the same tables. Every query your vendor’s engineers run touches infrastructure you share.
Single-tenant means one client, one environment: your database, your compute, provisioned for you alone. It costs more. What it buys is that the isolation question stops being about trust in code review and starts being about physics and cryptography.
2. Ownership: can you take the database and leave?
The practical test of ownership is the exit. Ask the vendor, in writing: if we terminate, what exactly do we receive, in what format, in what timeframe, and what does it cost? Grade the answer harshly. “CSV export of major objects” is not your operation; it is a souvenir of it. A real answer names the full schema, documents it, and treats export as a standing capability you can exercise any quarter — not a termination ceremony.
3. Keys: who can technically read your data?
Encryption at rest is table stakes and largely meaningless if the vendor holds the keys. The question that matters: can the vendor read your data without your participation? Bring-your-own-key (BYOK) arrangements — client-held keys via a KMS — change the answer from “we promise not to” to “we cannot.” For a firm whose book, client list and flow intelligence are the business, that distinction is the whole point.
4. Residency: which jurisdiction, whose subpoena?
Data location is legal exposure. US client data in US regions is increasingly a compliance requirement, not a preference; EU data has its own regime; and some firms have counterparty or licensing constraints that dictate specific jurisdictions. The serious version of residency is region pinning agreed per client and written into the engagement — not a vendor FAQ that says “we use leading cloud providers.”
5. The AI dimension: what leaves the boundary?
The newest sovereignty question, and the one most vendors answer worst. If AI features are bolted onto the product, ask precisely: which data is sent to which external model, under what API terms, with what retention, and can we turn it off? Enterprise API terms with no-training commitments and zero-or-limited retention exist and are contractible. So is architecture that sends scoped, minimal context to the model instead of shipping datasets to it. So is an off switch. If the vendor cannot answer in those terms, the feature was designed before the question was.
The checklist
- One client per environment, or a tenant ID in shared tables?
- Full, documented, standing data export — contractually?
- Client-held keys (BYOK/KMS), or vendor-held with policy promises?
- Region pinning per client, in the contract?
- For every AI feature: what leaves, under what terms, and where is the off switch?
None of these questions is hostile. A vendor with good answers will enjoy them — they are the questions their architecture was built to answer. A vendor without good answers will call them edge cases. That, too, is information.