Build vs. Buy: AI Agents for Regulated Risk Operations

Last updated: September 2026

Build vs buy for AI risk agents almost always gets argued as a cost question, and that is the wrong question to open with. A prototype that reads an alert, pulls the customer history and writes a disposition recommendation can be standing up inside a week, and once your team has watched it work, buying looks like paying for something you have already proved you can make. What the prototype does not show you is the part that never ends: evaluation that keeps running, drift you have to detect, analyst overrides you have to capture, documentation that has to survive the person who wrote it, and a supervisory framework that moved in April and will move again. Those obligations exist under both options. The decision is who holds each one three years from now.

TL;DR

• The prototype is not the thing you are deciding about. Building an agent is cheap relative to running one in a regulated alert queue.

• Six obligations outlive the prototype: ongoing evaluation, drift detection, override capture, model risk documentation, regulatory change, and on-call. Buying transfers some of them. It never transfers all of them.

• The obligation that most often decides it is independent challenge. If you build the agent, the team that built it cannot also be the team that credibly challenges it.

• Building is the right answer more often than a vendor page usually admits, and the lock-in objection against buying is real rather than a procurement formality.

• This page carries no cost figure in either direction, because no defensible one exists. Every cost statement here is structural: name the obligation, then name who owns it.

The person arguing hardest against building can build

The most forceful argument against building an in-house risk agent that we have heard this year came from a director of fraud management at a global payments company whose team builds its own data infrastructure for a living.

When colleagues push him to build, he pushes back. "They like to try and convince me that we want to build it and I do my best to convince them otherwise," he said, "because we are really good at certain things. So we are really good at moving data, that's what we do, right? We move money, which is just data, APIs and orchestrations and all that stuff. Like, we build that stuff all the time for all of our areas."

His objection is about competence, not capacity. He knows exactly what his team is good at, and he knows what falls outside it. He also did build: the fraud stack he runs today is an orchestration layer his own team designed, and it works. Most of what follows comes from him, because a working build tells you more about the cost of building than a failed one does.

What build versus buy means for a risk agent, specifically

Should a bank build or buy AI risk agents? Building means owning the agent and everything downstream of it: the evaluation programme, the monitoring, the override record, the model documentation, the on-call rotation, and the answer you give an examiner who asks why a decision went the way it did. Buying means transferring some of those obligations to a vendor and keeping the rest, and no vendor takes all of them. The regulated version of this decision is not whether your engineers could build it. It is which named person holds each obligation in three years, and whether they can still answer for it.

That reframing matters because the generic enterprise version of build versus buy, the one written for a document-processing tool or a customer support assistant, stops at development cost and time to market. A risk agent sits inside a decision your institution has to defend. The cost that decides it is the cost of defending the decision repeatedly, for years, under a framework that is still being written.

One thing is deliberately out of scope here. What you should evaluate an agent against, the criteria and the measurement, is a prior question and a separate piece: see how to evaluate an AI risk agent. This page assumes you already know what good looks like and are deciding who builds it.

What the prototype does not show you

A prototype proves an agent can produce a good recommendation once. Production asks whether it still produces a good recommendation in eighteen months, and whether you can show your work. Six obligations appear at that point and none of them are visible during a demo.

Ongoing evaluation. The evaluation that proved the prototype was a one-off against a curated sample. Production evaluation is a standing programme with an owner, a cadence, a held-out set that stays representative as your traffic changes, and a record of every result.

Drift detection. Fraud patterns move, your customer mix moves, and an agent tuned on last year's alerts quietly stops being tuned. Detecting that is one job; deciding what happens when the detector fires, and who is allowed to pause the agent, is a second and harder one. We have written about the mechanics separately in monitoring AI agents for drift.

Override capture. When an analyst disagrees with the agent and changes the disposition, that disagreement is the most valuable signal the system generates. It is only a signal if it is captured as an event with a reason attached. If it is captured as an edit to a field, you have lost it.

Model risk documentation. Version history, training decisions, evaluation results, known limitations, and the rationale for each change. The test is whether the documentation still answers questions after the engineer who built the agent has left.

