In a challenging environment where interest rates are low and credit risk elevated, the ability to price loans correctly is critical in determining a bank’s profitability. Ensuring the necessary level of interest margin, banks need to incorporate traditional contribution margins – cost components like credit and market liquidity, as well as new ones stemming from mounting regulatory costs – into calculations and analyses. The emergence of virtual banks built on state-of-the-art technological architecture puts additional pressure on incumbents running on less scalable and agile infrastructure. 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 methodologies of risk-adjusted pricing diverge, economic value added (EVA) is understood as 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 treasury and credit risk departments of lending institutions. Getting the measurement right – being sure profits outweigh costs – is more difficult when a transaction is large and/or complex.
The components of EVA are well known: net profit P reduced by cost of capital employed to generate it, C. Its variant RARORAC, or risk-adjusted return on risk-adjusted capital, is 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 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, (interest rate) that initially would be set on the loan, and the reference rate (cost of funds), at which a treasury department can finance itself.
Fees represent additional income to cover expenses of transactions ranging from residential mortgages to complex infrastructure projects.
Credit risk, is one of the most important determinants of profitability. The yardstick is that interest rate charged should at least cover credit risk. It can be calculated in line with models used in accounting standards (CECL – US system or ECL – 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, 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 should incorporate explicit (embedded caps, floors etc.) and implicit (prepayment) factors governing how interest rate is set. The credit risk costs and other components should be calculated per period, accounting for 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.
Additional to the credit spread, the FTP system should 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 should be considered where relevant.
Estimating funding costs is the treasury’s role. If a system in place assumes 100% of a transaction is financed by debt, then it’s necessary to calculate an equity credit to adjust for any portion of a transaction not financed by debt. In the case of RAROC as 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) calculated for the whole portfolio, and the marginal VaR contribution of the new transaction computed).
Because FTP calls for know-how across many factors, from credit risk to financial controlling to treasury, and asset and liability management, there’s a chance that the calculation will be broken down among several systems and departments within a bank, instead of in a unified, cohesive fashion. This greatly impedes the institutions’ business operations and ability to price new loans in response to market developments. It can obscure how and why a particular interest rate was set on a certain type of loan. Profitability analysis may become inefficient, which puts the bank itself at risk.
It is better that a single FTP system performs this function, and includes:
- 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’s therefore essential 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, estimated cash flows and 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 the financial and risk results of the calculation can circulate back and forth. In cases where 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.
Join Wolters Kluwer at RiskMinds International this December!
This article was first published on Wolters Kluwer.