In a challenging environment in which interest rates are low and credit risk remains elevated, the ability to price loans correctly is a critical factor in determining a bank’s profitability. To be able to ensure the necessary level of interest margin, banks need to incorporate traditional contribution margins – cost components such as credit and market liquidity, as well as relatively new ones stemming from mounting regulatory costs – into their calculations and analyses. The emergence of virtual banks built on state-of-the-art technological architecture puts additional pressure on incumbents running on infrastructure and applications that are less scalable and agile. Due to its reliance on collaboration among key functions like Risk and Finance, Funds Transfer Pricing (FTP) is deeply affected by these risk management and technological aspects.
Although the methodologies of risk-adjusted pricing diverge, economic value added (EVA) is widely understood to be a key measure of economic profit for a firm and, at a more granular level, a single transaction. Measuring EVA is carried out daily by the treasury and credit risk departments of lending institutions. Getting the measurement right – being sure profits outweigh costs – is even more difficult when a transaction is large and/or complex.
The components of EVA are well known: it is simply the net profit P reduced by the cost of capital employed to generate it, C. Its variant RARORAC, or risk-adjusted return on risk-adjusted capital, is generally defined as P/EC where EC is the economic capital used (P = RARORAC * EC = EVA + C). If we define the net profit as P = spread + fees – expected losses – cost of operations, then:
An FTP system greatly facilitates the ability to break out and quantify the cost components of a proposed transaction, providing an estimate of its profitability, if any. In the formula above, the spread is the difference between the external rate, or the interest rate that initially would be set on the loan, and the reference rate or cost of funds, the rate at which a treasury department can finance itself.
Fees represent additional income to cover the expenses of transactions ranging from residential mortgages to complex infrastructure projects.
Credit risk, of course, is one of the most important determinants of profitability. A rule of thumb is that the interest rate charged should at least cover credit risk. It can be calculated in line with models used in accounting standards – CECL under the American system or ECL under the international IFRS 9 system – or included in the FTP system as a spread based on the probability of default and loss given default estimated for the customer. Whatever method is chosen, there must be a time bucket system in place to project how income will change and impact the cost components in each bucket, as required under the two accounting standards.
The projection and slotting of cash flows within the bucketing is essential, and it should incorporate explicit (embedded caps, floors etc.) and implicit (prepayment) factors governing how the interest rate is set. The credit risk costs and the other components should be calculated per period, taking into account the variability of these cash flows and of the underlying market. The advantage of calculating an expected credit loss at this stage is that it should be very close to the provision amount, and therefore of P&L losses that will be booked against the new loan.
In addition to the credit spread, the FTP system should be able to add any other risk components, such as liquidity costs, with a curve-matching technique if required. The liquidity costs of any optionality in the contract also should be considered where relevant.
Estimating funding costs is the role of the treasury department. If a system in place assumes that 100% of a transaction is financed by debt, then it is necessary to calculate an equity credit to adjust for any portion of a transaction that is not financed by debt. In the case of RAROC in the formula above, one may divide into the share of equity allocated to financing the transaction according to the funding structure of the company as a whole, or of the business unit financing the loan; for RARORAC, the capital used will relate to the risk of the transaction by following a regulatory approach (capital charge calculated under a standardized or internal-ratings-based model under the Basel framework) or an economic approach (a credit value at risk (VaR) is calculated for the whole portfolio, and the marginal VaR contribution of the new transaction is computed).
Because FTP calls for know-how on a range of factors, from credit risk to financial controlling to treasury, and asset and liability management, there is a chance that the calculation will be done piecemeal, broken down among several systems and departments within a bank, instead of in a unified, cohesive fashion. This greatly impedes the business operations of the institution and its ability to price new loans in response to market developments. It also can obscure how and why a particular interest rate was set on a certain type of loan. The profitability analysis may become inefficient, which puts the bank itself at risk.
It is far better that a single FTP system performs this function. Its capabilities should include:
- The modeling of cash flows.
- The pricing of the debt funding portion of a loan using several types of curve-matching techniques by accounting for costs such as liquidity and embedded options, as well as overheads.
- The calculations of credit costs, ideally in line with US GAAP (CECL) or international accounting standards (IFRS 9).
- The calculation of capital requirements under standardized and internal-ratings-based approaches for a specific transaction.
- The calculation of a portfolio VaR for calculating economic capital.
The use of curves for setting the reference rate on both sides of the balance sheet implies sensitivity to current market data. It is essential, therefore, that data used for pricing is available and can be used immediately, even for intra-day calculations. Interpolations and manipulations of yield and swap curves should be supported. The application should be placed at the center of a process that connects front and back offices. When a loan is being considered, the estimated cash flows and the calculated contribution margins should quickly be made available to the loan officer for further analysis and contractual negotiations, and then sent to the middle office accounting system upon approval.
The pricing system should be integrated into an application programming interface (API) ecosystem to ensure that the financial and risk results of the calculation can circulate back and forth. In cases in which several versions of a proposed deal exist in the infrastructure, it must be possible to retrieve and compare them with the final version. In the contract life cycle, cash flows will have to be calculated again as required by accounting and other business processes. To ensure consistency with the original assessment, the same system should be used in every case.
FTP, and the topic of risk-adjusted pricing in general, has never been so relevant to banks. It is vital in ensuring a minimum threshold of profitability, while integrating the pricing process into modern and scalable architectures.
