I hear the same sentence in almost every first meeting with a bank's finance team. "We already have our models." And they do. The FTP engine runs every month. The profitability report goes to the board. The allocation rules have been in place for years.
Having a model and being able to defend it are two different things. The first is a technology question. The second is a governance question, and it usually comes up at a bad moment: an examiner asks who approved a change, a business head disputes a margin, or a new CFO wants to know why two reports show different numbers for the same product.
This is the last post in a three-part series. Part 1 covered how SR 26-2 decides which Finance tools are models. Part 2 followed one FTP curve through five decisions. This one is a checklist. Nine questions, one for each dimension we score in a review. You can run it yourself in an afternoon.
How to use the checklist
For each question, give yourself one of three answers.
Documented. You can hand over a document, a log or a report that answers it.
Known. Someone on the team knows the answer, but it isn't written down.
Unknown. Nobody is sure, or two people give different answers.
Be strict. "Known" is not a passing grade. It means the answer leaves when that person does.
The nine questions
1. Inventory and classification. Do you have a written list of every model Finance runs, with a decision on which ones are models under SR 26-2 and which are critical tools? Most banks have a model inventory. Fewer have one that includes the profitability engine, the allocation rules and the pricing spreadsheet.
2. Materiality and tiering. Is the effort you spend on each model proportional to its exposure and purpose? A tool that sets loan prices deserves more attention than one that produces an internal dashboard. If everything gets the same review, or nothing does, the tiering isn't working.
3. Ownership and challenge. For each model, can you name the owner and the person who challenges it? FTP often sits between Treasury and Finance. Profitability sits between Finance and IT. Shared ownership tends to mean nobody owns it.
4. Assumptions and documentation. Are the FTP curve, the liquidity premiums, the cost drivers and the capital rules written down, with the reason behind each one? A number without a rationale can't be defended. It can only be repeated.
5. Monitoring and outcomes. Does your profitability total reconcile to the general ledger every month? Is the FTP cost you charge compared against what funding actually costs? A model nobody checks against reality slowly drifts away from it.
6. Change control and traceability. If a rule, a driver or a curve version changes, can you show who changed it, when, and who approved it? In my experience it is the first question an examiner asks, and the one finance teams most often answer with "let me check."
7. Dependencies and aggregate risk. Which decisions break if the FTP curve or a key driver is wrong? Part 2 of this series walked through that chain. If you can't draw it, you can't say how big a single error would be.
8. Vendor models and customizations. Do you understand the logic inside the vendor software you run, and are your own customizations documented? EPM platforms ship with standard calculations. Over the years, every bank adds its own rules on top. Those additions are often the least documented part of the system.
9. Use within purpose. Are pricing, incentives and the budget using each model for what it was built to do? A profitability model designed for monthly reporting can end up setting bonuses. That may be fine. It should be a decision, not an accident.
Reading your score
Count your "Documented" answers.
Seven to nine. You can defend your models. Keep the documents current and test them once a year.
Four to six. Typical, in my experience. The models work, but the defense depends on a few people. Start with questions 6 and 7.
Three or fewer. The risk isn't in the math. It is in what happens when someone asks you to prove the math.
Any "Unknown" on questions 5, 6 or 7 matters more than the total. Those are the ones that turn a small error into a board conversation.
What the score doesn't tell you
A self-assessment shows where the gaps are. It doesn't show how large they are. Knowing that change control is weak is useful. Knowing that a weak control sits on the curve that feeds pricing, incentives and the budget is what tells you where to start.
This is also where an honest outside view helps. Teams that built a model are usually the last to see what it assumes. I say that as someone who has built more than 200 of them.
How I approach it
At Asher & Company, these nine questions are the backbone of our Model Governance Review. It is a fixed-scope review of the models Finance already has. We score each dimension from 1 to 5, classify your inventory against SR 26-2, map the dependencies from the FTP curve down and rank findings by materiality. Our agentic AI framework, Sáasil™, reads the rules, drivers and documentation across the chain. I review every finding before it reaches the report. You keep your models. If you want help with what comes after, that is a separate conversation.
The details are on the Model Governance Review page. Part 1 covers how SR 26-2 classifies Finance models, and Part 2 covers who governs the FTP chain.
If you ran the checklist and want to compare notes, 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); Interagency Guidance on Funds Transfer Pricing (March 1, 2016, SR 16-3). The scoring bands are my own rule of thumb, not a regulatory standard. This post is my reading of the guidance and is not legal or regulatory advice.
