An AI Guide for Finance Leaders

Does this sound familiar?

As we enter the last quarter of 2026, AI is everywhere, from a simple quarterly presentation to the most advanced quant algorithms. Most organizations are dealing with the same chaos, trying to work out the best way to implement AI across the company and for each individual.

The same questions come up in every boardroom

Whatever stage of AI you're at, these come up as soon as the conversation starts.

• Which AI should we use? An external provider like ChatGPT or Claude, or a self-hosted model of our own?
• Who owns our data? Who owns our business knowledge?
• Will our data end up training someone else's model?
• What will AI cost us, and how do we keep it within budget?
• How do we make sure we're using AI optimally?

Our aim is to help you answer these questions by sharing our experience designing and building AI strategies for our fintech and financial clients, so you can define your own.

A company rarely needs one AI

Every job or function within an organization is unique, and usually ends up in one of four places.

What decides the right option?

Which option fits your use case usually comes down to three things:

And two more you shouldn't skip:

• What regulations or rules apply to AI in your use case?
• What security measures will you put in place?

These aren't one person's questions. They are best answered collectively. The CEO or founder, the CTO, the CFO and the wider management team need to answer them together to choose the right AI strategy. This guide walks through each of those perspectives, individually and together.

We had built the bullion desk system for the treasury function of a bank. One day, the bank's CTO came to us with a challenge, and he started by describing a scene.

They're trying to answer:

The CTO saw the problem clearly. The system we built was designed to automate manual processes, not to produce answers in real time. The numbers were accurate and the data was already producing intelligent analysis. All that was needed was for AI to extend it, using those numbers and that data to produce answers in real time.

One solution, three perspectives

• Management wants it fast, and still accurate, reliable and trusted.
• Finance wants to know what it will cost and where to save money.
• Tech wants to know the solution, the infrastructure, the complexities, the vulnerabilities, and how something new plugs into a live system.

Here, we started with the CTO's perspective: what the AI must do, and what it must not.

What the AI must do, and must not

If you're wearing the CTO lens, ask:

1. 1What will the AI do? List all the do's.
2. 2What will the AI not do? List all the don'ts.
3. 3Will it communicate with existing systems and have access to sensitive data?
4. 4Will it modify data or run calculations on it, or just read and interpret it?
5. 5How will it connect to existing systems? Which channel? Is there an API pipeline?
6. 6Do we need to train a model on our own data? If so, does the data leave our environment?

The solution: a thin, read-only layer and a hybrid approach

Both feed the relationship managers.

The AI was limited to interpreting data, so relationship managers could answer customers proactively and in real time. It reads data only when a manager asks, only for the customer in question, and it can't change, manipulate or modify a record. Every request is logged and every response recorded.

Explanations, call priorities and customer fact sheets came from a self-hosted model, because they touch customer positions and credit limits. The market news summary came from an external AI service, because it only reads public information.

Self-hosted AI or external AI services?

Neither is better across the board. They ask different things of you.

External or self-hosted: side by side

Two questions we hear every time

"Will the provider train its models on our data?"

Sending data to a provider isn't the same as the provider training on it. OpenAI and Anthropic both state that they don't train on business and API data by default. But your data still leaves your environment, and it may be kept for a period.

Some firms prefer to access models through managed cloud services such as Amazon Bedrock, used through their own cloud setup and governed with the controls they already have in place.

"Isn't self-hosting automatically safer?"

Not always. It gives you more control, but you also take over patching, access control, monitoring and capacity planning. It's justified when you're handling sensitive and proprietary information.

Going self-hosted: which model?

It depends mainly on the nature of the job. Take a batch of real data from your use case, run a few models on it, and compare accuracy, speed and cost.

Volume matters, often the opposite way to what people expect. The more times a repetitive task runs each day, the stronger the case for a small model, because every saving per request multiplies.

Many teams use both. Routine bulk goes to a small model, harder cases to a larger model. The right mix comes from testing on your own data, not from the size or brand of the model.

