Interest Rate Management

The invisible steering wheel behind lending, deposits, pricing, and profitability

Interest rate management is the discipline that decides how the bank sets, changes, applies, monitors, and controls interest rates across loans, deposits, overdrafts, cards, treasury products, and internal funding. A customer may see only a savings rate, mortgage rate, overdraft rate, credit-card APR, or loan instalment. The bank sees a larger machine: reference rates, margins, floors, caps, repricing dates, yield curves, cost of funds, liquidity, net interest margin, risk appetite, conduct obligations, accounting, and customer communication.

A bank can have excellent products and still lose money if rate management is weak. If lending rates do not respond to funding cost, margin falls. If deposit rates move too slowly, customers leave. If floating-rate resets are wrong, customers are harmed and income is misstated. If rate changes are not communicated properly, complaints and remediation follow. If finance, treasury, product, and core banking systems use different rates, the bank cannot trust its own numbers.

Interest rate management is both a product capability and a balance-sheet discipline. Product teams care about competitive pricing and customer outcomes. Treasury cares about funding cost, liquidity, transfer pricing, and interest-rate risk. Finance cares about accrual, accounting, margin, and reporting. Risk cares about affordability, stress, conduct, and model assumptions. Operations care about effective dates, notices, exceptions, and corrections. Technology must make these rules deterministic, auditable, and resilient.

This chapter explains interest rate management in consumer and business banking from a functional implementation view. It covers reference rates, administered rates, fixed and floating pricing, rate curves, FTP, repricing, accrual, margin, floors, caps, customer notices, ALM, controls, data models, event flows, testing, production support, and real banking scenarios.

Learning objectives

By the end of this chapter, you should be able to explain how banks manage interest rates, what reference rates and administered rates are, how fixed and floating rates differ, how margins are added, how rate resets work, how FTP influences pricing, how accrual engines calculate interest, how product and treasury views connect, how customer notices are controlled, and how interest-rate changes should be tested.

You should also be able to identify common failures: stale benchmark rates, wrong effective dates, inconsistent day-count conventions, floating-rate resets missed by batch, floors and caps applied incorrectly, customer notices not sent, product rates changed without approval, deposit rates not aligned with pricing strategy, and finance accruals that do not tie to customer balances.

What interest rate management means

Interest rate management is the controlled handling of rates from source to customer account and financial reporting. It includes rate sourcing, rate approval, rate publication, product mapping, customer contract mapping, repricing, accrual, billing, statements, treasury reporting, risk measurement, customer communication, and correction handling.

Some rates are external reference rates. These may include central bank policy rates, overnight rates, interbank reference rates, treasury curves, swap curves, market indices, or other official or market benchmarks used in a jurisdiction. Some rates are internal administered rates, such as a bank's standard savings rate, base lending rate, mortgage product rate, overdraft rate, card purchase APR, or promotional deposit rate. Some rates are customer-specific, such as an approved loan margin, negotiated business deposit rate, or relationship pricing concession.

The functional challenge is not merely storing rates. The challenge is deciding which rate applies to which balance, on which day, for which customer, under which contract, with which margin, floor, cap, compounding rule, day-count convention, tax rule, fee interaction, statement wording, and accounting treatment.

Interest rate management should be governed because errors compound. A one-basis-point error on a large commercial portfolio can be material. A wrong mortgage reset can harm thousands of customers. A stale savings rate can damage trust. A missing customer notice can create regulatory exposure. The implementation should treat rate logic as financial control logic, not display content.

Reference rates, administered rates, and customer rates

A reference rate is a rate sourced from an external or formally governed internal benchmark. Floating-rate loans may use a benchmark plus margin. Treasury may use curves to calculate FTP. Risk models may stress portfolios using benchmark paths. Reference rates need source, publication time, calendar, currency, tenor, fallback rule, revision rule, and effective date.

An administered rate is a rate the bank sets by policy or product decision. Savings rates, standard variable mortgage rates, overdraft rates, base lending rates, and promotional deposit rates are common examples. These rates may respond to market movement, competitor behaviour, funding strategy, liquidity need, or product campaign. They need approval workflow, effective date, publication, customer communication, and channel alignment.

