Deposit beta measures how much a bank's deposit rates move when market rates change, and because that relationship is often dynamic and convex rather than fixed, modelers who rely on static vendor defaults tend to understate both interest rate risk and liquidity risk. A deposit that moves proportionally often has a beta close to the relative change in rates, but that ratio shifts as rates climb further. The defensible approach segments deposits by product and customer type, calibrates dynamic models against real data, stresses the results, and documents every assumption for examiners.
TL;DR:
- Deposit betas tend to increase during rate hikes, meaning deposit rate pass-through is often underestimated in static models calibrated during low-rate periods.
- Using a single static beta risks missing convexity, which causes deposit sensitivities to accelerate as market rates rise further, especially during high-rate cycles.
- Segmentation by product, customer type, and deposit source is essential for accurate modeling, as uninsured and brokered deposits react faster and more strongly to rate changes.
- Validating models with long-term data, stress testing across multiple scenarios, and maintaining detailed documentation are critical for examiner approval.
- Dynamic, level-dependent models better capture convexity and should be supported by frequent recalibration and automation to ensure ongoing accuracy.
Automate Regulatory Model Risk Governance
Examine models against 32 qualitative criteria and resolve risk Tiers with pre-deployment checklists per OCC 2011-12 guidelines.
Table of Contents
- What deposit beta and deposit convexity actually measure
- Comparing deposit beta modeling techniques for practical use
- Data and segmentation needed to build defensible betas
- Calibration, validation, and what examiners expect to see
- Stress testing and the effective beta concept
- What dynamic betas mean for hedging and portfolio duration
- A practical workflow for regulator-ready deposit beta models
- Where modelers still get deposit beta wrong
- How RiskInMind supports deposit beta modeling programs
- Sources
- FAQ
What deposit beta and deposit convexity actually measure
Deposit beta is the ratio of the change in a bank's deposit rate to the change in a reference market rate over the same period. If the federal funds rate rises 100 basis points and a bank's money market deposit rate rises 80 basis points, the measured beta is 0.80, or 80%. A savings account that moves only 20 basis points under the same shock carries a beta of 0.20, reflecting far weaker rate sensitivity and, by extension, longer effective duration.
The complication is that betas rarely stay constant across a rate cycle. Dallas Fed research on deposit convexity found that betas tend to rise as market rates climb higher, which shortens deposit duration precisely when a bank most needs it to hold steady. This convexity effect means a beta estimated during a low-rate environment can badly understate pass-through once rates move into higher territory, a pattern that surfaced sharply during the 2023 deposit outflows at several regional banks, when uninsured depositors moved balances quickly in response to rate and confidence pressures.
That episode also underscored why the deposit franchise itself, not just the beta number, matters to interest rate risk:
- Deposit franchise value depends on how sticky balances are across rate cycles, not just their stated maturity.
- Uninsured deposits behave differently than insured balances and often carry higher effective betas under stress.
- A model that ignores rate-level effects will systematically miss the convexity that shows up late in a hiking cycle.
Comparing deposit beta modeling techniques for practical use
Static linear regression remains the most common starting point: a single beta is estimated by regressing historical deposit rate changes on market rate changes over a fixed window. It is easy to build and easy to explain to an ALCO committee, but it assumes the relationship holds regardless of rate level or cycle stage, an assumption the Dallas Fed's convexity findings directly contradict. Static models tend to work reasonably well in stable, low-volatility periods and fail exactly when they matter most, during rapid tightening or a liquidity event.
Multivariate approaches address some of that weakness by adding volumes, repricing lags, and peer or competitor rates as explanatory variables alongside the market rate. This lets the model separate the effect of a bank's own pricing decisions from broader market movement and can improve identification when deposit flows respond to more than one driver at a time. The tradeoff is added complexity: more variables mean more assumptions to defend during validation.
Dynamic and nonlinear methods go further, allowing the beta itself to shift with rate level through regime-switching terms, splines, or interaction variables between the market rate and its own level. These specifications are better suited to capturing the convexity effect but require longer, cleaner data histories to estimate reliably, and they are harder to explain in a model documentation package.
Error-correction models, the approach detailed in Federal Reserve FEDS research on funding betas, separate short-run pass-through from a long-run equilibrium beta, using lagged funding rates alongside current and lagged policy rates. This structure tends to produce more stable long-run beta estimates, which matters for hedging decisions built on multi-year horizons rather than quarterly repricing.
Choosing among these families comes down to a few practical checks:
- Confirm the data history is long enough to span at least one full rate cycle before attempting a dynamic or error-correction specification.
- Test whether a static beta materially understates pass-through in the highest-rate subperiod of the sample.
- Segment by product before deciding on model family, since transactional and time deposits often need different specifications entirely.
- Validate that peer or competitor rate variables are not simply proxying for the same market rate already in the model.
Pro Tip: Run a static and a dynamic specification side by side on the same segment before presenting results, since the gap between them is often the clearest evidence a validator or examiner will want to see.
Data and segmentation needed to build defensible betas
A credible beta estimate depends on data granularity most institutions do not track by default. At minimum, modelers need transactional balance histories, interest credited by account, effective repricing dates, new-money flow rates, and a record of marketing or promotional rate events that could distort the pattern.
Segmentation should go beyond product type. Channel matters, since brokered and internet-sourced deposits typically reprice faster and run off more readily than relationship-based balances. Customer class matters, since retail and commercial depositors respond to rate changes on different timelines. Insured versus uninsured status matters most of all, given the run dynamics documented in FDIC research on uninsured deposits.
Behavioral inputs round out the picture:
- Decay and runoff rates need their own estimation separate from beta, since a deposit can be low-beta and still highly volatile in balance.
- Volume weighting prevents a handful of large accounts from distorting a segment-level average.
- Promotional spikes should be flagged and either excluded or modeled explicitly, since they create short-term beta noise unrelated to underlying customer behavior.
- Winsorizing extreme observations and testing sensitivity across different data windows helps confirm the estimate is not an artifact of one unusual quarter.
Calibration, validation, and what examiners expect to see
The OCC's Comptroller's Handbook on interest rate risk sets a clear bar: examiners expect bank-specific analysis of deposit performance, documented betas and decay rates by product and customer group, and evidence that management used data appropriate to the bank's own book rather than borrowed industry averages. A model built entirely on vendor defaults, without evidence tying assumptions back to the bank's actual deposit behavior, invites exactly the kind of finding no ALCO wants at its next exam.
A validation checklist that holds up under review typically includes:
- Backtesting the model against realized rate changes over at least one full cycle, not just the most recent quarter.
- Out-of-sample testing on a holdout period the model was never calibrated against.
- A sensitivity matrix showing how beta estimates shift under different data windows, segment definitions, or lag structures.
- Peer benchmarking against published statistics, such as the OCC's interest-rate-risk statistics reports, which publish repricing rates and average lives by NMD account type.
Governance matters as much as the math. Version control on model assumptions, a decision log explaining why a segment's beta changed between cycles, a named model owner, and a defined review cadence are the artifacts examiners ask for first. A data dictionary, a model change memo, and documented sensitivity runs turn a defensible model into a demonstrably defensible one.
Pro Tip: Keep the model change memo current as changes happen, not reconstructed before the exam, since examiners can usually tell the difference.
Stress testing and the effective beta concept
A measured beta describes average historical pass-through. An effective beta, the number that should drive hedging and liquidity decisions, is often higher, particularly when uninsured deposit shares are elevated. FDIC conference research models this interaction directly, arguing that uninsured deposits and run incentives justify treating the effective beta as higher than the measured beta to properly hedge liquidity risk under stress.
Building that stress view into a model program means running several distinct scenario designs:
- A parallel rate shock across the curve, testing how NII and EVE respond when every segment's beta is applied simultaneously.
- A curve-steepening scenario, since deposit repricing behavior does not always track a single point on the curve.
- A fast-ramp hiking scenario compressed into a few months rather than spread over a year, testing whether decay assumptions hold up under speed.
- A run scenario explicitly tied to uninsured deposit share, simulating accelerated outflows beyond what the historical beta would predict.
The output of this work should feed directly into delta-EVE tables that show the dollar and percentage impact of each scenario, contingency funding triggers set at specific outflow thresholds, and capital buffer recommendations sized to the gap between measured and effective beta. Convexity belongs in this math explicitly: a beta that rises with rate level should be reflected as a schedule, not a single number, when EVE and NII are recalculated under a fast-ramp scenario.
What dynamic betas mean for hedging and portfolio duration
When measured and effective betas rise, deposit duration shortens, and a bank's asset duration or hedge overlay needs to shorten with it or the balance sheet accumulates unrecognized rate risk. This is the practical link between the modeling work above and the decisions an ALCO committee actually makes each quarter.
The instrument choice depends on the gap being closed:
- Interest rate swaps can shorten effective asset duration without altering the balance sheet's composition.
- Swaptions add flexibility when the timing of a rate move, rather than its size, is the bigger uncertainty.
- Puttable long-term bonds offer a built-in adjustment if rates move sharply against the position.
- Strategic balance sheet options, such as adjusting loan or investment portfolio mix, work over a longer horizon than derivatives typically address.
Prudence margins matter here too. If a model shows meaningful uncertainty in its beta estimate, that uncertainty should show up as an add-on to the effective beta used in limits, not get absorbed silently into the base case. That shift alone can justify trimming target asset duration by a meaningful margin to keep EVE sensitivity within policy limits, since the deposit book is now repricing faster than the original hedge assumed.
A practical workflow for regulator-ready deposit beta models
A model program that survives an exam cycle tends to follow the same sequence regardless of institution size: ingest account-level data, segment by product and channel, estimate both a baseline static beta and a dynamic specification, validate against holdout data, stress the results across the scenario set above, route the outcome through formal governance, and monitor for drift as new data arrives.
The deliverables that make this defensible are consistent: a data dictionary, sensitivity matrices across segments and windows, a model change log, documented backtest evidence, and signed governance approval before the numbers reach the ALCO packet.
Where automation genuinely helps is in the repetition this cycle demands. Recalibrating betas quarterly, rerunning the full stress scenario set after each rate decision, and keeping an unbroken audit trail across every version is tedious work when done by hand and error-prone under deadline pressure. Platforms built for this kind of workflow are designed to keep that repetition reproducible rather than reinvented every quarter.
A minimum checklist for the next ALCO cycle:
- Confirm segment definitions still match current product and channel structure.
- Rerun the dynamic specification against the most recent quarter of data and compare the gap to the static estimate.
- Refresh the delta-EVE table under the parallel, steepening, fast-ramp, and run scenarios.
- Update the model change memo with any assumption shifts and their rationale.
Pro Tip: Treat a widening gap between static and dynamic beta estimates as an early warning sign worth escalating to ALCO before the next full model refresh, not after.
Where modelers still get deposit beta wrong
The most common failure I still see is reliance on a vendor's default beta table applied uniformly across a deposit book that has almost nothing in common with the vendor's reference sample. Weak segmentation compounds it: lumping brokered and relationship deposits into one bucket, or ignoring insured versus uninsured status, produces a beta that describes an average customer who does not exist. Infrequent recalibration is the third mistake, and it is the quietest one, since a beta estimated two rate cycles ago can look stable right up until it isn't.
The priorities for 2026 are straightforward: build dynamic, level-dependent stress tests rather than a single static number, invest in governance that produces a clean audit trail without scrambling before an exam, and keep documentation examiner-ready as a standing practice, not a pre-exam project. Get those three right and the rest of the modeling work holds up under scrutiny.
— Raj
How RiskInMind supports deposit beta modeling programs
Building and maintaining a defensible deposit beta model means running the same calibration, stress test, and documentation cycle every quarter without letting any step slip when deadlines tighten. RiskInMind's platform is built for that kind of recurring, audit-sensitive workflow rather than a one-time analysis.
- Security controls and measures keep sensitive deposit data in-house rather than exposed to third parties.
- Real-time processing supports scenario runs across multiple segments without the wait times that discourage frequent recalibration.
- Specialized AI agents coordinated under a central director can help automate the repetitive parts of scenario analysis and reporting.
- Audit trails are structured to hold up under the kind of documentation scrutiny examiners apply to NMD assumptions.
Risk and compliance leaders who want to see how this fits their own ALCO cycle can view pricing and plans or explore the platform's product lines directly.
Sources
- Deposit Convexity, Monetary Policy and Financial Stability – Research Dept. Working Paper No. 2315 – Dallas Fed
- Interest Rate Risk, Comptroller's Handbook
- Banking on Uninsured Deposits (FDIC conference paper)
- Federal Reserve FEDS research on funding betas and econometric modeling
FAQ
What does deposit beta mean?
Deposit beta is the share of a market rate change that passes through to a bank's deposit rate, calculated as the change in deposit rate divided by the change in the reference market rate. A beta of 80% means an 80 basis point deposit rate move for every 100 basis point move in the market rate, though Dallas Fed research shows this ratio tends to rise as rates climb higher.
What is the $3,000 rule for banks?
This question refers to currency transaction and reporting thresholds under anti-money laundering rules, not deposit beta modeling, and it falls outside the scope of interest rate risk analysis covered here. Readers looking for guidance on transaction reporting thresholds should consult their institution's compliance function or primary regulatory guidance directly.
Will depositing $2,000 cash raise a red flag?
This is a question about anti-money laundering and currency transaction reporting practices, which is separate from deposit beta and interest rate risk modeling. Financial institutions set their own monitoring thresholds within regulatory frameworks, so this is best directed to compliance guidance rather than a rate-risk model.
How are PD and LGD calculated?
Probability of default (PD) and loss given default (LGD) are credit risk metrics used in expected loss and capital calculations, distinct from deposit beta, which measures interest rate pass-through rather than credit loss. PD is typically estimated from historical default frequencies within a risk grade or segment, while LGD reflects the portion of exposure not recovered after default, and both sit in a different modeling framework than the deposit repricing work described above.
Why do deposit betas rise during rate hiking cycles?
Deposit betas tend to increase as market rates climb because depositors have a stronger incentive to move balances toward higher-yielding alternatives, a pattern Dallas Fed research on deposit convexity documents directly. This dynamic, level-dependent behavior is why static models calibrated in low-rate periods often understate pass-through once a hiking cycle accelerates.