Regulatory change. On 17 April 2026 the Federal Reserve, FDIC and OCC jointly issued revised guidance on model risk management, carried as SR 26-2 at the Federal Reserve, Bulletin 2026-13 at the OCC and FIL-15-2026 at the FDIC. The Fed letter states that it "supersedes and replaces SR letter 11-7" and the 2021 interagency statement on model risk for BSA/AML systems. Anything in your governance documentation that still cites the old letters needs rewriting. The agencies have also said they plan to issue a request for information covering banks' use of AI, which has not appeared yet. It will move the ground again when it does.

On-call. An agent working a live alert queue is production infrastructure. Somebody's phone rings at 3am when it stops responding, and that somebody needs to know both the system and the risk consequence of leaving it down.

Here is the same list as a decision table. The useful exercise is not reading it, it is writing a person's name into every cell for your own institution.

No row in that table is empty under either option. That is the whole argument.

The obligation that decides it: independent challenge

The revised guidance keeps the concept of effective challenge and is specific about who can perform it. SR 26-2 describes it as "the critical analysis conducted by objective experts who evaluate model risk and effect appropriate changes throughout the model lifecycle," performed by "individuals with the appropriate expertise to conduct a critical and objective challenge, sufficient independence to maintain objectivity, as well as the organizational standing and influence to effect any change."

Read that as three conditions: expertise, independence, and the standing to actually change something. Then apply it to a build. The people who know the agent well enough to challenge it are the people who built it, and they fail the independence condition. So building an agent means staffing its challenger as well as its builder, from a different reporting line, with enough depth to argue with the build team and enough authority to stop them. Buying does not remove the obligation, but it does put the expertise and the independence in different organisations by default, which is a much easier thing to evidence.

Two precision points, because this argument is easy to overstate. The revised guidance places generative and agentic AI outside its own scope: the OCC bulletin states that "generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance," and SR 26-2 confirms the principles apply to "traditional statistical and quantitative models and non-generative, non-agentic AI models." Effective challenge is therefore a test worth borrowing, not a rule that binds your agent. The guidance also says it is "expected to be most relevant to banking organizations with over $30 billion in total assets," and most relevant to is not the same as applies only to.

The revision narrowed the definition of a model as well, to "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates." A risk function running a rules engine, a scoring model and an agent now has three components sitting in three different places relative to one framework. You cannot assume a single governance regime covers all three, and that mapping work lands on you regardless of who wrote the code. Our longer treatment of the governance question is in governing AI risk agents.

What building actually costs, from someone who did it

Asked how hard the in-house orchestration was, the fraud director's answer was four words: "it's more challenging than I signed up for."

He was precise about where the difficulty sits, and it is not the model. "The challenge is enrichment inside that orchestration layer, because of the amount of work it takes to enrich data, to get data from multiple sources into the single decisioning platform. So there's definitely some challenges there." Then the part worth quoting in full, because it is the honest verdict rather than a failure story: "It's nothing that can't be handled right with resourcing and time, but those are hard to come by."

That is the real shape of AI agent development cost in a risk function. Not an impossibility. A steady claim on two resources you never have enough of, against a queue that does not get shorter. Ask him when the consolidated system will be finished and the answer is a joke with a real number in it: "there's a single plug and play point for all of our internal processes that sometime before I'm dead, everyone will be plugged into. Because we are a big company. We're also a company of acquisitions, frankly. So we've got probably 30 different platforms on the backlog of trying to get them into the consolidated fraud system."

Buying does not exempt you from the data work either. An R&D director at a global payments platform, listing the largest open items on a live deployment, put the historical data load second: "the historical data load, which is more of a strategic thing, not specifically a tactical thing for now." An agent that reasons about a customer relationship needs the history of that relationship, and moving it is strategic work under either option.

A note on total cost of ownership. This page carries no cost figure, in either direction. There is no defensible number we can publish for what an in-house risk agent costs to build or to run, and we are not going to estimate one. If a vendor hands you an AI total cost of ownership model for this decision, ask where each input came from and what it was measured against. Most of these models are built backwards from the answer the author wanted.

When building actually makes sense

Building is frequently the right call, and five situations make it the obvious one.

The agent is the product, or inseparable from it. If your risk logic is what customers are buying, or is the thing that makes your pricing work, outsourcing it outsources your margin.

You already run the data layer well and the agent is a thin addition. This is the fraud director's own position, and it is the strongest version of the build case. The expensive part of a risk agent is getting clean, enriched, timely data into one place to reason over. If you have already paid that cost, the remaining work is genuinely small, and paying a vendor to re-solve a solved problem is waste.