A customer rate is the actual rate applied to a customer account or facility. It may be reference rate plus margin, product rate minus concession, promotional rate for a period, tiered deposit rate, penalty rate after default, or fixed rate for a contracted term. Customer rate records must preserve the reason and version because servicing teams need to explain them later.

The bank should never rely only on a label such as current rate. It should know rate type, source, component rates, margin, spread, floor, cap, tier, effective date, expiry, reset frequency, next reset date, approval, customer notice, and account coverage. Without that, rate inquiries and remediation become archaeology.

Fixed, floating, variable, and tiered rates

A fixed rate is contractually set for a defined period. It gives the customer certainty and gives the bank interest-rate risk if funding cost changes. A fixed-rate personal loan may have one rate for the full term. A mortgage may be fixed for two, five, or ten years and then move to a variable rate. A fixed business loan may require break-cost calculation if prepaid before maturity.

A floating rate moves according to a reference rate plus or minus a margin. A business loan may be priced at benchmark plus 250 basis points. A mortgage may reset monthly or quarterly. A floating rate requires reference-rate sourcing, reset calendar, lookback or observation rule, margin, floor, cap, customer notice, and schedule recalculation.

A variable or administered rate is changed by the bank according to product terms and governance, not by automatic benchmark formula alone. Savings rates and standard variable lending rates often work this way. The bank must decide who can change the rate, what approval is needed, which customers are affected, when notice is required, and how channels display the change.

Tiered rates apply different rates to balance bands or product conditions. A savings account may pay one rate up to a threshold and another rate above it. A business deposit may pay negotiated rates by balance. A loan may have risk-based pricing by score band. Tiering requires clear calculation rules: marginal tiers, whole-balance tiers, blended rates, effective dates, and statement disclosure.

Margins, spreads, floors, and caps

The margin is the bank's spread above or below a base rate. For lending, margin compensates for credit risk, capital, operating cost, liquidity, term, collateral, customer relationship, and target return. For deposits, spread reflects funding value, liquidity need, product strategy, and market competition. The margin must be tied to product, customer, approval, and effective date.

Floors and caps control rate movement. A floor prevents a rate from falling below a minimum. A cap prevents it from rising above a maximum. A loan may have benchmark plus margin, subject to floor and cap. A deposit may have a promotional minimum for a period. Floors and caps need careful ordering: the bank must define whether the floor applies to benchmark, total rate, margin, or customer rate.

Negative rates create special complexity. Some markets have experienced negative benchmarks. Product terms may or may not allow customer lending rates or deposit rates to go below zero. The platform should not assume all rates are positive. It should define how negative reference rates interact with margins, floors, caps, accrual, statements, tax, and customer communication.

Rate concessions must be governed. A relationship manager may offer a better business loan margin. A retention team may offer a mortgage discount. A treasury desk may approve a negotiated deposit rate. Each concession should have authority, expiry, reason, profitability impact, and renewal rule. Otherwise pricing leakage hides inside customer-specific overrides.

Funds transfer pricing and product profitability

Funds transfer pricing, or FTP, is the internal price treasury charges or credits business lines for funding. Lending products consume funds and are charged an internal funding cost. Deposit products provide funds and may receive an internal credit. FTP allows product teams to understand profitability after funding cost, not only customer interest.

FTP depends on term, currency, liquidity, optionality, behavioural maturity, interest-rate profile, prepayment risk, and balance stability. A thirty-year mortgage funded by short-term deposits has interest-rate and liquidity implications. A stable current-account balance has more funding value than a temporary promotional deposit that may leave next month.

Product profitability should combine customer rate, FTP, expected credit loss, operating cost, capital cost, fees, servicing cost, acquisition cost, and expected life. A loan that looks profitable on headline margin may be unattractive after funding cost and credit loss. A deposit that appears expensive may still be valuable if it provides stable funding.

Technology should not force treasury FTP into product pricing manually. The pricing engine should consume approved FTP curves or assumptions, store the version used, and allow analysis of pricing at approval date versus actual life. Finance and product should be able to reconcile net interest margin by product, segment, and vintage.

Rate curves and benchmark operations

