Connecting AI to the Systems You Already Govern: MCP for Finance

Almost every AI pilot in a regulated firm starts the same way. Somebody exports a file, uploads it, and gets a good answer. The pilot is judged on the answer, the answer is fine, so it passes. What was actually tested was the model. What was not tested was everything the export destroyed on its way out of the system.

Why the export is the weakest link

An emailed spreadsheet cannot be revoked. It has no owner after the first forward, it is stale from the moment it is written, and it will happily show a junior the whole book because the filter was applied by hand and somebody was in a hurry. A live connection preserves four things the export throws away:

• Currency. The figure is the figure now, not the figure on the morning somebody remembered to run the report.
• Entitlement. The model sees what the calling user is permitted to see, enforced by the system that already knows.
• Attribution. Every read is a logged call with a caller, a timestamp and a query.
• Revocability. Access ends when you end it, in one place, without chasing inboxes.

None of these are AI properties. They are properties your systems already have. If your data governance survives right up until somebody clicks "download as CSV", you do not have data governance. You have a habit.

What MCP actually is

The Model Context Protocol is a way of exposing tools to a model over a defined interface. An MCP server sits in front of a system and publishes a set of tools. Each tool carries a name, a description of when to use it, a typed input schema validated before your system is touched, and a structured output with errors that explain rather than just fail. A client, which is Claude in one of its surfaces, discovers those tools and calls them when a task requires them.

The part worth internalising is where the boundary sits. The model chooses whether to call and with what arguments. Your server decides what is possible at all, and enforces every rule about who may do it. Treat the tool list as the security perimeter, because it is. If there is no tool for deleting a record, no amount of clever prompting produces one. This connector layer sits directly on top of the skills described in capturing a process that runs the same way every time: a skill fed stale exports produces consistent nonsense, and a connector with no skill on top of it is a very expensive API client.

Three primitives, not one

Almost every MCP conversation is about tools, but the protocol has three primitives, and they differ in who is in control. Tools are actions the model may choose to invoke. Resources are data the application attaches to context, where the host decides what to include using the entitlements it already enforces. Prompts are templated workflows the server offers to the person. The distinction matters: exposed as a tool, the model may fetch any client it can name. Exposed as a resource, the application hands over one record. That is the difference between an agent that could reach the whole book and one that was handed a single file. It costs nothing to design correctly and is painful to retrofit.

The connector map

Market data and document stores are largely solved. The open financial-services library ships twelve connectors covering fundamentals and filings, credit and ratings, news, cross-asset analytics, private markets and document stores. Each generally needs its own subscription, and your existing licence may or may not cover programmatic use, which is a contract question worth resolving first.

Your own systems are where the work is. The connectors that create the most value are always the internal ones, because that is where your firm's actual knowledge lives, and they are also the ones nobody else will build for you. A reasonable division of effort: take the vendor connectors as they come, and spend your engineering time on two internal ones, the system that holds the numbers you report and the system that holds the documents you evidence them from. Those two cover most of what an examiner will ever ask about.

The security model, in three questions

Ask three questions in order. Who is asking? The calling user's identity should reach the underlying system. A connector authenticating as a broad service account collapses your entitlement model into one identity, and access reviews become meaningless. What can it do? Start read-only, not as a phase you skip but as the default state that requires a specific argument to leave. Most of the value in the first year is in reading. When you do add a write path, make it a staging write: the agent proposes, a person approves, the system records both. What is it reading? A connector to a document store is a connector to documents written by people outside your firm. Documents are data to extract from, never instructions to follow, and the boundary belongs in the substrate, not in a prompt.

The test is simple. If a supplier emailed an invoice containing an instruction, what would stop it working? The weak answer is that the prompt tells the model not to follow instructions in documents. The strong answer is that the agent reading it holds no tool that could act on one. That distinction runs through all of the AI field guide for regulated finance.

Sequencing: what to connect first

Four stages, each earning the next. Stage one is public and read-only: a register, a filings source, market reference data, where your team learns how agents behave against a real API before anything is at stake. Stage two is internal, read-only and narrow: one system, one dataset, one team, small enough that the blast radius of a mistake is a conversation rather than an incident. Stage three widens with the calling user's identity flowing through and access reviews covering the connector the same way they cover the underlying system. Stage four is staged writes.

Do not skip ahead to the ledger. The reason is not that the technology is not ready. It is that your organisation has not yet built the review habits, the incident path or the access review that stage three requires, and the first time something goes wrong you want it to have gone wrong on the entity master.

The evidence you design

Your source systems already log, so once the model reads through a connector rather than an export, those logs cover the AI too. That alone puts you ahead of most firms. What system logs do not tell you is that this call produced that figure in this client report. The link between a retrieved value and the deliverable it ended up in is the thing an examiner actually asks for, and nothing produces it by accident. It has to be designed, which is why the next step is packaging skills, commands and connectors into something a firm can deploy.

To go deeper, download the five-part finance series, or send us a workflow and we will map the connectors it would need.