The Solution Architect View: Retrofitting Treasury with AI

Why pre-trained models change everything — and what they still don't know

The old approach to AI in treasury — feeding proprietary data into a model and training it from scratch — is effectively dead, according to Marcus Gullers, Head of Software Solutions at SkySparc. The arrival of large, pre-trained models like GPT has rendered that model obsolete.

But there is a critical gap. These general-purpose models understand finance conceptually — they know what a bond is, what hedging means, how treasury functions — but they have no knowledge of your company's actual position today. That real-time, proprietary context is precisely what an AI needs to move from explaining concepts to making recommendations.

Marcus Gullers: What they don't know is what the customer's cash position is right now. They're lacking the snapshots — so they can put all of their expertise into context and give recommendations. And this is what we are offering with OmniFi.

The mechanism SkySparc has built to bridge this gap is an MCP server — Model Context Protocol. For treasurers not yet familiar with the term, it is worth pausing here, because Marcus is emphatic that MCP is the AI concept most directly relevant to their world today.

Marcus Gullers: The LLM is of course important, GPT is important, but more concretely, I think they need to understand MCPs as a concept. MCP is a conceptual standard for how AI models gain access to data. It's like a harmonised integration layer that AI models can connect to.

Think of it this way: instead of connecting an AI model directly to each individual data source — a bank, a Bloomberg feed, a TMS, a ratings provider — you connect it to an MCP server. That server advertises what it knows and what it can do. When the AI receives a user query, it interrogates all connected MCP servers, determines which ones have relevant data, and assembles an answer.

Marcus Gullers: When an AI model gets a request from a user, it goes out and checks all of its potential sources. The user wants a risk position. Then it starts querying OmniFi to get the positions, Bloomberg to get the market data, and MSCI to get the ratings. But it's all discoverable through this MCP server — that's how the AI model knows what data is out there.

Turning a legacy TMS into an AI-ready system — without a three-year project

One of the most practical questions facing treasury departments right now is this: my current TMS is robust but not AI-native. Do I have to wait for my vendor to catch up, or initiate a full platform migration, before I can work with AI?

Marcus's answer is no — and OmniFi is built specifically to solve that problem. Not a single major TMS vendor currently offers an MCP server, he notes. FIS, Kyriba, and others are likely working on it — but the capability is not there yet.

Marcus Gullers: That's a problem for clients that want to do this. But it's also that the MCP server exposes the tools it can have. With OmniFi, it's not just getting raw data from FIS Quantum up to the AI model — it's also leveraging everything that OmniFi does in the middle: cleaning the data, adding context so the model knows what type of data set this is.

This data enrichment layer is not a minor detail. Raw TMS data is just rows of numbers. OmniFi adds a semantic layer — explaining to the AI model that this dataset represents investment positions for a set of group companies, not just an anonymous table of figures. That context is what enables the model to reason correctly.

On implementation speed, the contrast with legacy TMS projects is stark:

Marcus Gullers: If it's just about rolling out an MCP, it can be a week or less — very quick. For Kyriba, I can probably get an MCP up and running within two days, because Kyriba is cloud-based and we are cloud-based. It's just a matter of selecting what sort of data set you want to expose to the MCP.

The reason that speed is possible is that SkySparc has acted as an API gateway for TMS systems for over a decade. The integrations already exist. OmniFi is a bolt-on — no impact on the underlying TMS, no upgrade cycle required.

Marcus Gullers: We have off-the-shelf integration to the TMS systems. We understand how they work. We've consolidated that information and exposed it to other applications historically — but not necessarily through an MCP server, rather through regular APIs. That's why it's a quick bolt-on. The client doesn't have to upgrade their TMS to gain access to these features.

Where AI adds real value — and where it doesn't (yet)

The discussion of automation potential is one where Marcus introduces a useful framework: treasury automation as a progression. Excel as baseline — everything manual. Implement a TMS — reach roughly 80% automation. Add OmniFi — push toward 90%. Now layer AI on top — and you close the gap further, perhaps reaching 95%.

But he cautions against over-indexing on straightforward automation wins like automated commentary generation — something OmniFi already does with rule-based logic today.

Marcus Gullers: I don't think it has the highest business value, these things. If you're hiring skilled treasurers, one of the reasons you're hiring them is for them to perform the more complex analytics — to understand these things. Maybe you should not outsource everything to the model.

Where he sees genuine AI impact is in exception handling and anomaly detection — the cases that fall outside the predefined rules that automated systems are built around.

Marcus Gullers: What we could find historically was that we have a deterministic way of defining rules to spot deviations. But sometimes things happen that are unaccounted for. You can send data to AI and say: have a look at this. Do you see anything different or funny? It's one more layer of spotting deviations and outliers — covering the things you don't think about when you build the model to begin with.

