Depository Yield Modeling#

Yield modeling refers to the tracking of APY/interest rates and the automatic accrual of interest income on depository accounts. This is distinct from the delegated-type polymorphic structure (covered in Account Type Architecture) and from balance calculation strategies.

Current State of the Codebase#

As of the current main branch, Depository accounts carry no APY or interest-rate fields. The Depository model defines five subtypes — checking, savings, hsa, cd, money_market — but contains only tax-treatment logic (for HSA) and no rate or yield attributes. 1

Interest-rate fields (interest_rate, rate_type) exist exclusively on the Loan model for liability-side payment calculations and are not shared with depository accounts.

Proposed Design (PR #1392 — Closed, Not Merged)#

A detailed implementation was proposed in PR #1392 but closed without merge. It represents the most complete blueprint for how yield modeling would work in this codebase:

Schema additions to depositories:

• interest_rate — decimal (precision 5, scale 4); validated to be > 0 and ≤ 100
• interest_enabled — boolean, default false

InterestAccrual model — a dedicated table tracking each day's accrual per depository, with columns date, balance_used, daily_rate, amount, and paid_out. A unique index on (depository_id, date) prevents duplicate records. 2

Daily rate formula (leap-year-aware):

daily_rate = interest_rate / 100.0 / days_in_year # 365 or 366
accrued = (account.balance * daily_rate).round(4)

2

Background jobs:

Eligibility (interest_eligible?) requires interest_enabled: true, a present interest_rate, and interest_rate > 0. The design is opt-in for manual accounts only to avoid conflicts with provider-linked balances.

Subtype Relevance#

Not all depository subtypes are equally relevant to yield modeling:

CDs would benefit from a maturity_date or term_months field (analogous to the term_months on loans) to model the fixed-term nature of the deposit, but this was not included in PR #1392.

Community Demand#

• Feature Request: Fixed Return Accounts (2026-08-06) — asks for manual-entry fixed-interest accounts with automatic calculation over time; the stated use case is non-integrated accounts such as German Tagesgeldkontos.
• A separate discussion requested surfacing interest rates more prominently in the account overview UI rather than requiring users to open the edit dialog.

Related Areas#

• Account Type Architecture — explains the delegated_type polymorphic structure that routes records to Depository.
• Loan interest modeling — the loan side has interest_rate, rate_type, and (in the open PR #2842) effective-dated Loan::RateChange records for variable-rate support. The depository pattern in PR #1392 takes a simpler flat-rate approach.
• app/models/depository.rb — the canonical entry point for all depository subtype logic. 4