AI sourcing requires separate decisions about models, workflows, data, and controls. A bank may need a different approach for each layer.
Consider a hypothetical lender buying an AI service that reads loan files and prepares case summaries. The vendor supplies the app, but another firm supplies the model. A cloud provider runs the service, while the bank’s records feed the workflow.
That lender has more than one outside dependency. It also needs to decide which parts of the process it must control itself.
For financial-services leaders, a useful starting point is to separate the model, the workflow, the data, and the checks. You can then choose what to build, buy, or develop with a partner at each layer.
Start AI sourcing with a map of the stack
A single vendor contract can hide a chain of services. Before comparing offers, draw the route from a customer record to the final action.
Which system holds the data? Who runs the model? What software chooses the next step? Who can approve a decision or stop the process?

The following map helps turn those questions into sourcing choices.
| Layer | What it does | Decision to resolve |
|---|---|---|
| Model | Reads, predicts, or generates an output. | Use an external model, adapt one, or build a task-specific model. |
| Workflow | Moves work between people and systems. | Build the process logic or buy a product that fits it. |
| Data access | Supplies approved records and sources. | Control access, data quality, and source rights. |
| Review and controls | Checks outputs and manages exceptions. | Define decision rights and retain the means to act. |
| Hosting and support | Keeps the service running. | Assess service resilience, support, and recovery options. |
For example, a bank may buy the model service while building its own workflow. It may also use a partner to connect that workflow to older systems.
Each handoff in this arrangement needs a named owner. A contract for the whole package does not remove the need to understand its parts.
Build the parts that create a useful difference
Building makes sense when the bank’s process needs a capability that standard products cannot provide well. For example, that might be a document workflow shaped by its loan products, languages, or source records.
Still, custom software creates work after launch. Your team must test changes, fix failures, maintain access controls, and support staff who use it.
The case for building therefore needs more than an estimate of coding time. Ask which advantage the custom work creates and who will maintain it.
It also helps to separate building an application from training a large language model from scratch. The Financial Stability Board’s November 2024 report describes the cost and complexity of that training as generally prohibitive for non-specialist firms.
That assessment concerns cost and technical capability. A bank can still build workflows, adapt existing models, or develop smaller models for defined tasks.
So the practical question is whether those choices solve its problem at a cost it can sustain.
Compare AI sourcing costs beyond the license fee
Buying can give a team access to a mature product and outside expertise. However, a full cost estimate must cover the work needed to use it.
Also include the cost of connecting systems, preparing data, testing outputs, training staff, reviewing exceptions, and making later changes. A low initial price can come with costly limits on data access or customization.
For AI sourcing, compare offers against the same set of real tasks. Ask vendors to show how their products handle incomplete records, conflicting evidence, and unavailable source systems.
The demo should include a failed case as well as a successful one. Otherwise, the team may compare polished presentations while missing the work needed in production.
Our human review article explains why staff need records they can inspect and the authority to correct an error. Include those needs in the purchase test.
A partnership also needs the same discipline. State which party builds each component, who owns the resulting assets, and how the bank can maintain them if the relationship ends.
Separate provider failure from shared-model risk
AI sourcing creates two distinct risks that need different responses.
The first is operational dependence. If a supplier stops serving you, can you keep an important process running?
The second is shared-model risk. Different firms may rely on similar models or data and reach similar conclusions, even when every provider is working.
The Bank of England’s April 2025 analysis discusses both provider dependence and the possibility of correlated trading positions. It notes that similar models, designs, or datasets could contribute to firms acting alike during stress.
Holding contracts with several vendors does not settle both problems. Those vendors may use the same cloud service or the same underlying model.
You should therefore map the suppliers behind the products. Also test whether different tools fail on the same kinds of cases.
Multiple suppliers can help with continuity, while varied models and independent checks may address some shared weaknesses. Neither approach guarantees resilience on its own.
Make the exit plan part of AI sourcing
A switchable system needs more than a second vendor on a procurement list. The replacement must work with the data, prompts, tools, and controls your process uses.
Before signing, ask the team to demonstrate a switch on a small set of cases. Compare the results and record which parts need new work.
Also check whether you can export the records and logs you need. Can you rebuild a past decision? What happens to custom prompts, test cases, and interfaces when the contract ends?
These questions matter when an AI agent can call other systems. Our agentic KYC guide shows why research, policy checks, and client decisions need clear boundaries.
An exit test should cover those boundaries too. A model that produces similar text may still use tools differently or leave gaps in the audit record.
If migration is difficult, price that dependence into the decision. You may still choose the product, but the team should know what leaving it would involve.
Decide layer by layer, with a named owner
For your next AI sourcing decision, prepare a short recommendation for each layer. State the chosen option, the reason, the owner, and the main outside dependency.
Then test the proposed mix against a real workflow. Include the review burden, the failure route, and the work required to change suppliers.
Build where custom work creates a clear benefit. Buy where a product meets the need and its limits are acceptable. Partner where outside skill fills a defined gap and the responsibilities are clear.
Before committing, ask the owner of each layer to show how it will keep working if its main supplier changes.
For more practical analysis of financial AI decisions, subscribe to FinTech Briefing.
FINTECH BRIEFING · A FUTURECENTRAL BRIEFING
Get practical financial AI analysis in your inbox.
Useful signals, focused analysis and decision questions on AI in banking, payments, lending, insurance, wealth and risk.
Free to subscribe. Confirm your email after signing up. Unsubscribe at any time.