Rate curves represent rates by tenor and currency. Treasury, pricing, risk, and valuation processes may use overnight, one-month, three-month, six-month, one-year, swap, government, or internal curves. Consumer systems may not expose curves directly, but the impact appears through mortgage rates, deposit rates, loan pricing, and FTP.

Benchmark operations require calendars and cut-offs. A rate may be published on business days only. A product may use previous business day, same day, month-end, observation period, lookback, lockout, or average rate. Some benchmarks can be revised. Some may be unavailable. The bank needs fallback rules before outages happen.

Rate ingestion should be controlled. The platform should capture source, rate, currency, tenor, publication timestamp, ingestion timestamp, validation status, approval status, and effective date. It should detect missing rates, duplicate rates, outliers, stale rates, future-dated rates, and rates outside tolerance. Manual rate entry should require maker-checker and reason.

Rate publication should be event-driven. Once an approved rate is available, dependent products, pricing engines, accrual engines, channels, and reporting systems should receive the update. If downstream systems fail, the bank needs an exception queue. A rate loaded in treasury but not in the core banking system can create customer and accounting errors.

Repricing and reset lifecycle

Repricing is the process of changing the customer rate according to contract, product, or bank decision. A fixed-rate loan may reprice at the end of fixed period. A floating-rate loan may reset monthly. A savings account may change when the bank updates administered rates. A business facility may reprice after annual review or covenant change.

A rate reset should identify affected accounts, current rate, new rate, effective date, reason, source rate, margin, floor, cap, schedule impact, customer notice, accounting impact, and exception status. The platform should not simply overwrite the rate. It should create a rate history so servicing can explain why the rate changed.

Schedule recalculation is often needed. If a loan rate changes, the bank may recalculate instalment, term, balloon amount, interest-only payment, or maturity. The contract defines which variable changes. Some products keep payment fixed and change term. Others keep term fixed and change payment. Business loans may bill interest separately. The schedule engine must reflect product rules.

Repricing failures should be visible. Missed reset, duplicate reset, wrong benchmark, wrong margin, failed notice, schedule mismatch, and GL mismatch should route to owned exception queues. The bank should know financial impact and customer impact immediately.

Interest accrual and posting

Interest accrual calculates earned or payable interest over time. For loans, interest income accrues as the borrower uses money. For deposits, interest expense accrues as the bank uses customer funds. Accrual depends on balance, rate, value date, day-count convention, compounding, payment frequency, non-accrual status, tax, and rounding.

Day-count conventions matter. Actual/365, actual/360, 30/360, and market-specific conventions can create different interest amounts. A product should define its convention. The accrual engine, statement engine, pricing engine, payoff quote, and GL should use the same convention. Differences create reconciliation breaks and customer disputes.

Interest posting is the act of applying accrued interest to customer account or GL. Loan interest may post monthly, at payment due date, at maturity, at payoff, or on demand. Deposit interest may post monthly, quarterly, annually, or at closure. Business facilities may accrue daily and bill periodically. The posting event should carry calculation period, rate, balance basis, amount, currency, tax, and GL mapping.

Backdated transactions complicate accrual. A backdated repayment, reversal, rate correction, or value-date adjustment may require interest recalculation. The platform should handle recalculation transparently and preserve audit. Manual interest adjustment should be controlled because it directly affects customer money and bank income.

Customer notices and conduct

Interest-rate changes often require customer communication. The exact rules depend on product, market, contract, and whether the change benefits or harms the customer. A savings rate decrease, mortgage variable-rate increase, loan reset, promotional-rate expiry, overdraft change, or default-rate application may require notice wording, timing, channel, and evidence.

Notices should be generated from the actual rate event, not manually drafted from memory. The notice should include old rate, new rate, effective date, reason where required, product, account, impact on payment or interest, customer options, and contact route. For digital channels, the same information should align with statements and account screens.

Conduct risk appears when rates are technically correct but customer treatment is poor. Examples include confusing promotional rates, hidden reversion rates, unclear tiering, late notices, misleading APR displays, unexplained business margin changes, failure to pass on rate increases or decreases according to product promises, and rate concessions removed without clear authority.

