Building an ROI model for an AI initiative

A mid-sized asset manager rolls out an AI transaction-forecasting tool, promising a 30% reduction in cash-buffer needs. Eighteen months later, finance flags the project as a loss. Nobody budgeted for the three data engineers hired to keep the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → clean, or the quarterly model retraining that ballooned cloud compute bills. The model worked. The business case didn't.

This is the single most common failure mode in fintech AI adoption: benefits get modeled generously, costs get modeled narrowly. This lesson builds a cost-benefit framework that closes that gap.

Why fintech AI business cases go wrong

Most 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 investment) pitches for AI tools compare a single upfront license or build cost against projected savings. That comparison is incomplete for three reasons specific to AI systems:

1. AI has a maintenance tail that software licenses don't. A rules-based fraud filter, once built, is largely static. A machine learning model trained on transaction patterns degrades as customer behavior shifts (this is called "model drift"). It needs monitoring, retraining, and revalidation, often quarterly.
2. Data infrastructure is a prerequisite cost, not a project cost. Portfolio-monitoring AI needs clean, timestamped, reconciled data feeds. Most institutions don't have this ready; building it is frequently the majority of total project spend.
3. Integration with legacy core systems is nonlinear. A model that performs well in a sandbox may require months of engineering to connect to a bank's core banking platform or a broker's order management system.

The four cost buckets everyone underestimates

1. Data infrastructure

Pipelines to ingest, clean, label, and store data. For transaction forecasting, this might mean normalizing feeds from multiple custodians or payment rails. Estimate (2025 industry commentary, e.g. from McKinsey's work on AI implementation costs): data preparation and infrastructure commonly consumes 40 to 60% of total AI project budgets in financial services, well above the model-building cost itself.

2. Integration and change management

Connecting a model's output to a decision system (a trading desk, a compliance workflow, a customer app) requires APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → work, testing, and often retraining staff. A portfolio-monitoring AI that flags anomalies is worthless if relationship managers ignore the alerts because the workflow wasn't redesigned around them.

3. Model risk management and validation

US banks operate under supervisory guidance commonly known as SR 11-7 (Federal Reserve/OCC guidance on model risk management), which requires independent validation of models used in decision-making. In the EU, the AI Act (entered into force 2024, phased obligations through 2026-2027) imposes documentation and risk-management duties on "high-risk" AI systems, which can include creditworthiness and certain financial-risk models. Validation is recurring labor, not a one-time audit.

4. Ongoing monitoring and retraining

Model performance must be tracked against live outcomes (this is sometimes called "model monitoring" or "MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.View full definition →," short for machine learning operations). Retraining cadence depends on how fast the underlying data patterns shift; transaction forecasting in volatile markets may need monthly recalibration.

A simple ROI framework

Structure the business case as three layers, not one number.

Layer 1: One-time costs

• Data pipelineData pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition → build
• Model development or vendor licensing
• Integration engineering
• Initial validation

Layer 2: Recurring annual costs

• Cloud compute and storage
• Monitoring and retraining labor
• Ongoing model validationmodel validationThe process of measuring whether an AI model performs well enough, and safely enough, for the business decision it is meant to support.View full definition → (recurring, especially under regulatory regimes)
• Vendor support fees

Layer 3: Benefits, discounted for realism

• Direct cost savings (e.g., fewer manual reconciliations)
• Risk reduction (e.g., earlier fraud detection, lower loss rates)
• Revenue enablement (e.g., faster onboarding increasing conversion)

Apply a realism discount to benefits. If a vendor claims 30% efficiency gains, model two scenarios: base case (vendor claim) and conservative case (50 to 60% of vendor claim), because pilot results routinely overstate production performance.

Worked example: transaction-forecasting tool

Assume a mid-sized fintech lender evaluating an AI tool to forecast short-term cash flow needs for a lending book.

One-time costs (Year 0), illustrative estimate:

• Data infrastructure build: $250,000
• Model licensing/build: $150,000
• Integration with core lending system: $100,000
• Initial validation: $50,000
• Total Year 0: $550,000

Recurring annual costs, illustrative estimate:

• Cloud compute/storage: $60,000/year
• Monitoring + retraining labor (fractional FTE, full-time equivalent staff): $120,000/year
• Ongoing validation: $40,000/year
• Total annual recurring: $220,000/year

Benefits, conservative case:

• Reduced cash-buffer holding costs: vendor claims $400,000/year saved; conservative case applies 55%: $220,000/year
• Fewer manual forecasting hours (2 analysts redeployed): $150,000/year
• Total annual benefit: $370,000/year

Simple three-year ROI:

Year 0:  -550,000
Year 1:  +370,000 - 220,000 = +150,000
Year 2:  +370,000 - 220,000 = +150,000
Year 3:  +370,000 - 220,000 = +150,000

Cumulative after 3 years: -550,000 + 150,000 x 3 = -100,000

Under the conservative case, this project has not broken even by year three. It likely turns positive in year four. That's a materially different story than the vendor's pitch (which, using the full $400,000 claimed benefit, would show breakeven inside year two). The point of the framework isn't to kill the project, it's to make the real payback horizon visible before signing a contract.

Sensitivity checks worth running

Before presenting a business case to a steering committee, stress-test it:

• What if retraining frequency doubles? Volatile markets or regulatory changes can force more frequent recalibration than planned.
• What if integration takes twice as long? Legacy core-system integration delays are the norm, not the exception, in banking and insurance IT.
• What if adoption inside the organization is partial? If only 60% of relationship managers act on portfolio-monitoring alerts, benefit capture drops proportionally.

A useful discipline: present ROI as a range (conservative to base case) rather than a single number. Boards and risk committees trust ranges more than they trust point estimates that later prove wrong.

🎬 [VIDEO: "How to Calculate ROI for AI Projects" - youtube.com - search for recent (2024-2025) talks from enterprise AI practitioners covering total cost of ownership frameworks for machine learning deployments; useful for seeing how practitioners outside fintech frame the same maintenance-cost problem]

What good practice looks like

Firms that get this right generally do three things differently:

1. They price data infrastructure and MLOps tooling as part of the initiative, not as "existing IT capacity."
2. They build in model validation costs upfront, anticipating regulatory scrutiny (SR 11-7 in the US, AI Act obligations in the EU) rather than treating validation as an afterthought.
3. They run pilots long enough to observe at least one retraining cycle before finalizing the business case, so maintenance costs are measured, not assumed.

For a practical reference on model risk expectations, the Federal Reserve's SR 11-7 guidance is freely available and still the baseline framework cited across US financial institutions.

Key Takeaways

• AI business cases fail most often by undercounting recurring costs (data infrastructure, monitoring, retraining, validation), not by overestimating the model's technical performance.
• Structure ROI in three layers: one-time costs, recurring annual costs, and discounted benefits, rather than a single net figure.
• Apply a realism discount (roughly 50 to 60% of vendor-claimed benefits) when modeling the conservative case; present a range, not a point estimate.
• Data infrastructure alone can consume 40 to 60% of total AI project budgets in financial services (industry estimate); budget for it explicitly.
• Regulatory obligations (SR 11-7 in the US, the EU AI Act for high-risk systems) turn model validation into a recurring cost line, not a one-time audit, and should be priced into the business case from day one.