At a glance
  • Most finance-AI offerings make you a tenant: your invoices, ledgers, and forecasts feed a model on someone else's platform, under someone else's terms, in someone else's jurisdiction.
  • The alternative is ownership — models deployed inside your own cloud boundary, where the data never leaves and the capability survives the contract.
  • Gulf regulation is moving towards residency and sovereignty: PDPL regimes in the UAE and KSA, in-country cloud regions such as me-central-1.
  • Five questions separate the two: where inference runs, what leaves your boundary, who can retrain on your data, what survives contract end, and whose law governs the logs.

There is a question that reorganises every finance-AI vendor meeting the moment it is asked, and it is not about accuracy, features, or price. It is this: when the contract ends, what do we still have?

Watch carefully what happens next. A vendor whose answer is "your exported data, in CSV" has just told you something important about the previous three years of the relationship — namely, that during those years your invoices, ledgers, payment histories, and forecasts were feeding a capability that was never yours. You were renting intelligence built partly from your own information. You were a tenant.

Tenancy is the default, not the exception

This is worth stating plainly, because vendor language obscures it. Most finance-AI products on the market today are multi-tenant platforms: your transaction data flows out of your environment, into the vendor's infrastructure, where a model — trained, tuned, and operated by the vendor — produces predictions and sends results back. The model lives there. The accumulated learning lives there. Often, the enriched and structured version of your own historical data lives there too, in a schema you did not design and cannot fully extract.

The terms of that arrangement are set by the vendor's contract, which you negotiated once, under deadline pressure, with the procurement leverage of a mid-market firm. The infrastructure sits in whatever jurisdiction the vendor chose, subject to whatever legal process applies there. And the improvement loop — the thing that makes the product better each quarter — runs on the pooled data of every tenant, including you.

To be fair: for many tools, this is a perfectly sensible trade. Nobody needs to own the model that schedules meetings or drafts marketing copy. Tenancy buys speed, and for low-stakes workloads speed is the right thing to buy.

Finance data is not a low-stakes workload. Your invoice stream encodes your prices, margins, customer concentration, supplier dependencies, and payment behaviour — the commercial anatomy of the firm. A forecasting model trained on it is not a productivity tool. It is a strategic capability wearing a subscription's clothing.

What ownership actually looks like

The alternative is not building a frontier model from scratch, and vendors who frame it that way are arguing against a position nobody holds. Ownership, in practical terms, means the model runs inside your cloud boundary. On AWS, that is a foundation model invoked through Amazon Bedrock in your own tenant, or a model trained and hosted in SageMaker inside your own VPC — with guardrails screening personally identifiable information before anything reaches a prompt. Your data is never transmitted to a third party's platform. Inference happens on infrastructure you govern, under identity and access controls you set, producing logs you keep.

The distinction is architectural, not philosophical. In a tenancy, data travels to the model. In ownership, the model travels to the data — and the data stays put.

In a tenancy, your data travels to the model. In ownership, the model travels to your data — and the data stays put.

Ownership also changes what the end of a contract means. When an in-boundary deployment winds down, the prompts, the fine-tuned weights you commissioned, the feature pipelines, the curated training datasets, and every log remain in your account. The capability persists. When a tenancy winds down, you get an export and a deactivation date.

The objection usually raised at this point is cost — surely renting is cheaper than owning. Sometimes it is, in year one. But the comparison most buyers run is incomplete: tenancy pricing compounds with usage and renews at the vendor's discretion, while the largest cost of an owned deployment — preparing your data well enough to be useful — is a cost you pay under either model. You cannot rent your way out of having clean ledgers. Once that spend is recognised as common to both paths, the gap narrows considerably, and what remains buys you the exit terms.

The regulatory wind is not neutral

If the architectural argument leaves you undecided, the regulatory direction of travel in the Gulf should not. Both the UAE and Saudi Arabia now operate personal data protection laws — each known as PDPL — that constrain cross-border transfer of personal data, and financial records are dense with it: names, addresses, tax registration numbers, bank details. The hyperscalers have responded with in-country regions; AWS me-central-1 exists in Dubai precisely because regional customers and regulators want data processed on national soil.

A finance-AI tenancy whose inference runs in another jurisdiction is, at minimum, a transfer-assessment exercise today. The consistent regional pattern — data residency expectations tightening, not loosening — suggests it becomes harder to defend each year. An in-boundary deployment in a local region largely dissolves the question.

The five questions

None of this requires you to become an infrastructure expert. It requires five questions, asked in writing, of every vendor whose product will touch finance data. First: where does inference run — in our cloud tenant, or yours? Second: what leaves our boundary — exactly which fields, to which endpoints, in which country? Third: who can retrain on our data — is our information ever used to improve a model that serves other customers? Fourth: what survives contract end — models, weights, pipelines, logs, or just an export? Fifth: which jurisdiction's law governs the logs — and who else can lawfully compel access to them?

The questions are not hostile, and a good vendor will not treat them as such. Several will have strong answers; in-tenant deployment options are increasingly common precisely because buyers have started asking. The point is that the answers sort every offering on the market into one of two boxes — tenant or owner — and the sales deck will never volunteer which box you are in. The silence is not accidental. Tenancy is the better business model for the vendor; ownership is the better one for you.

Choose deliberately

There is no universal right answer, but there is a wrong way to answer: by default. A firm that becomes a tenant knowingly, for a bounded use case, with eyes on the exit terms, has made a decision. A firm that discovers its tenancy three years in, during a regulatory inquiry or a renewal negotiation, has had a decision made for it.

Finance data is the one dataset where that discovery is most expensive. Ask the five questions before the pilot, not after the renewal — and if a vendor cannot answer them crisply, you have your answer anyway.