The platform should retain notice evidence. It should know who received notice, when, through which channel, what version, whether delivery failed, and whether the account was excluded. If remediation is required later, notice evidence becomes central.

Interest rate risk in the banking book

Interest rate risk in the banking book is the risk that changes in rates affect the bank's earnings or economic value. A bank may fund long-term fixed-rate loans with short-term deposits. If funding cost rises while loan rates remain fixed, margin falls. If customers prepay fixed-rate loans when rates fall, expected income changes. If deposits reprice faster than assets, earnings can move sharply.

ALM teams monitor repricing gaps, duration, sensitivity, earnings at risk, economic value of equity, basis risk, optionality, and behavioural assumptions. Product systems feed ALM with balances, rates, maturity, repricing dates, behavioural maturity, prepayment assumptions, and customer segments. If product data is poor, ALM measurement is weak.

Interest-rate risk is not only treasury's problem. Product design creates it. A campaign offering long fixed-rate loans, a large volume of instant-access deposits, or a business portfolio linked to a benchmark can change the balance-sheet profile. Product, treasury, finance, and risk need aligned data and governance.

Stress testing should include rate shocks, curve steepening, curve flattening, basis movement, deposit beta changes, prepayment changes, and margin compression. The output should influence pricing, hedging, product limits, FTP, and risk appetite.

Data model for rate management

A functional rate-management data model should include rate source, benchmark, curve, tenor, currency, rate value, publication timestamp, effective date, approval status, product rate, customer rate, margin, spread, floor, cap, tier, concession, reset rule, notice rule, accrual rule, day-count convention, schedule impact, account rate history, and GL mapping.

The rate source record proves where the rate came from. The product rate record maps an approved rate to a product and segment. The customer rate record maps the applicable rate to a specific account or facility. The rate history record preserves previous and new values. The notice record proves communication. The accrual record proves calculation.

Rate records should be immutable once used for posting, except through controlled correction. If a published benchmark is revised, the bank should store both original and revised values and define whether recalculation is required. Overwriting history destroys audit evidence.

The model should support precision. Rates may have several decimal places. Basis points, percentages, decimal rates, APR, EAR, nominal annual rate, monthly rate, and daily rate are not the same. The platform should define representation clearly and avoid repeated conversion errors.

Functional interest-rate implementation catalogue

A world-class rate platform is a set of owned, tested capabilities. Each capability should have a business owner, source system, effective-date logic, approval workflow, event publication, audit record, exception handling, finance impact, customer impact, and regression tests. The following catalogue is written for teams that actually need to build, configure, test, and operate the platform.

Rate source onboarding

Rate source onboarding should define the rate type, product scope, customer scope, currency, effective date, approval owner, source system, downstream consumers, customer impact, finance impact, and exception owner. Runtime behaviour should be deterministic: the same approved rate, balance, date, margin, floor, cap, tier, and day-count rule should produce the same customer rate and interest amount in pricing, core banking, statements, GL, and reporting. The platform should retain before value, after value, source, actor, timestamp, reason, event ID, affected accounts, postings, notices, and reconciliation references.

For consumer products, Rate source onboarding must support transparent display, clear notices, accurate instalments, rate histories, complaint evidence, and remediation if customers are overcharged or underpaid. For business products, it must also show benchmark, margin, negotiated spread, concession expiry, facility terms, covenant or default interaction, relationship-manager explanation, and treasury impact. Testing should cover normal case, boundary dates, month-end, weekends, holidays, leap year, missing benchmark, duplicate rate, stale rate, negative rate, high rate, zero rate, backdated correction, notice failure, GL impact, statement impact, and production support retrieval.

Benchmark ingestion

Benchmark ingestion should define the rate type, product scope, customer scope, currency, effective date, approval owner, source system, downstream consumers, customer impact, finance impact, and exception owner.

For consumer products, Benchmark ingestion must support transparent display, clear notices, accurate instalments, rate histories, complaint evidence, and remediation if customers are overcharged or underpaid.

Acceptance scenarios

Role perspectives

Business analyst perspective

