SR 26-2 Redrew the Line. Is Your Profitability Model Still a Model?
On April 17, 2026, the Federal Reserve, the OCC and the FDIC replaced SR 11-7. For fifteen years that letter told banks how to manage model risk. Its successor, SR 26-2, is more risk-based and more explicit about what counts as a model in the first place.
Most of the commentary I have read since April is written for the model risk team. This post is for the people who own the numbers Finance produces every month. The CFO, the treasurer, the head of FP&A. Your funds transfer pricing curve, your profitability engine and your cost allocations sit in a strange spot under the new guidance. Some of them are models. Some of them no longer are. Almost nobody has written down which is which.
What changed
SR 26-2 defines a model as a complex quantitative method that applies statistical, economic or financial theory to turn input data into quantitative estimates. Then it says what falls outside. Simple arithmetic, the kind you find in spreadsheets, is out. So are deterministic, rule-based processes with no statistical, economic or financial theory behind them.
Three other changes matter for Finance.
Materiality now drives effort. The guidance looks at a model's exposure and its purpose. A material model gets the full treatment. An immaterial one can be identified and monitored, without the same validation burden.
Models are judged in aggregate. The letter asks banks to look at model risk across models, including shared assumptions, shared data and shared methods.
Size matters, and the letter says so. SR 26-2 is described as most relevant to banks above $30 billion in total assets. The FDIC's version goes further: for banks at or below $30 billion, it generally does not apply unless the bank has significant exposure to model risk. Those banks are expected to govern their models in a way that fits their size and risk profile.
Where Finance models land
Here is my reading, model by model. Use it as a starting point for your own classification.
Funds transfer pricing. FTP sits inside the definition. Building a transfer curve, setting liquidity premiums and modeling the behavior of non-maturity deposits all apply financial theory to data. The 2016 interagency guidance on FTP already said the models used in FTP should be independently validated and regularly reviewed. Nothing in SR 26-2 takes FTP out.
Customer and product profitability. This one splits in two. The FTP charge and the capital charge inside your profitability numbers carry model risk. The aggregation that adds revenue, subtracts allocated cost and rolls results up by branch or segment is mostly arithmetic. Same report, two different risk profiles.
Cost allocation and ABC. A driver-based allocation engine is, in most banks, deterministic logic. Costs move from pools to activities to products according to rules someone wrote. Under the new definition, many of these engines will leave the formal model inventory.
RAROC and economic capital. If your capital numbers come from probability of default, loss given default or volatility estimates, you are in model territory. If they come from a fixed regulatory ratio applied to a balance, much less so.
Budgeting and forecasting. It depends on what is inside. A forecast built on statistical relationships or economic assumptions is a model. A plan that extrapolates last year by a growth rate is a spreadsheet.
Leaving the inventory is not leaving the risk
This is the part I worry about.
When an allocation engine drops out of the model inventory, it also drops out of the validation calendar. Nobody schedules a review. Nobody asks who changed a driver last quarter, or why. And that engine still decides which products look profitable, which branches get investment, and how a relationship manager's bonus is calculated.
Over thirty years I have built more than 200 integrated EPM models. The failures I remember were rarely in the math. They came from a driver nobody updated after a reorganization, a manual override that stayed in place for two years, or an FTP curve that changed in Treasury without anyone telling the team that prices loans. None of those would have been caught by a validation program focused on credit models.
SR 26-2's aggregate view points straight at this problem. One FTP curve feeds profitability, pricing, incentives, RAROC and the budget. If the curve is wrong, five decisions are wrong at once. The model risk team reviews models one at a time. The chain between them usually belongs to nobody.
Five questions to ask this quarter
Do we have a written list of every model Finance runs, and a decision on which ones are models under SR 26-2?
For the tools we classify out, who owns them now, and what controls replace validation?
Can we trace the FTP curve to every decision it feeds?
Does our profitability total reconcile to the general ledger every month, and who signs off when it doesn't?
If a driver or a rule changes, is there a record of who changed it and who approved it?
If you can answer all five with a document, you are in good shape. If the honest answer to two or more is "it depends who you ask," that is your governance gap.
How I approach it
At Asher & Company we run a fixed-scope review of how banks govern the models Finance already has. We classify each model against the new definition, map the dependencies from the FTP curve down, and score governance on nine dimensions. Our agentic AI framework, Sáasil™, does the wide reading across rules, drivers and documentation. I review every finding before it reaches the report. You keep your models. You get a clear view of whether you can defend them. The details are on the Model Governance Review page.
If you want to compare notes on your own classification, write to me at psanmartin@asher.company.
Pedro San Martín is Founder & Principal of Asher & Company and Chair of the IMA Profitability & Cost Management SIG.
Sources: Federal Reserve SR 26-2, Revised Guidance on Model Risk Management (April 17, 2026); OCC Bulletin 2026-13; FDIC FIL-15-2026; Interagency Guidance on Funds Transfer Pricing Related to Funding and Contingent Liquidity Risks (2016). This post is my reading of the guidance and is not legal or regulatory advice.
