Funds Transfer Pricing Engine Design That Reflects Real Economics
Pricing Internal Funding So Business Units See What They Actually Cost
Funds transfer pricing is where a bank's balance sheet economics meet its internal politics, and the engine usually loses. A methodology gets agreed, rates start flowing into unit profitability, and within two quarters the monthly performance meeting is spent arguing about the charge rather than about the business that incurred it.
That outcome is an architecture problem more than a methodology problem. A funds transfer pricing engine that cannot explain a rate, at deal level, in terms a business head recognises, will be treated as an accounting overhead and ignored. One that can explain it changes lending and deposit behaviour within a quarter, which is the entire point of building it.
What is a funds transfer pricing engine actually for?
To charge users of funding and credit providers of funding, so unit profitability reflects real balance sheet economics.
Without it, a five-year fixed-rate loan and an overnight deposit appear to cost the same to fund, so business units are rewarded for taking term and liquidity risk the treasury absorbs invisibly. The engine moves that cost to the decision point. The Basel Committee's liquidity principles are explicit that liquidity costs, benefits and risks should be allocated to all significant business activities, which is precisely what internal pricing operationalises.
What does an FTP rate have to charge for?
Term funding cost, liquidity premium, contingent liquidity, and the specific risks the business creates.
| Component | What it prices | Why it belongs |
|---|---|---|
| Base reference rate | The cost of money for the relevant tenor | Neutral starting point everyone recognises |
| Term liquidity premium | The cost of raising funding for that term | Makes long-dated lending carry its real cost |
| Contingent liquidity cost | Buffers held for undrawn commitments and outflow risk | Charges the business that creates the contingency |
| Basis cost | Mismatch between the reference rate a product pays and the funding basis | Prevents hidden basis risk sitting with treasury |
| Optionality cost | Prepayment rights, caps, floors, early withdrawal | Prices the option the customer holds |
| Regulatory cost, where genuinely attributable | Ratio impact driven by specific business | Only if attribution is defensible |
The last row is where methodologies overreach. If a regulatory cost cannot be attributed to a business decision in a way that business can influence, charging it produces resentment without changing behaviour, which is the worst of both outcomes.
Why does a term liquidity premium matter more than the base rate?
Because it is the component that changes decisions, and the one most often flattened away.
A single pooled funding rate makes every tenor look identical, which is exactly the distortion that leaves a bank holding long-dated fixed-rate assets funded by overnight money. The term premium is what makes a five-year commitment feel different from a one-year commitment at the point somebody prices a deal. If your methodology has one number for funding cost, it is not really a transfer pricing system, it is an internal tax with a curve-shaped name.
Are your business units pricing long-dated deals against a single pooled funding rate?
Talk to Digiqt about an FTP methodology and architecture review
Why do FTP disputes happen so predictably?
Because charges arrive without explanation, and an unexplainable charge is always assumed to be wrong.
Three design flaws produce almost all of the arguing. Rates computed at portfolio level so no individual deal can be traced. Curves refreshed on an unclear schedule so a rate cannot be tied back to market conditions on the day the deal was struck. And allocations that cannot be decomposed into components, which turns every question into an escalation. The allocation-breakage pattern is familiar from any system that splits amounts across parties without traceability, exactly as described in this account of billing allocations that still break.
Why does an unexplainable charge get ignored?
Because a price nobody understands cannot influence a decision.
If a relationship manager cannot see how pricing a deal differently would change the charge, the charge is noise in their world and they will price against the customer conversation instead. Explainability is therefore not a reporting nicety, it is the mechanism by which the whole system works. The test is whether a business head can be shown a single deal, see its components, and change the outcome by changing the deal.
What must the engine store to answer a challenge?
The deal attributes used, the curve version, the component breakdown, and the methodology version, all as at origination.
Store the inputs and the decomposition alongside the result for every priced item. When somebody disputes a charge nine months later, you should be able to show which curve was in force, what tenor profile applied, and which components summed to the rate. That record ends most disputes immediately, and where it does not, it produces a specific methodology question instead of a general grievance.
How should the engine be architected?
As a deal-level pricing service that locks a rate at origination and revalues only where methodology intends it.
Price at origination, at deal level, using the curve in force at that moment, then lock it for the term of the deal so subsequent curve movement affects treasury rather than the business that already made its decision. Where a product legitimately reprices, model that explicitly rather than by refreshing everything. Then keep the engine callable at pricing time, because the highest-value use of FTP is not the monthly report, it is a relationship manager seeing the funding cost before quoting. That means an API with latency low enough for a pricing screen, which makes it an operational service rather than a finance batch job.
Deal level or portfolio level?
Deal level, always, with aggregation performed afterwards for reporting.
Deal-level attribution allows portfolio reporting, and portfolio-level attribution allows nothing else. It is also the only way to support pricing decisions, because a relationship manager needs a number for the deal in front of them. Volume is rarely the obstacle: pricing is a small calculation per deal, and the engineering work is in the data quality that makes each deal's attributes trustworthy, which is the same underlying constraint described in this guide to improving data quality across legacy systems.
How do you price products with no contractual maturity?
Through a behavioural tenor profile drawn from the same assumptions the ALM system uses.
A stable core deposit balance provides term liquidity even though it is contractually overnight, and pricing it at an overnight rate systematically under-rewards the business that gathered it. Split the balance into behavioural tranches with different tenors, apply the appropriate premium to each, and take the tranche profile from the same assumption store the ALM platform uses. Sharing that store is not optional. When ALM and IRRBB assumptions diverge from FTP assumptions, the bank prices deposits against one view of behaviour and reports risk against another, and the reconciliation between them becomes a permanent unresolved argument.
Which curves does the engine need, and who owns them?
A small set of authoritative curves with one named owner, one publication schedule, and versioned history.
Curve proliferation is the quiet failure mode: a treasury curve, a planning curve, an ALM curve, and a pricing curve that differ slightly and are each defended by a different team. Consolidate to one authoritative set, publish on a defined schedule with a version identifier, retain every historical version, and require every consumer to record which version it used. Where genuinely different curves are needed, for different currencies or funding programmes, make the difference explicit and documented rather than incidental. The intraday cash reality that validates those curves comes from the real-time treasury platform, which is where actual funding behaviour becomes observable.
Running four slightly different funding curves owned by four different teams?
How do you make results explainable to the business?
With a decomposition view per deal and per portfolio, plus a movement explanation between periods.
Give every user two things. First, a component breakdown for any deal or portfolio: base rate, term premium, contingent liquidity, basis, optionality, and any other charge, each with its value and the input that drove it. Second, an explanation of period-on-period movement attributed to volume, mix, curve movement, and methodology change. Those two views convert the monthly meeting from a dispute into a business conversation, because the debate moves from whether the number is right to what the business should do about it. Configuration matters here too: methodology should be versioned configuration rather than code, in the same way a well-built rating engine keeps pricing rules out of application logic so they can be changed and tested by the people accountable for them.
How does FTP change behaviour, and how do you know it worked?
Through visible pricing at origination, and you measure it by watching what the business actually books.
The purpose is behavioural, so measure behaviour. After the engine is in place and explainable, look for shifts in the tenor mix of new lending, in the deposit gathering effort by product, and in how often relationship managers query a rate before pricing rather than after invoicing. If none of those change, the signal is not reaching the decision, and the cause is almost always that the rate arrives too late or cannot be explained. Adoption is the metric that matters, not calculation coverage.
How do you change methodology without destroying comparability?
By versioning methodology, preserving locked historical rates, and publishing a bridge between old and new.
Methodology will change, because the balance sheet, the funding environment, and the regulatory framework all change. Handle it the same way you would a pricing model change: version the methodology, never retrospectively alter rates already locked to deals, restate a prior period under both versions for one reporting cycle, and publish the bridge so business units can see exactly what moved because of methodology rather than performance. Skipping the parallel period is what convinces business heads that FTP changes are a way of moving profit between units, and that impression takes years to undo.
How should delivery be phased?
Curves and data first, then deal-level pricing for the largest products, then explainability, then pricing-time integration.
| Phase | Duration | Deliverable |
|---|---|---|
| Curve and data foundation | 2 to 4 months | Authoritative curves, versioning, deal attribute sourcing |
| Deal-level pricing for major products | 3 to 4 months | Origination pricing and rate locking for lending and deposits |
| Behavioural profiles | 2 to 3 months | Shared assumption integration for non-maturity products |
| Explainability and movement analysis | 2 to 3 months | Component decomposition, period-on-period attribution |
| Pricing-time integration | 2 to 3 months | Callable service in origination and relationship tooling |
| Methodology governance | Ongoing | Versioning, parallel restatement, committee process |
Note that explainability sits before pricing-time integration deliberately. Pushing an unexplainable rate into a relationship manager's screen accelerates rejection of the whole system rather than adoption of it.
Which metrics prove the engine is working?
Coverage of balance sheet priced at deal level, dispute volume and resolution time, query-before-pricing rate, and behavioural shift in new business mix.
Track the share of assets and liabilities priced at deal level rather than allocated, which is the credibility base. Watch dispute volume and, more importantly, how long a dispute takes to resolve, since a good decomposition view should make most of them a five-minute conversation. Measure how often the engine is called at origination rather than in the monthly cycle, because that ratio tells you whether FTP is a pricing tool or a reporting artefact. And follow the tenor and mix of new business, since a working transfer pricing system should visibly change what the bank chooses to write.
Funds transfer pricing is one of the few internal systems whose success is measured entirely by whether people outside finance change their behaviour. That makes explainability the primary engineering requirement, and it is why the most sophisticated methodology in the bank is worth less than a rate a business head can see, question, and act on.
Frequently Asked Questions
What is a funds transfer pricing engine for?
It charges business units for the funding they use and credits them for the funding they raise, so unit profitability reflects the real economics of the balance sheet rather than a flat internal rate.
Why do supervisors care about internal pricing?
Because allocating liquidity costs, benefits and risks to significant business activities is a supervisory expectation. Internal pricing is how a bank makes those costs visible where decisions are made.
What causes most FTP disputes?
Unexplainable charges. When a business head cannot see which components produced a rate, the debate becomes political and the pricing signal stops influencing behaviour.
Should attribution be at deal level or portfolio level?
Deal level, priced at origination and locked for the deal's term. Portfolio averages hide exactly the differences FTP exists to reveal.
How do you price deposits with no contractual maturity?
Using the same behavioural assumptions the ALM system uses, applied through a tenor profile rather than an overnight rate, so stable balances receive credit for the term liquidity they genuinely provide.
What components belong in an FTP rate?
A base reference rate, a term liquidity premium, contingent liquidity cost, basis and optionality costs where relevant, and any regulatory cost the business genuinely drives.
How do you change methodology without breaking comparability?
Version the methodology, keep locked historical rates intact, restate prior periods under both versions for one reporting cycle, and publish the bridge between them.
Why must FTP and ALM share assumptions?
Otherwise the bank prices business against one view of behaviour and reports risk against another, and no amount of reconciliation will make the two conversations agree.
