Treasury and ALM Implementation: What UAT Misses on EVE, FTP and HQLA

Treasury and ALM implementations carry a specific risk that other core banking domains do not: the business impact of a misconfiguration is not immediately visible. A wrong DSCR computation fails within a reporting cycle. A wrong FTP rate assignment, or an EVE sensitivity calculated under an incomplete interest rate scenario set, may produce numbers that look plausible and go unchallenged for months — until a regulatory inspection or an ALCO review surfaces the discrepancy.

The test coverage gaps in Treasury and ALM UAT are almost always in the same three places: FTP method validation, EVE sensitivity under the full Basel III scenario set, and India-specific HQLA classification and treatment under the LCR computation. Each of these requires domain knowledge that is rarely present in a delivery team.

Fund Transfer Pricing: Method, Not Just Rate

Fund Transfer Pricing is the mechanism by which a bank allocates the cost of funds to business units — in effect, the internal price at which a lending unit buys funds from treasury. Getting this right matters because FTP rates directly affect business unit profitability reporting, pricing decisions, and ALCO strategy.

There are three FTP methods in common use: single pool (one rate applied to all assets and liabilities), tenor-banded (rates differentiated by maturity bucket), and matched maturity (each transaction matched to a specific funding source with a corresponding rate). The method choice is a configuration decision that determines how the system derives FTP rates. It is also the thing that is most commonly not tested.

What FTP UAT typically covers

A standard UAT test case confirms that an FTP rate is applied to a loan or deposit product. The rate appears in the reporting output. The test passes. What is not confirmed is whether the rate is derived from the correct method, whether the tenor band applied matches the product's maturity, and whether a matched-maturity product is being correctly paired with its funding source rather than defaulting silently to a single-pool rate.

EVE Sensitivity: NII Is Not Enough

Economic Value of Equity sensitivity measures the impact of interest rate changes on the present value of the bank's balance sheet. It is a core IRRBB measure required under RBI's guidelines on interest rate risk in the banking book. NII (Net Interest Income) sensitivity, which measures the impact on near-term income, is more familiar to credit teams and gets tested first and most thoroughly.

EVE is systematically undertested. The most common gap is that UAT covers EVE under a parallel upward shock — rates increase uniformly across all tenors. The full Basel III standardised framework specifies six interest rate shock scenarios:

• Parallel up
• Parallel down
• Steepener (short rates fall, long rates rise)
• Flattener (short rates rise, long rates fall)
• Short rate shock up
• Short rate shock down

The RBI outlier test — which identifies banks whose EVE falls by more than 15% of Tier 1 capital under the most adverse scenario — requires the EVE to be computed under all six scenarios to determine which is most adverse. A system tested only under the parallel upward shock has not been tested in a way that would reveal whether the outlier test would be triggered.

HQLA Classification: India-Specific Treatment

The Liquidity Coverage Ratio computation requires a classification of assets into High Quality Liquid Assets at Level 1 and Level 2, with specific haircuts applied at each level. The classification rules under RBI's LCR framework differ in important respects from the Basel Committee's standard — and these differences are consistently the source of misconfiguration in Indian bank implementations.

Three India-specific HQLA treatment points that UAT misses

• SLR excess as Level 1 HQLA — Government securities held in excess of the mandatory SLR requirement qualify as Level 1 HQLA under RBI's framework. The boundary between mandatory SLR and the excess eligible for LCR must be correctly computed and classified; systems that treat all G-Sec holdings as Level 1 without applying this boundary will overstate the LCR
• Facility to Avail Liquidity for Liquidity Coverage Ratio (FALLCR) — RBI permits banks to include a portion of their mandatory SLR holdings as HQLA through the FALLCR facility, subject to a defined limit. This treatment is India-specific and requires a specific configuration that is frequently omitted from the initial implementation scope
• State government securities treatment — State Development Loans (SDLs) are classified as Level 2B HQLA under RBI's framework, not Level 1. Systems that classify all sovereign paper at Level 1 without distinguishing central government securities from SDLs will miscalculate the LCR

NSFR: Behavioural Assumptions Are Not Self-Evident

The Net Stable Funding Ratio measures the adequacy of stable funding sources against the stable funding required by the bank's asset profile. Unlike LCR, which is computed on a point-in-time basis, NSFR requires behavioural assumptions about the stability of deposits — in particular, the split between stable and less-stable retail deposits, and the treatment of operational deposits from corporate customers.

These behavioural assumptions are bank-specific, require ALCO approval, and must be correctly parameterised in the system. UAT plans rarely test whether the parameterisation matches the approved assumptions. They test whether the NSFR ratio is computed — not whether it is computed using the right behavioural inputs.

The Domain Distance Problem in ALM UAT

Treasury and ALM is a domain where the gap between delivery-team knowledge and business-user knowledge is wider than in most other banking areas. The team implementing an ALM system on Oracle OFSA or Murex may have strong platform expertise and limited understanding of what EVE is supposed to measure or why matched-maturity FTP requires a different test approach than single-pool FTP.

The consequence is a UAT register that is comprehensive on the system side — every screen is tested, every report runs, every computed field is verified — and thin on the business-logic side. The scenarios that test whether the system is computing the right thing, using the right method, with the right inputs, are the ones that are missing.

Bankly's Treasury and ALM Consulting practice provides functional domain support for teams implementing IRRBB, LCR, NSFR, and FTP on Murex, Oracle OFSA, Temenos, and custom builds — including UAT plan review, ready-to-use test cases covering EVE, FTP, and HQLA scenarios, and on-project consulting during the testing phase.