One FTP Curve, Five Decisions: Who Governs the Chain?

Here is a pattern I have seen more than once. Treasury updates the funds transfer pricing curve. The change is sensible. Liquidity premiums were stale, or the deposit behavior assumptions needed a refresh. Treasury documents it, gets it approved, and loads it.

Three weeks later the head of retail asks why the checking portfolio suddenly looks unprofitable. Nothing changed in the business. Balances are flat, fees are flat, costs are flat. The margin moved because the credit the deposits receive for their funding value moved. Nobody told the retail team, the pricing desk or the people who calculate bonuses.

Every link in that chain worked as designed. The chain itself had no owner.

What one curve touches

In most banks I have worked with, the FTP curve feeds at least five decisions.

Profitability. Every loan is charged for the funds it uses and every deposit is credited for the funds it provides. Change the curve and you change the margin of every product, branch and relationship in the report.

Pricing. Loan and deposit pricing desks quote off the transfer rate. A higher funding charge raises the floor on a new loan. A lower deposit credit makes a promotional rate look expensive.

Incentives. If relationship managers are paid on contribution margin, the FTP curve is part of their paycheck. Bankers often notice a 10 basis point move before Finance does.

RAROC and capital allocation. Risk-adjusted return starts from a margin that already carries the FTP charge. Move the curve and a business line can cross its hurdle rate without making a single new decision.

Budget and forecast. The plan for next year uses a curve. Often it uses last quarter's curve, frozen in a spreadsheet, while actuals run on the new one.

The interagency guidance on funds transfer pricing, issued in March 2016 (SR 16-3), already asked banks to build FTP costs and benefits into product pricing, business metrics and new product approval. In my experience, each of those uses got attention. The connections between them got much less.

A small move, a large reallocation

Take an illustrative bank with $2 billion in non-maturity deposits. Treasury lowers the credit those deposits receive by 10 basis points.

That is $2 million a year of net interest margin moving from the deposit business to Treasury, on paper, with no change in customer behavior. The bank's total income is the same. The story each business line tells the board is not.

Ten basis points is a modest adjustment. In a year of rate moves, curve updates can be several times larger, and the reallocation grows with them.

Why nobody owns it

Look at who owns each link.

Treasury owns the curve. FP&A owns the plan. The business lines own pricing. Human resources or a compensation committee owns incentives. Risk owns capital and RAROC. Each owner governs its piece well, and each piece passes review.

The model risk team, where it exists, reviews models one at a time. The FTP model gets validated. The profitability engine may or may not be in the inventory. The pricing tool is often a spreadsheet. The incentive calculation is almost never treated as a model at all.

SR 26-2, the new interagency guidance on model risk management issued in April, asks banks to assess model risk in aggregate, including the risk that comes from shared assumptions and shared data. The FTP curve is the clearest shared assumption a bank has. It is the place to start.

Map the chain in a week

You don't need a new system to see your chain. You need a list and a few conversations.

  1. Find every consumer of the curve. Profitability, pricing, incentives, capital, planning, and anything else that reads a transfer rate. Ask who runs each one.

  2. Record which version each consumer uses. Same curve, same date? Or is the plan running on a version from two quarters ago?

  3. Trace the timing. When Treasury loads a new curve, how long until each consumer picks it up? Who triggers the update?

  4. Check one number across reports. Pick a single product and a single month. Compare the FTP charge in the profitability report, the pricing model and the incentive file. They should match.

  5. Write the change protocol. Who gets told before the curve changes, who re-runs what, and who signs off that the downstream numbers moved for the right reason.

Step four is the one that usually surprises people.

Signs your chain needs attention

Three FTP rates for the same product in three different reports. A product that swings from profitable to unprofitable with no change in volume, price or cost. Compensation disputes where the banker and Finance are both right because they used different curves. A budget that misses because the plan and the actuals were never on the same rates.

Any one of these points to governance. The math in each model can be fine while the chain between them is broken.

How I approach it

At Asher & Company, mapping this chain is one of the core deliverables of our Model Governance Review. We trace the FTP curve to every decision it feeds, check that each consumer runs on the same version, and score how changes are controlled. Our agentic AI framework, Sáasil™, reads the rules, rate tables and documentation across the chain. I review every finding before it reaches the report. The details are on the Model Governance Review page, and Part 1 of this series covers how SR 26-2 classifies Finance models.

If you want to compare notes on your own chain, 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: Interagency Guidance on Funds Transfer Pricing Related to Funding and Contingent Liquidity Risks (March 1, 2016, SR 16-3); Federal Reserve SR 26-2, Revised Guidance on Model Risk Management (April 17, 2026). The $2 billion example is illustrative arithmetic, not client data. This post is my reading of the guidance and is not legal or regulatory advice.

Previous
Previous

Who Governs the Model When an Agent Runs It?

Next
Next

The Megawatt Is the New Lease: How to Keep the Data Center Race from Destroying Value