September 8, 2026

Build vs Buy: AI for Compliance Operations

Axle Team

Key takeaways

Build vs buy compliance AI is a model governance question, not an engineering one. Whoever builds the model owns its validation, documentation, and tuning for as long as it runs.
U.S. regulators encourage AI in BSA/AML programs. The 2018 interagency statement says pilot programs alone should not draw supervisory criticism — but exam standards are identical for built and bought tools.
Build when your risk is genuinely idiosyncratic and you can staff a permanent model team. Buy when speed to production, examiner-ready documentation, and maintenance cost dominate.
The run cost of building is the number teams miss: typology drift, rule changes, and validator findings turn a one-time project into a standing budget line.
Most institutions land on a hybrid: buy the platform and agent layer, keep risk appetite, thresholds, and final decisions in-house.

Build vs buy compliance AI: what the decision actually turns on

Should you build or buy compliance AI? Build only if your risk profile is genuinely unusual and you can permanently staff model development, validation, and documentation. Otherwise buy: vendors amortize model governance, regulatory change, and tuning across many customers, and U.S. regulators neither require nor favor in-house tools.

That is the short version. The longer version is that build vs buy compliance AI debates inside banks tend to fixate on the wrong variable — whether your engineers can build a monitoring model or an alert-triage agent. They usually can. The real question is whether the institution can carry the model risk obligations that come with authorship, on top of a BSA program you already run lean.

What regulators have actually said

Start with what supervision expects, because it shapes everything downstream. The federal banking agencies and FinCEN addressed this directly in their December 2018 joint statement:

"The Agencies recognize that private sector innovation, including new ways of using existing tools or adopting new technologies, can help banks identify and report money laundering, terrorist financing, and other illicit financial activity by enhancing the effectiveness and efficiency of banks' BSA/AML compliance programs."
— Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing, Dec. 3, 2018

The same statement removed the most common objection to piloting new tools:

"While the Agencies may provide feedback, pilot programs in and of themselves should not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful."
— Joint Statement, Dec. 3, 2018

Note what the statement does not say. It does not favor built over bought, and the agencies explicitly decline to advocate any particular method or technology. Whether you build or buy compliance AI, examiners assess the same things: is the tool validated, is it documented, does someone accountable understand how it behaves, and does the program still catch what it should.

For banks, that assessment runs through model risk management guidance (Federal Reserve SR 11-7 and the OCC's parallel bulletin): development evidence, independent validation, ongoing monitoring. Those obligations attach to the model owner. When you build, that owner is you — permanently.

The cost structure nobody budgets

FATF's 2021 study of new technologies in AML/CFT is clear-eyed about why institutions modernize monitoring in the first place:

"These solutions can automatically monitor, process and analyse suspicious transactions and other illicit activity, distinguishing it from normal activity in real time, whilst reducing the need for initial, front-line human review."
— FATF, Opportunities and Challenges of New Technologies for AML/CFT (2021), para. 15

The same report describes what happens to systems that stop getting investment:

"Legacy systems are updated with new algorithms and manually inputted information, generating matrixes for risk interpretation and action, but these very rarely offer a real time overview of customer transactional or institutional risks."
— FATF, Opportunities and Challenges of New Technologies for AML/CFT (2021), para. 36

Here is the uncomfortable implication for the build path: an in-house tool starts drifting toward legacy status the day it ships. Typologies move, products change, the validator files findings, and each of those events lands in an internal backlog that competes with every other engineering priority in the institution. Vendors carry the same maintenance burden, but they amortize it across their entire customer base and are contractually obligated to keep up.

Time to production: Building is the longest path — design, build, then full model validation before go-live. Buying is shorter: configure, integrate, validate fit.
Model documentation: When you build, you author every artifact from scratch. When you buy, the vendor supplies core documentation and you evidence fit to your program.
Regulatory change: For built tools, it competes with everything else in your backlog. For bought tools, it is a vendor obligation across its whole customer base.
Talent: Building carries key-person risk inside a cost center. Buying carries vendor concentration risk — manage it with exit and data-portability terms.
Fit to your risk profile: Built is exact, if scoped and maintained. Bought is configurable; test your edge cases in the pilot.
Cost over time: Build costs grow with drift, validator findings, and attrition. Buy costs are mostly contractual and predictable.

When building is the right call

There are honest cases for building:

Your monitored activity is genuinely unlike anyone else's — a niche asset class, an unusual settlement model — and no vendor's training data resembles your book.
You already run a mature model development and validation function for credit or market risk, so the marginal governance cost is low.
The capability itself is strategic: you intend to differentiate on risk decisioning, not just satisfy your obligations.

If none of those describe you, the build case usually reduces to engineering enthusiasm plus an underestimate of run cost. For most banks, fintechs, and crypto firms, the pragmatic split is: buy the workflow and agent layer, and keep the parts that are genuinely yours — risk appetite, thresholds, escalation rules, and final decision authority — in-house and documented.

One thing we see in practice

The build decision is really a hiring decision. An AML model needs care for its whole life: threshold tuning after every validator finding, retraining as typologies drift, documentation updates with every change. That work needs engineers who understand both machine learning and BSA — and they sit in a cost center, which makes them hard to retain. When one leaves, their undocumented judgment leaves too, and the gap surfaces at your next independent validation, not the day they resign. Vendors have attrition as well, but their maintenance obligation is contractual rather than dependent on whether you can re-hire a rare profile mid-exam-cycle.

FAQ

Is it cheaper to build compliance AI in-house?

Rarely over the full life of the system. The build estimate teams present is usually the cost to reach production; the cost that dominates is everything after — validation cycles, regulatory change, retraining, and documentation. Run the numbers on your own volumes with Axle's ROI calculator before deciding.

Will examiners penalize us for using a vendor's AI?

No U.S. guidance favors in-house tools. The 2018 joint statement encourages responsible innovation without advocating any method. You still own third-party risk management: due diligence on the vendor, validation of the tool against your data, and ongoing monitoring.

Can we pilot a bought tool alongside our current monitoring system?

Yes, and that is the pattern the agencies explicitly contemplated: pilots run in conjunction with existing BSA/AML processes, and a pilot that surfaces gaps will not automatically trigger supervisory action against the existing program.

Deciding for your own program

If you are working through a build vs buy compliance AI decision this year, ground it in your own alert volumes, staffing, and exam calendar rather than a generic framework. Axle's AI agents handle alert triage, KYB research, and SAR drafting support inside your existing program, with every step logged and auditable. Start with the AI readiness playbook, then see how the agents work on the Axle platform.

Build vs Buy: AI for Compliance Operations

More from the blog