Put AI investment through the same diligence as every other capital decision

Every vendor deck and internal champion has reason to round up: pilots get reported as wins, and “AI-powered” gets attached to outcomes it didn't drive. The anchor that holds under scrutiny is the public record — what a peer bank, or the vendor it named, has stated openly, with a number where one exists. The read starts there, and treats a benefit no one has disclosed as missing evidence, not as proof the value isn't real.

The read has two parts: how widely a use case has evidenced value, and how deep its single best result runs.

It asks whether benefit has been disclosed across the kinds of value a bank actually weighs, rather than in one place only — nine benefit dimensions, grouped into four categories:

A use case with disclosed benefit across many of these reads as more comprehensively proven than one resting on a single claim.

It is the single strongest result on the record. Breadth can flatter a use case with many small, well-reported claims; depth surfaces the one most consequential outcome a peer has actually disclosed. The two are read together, because they tell different stories: a broad-but-shallow case — benefit shown widely, but modestly — is a different proposition from a narrow-but-exceptional one, where coverage is thin but a single result stands out.

Three things govern what counts:

Across the six sample use cases, drawing on 111 publicly disclosed benefit claims, treasury forecasting is the most broadly evidenced value case, scoring 85. Its disclosed benefits concentrate in operational efficiency and analytical depth: across four major US-bank deployments — Bank of America's CashPro, JPMorgan's Cash Flow Intelligence, PNC's PINACLE, and Citi's Cashforce / TIS — the consistent public claims are about labor saved and forecasts that reach further and see more. What the 85 says is narrow, and worth stating plainly: of these six functions, treasury forecasting's value is the best documented — not that it is the most valuable bet a given bank could make.

A well-evidenced use case can still be costly to run safely. The next three sections read those costs — beginning with the one that most often separates a back-office tool from a customer-facing system: regulatory intensity.

The instinct is to count the laws on the books, or to assume the most advanced AI draws the most scrutiny. Both mislead. A use case's regulatory weight is set by what it does — and the sharpest dividing line is whether the system reaches a decision about a person (their credit, their eligibility, their treatment) or only produces analysis a human acts on. Cross that line and consumer-protection, fair-lending, and the new state AI statutes engage; stay on the analytical side and most of them fall away.

A second distinction matters as much. Not every applicable rule bites the same way. Some carry statutory penalties, attorney-general actions, and private rights of action; others run entirely through supervisory examination — matters requiring attention, consent orders, heightened oversight — with no direct fine attached. A use case can be subject to many instruments and still carry light intensity if its exposure is supervisory and its workflow analytical.

For each use case, the framework constructs a regulatory surface by asking three things of every instrument:

This runs across 31 instruments spanning nine regulatory domains and four jurisdictions, anchored on the 14 U.S. instruments that bear on U.S. institutions: AI-specific, consumer protection and fair lending, data privacy and security, financial crime and payments, market conduct and trading, model risk, operational resilience, tech governance, and third-party and outsourcing.

One distinction does quiet but important work: how directly an instrument applies to a workflow is scored separately from how hard it would bite if violated. Keeping the two apart stops a heavy-penalty law that a use case barely touches from masquerading as a central obligation — a common way regulatory heat-maps mislead.

At a regulatory intensity of 50, treasury forecasting carries the lightest profile of the six sample use cases — and lighter in kind, not only in degree. Because it produces analysis rather than decisions about people, the consumer-facing regimes that drive intensity elsewhere simply don't engage: fair-lending and consumer-protection law (ECOA/Reg B, FCRA/Reg V, UDAAP) and the new state AI statutes (the Colorado ADMT Act, Texas's TRAIGA, Utah's AIPA) all read as Not relevant to its workflow. What remains concentrates in three supervisory regimes — third-party and outsourcing risk (Interagency TPRM, the primary driver), model risk (SR 26-2), and tech governance (the FFIEC IT Handbook and OCC Heightened Standards). Notably, SR 26-2 — which replaced SR 11-7 in 2026 and expressly excludes generative and agentic AI — sits at Medium for a conventional-ML forecasting tool, not High. And all of this exposure runs through examination, not statute: matters requiring attention and supervisory remediation, not direct fines, attorney-general actions, or private litigation. The result is a profile qualitatively different from a customer-facing system like credit underwriting, where exposure compounds across consumer-protection, fair-lending, privacy, and model-risk regimes at once.

