Take it to the Bridge

How MCPs are Easing Data Connection Concerns

Just as APIs have revolutionised connectivity between internal and external systems, so Model Context Protocols are now offering a new layer capable of transforming communication between business software and external AI assistants. Tiago Batista, Co-Founder and Vice-President, Engineering, FinanceKey, explains all.

Connecting treasury data to AI models such as Copilot, Claude or ChatGPT sounds like a move that would induce a severe nervous reaction in most internal IT teams. But the introduction of a secure bridge between internal data and external AI assistants can harness the power of both in a manner that even IT should find acceptable. That bridge is the Model Context Protocol (MCP) server. 

MCP is an architecturally lightweight, open-source standardised arrangement that enables the user’s preferred AI model (Copilot et al) to securely interact with external tools, APIs, and various data sources such as a TMS. It has become the de facto standard for connecting AI applications to outside services. So, is this really a sensible idea for treasurers?

Faster, easier, clearer

FinanceKey is one of the first treasury platforms to launch an MCP server. In doing so, it becomes a treasury reality, not just a theoretical notion. And while the vendor’s MCP project is still at an early stage – it commenced in mid-2025 – Batista says there is an adoption path opening up already, so it has market engagement.

The work to reach this stage has been “rather faster and easier” than expected to move along, comments Batista. “But we already had the APIs available to us, so then it was ‘just’ a matter of adding the MCP layer on top before implementing it with our first clients.”

While no client names are forthcoming at this stage as this is still not much more than beta testing, these clients are nonetheless active users of this set-up, currently using Copilot and Claude AI to query their data sets.

Having live users in the treasury realm is beginning to reveal just how well this model works, comments Batista. “We can see them interacting in a more natural way with their data. Rather than navigating through dashboards and reports, they are using natural language queries to get answers so much quicker and clearer.”

The AI systems are being tested with basic queries such as “which payments in the system are waiting for approval?”. But one user has also asked AI to “explain why this payment was rejected”. It’s a good question, says Batista, as a bank rejection message may not always reveal the details, thus demanding further investigation. But in this case, the system detected the exact reason, offering “quite an exhaustive explanation”.

The system has also been used with existing client data to draft forecasts and to analyse trends within that dataset. Another user posed questions on the level of idle cash in a specific region. This led it to a request for an overview of all its accounts, and further enquiries as to the level of cash movements across all well-funded accounts, with an eye firmly on optimising its cash holdings.

With queries and responses in this set-up universally based on natural language, it makes it easier for users to keep probing, notes Batista. “For our clients using Claude and Copilot, the first query is normally an explanation just in text. But we’ve seen them analyse existing data, and on the basis of that analysis, use AI to help them develop their own FX hedging programme, with the system charting all the steps for the user to execute that plan.”

Ports, bridges, and platforms

In technical terms, MCP protocols are built around an open standard, and are therefore vendor-agnostic by default, explains Batista. What’s more, by adhering to that global standard, they need only be implemented once to enable integration with most current (and probably future) mainstream AI assistants that clients may wish to use.

To help understand how it works, Batista explains that an MCP can be likened to a USB-C port for hardware devices, with USB-C acting as the bridge between one software platform and another. Being standardised, a device with a USB-C port will always take any USB-C connector. Conversely, where a device offers only a proprietary port, its developers (or users) would have to find a way to support multiple connectors to interface their different software platforms. This would be an almost impossible task for most (Apple has its Lightning connector of course, but few hardware manufacturers have the market presence of Apple).

The use of an MCP in treasury therefore provides a common connection between a treasury system (such as FinanceKey) and all the data it holds, and all similarly standardised AI assistants with which that treasury system developer has decided to interface.

Diving deeper, the MCP protocol itself is an abstraction layer. This is a ‘simple’ and unified interface that sits on top of its underlying subsystems, screening users from the complexity. This means developers don’t need to know how those subsystems work to be able to make connections between systems; they operate at the interface level only.

The MCP itself normally sits on top of an API (which is another form of abstraction layer) which provides the connecting path. The developer defines the list of available tools to connect (its own platform and AI assistants such as Copilot, Claude or ChatGPT, for example) and then establishes the rules as to how these tools interact.