Vendor concentration is itself the risk you are managing. If a material share of your risk decisioning already runs through one external provider, adding another dependency to the same provider is a concentration decision before it is a technology decision, and it belongs in front of whoever owns third-party risk.

No product fits the flow, and the gap is structural. Unusual products, unusual regulatory perimeters and unusual customer journeys produce requirements that vendor roadmaps will not reach. The test is whether the gap is a missing feature or a different shape. A missing feature is a roadmap conversation. A different shape is a build.

You can staff the challenger independently of the builder. If you cannot, you are not choosing between build and buy. You are choosing between a build you can defend and one you cannot.

The lock-in objection, printed rather than handled

The strongest argument against buying came from the same fraud director, and it deserves to be read in his words rather than paraphrased into something weaker.

"I look at risk for more than just fraud risk. I've also got to consider vendor risk and exposure to the market. It was very critical from my perspective that we maintain agency over the actual connection points, and that no vendor be implemented in such a manner that they can't be replaced. If you hook your systems up into a single vendor, you're kind of like, you're not going anywhere. There is no pivot point at that point. You kind of get stuck into this unintentional marriage with an external partner."

Asked directly what his company would make of adopting a platform like ours, he did not soften it: "From a business sense perspective, it's just a high risk move."

He is right, and the honest response is not a rebuttal. It is a test you write into the contract before you sign it. What does the exit look like? Can you get your data, your evaluation history and your override record out in a usable form, on your own initiative, without a professional services engagement? Are the connection points yours, so that replacing one component does not mean replacing the stack? Is there a named contractual obligation to hand back model documentation? A vendor who cannot answer those questions in writing is the vendor he is describing.

The structural half of the answer is that an agent layer does not have to sit underneath everything. Oscilar's agents can run inside the full platform or as a standalone layer on top of your existing stack, which keeps the orchestration and the connection points where they already are. That does not eliminate vendor risk. It changes what replacing the vendor costs, which is the thing he is actually protecting.

The hybrid answer, which is what most institutions actually do

Most regulated risk teams do not land on build or buy. They land in between, and the good versions of that split share a property: the boundary follows the obligations rather than the org chart.

Three shapes recur. Buy the reasoning layer and keep the connection points, which is close to what the fraud director built for himself, except that the layer above the orchestration is bought rather than written. Buy for one queue and build for the flow nobody else has, which works when one part of the book is genuinely unusual and the rest is not. Buy the platform and build the evaluation, which keeps the judgment about whether the agent is working inside the institution.

The hybrid is not free. Two governance regimes means two sets of documentation, two evaluation cadences, and a boundary that somebody has to own explicitly. Undefended boundaries are where incidents live. What makes a hybrid defensible rather than merely convenient is that someone can name, for every obligation in the table above, which side of the line it sits on and why.

How to run the decision

The best method we have seen described was not a weighted scoring matrix. Someone running the build-versus-buy assessment for credit and collections at a digital financial-services firm laid it out in three documents.

1. A specification for the build. "A requirements or spec doc for what it would take for us to get our internal tools functional to meet the specific needs that we have."

2. A contrast document. "Everything that's already ready made with all of these vendors," listed against the same requirements.

3. A resourcing comparison. "How much of our internal resources do we need to build everything that we need on this wish list versus how much is it going to cost us to just sign a contract and get somebody onboarded that already has all these things pre-built?"

Then the sentence that should change how you plan this. On the cost comparison: "I don't think that argument is gonna be too difficult to navigate. It's more so navigating the argument of like, okay, we have 20 different tools. Why do we need tool number 21?"

The cost case is the easy one. The hard one is consolidation. If you are making the case for buying, most of your preparation should go into why this does not add another silo: which existing tools it replaces or absorbs, whose screen it appears on, and what the analyst's day looks like afterwards. A buy recommendation that only answers on price will lose to the twenty-first-tool objection, and it will deserve to.

Two more things to plan for. Buying's evaluation path has a known shape you can demand of any vendor, and it is a fair test of whether they have done this before: data setup, a backtest against your own historical alerts, a shadow-mode run alongside your analysts, and a human readout of the results before anything touches production. Ask for those four phases by name. Separately, know who the document is for. On the same call: "Our project team is really advocating for the buy as opposed to build. We just need to get our senior stakeholders aligned with that recommendation." The working team has usually decided already. What they need is an argument that survives a senior stakeholder review, which is a different document from a decision framework.