The BA should define rate types, source systems, effective dates, rate components, product mapping, customer mapping, floors, caps, tiering, reset rules, notice rules, accrual rules, GL mapping, exception queues, and report definitions. The BA should document examples with numbers because rate logic becomes clear only when dates, balances, rates, and rounding are tested together.

Solution architect perspective

The architect should separate rate sourcing, rate governance, product pricing, customer contract rates, accrual, posting, notices, ALM feeds, and reporting. Duplication is dangerous. If channels, core banking, pricing engines, and statements each calculate rates independently, they will drift. Architecture should provide one governed rate source and clear downstream contracts.

Developer perspective

Developers should treat rates as high-precision financial data. They should avoid floating-point money and rate errors, preserve effective dates, handle time zones and calendars carefully, and keep rate histories immutable after posting. Tests should include leap years, month-end, holidays, negative rates, zero rates, high rates, tier boundaries, rate corrections, and backdated transactions.

Tester perspective

Testers should verify benchmark ingestion, administered-rate approval, floating reset, fixed expiry, tier calculation, margin concession, floor and cap ordering, accrual calculation, posting, notices, GL, statements, channels, ALM feed, and remediation. Boundary tests are essential because most defects appear around effective dates, weekends, holidays, rate reset dates, maturity dates, and backdated postings.

Operations perspective

Operations teams need dashboards for missing rates, failed publications, reset exceptions, notice failures, posting rejects, GL breaks, and customer complaints. They need safe tools to correct rates, rerun calculations, identify affected customers, and document decisions. Manual corrections should require authority and should never erase the original rate history.

Common implementation mistakes

Treating rates as static product text

Rates are financial rules with effective dates, approvals, calculations, and customer impact. Treating them as website content creates inconsistency between marketing, channels, core banking, and statements.

Overwriting rate history

Overwriting old rates destroys audit evidence. The bank should preserve rate history and post corrections through controlled adjustments.

Confusing benchmark, product rate, and customer rate

A benchmark is not the customer rate. Product margin, concession, floor, cap, and tier rules may change the final rate. Systems should store components separately.

Missing reset calendars

Floating-rate products depend on calendars, observation dates, and reset frequency. Ignoring non-business days, holidays, and publication delays causes wrong rates.

Weak notice control

A rate change without correct notice can create customer harm even if the calculation is technically correct. Notices need evidence, retry, and exception handling.

No GL reconciliation

Interest accrual and posting must reconcile to finance. If customer balances and GL disagree, income and expense reporting are unreliable.

Manual concessions without expiry

Negotiated rates need expiry and review. Otherwise old concessions continue silently and erode margin.

Best-practice principles

Keep rates componentised: source, benchmark, margin, concession, floor, cap, tier, and final customer rate. Use effective dating everywhere. Preserve immutable history. Centralise rate governance. Test calculations with real dates and balances. Generate customer notices from rate events. Reconcile accrual and GL daily. Feed ALM and FTP from governed data. Monitor exceptions. Treat remediation as a designed capability, not an emergency spreadsheet exercise.

Practical example: floating business facility

A business facility is priced at a three-month benchmark plus a 2.25 percent margin, subject to a zero total-rate floor. The benchmark is observed two business days before the reset date. The rate resets quarterly. Interest accrues daily and bills monthly. The relationship manager has approved a 0.25 percent margin concession for one year.

The platform needs benchmark ingestion, observation calendar, margin record, concession expiry, floor logic, daily accrual, monthly billing, customer statement wording, GL mapping, and rate history. If the benchmark is missing on observation date, the facility should enter a controlled exception or use an approved fallback. If the concession expires, the rate should reset to standard margin or route for review.

Practical example: savings rate campaign

The bank launches a promotional savings rate for new deposits for six months. The rate applies only to eligible accounts opened during the campaign and only up to a balance threshold. After expiry, the account moves to standard variable rate. Customers must see promotional and reversion information clearly.

The platform needs eligibility rules, campaign rate, balance tier logic, expiry date, reversion rate, customer communication, channel display, interest accrual, tax handling, and campaign profitability reporting. If the reversion rate changes before a customer's promotional period ends, the future rate should update according to product terms without changing the promotional promise.

Interview and scenario questions

What is interest rate management?

