# Running a build-buy-partner decision for core AI capability
A mid-size US bank (roughly $30 billion in assets) is staring at a deadline. Its AML (anti-money laundering, the regulatory regime requiring banks to detect and report suspicious financial activity) transaction-monitoring system is nine years old, throwing false positives at a rate compliance staff describe as "unmanageable," and a recent regulatory exam flagged model documentation gaps. The CIO has three options on the table: build a new system in-house using the bank's data science team, buy a vendor platform, or co-develop with a fintech partner. The board wants a recommendation in six weeks. This is the decision this lesson equips you to run.
AML transaction monitoring uses AI/ML (machine learning) to score transactions for suspicious activity, replacing or augmenting static rules ("flag any wire over $10,000") with pattern detection that adapts to new laundering techniques.
The stakes cut both ways. Under-detect and you risk regulatory penalties under the Bank Secrecy Act (BSA, the core US AML law) and enforcement from FinCEN (Financial Crimes Enforcement Network) or, in Europe, national regulators applying the EU's AML directives. Over-detect and you drown investigators in false positives, industry estimates commonly cite false positive rates above 90% for legacy rules-based systems, an approximation worth treating as directional, not exact.
This isn't a generic "AI adoption" choice. It's a decision about a system that sits inside a heavily audited, high-liability compliance function. That changes the calculus versus, say, adopting an AI tool for marketing copy.
You retain full control over the model, the , and the logic, which matters when regulators ask "why did the model flag this transaction?" (a requirement often called model explainability).
Costs are real and recurring: data scientists, ML engineers, MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.View full definition → infrastructure, and crucially, the compliance and validation staff needed to document the model under supervisory guidance like the Federal Reserve's SR 11-7 on model risk management. Most mid-size banks underestimate this second cost bucket.
Build makes sense when you have a differentiated data asset (a genuinely unusual customer base or transaction pattern) or when off-the-shelf models perform poorly on your segment. It rarely makes sense as a first move for a mid-size bank with a lean data science bench.
Vendors like NICE Actimize, Oracle Financial Services, SAS, and Feedzai sell AML platforms with pre-trained detection models, case management workflows, and (critically) pre-built regulatory reporting.
The advantage is speed to compliance and shared model validation burden, since these vendors have already been through multiple bank examinations. The disadvantage is fit: a vendor model trained across hundreds of institutions may not catch patterns specific to your customer base (a bank heavy in trade finance or correspondent banking has different risk patterns than a retail-heavy bank).
Buy also means vendor lock-in risk and less transparency into the model internals, which can complicate explaining decisions to examiners. You are compliant, but dependent.
This hybrid path (the bank supplies data and compliance expertise, a fintech supplies ML engineering and a lighter-weight platform) is increasingly common for capabilities like alert triage and transaction scoring, where firms such as Hawk AI or ThetaRay operate.
Partnership can combine domain fit with faster iteration than build, and more customization than buy. The catch: governance. Who owns the model documentation when the regulator asks? Who is liable if the model misses a sanctions match? These need to be contractual, not assumed.
Score each option 1 to 5 on these dimensions, weighted by what matters most to your institution:
| Dimension | What to ask |
|---|---|
| Regulatory defensibility | Can you produce model documentation an examiner will accept? |
| Data fit | Does the model perform on your actual customer/transaction mix, not a vendor's benchmark? |
| Time to compliance | Can this be validated and live before your next exam cycle? |
| Total cost of ownership | Licensing/build cost plus the compliance, validation, and maintenance tail |
| Talent dependency | Do you have (or can you retain) staff to run this, whichever path you choose? |
| Explainability | Can you trace a specific alert back to the features that triggered it? |
For the AML case: if the exam finding centered on documentation gaps, regulatory defensibility and explainability should carry the heaviest weight, often pointing toward buy or partner, where vendors bring examination-tested documentation, rather than build, where the bank inherits that burden from scratch.
Say the bank's current system generates 100,000 alerts per year, with a 90% false positive rate (an industry-cited estimate, treat as approximate) and each alert takes an analyst 20 minutes to review.
If a new AI-enhanced system (build, buy, or partner) cuts false positives to 70% while catching the same true positives, alert volume for review drops proportionally: roughly 100,000 → about 70,000 relevant alerts, saving close to 10,000 analyst hours, or roughly $600,000/year.
Weigh that saving against the cost of each path over a 3-year horizon (vendor licensing fees typically run in the high six to low seven figures annually for mid-size banks, build costs concentrate upfront in talent and infrastructure, partner costs are usually a blend). The ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition → (return on investmentreturn on investmentReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition →) case only works if you model the compliance and validation tail cost, not just the license or dev cost, a mistake many banks make when the business case looks good on a vendor's slide deck but ignores internal implementation lift.
Knowledge check
1. Why does the AML transaction-monitoring context make the build-buy-partner decision fundamentally different from adopting an AI tool for something like marketing copy?
2. A bank's legacy AML system has a very high false positive rate. What is the core tradeoff this illustrates in transaction monitoring?
3. Why does model explainability matter specifically as an argument for building an AML system in-house rather than buying a vendor platform?
4. Select ALL correct answers about why this bank's AML decision is considered high-stakes and time-pressured.
Select all the correct answers.
5. Select ALL correct answers about factors that make AML transaction monitoring a good candidate for AI/ML rather than static, rules-based flagging alone.
Select all the correct answers.
Whichever path you pick, US and EU regulators are converging on similar expectations: demonstrable model governance, not necessarily a specific vendor or build choice.
The Fed's SR 11-7 framework (still the reference standard as of 2026) requires independent validation, ongoing monitoring, and clear documentation of model limitations. The EU's evolving AI Act imposes additional obligations on "high-risk" AI systems, and AML transaction monitoring plausibly falls into scrutiny given its impact on individuals' financial access, though banks should track final guidance from the European Banking Authority rather than assume classification.
Practically: a "buy" decision does not outsource regulatory responsibility. The bank remains accountable even if the vendor built the model. This is the single most common misunderstanding in build-buy-partner decisions across banking AI, not just AML.
🎬 [VIDEO: "How Banks Use AI to Fight Money Laundering" - youtube.com/results?search_query=how+banks+use+ai+to+fight+money+laundering - search for recent explainer content from banking technology channels covering AML transaction monitoring and AI, useful for a visual walkthrough of alert scoring and case management workflows]
Given the exam finding was about documentation, not detection accuracy, the strongest initial move is likely buy or partner, not build. A vendor platform brings examination-tested documentation out of the box; a fintech partnership can be layered in later for segment-specific tuning once the base compliance gap is closed.
Build remains the long-term option if, after two or three years running a vendor or partner solution, the bank identifies a genuinely differentiated detection need the market doesn't serve, at which point it has both the data and the internal experience to build credibly.