Why data ontology matters for treasury teams – and how AI raises the stakes
What is data ontology, and why does it matter for AI in treasury? Find out how well-structured data enables reliable AI and better treasury operations.
By Veikko Koski, Co-Founder, FinanceKey
I heard the term “data ontology” for the first time only a couple of months ago, and I’ve heard it repeatedly since – even customers bringing it to the table themselves.
It arrives with the tone of a buzzword, and it would be easy to treat it as one. It comes, in fact, from data architecture, where it names something specific and structural about how a system is built rather than how it’s marketed. And for finance and treasury teams handling large volumes of data, it’s hard to think of anything that matters more.
Data ontology came up repeatedly, too, at the recent PwC Treasury Tech Days, in the context of AI and agentic treasury. So what is it, and why is it so crucial for treasury AI? This article breaks down what finance teams need to know.
What is data ontology?
A data ontology is the semantic structure that defines what the data in a system means: the entities it recognises, their attributes, the labels and definitions attached to them, and the relationships between them. Tables and columns are one implementation of that model, but the ontology is the meaning carried by the structure rather than the storage format itself.
In treasury terms, it’s the difference between a system that just holds numbers and one that knows a payment date is a payment date (which might be different to invoice due date), that a counterparty is linked to specific accounts, and that a fee category rolls up into a specific cost centre. Ontology is the structure that gives data meaning and makes it usable.
It’s also work you never see. Ontology is settled in the back end, by engineers who stubbornly get the nitty-gritty right – what each field means, and whether it means the same thing everywhere – without making much noise about why it matters. Done well, it’s invisible, which is exactly why its value has been so easy to overlook.
What is ontology management?
Ontology management is the ongoing discipline of keeping that structure consistent as a platform grows. New modules, new integrations and new data sources all put pressure on a data model: a field added for one use case can break the labelling another use case depends on without anyone noticing right away.
Ontology management means governing how entities, columns and relationships are defined, versioned and extended over time, so the structure stays coherent instead of drifting into inconsistency. Without it, even a well-designed data model degrades as a platform expands.
Data ontology and “good data” – are they the same?
Data quality gets cited a lot, and never more than now. “Rubbish in, rubbish out” is how it’s often phrased: if the data going in isn’t good, no system – and no AI tool built on top of it – can deliver the outcomes you expect. That has always been true, but AI has raised the cost of getting it wrong, because models act on what they are given at a speed and scale no human review layer can keep up with. For treasury teams the exposure is sharper still: they sit at the crossroads of banks, ERPs, trading platforms and market data feeds, so every weakness in any one of those streams lands on their desk.
So, does data ontology fix bad data?
No, and that distinction matters.
Data quality and data ontology solve different problems, even though they get folded into the same conversation. Data quality is about whether the values in the system are correct, complete and consistent – no duplicates, no blank fields, no drift over time.
Ontology is about whether the system knows what those values mean and how they relate to each other: whether a payment date is understood as distinct from a value date, and whether a counterparty or a business unit is labelled and defined the same way across every module.
A platform can score well on data quality and still have a weak ontology. Every field can be accurate, complete and up to date, while “counterparty” means something slightly different in payments than it does in reporting.
A person scanning a clean-looking report won’t notice that inconsistency. An AI tool querying across those same modules will act on it, and get the answer wrong with full confidence, because it has no way to resolve the ambiguity the way a person would.
So data ontology doesn’t fix bad data. Its role is to determine whether good data is actually usable at scale, and specifically usable by AI. Get the data quality right and the ontology wrong, and the result is still an AI tool that’s confidently mistaken.
Where this shows up in the FinanceKey platform
Ontology isn’t an abstract concept for us – it’s the reason certain features work well and others don’t. Two examples:
A single API across our modules only holds together if the underlying entities are consistently defined. Cash Visibility, Payment Hub, Bank Account Management and Cash Flow Forecasting all need to reference the same account, the same counterparty and the same transaction in the same way.
OData connectivity makes the same structure visible to the client. When a treasury team connects our data to Excel or Power BI, the entities, columns and relationships that arrive are already clearly labelled and consistently structured. There’s no relabelling exercise, no reverse-engineering what a field actually contains. That’s ontology made visible – something a treasury team can see for themselves the moment they build a report.
Both these examples depend on decisions we made early – and on years of quiet, invisible work to keep them intact. No demo ever showed it, no roadmap item was named after it, yet it is the single reason the platform behaves consistently today, and it’s a big part of what we mean when we call FinanceKey an adaptable treasury platform.
The same underlying structure holds up whether it’s a person building a report, a spreadsheet pulling a data feed, or an AI tool querying live data. Structural work of that kind only ever pays back later, which is why it is so easy to defer – and why the platforms that did it early are the ones incorporating AI now without re-architecting anything.
Why AI raises the stakes
What changes with AI is who – or what – is doing the querying. A lot of “AI-native” claims in treasury and finance software describe an interface layer: a chat window or a copilot sitting on top of the same underlying data structure the platform always had. If that structure was never designed with clarity in mind, the AI layer inherits the same ambiguity. It can still produce an answer.
Whether that answer is reliable depends entirely on whether the data it drew from was well defined in the first place.
This is where the same foundation that makes our single API and OData feeds work pays off again. Our native MCP server gives AI tools like Claude, Copilot or ChatGPT direct access to live treasury data, with human approval required on write actions. That access is only valuable if the AI tool can correctly interpret what it’s looking at – which depends on the same ontology behind the API and OData connections.
None of this is a separate AI initiative for us. It’s our same underlying data model, applied consistently, that happens to be exactly what AI tools need to work well.
What to ask a treasury platform about its data ontology
If you’re evaluating platforms, a few questions cut through the marketing quickly:
- Can you connect the platform’s data to a tool like Excel or Power BI and immediately understand what each column means, without documentation?
- Does the platform’s API treat the same account, counterparty and transaction consistently across every module, or does each module define things its own way?
- If an AI tool queries the platform’s data directly, does it get clearly labelled, structured data – or a flat export that still needs interpretation?
- Was the data model designed for this kind of access, or adapted for it after the fact?
The answers tend to separate platforms that added AI or integrations as an afterthought from platforms built on a data foundation designed to support them from the start.
The takeaway
Data ontology isn’t a new concept, but it’s a newly visible one. AI raises the stakes because there’s no longer a person on hand to work out what an unclear field probably means, so the quality of the underlying structure stops being invisible infrastructure and starts being a genuine differentiator. We made those choices years before anyone was asking us about ontology, and it is the part of the platform I would point to first.