These mismatches are called exceptions:

• A transaction on one side only
• A settlement file that never arrived
• A posting that failed during maintenance
• A duplicate

Each one lands on someone's desk.

A roadmap built for the whole year

Our roadmap was designed for a full year, with one focus: making sure the projections met expectations.

1. 1Known problems get simple rules, not AI. Failed postings during planned maintenance were already being reposted by our middleware. Duplicates were already caught by routine checks. Both were dropped from the AI scope.
2. 2Everyday exceptions go to a smaller, self-hosted model. Running in their own cloud environment. The main reason was control, since the records hold customer transactions from several banks. Cost projections came down to acceptable levels, and monthly costs became easier to predict.
3. 3Extreme, unusual cases get people. Manual intervention and controlled monitoring, so the impact on cost stays manageable.

Before launch, finance set the ground rules

Rules set early let the team move fast without surprises.

So what should finance look at when approving AI? These are the fundamental questions that determine the finance equation.

"What are we actually paying for?"

The subscription is only the visible part. Once AI is part of daily work, the bill has several layers.

Financial businesses tend to pay for AI twice over: business teams use it for their own work, and tech teams use it again to build and run systems. Our founder calls this Tokenomics: managing AI spend is a finance skill, not just a tech one.

"Why does the bill grow faster than we expected?"

Because small design choices multiply at volume.

• Sending a full transaction history instead of one line makes every request cost more.
• Keeping a long conversation in memory makes each new message pricier.
• An AI agent that checks three systems before answering is several paid calls, not one.
• Using a large model where a small one would do multiplies the cost of the same job.

"Isn't self-hosting cheaper?"

Sometimes. But the two don't just cost different amounts. Their costs grow differently.

At modest volumes, a small external model is often the cheaper option, so self-hosting usually needs to be justified by control, not price. At steady, high volumes, self-hosting can become cheaper, but only once you've tested how much work your servers can actually handle.

Want the full guide as a PDF?

Download the guide (PDF)

"What results do we want?"

The most fundamental question. AI implementation needs to be outcome-based: a measurable, tangible benefit that shows, in numbers preferably, how AI improves on the existing system.

How is our use case different? How much should AI see?

Every company has knowledge held across its systems, documents and people, and much of it is sensitive, proprietary or both:

• How you price risk
• Your calculation engines
• Your quants' algorithms
• Client financial data
• Client personal data

"What can we actually keep running?"

A self-hosted model is a system you'll operate for years. An external service is a supplier you'll manage. Both can scale up quickly in cost and in the tech required. Weigh your short-term goals against your long-term vision to decide how much goes to external AI and how much you self-host.

Are you paying twice for your AI?

When teams use AI, the knowledge held across your systems, documents and people flows into prompts, corrections and approved answers. Our founder describes this as paying twice.

Microsoft CEO Satya Nadella made a related point in The Reverse Information Paradox.

Six pointers for evaluating AI strategies, options and vendors

1. 1Identify the need and define the outcome. Measurable, tangible, and within budgeted cost and effort.
2. 2Control the data. Customer data, business logic, calculations, algorithms and proprietary methods must be protected and supervised. This usually settles the decision before cost does.
3. 3Assess existing systems first. Can they be extended, instead of handing AI tasks that system enhancements could manage? Less onus on AI, lower cost.
4. 4Always be testing. Try a few models on sample data for latency, accuracy and efficiency, and project the costs over a year.
5. 5Choose external, self-hosted or hybrid. In most of our projects so far, a hybrid approach has worked best for performance, security and cost.
6. 6Define the numbers. Users, token limits and usage limits, calibrated as you go. Projections for at least a year help a lot.

For both the bullion desk and the reconciliation engine, this was the template we gave management, with our analysis for each point, so they could make an informed decision.

Three lenses, one decision

Every AI implementation needs to pass through all three.

All of this feeds one decision: external AI, self-hosted AI, a hybrid, or simple automation (no AI).