Troubleshooting also ranks high on his impact scale: if a bank reconciliation fails to close, an AI model equipped with the right context can diagnose the cause far faster than a human analyst working through transaction logs manually.

Real-time scenario analysis: the emerging frontier

Perhaps the most forward-looking exchange in the conversation concerns the possibility of connecting live news feeds to treasury AI — enabling the system to construct and run novel risk scenarios in real time, rather than only applying pre-built historical stress tests.

Today, most scenario analysis in treasury is deterministic: you take a historical event — a financial crisis, a geopolitical shock — and apply its known impact to your current portfolio. The limitation is obvious: you can only run scenarios someone has already defined.

Marcus Gullers: Potentially, one could use AI to build potential future scenarios that have not occurred yet. You can't really do it in real time — say, a hurricane just happened in Florida that affected this sector, and there's not going to be a pre-made scenario for that. But the AI model can probably whip it together.

The architecture to support this already exists in principle. An MCP server connecting to a news feed — CNN, Reuters, Bloomberg — would allow an AI model to detect a significant market event, assess its potential impact, instruct OmniFi to run the relevant calculations, and surface the results to the treasurer. The human then reviews, judges, and decides.

Marcus Gullers: There's another MCP server that is for news. The AI model says, okay, here's an interesting news item. I want to see how this impacts our portfolio. Then it goes to the OmniFi MCP server and says: this is my scenario. Please calculate it for me. And then OmniFi crunches the numbers, figures out the impact based on the market data it was provided.

Security, data sovereignty, and why MCP is also a compliance story

When treasurers and CFOs consider adopting AI, data security is consistently the first objection raised. Where does our data go? Who can see it? Does it leave the EU? Marcus addresses these concerns directly — and his answers reveal that the MCP architecture is, by design, also a security architecture.

The MCP server acts as a single, observable, auditable gateway between the AI model and all data sources. Every query the AI makes, every dataset it accesses, routes through this controlled point. That makes audit logging straightforward and access control manageable.

Marcus Gullers: Everything that happens in the MCP server is observable and auditable. As soon as the model talks to your data — which might be classified TMS data — that information always routes through the MCP server. That's important from the perspective of understanding who is accessing the information and why.

He also addresses the question of personally identifiable information — PII, the category of data that GDPR most tightly regulates. While treasury systems typically deal with legal entities rather than individuals (and therefore face less PII exposure than, say, HR systems), the MCP architecture can support anonymisation as a built-in step:

Marcus Gullers: Between the server and the data sources, there can be an anonymisation service. OmniFi pulls out the customers from the TMS, anonymises them, and when it serves the data to the cloud AI, that cloud model has no idea what it's looking at — because it doesn't say JP Morgan, it says Counterparty One.

On data residency — the question of whether treasury data physically stays within the EU — OmniFi offers clients a choice of jurisdiction, with primary and secondary data centres selectable within approved regions. For the most security-sensitive clients, including central banks, a fully isolated on-premise deployment is available.

Marcus Gullers: For those that are very keen on securing the data — like central banks — we have options that allow them to be 110% safe. Data never leaves the country, never leaves their data centre. It's fully isolated.

The model-agnostic nature of MCP is a final, important security feature. Rather than being locked into a single AI vendor — and thus into that vendor's data handling policies — an MCP-based architecture allows organisations to plug in whichever AI model their enterprise governance permits: Microsoft Copilot, Claude, Google's models, or others, as policy dictates.

Marcus Gullers: A lot of the big enterprises will simply say: this is our preferred vendor, or our only vendor for AI. The MCP concept is model-agnostic — it can be Copilot, it can be Claude, it can be Google's version. That's also part of the conceptual design of OmniFi: we don't care where the data gets consumed. We have Excel plugins, Power BI plugins, Tableau plugins. The MCP thing plays nicely into that.

MCP: the next API

Marcus closes with a parallel that frames the current moment well for any treasurer thinking about how seriously to take all this. Twenty years ago, SkySparc was one of a small number of voices in treasury technology insisting that APIs — not direct database connections — were the right integration standard. It took a decade before that became obvious to everyone. Today, every application has API integration; it is simply assumed.

Marcus Gullers: Twenty years ago, only Wall Street had APIs. Nearly everyone else did not. And I think MCP is the next such big thing. It's a good moment to become the evangelist for MCPs — and this is what every other application will require in order to interact with AI.

For treasury professionals reading the signals: LLMs are the foundation, but MCP is the infrastructure. Understanding what an MCP server does — and what it means for the systems your team already runs — may turn out to be the most practically important piece of AI literacy you can acquire right now.

‍