Where this breaks

Four limits on everything above.

This page carries no cost figure. That is a real limitation, not modesty. Any build-versus-buy analysis eventually needs numbers, and yours will have to come from your own resourcing model rather than from an article.

The one measured result we can point to is narrow. A bank in deployment shows 92% agent agreement with its analyst team on alert disposition, and 75% less time per review. That is a single deployment in a single risk domain, and it is not a benchmark another institution should expect to reproduce.

Neither option answers the prior question. Deciding what "working" means for your agents, and what evidence would convince you, comes before the build-versus-buy decision and does not get easier under either answer.

Build versus buy is also not a permanent state. The boundary moves as your data layer matures, as products ship, and as people leave. Treat the decision as reversible and design the exit accordingly, whichever way you go.

Frequently asked questions

Should a bank build or buy AI risk agents?

Build when the agent is inseparable from your product, when your data layer is already strong enough that the agent is a thin addition, when vendor concentration is itself a risk you are managing, or when no product fits a structurally unusual flow. Buy when you need production-grade evaluation, monitoring and documentation faster than you can staff them, and particularly when you cannot resource an independent challenger separate from the build team. Either way, the obligations survive the choice.

How do you evaluate build versus buy for an AI capability?

Write three documents: a specification of what building would require, a contrast document of what each vendor ships ready-made against the same requirements, and a straight resourcing comparison. Then answer the consolidation question separately, because a buy case that only argues on cost loses to the objection that you already have too many tools.

When should a team build an AI agent rather than buy one?

Build when you already own the hard part. The expensive work in a risk agent is enrichment and getting data from multiple sources into one decisioning platform, so a team that has already solved that is paying for very little by building the reasoning layer on top. Build also when the gap between your requirements and every available product is structural rather than a roadmap item.

What does an AI risk agent cost to develop in-house?

There is no published figure worth quoting, and this page does not offer one. What practitioners describe instead is the shape of the cost: enrichment across multiple sources, a platform backlog that does not shrink, and a standing claim on engineering capacity. One fraud director who built a working in-house orchestration layer put the completion date for connecting everything at "sometime before I'm dead."

What has to be maintained after the prototype works?

Six things: ongoing evaluation, drift detection with a response policy, override capture as a structured event, model risk documentation that survives its author, tracking of regulatory change, and an on-call rotation. None of them appear during a demo, and all of them have an owner from the day the agent enters a live queue.

Who owns model risk documentation if we build the agent ourselves?

You do, in full, including version history, evaluation results, known limitations and the rationale for every change. If you buy, the vendor supplies the model record and you own how it maps into your own framework. The test in both cases is whether the documentation still answers an examiner's question after the person who wrote it has left.

Can a bought AI risk agent work with an institution's existing risk systems?

Yes, and this is worth confirming explicitly before you sign anything. Oscilar's agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform, so buying an agent layer does not require replacing your orchestration or your existing vendors. The question to ask any vendor is whether the connection points stay yours.

How are human review, auditability and agent performance governed under each option?

Under both, the institution owns the governance. Oscilar's published position is that agents never autonomously close or escalate alerts, and that every recommendation is reviewed and confirmed by a human analyst before any action is taken, with a full audit trail showing the input, the agent's reasoning and the final output. If you build, you are creating the equivalent record yourself, including the part that shows a regulator exactly where humans make decisions.

Where to start

Take the obligations table above and write a person's name in every cell, for both columns, for your own institution. The exercise takes an afternoon and it tends to settle the argument, because one column usually has rows nobody can fill. That is your answer, and it is a more honest one than a cost model.

Two follow-ons. If you cannot yet say what you would measure the agent against, that question comes first and is covered separately. And what thresholds a pilot should have to clear before you accept it is its own decision, which we will cover in a companion piece.

If the buy column is the one with gaps, the fastest way to fill it is to make a vendor run the four phases against your own data: data setup, a backtest on your historical alerts, a shadow-mode run, and a human readout. See how Oscilar's risk agents are built to run alongside the analysts and systems you already have, and bring the obligations table to the first conversation.