Untere Bruech 109, CH - 8706 Meilen
+41 44 586 66 18
info@imberg-consulting.com

Funds Transfer Pricing (FTP)

Risk. Treasury. Regulatory. Controlling. Accounting.

Imberg RaPID© is an integrated software for internal quantitative risk management (interest, liquidity, credit, market), balance sheet management and simulation, Liquidity at Risk (LaR), EBA/ECB regulatory reporting, IFRS (7, 9, 13), limit management, intraday liquidity (BCBS 248) and treasury for banks and insurance companies. RaPID is web based and uses an Oracle database (SE or EE). RaPID can be installed on site or operated as SaaS (Software as a Service). It is built for high data volumes and supports massive parallel processing.

The current facts sheet treats the funds transfer pricing (FTP) – other facts sheets exist for other areas.

Problem at hand

  • How to measure the profit or loss of operations, e.g., how can we decide that loss should be counted as a loss on the loans, a loss on the savings accounts or a loss to the fixed-income trading desk.
The assignment of this profit and loss is important:
  • It determines the risk and profitability of each business unit (BU).
  • It determines the price that the bank should charge its customers.
  • It can be a basis for remunerating staff,
  • It can determine whether certain business units must be enhanced, restructured, or closed.

What is FTP about

  • Transfer pricing is a framework of internal transactions and payments between BUs.
  • Funds-transfer pricing can be viewed as the interest payments charged when one unit lends funds to another.
Thus:
  • FTP is an income adjustment made to the bank’s balance sheet to reflect funding cost impact.
  • It is also the structure of funds-transfer pricing which moves interest-rate and liquidity risks between units.
  • The transfer payments significantly affect the measured accounting profitability of each unit.
  • By affecting the measured profitability, we affect the prices that each unit must charge to its customers, and we affect the bonuses of the staff.
  • If one unit is forced to pay a higher transfer price to another unit, the first unit’s measured profitability will fall, their bonuses will be reduced, and senior management may decide to scale back the activities of the less-profitable unit.
  • In this chapter, we are concerned only with funds-transfer pricing.
  • The transfer payments significantly affect the measured accounting profitability of each unit.
  • By affecting the measured profitability, we affect the prices that each unit must charge to its customers, and we affect the bonuses of the staff.
  • If one unit is forced to pay a higher transfer price to another unit, the first unit’s measured profitability will fall, their bonuses will be reduced, and senior management may decide to scale back the activities of the less-profitable unit.
  • To enable transfer pricing, an intermediary through which transactions flow must be created within the bank (treasury, central office or ALM).
Roles of the BUs:
  • All the fund-raising units raise funds from the market at a particular rate and lend the same to the central office at a higher rate.
  • All the lending units borrow the funds from the central office at a particular rate and lend the same to the borrowers at a higher rate.
  • The trading unit sits between fund-raising (from its profits) and fund using (to trade or compensate losses).
  • The central office rate is notional in nature and aligned to market conditions.

Thus, for all the units, two rates are available to measure their performance:

  • For a fund-raising unit, the difference between interest paid to the deposit-holders or bond holders and interest receivable from central office is the contribution to the bank’s profitability.
  • For a lending unit, the difference between interest payable to central office and the interest received from the borrowers is the contribution to the bank’s performance.
  • A typical situation in a universal bank is that the retail banking group takes in deposits and lends them out to retail customers.
  • The amount of deposits generally exceeds retail loans, so the excess is given to the bank’s ALM desk.
Process:
      • The ALM desk takes the excess funds from the retail unit and lends them out.
      • It may lend them to another bank in the interbank market or to another group within the bank, such as commercial lending or the trading group.
      • In return for providing these funds, the retail group receives some interest payments from the ALM desk.
      • In the traditional framework, the transfer rate for these interest payments is typically either the overnight interbank rate or the retail deposit rate, plus a small spread to cover operating expenses.
FTP is used for
    • measuring ex-post (historically) 
    • deciding about deal making (application process)
    • and ex-ante (future looking)
Following rules are recommended:
Rule 1:
  • The funding requirements for all transactions are considered to go through the ALM desk (see diagram)
  • Notice that the BUs do not just go to the ALM desk for their net requirements. 
  • Each BU gives all of its deposits to the ALM desk to be invested at market rates, and goes to the ALM desk for all its funding requirements if it wishes to make loans
Rule 2:
  • For every transaction, there is an agreement between the BU and the ALM desk about the terms of the fictitious asset or liability.
  • These terms are the same as would be agreed between the bank and an external counterparty.
  • The terms specify the amount, the repricing frequency, the time for final repayment of the principle, any amortization, any prepayment options, and the rate, which is the current market rate
  • These terms should mirror the interest-rate characteristics of the BU’s transaction with the customer.
 Rule 3:
  • For each transaction, the BU receives a fictitious asset (liability) and the ALM desk receives the opposite fictitious liability (asset).
Rule 4:
  • The trading unit is a special case.
  • Like the other units, any transaction between the trading unit and the ALM desk has the price fixed according to the effective maturity of the loan.
  • But, unlike the other BUs, the trading unit has access directly to the interbank market and is not required go to the ALM desk to match every transaction.
  • For risk-measurement purposes, any fictitious liability that the trading unit has goes into the trading VaR calculator, and the corresponding fictitious asset goes into the ALM simulation.

Additional software components

  • ETL (extract transform load) for data interfacing to core or trading systems 
  • SQL interface / List generator
  • Self-service dashboarding / Excel to web reporting
  • Pivot tables / OLAP cubes

Technical requirements

  • Server: Windows or Unix
  • Database: Oracle XE, SE, and EE
  • Edge, Firefox, and Chrome

Additional features

  • Job control for workflow automation
  • Audit trail