Working with the MCP

While the list of tools a vendor selects will of course vary (depending on what it wants to achieve), the way it publishes its MCP server will be standard across them all. Publishing typically involves packaging the project technical notes and sharing them via the Official MCP Registry (although other access points are available). 

The creation of the MCP server means there is no additional work required with any of the standardised connections. Just as with the USB-C, it connects to every instance that has been configured using that standard. And while the vendor is not required to develop a new connector for each new AI assistant that its clients wish to use, by that same token, the client can use any standardised AI assistant with the vendor’s software without needing a new connector each time. This also means all existing security protocols established by the user (such as for user authentications or permissions) can remain the same in each instance.

Quality and safety first

Many users understand that AI tools trawl the web for their responses and are therefore sampling from sometimes murky waters. However, because the MCP-based set-up uses data from within the client’s own ecosystem, the ‘rubbish in, rubbish out’ trope applies only if the client’s data is of low quality.

This is a matter for robust data management. “If you have good master data, you’re more likely to get good answers,” Batista emphasises. “It’s why the potential user of this model needs to focus on the quality of their data before they begin leveraging AI capabilities. But they can still use AI to help identify data issues to improve the quality.” However, he warns, where clients wish to incorporate factors such as geopolitical events or meteorological conditions within their data, then of course they really do need to verify the reliability of their sources.

Again, it’s a matter of policy and management, but this is also where the sound professional judgment of the treasurer comes into play, says Batista. It’s not a case of never trusting the output, but of exercising appropriate diligence to verify data accuracy. And because the MCP server is just the bridge between systems, he urges all users to pay close attention to the overall implementation, especially the user controls around it.

Indeed, MCP’s open-source roots may come up against some company IT policies, where some deem this development process too much of a risk. “I think it’s a reasonable concern, but I would separate the protocol from the implementation, and suggest users really do create a robust governance approach to their data,” says Batista. “Involve your IT team in assessing and validating the data that the AI system will be using. And make sure that you are using it in a controlled manner. Follow the policies and guidelines of the company, so you don’t risk inadvertently exposing data externally, or not having the proper user permissions in place.”

Contrary to the view that open-source can be a vector of risk, Batista suggests that its “largely agnostic” nature can even mitigate some risks. Because open-source protocols are communication standards that are publicly available, and not owned by any single company, there is never any user-dependency on a single entity to maintain development and support.

No vendor lock-in also enables far greater interoperability, as is the case with MCP servers. What’s more, it has also kept the protocol itself relatively simple. “It does not try to steer the user or developer in any one direction regarding how they should expose their data or handle the permissions,” Batista explains.

Get comfortable, start exploring

Beyond the initial requirements, Batista’s advice to any treasury team curious about connecting AI applications to outside services is to start small. “Begin with read-only access, and with simple queries,” he suggests. “Use it to follow a payment status, query balances, or create bank account reports. If you start small you can build confidence in the process and its outputs. Once both treasury and IT are familiar and comfortable with the technology, then start thinking about leveraging its deeper possibilities.”

It could be used to automate many more routine treasury activities, for example. Or some activities could step beyond read-only and enable AI to propose a course of action. But, warns Batista, “you should always have a human in the loop, making sure that anything of a critical nature still requires consent before action”.

For FinanceKey, the MCP path “is definitely something that we’re investing in heavily”, confirms Batista. “Obviously we want our customers to benefit from all the data that they have with us, and this is a very fast way for them to achieve the insight they want.”

And while the aim is to retain within its system all the classic dashboards, reports, and web applications as data access points, he says, “when you can query using natural language, nothing can beat it. It's really fast and is a more natural, intuitive way to interact with treasury systems”.

FinanceKey is following its own advice and currently permitting read-only access to its MCP server set-up. But Batista says the aim is to roll out this technology to all of its customers. “We want to help build up customer confidence to start using it for recommendations, and perhaps one day take actions on their behalf.”

With other vendors also now taking the same exploratory route with MCP servers, it’s likely that this technology will become increasingly visible in the treasury world. How it develops is now up to the treasury community to step across that bridge and start exploring.