Knowing which rules bite is one cost; running and governing the system that satisfies them is another. The next section reads the second of those costs — operating intensity.

The temptation is to treat an AI use case as a build — scope it, ship it, book the benefit. But the build is the cheap part. Running and governing the system is permanent, and cross-functional in a way a one-time project is not: it draws continuously on model risk, data operations, and governance. It is also where evidenced value quietly erodes — a use case that looked attractive on its business case can underdeliver because the operating intensity was never priced in. And that burden is unevenly distributed: it concentrates in particular categories, often shaped by what regulation and the technology demand rather than freely chosen. Knowing where it concentrates is what lets a bank budget for it, rather than discover it after the system is live.

The framework characterizes how a system is actually built, run, and governed — across 14 operating-model categories, grouped into four layers:

The distinctive part is the method. Banks rarely publish their full operating model, so each category is characterized the way the rest of the framework works: by reading the public record first, and where the record stops, applying a single labeled inference — never presented as fact. Three inference types do that work: a technical implication (an architecture or control the system must have to work as described), a regulatory expectation (a control a regulated bank would be expected to operate), or a domain-typical practice (what banks running this kind of AI conventionally do). Every characterization carries its tag, so a reader can see exactly where disclosure ends and inference begins.

Four things govern the read:

At an operating intensity of 56, treasury forecasting carries the lightest profile of the six sample use cases — most of its run-and-govern choices sit at the cohort floor: ensemble models on scheduled-batch inference, pre-decision human review, and informational output that doesn't trigger automated action. But "light overall" hides where the weight sits. Its operating intensity concentrates in one category — data sourcing: the multi-source external integration the forecasts depend on, pulling from client ERP systems, external bank accounts, and internal systems, each a system of record that tolerates no latency or reconciliation gaps. And a few governance categories are shaped by regulation rather than choice — model validation, where SR 26-2 expects independent validation for a material model, and data privacy, because personal data flows through the pipeline. The lesson generalizes: even a light use case carries a specific, locatable operating intensity, and the value of the read is knowing exactly where it sits before the system is live.

Running the system is one cost; the difficulty of building it in the first place is another. The final section reads technical complexity.

The temptation is to read “AI complexity” as a single dial: the more advanced the model, the harder the build. It doesn't hold. Build difficulty has at least three separable sources, and for a great deal of banking AI the model is the cheapest of them — a conventional, well-understood algorithm can be far less work to stand up than the data pipeline that feeds it or the systems of record it has to integrate with. The framework decomposes build difficulty into its sources so a bank can see where the cost actually sits, and so a use case isn't waved through on the strength of “frontier AI” that is, in build terms, lighter than a conventional model wired into a treasury management system.

The framework reads three components:

Two moves keep the read honest. It records not only what a system uses but what it notably does not — the absence of large language models, graph networks, or unstructured data is part of the profile, and recording it stops a conventional system from being scored as if it were frontier. And where disclosure stops, the same three labeled inference types fill the gap — a technical implication, a regulatory expectation, or a domain-typical practice — each tagged, never presented as fact.

Four things govern the read:

At a technical complexity of 40, treasury forecasting is the lightest build of the six sample use cases — and the decomposition shows why. Its disclosed AI is conventional and mature: ensemble methods, time-series forecasting, scenario simulation, AutoML, and drift monitoring, with neural networks a domain-typical inference and anomaly detection a technical implication. The frontier categories that lift other functions are notably absent — no large language models, no generative AI, no graph neural networks, no federated or edge learning. The data layer is narrow: two modalities, structured transaction records and time series, with none of the graph relationships or text feeds that make compliance functions data-heavy. What complexity exists lives almost entirely in the integration — multi-bank ingestion, ERP (SAP), and treasury management systems: few system classes, but each a system of record that tolerates no latency or error. The lesson is the one the score is built to surface: the build is light precisely because the model is conventional and the data narrow, and the engineering effort that remains is robust integration, not the AI. It is the same picture the operating read showed — the weight sits in the data plumbing, not the model.

That completes the read. With value set against the three costs of realizing it — regulatory, operating, and technical — a use case can be placed the way any other claim on capital is: the well-evidenced, light-to-build cases that earn capital first, and the ones whose value is outweighed by what it takes to build, govern, and sustain. Producing that placement, on common terms, is what the framework is for.