It is the controlled process for sourcing, approving, applying, changing, calculating, communicating, and reporting rates across customer products and bank balance-sheet management.

What is the difference between reference rate and customer rate?

A reference rate is an underlying benchmark or source rate. The customer rate is the final rate applied to the account after margin, spread, floor, cap, concession, tier, or product rule.

Why is effective dating important?

Rates apply from specific dates. Without effective dating, the bank cannot know which rate applied to which balance and period, making statements, accruals, and corrections unreliable.

What is FTP?

Funds transfer pricing is the internal funding cost or credit assigned by treasury to business lines. It helps product teams measure profitability after funding economics.

Why do floors and caps matter?

They limit rate movement. Incorrect floor or cap logic can overcharge or undercharge customers and materially affect income.

Why are customer notices important?

Rate changes affect customer cost or income. Notices provide transparency, meet contractual or regulatory obligations, and create evidence that the bank treated customers properly.

What should happen when a benchmark is unavailable?

The bank should use an approved fallback or route to exception handling. It should not silently invent a rate or use stale data unless policy permits it.

Final perspective

Interest rate management is one of the quietest but most powerful disciplines in banking. It shapes net interest margin, product competitiveness, customer trust, treasury risk, finance accuracy, and regulatory confidence. A bank can make a lending decision correctly and still damage the customer if the rate resets wrongly. It can win deposits and still lose margin if funding value is misunderstood. It can publish a campaign and still create remediation if expiry rules are unclear.

World-class rate management is precise, governed, explainable, and connected. It links treasury curves to product pricing, product pricing to customer contracts, customer contracts to accrual, accrual to GL, GL to finance, and rate events to customer communication. It treats every rate as a financial promise with evidence.

The best banks do not manage rates by spreadsheet and memory. They manage rates through controlled data, effective-dated rules, tested calculations, owned exceptions, clear notices, reconciled finance, and feedback into product and treasury decisions.

Standards and authoritative references

Implementations should use current official and bank-approved sources relevant to the institution, product, and market, including:

• Local banking, consumer-credit, mortgage, deposit, disclosure, conduct, accounting, tax, and data-protection requirements.
• Official benchmark administrator publications, fallback methodologies, benchmark transition rules, and market conventions.
• Prudential guidance for interest-rate risk in the banking book, liquidity, FTP, ALM, stress testing, and governance.
• Accounting standards and bank policy for interest recognition, effective interest rate, modifications, non-accrual, fees, and hedge relationships where applicable.
• Bank-approved product terms, rate governance policy, pricing committee decisions, treasury FTP methodology, ALM assumptions, customer notice templates, and operational procedures.
• Contracts and specifications for rate vendors, market-data platforms, core banking systems, pricing engines, statement systems, and GL integrations.

Exact benchmark names, observation rules, notice periods, tax treatments, day-count conventions, fallback rules, approval authorities, and remediation requirements must always be confirmed against the current official source for the relevant jurisdiction, product, and institution.

A floating-rate reset is an effective-dated calculation

For a fictional SME line of 250,000, assume a contractual annual reference rate of 4 percent plus a 2 percent margin, Actual/365, no compounding within the period and ten days outstanding. Interest is 250,000 × 0.06 × 10/365 = 410.96 before tax and charges. If the contractual reset changes the total rate to 6.5 percent for the final five days, split the period: 250,000 × (0.06 × 5 + 0.065 × 5)/365 = 428.08. Do not apply the later rate retrospectively to all ten days.

The contract must identify the benchmark, fixing source, observation or lookback convention, reset date, spread, floor, cap and fallback. An overnight compounded benchmark is not interchangeable with a published term rate. Store publication time and corrected fixings, and define authority for recalculation. Model funding and customer repricing separately: the treasury transfer price does not amend the customer's contract.

Test a missing benchmark, negative fixing, leap year, non-business-day reset, mid-period repayment and corrected historical fixing. Reconcile accrued interest, customer posting and income; deliver any required notice at the applicable legal and contractual timing; an indexed reset does not universally require advance notice. Customer disclosure calculations remain jurisdiction-specific; see US APR calculation rules and deposit-interest rules.