Skip to Content

Balance Prediction Algorithm Analysis

Analysis of the balance prediction algorithm — category volatility calculation, scenario generation, and improvement recommendations.

For saved scenarios, inline adjustments, affordability, and budget impact, see balance-prediction-scenario-lab.md.

Current Implementation (Before Improvements)

1. Category Volatility Calculation

  • Data Source: Only EXPENSE transactions from last 6 months
  • Method: Coefficient of Variation (stdDev / mean)
  • Range: Capped to [0, 1]
  • Default: 0.5 if insufficient data (< 2 transactions) or mean = 0

2. Scenario Generation

  • Base Scenario: Sum of all transaction amounts (signed)
  • Optimistic Scenario:
    • Expenses: Spend less (add adjustment)
    • Income: Earn more (add adjustment)
  • Pessimistic Scenario:
    • Expenses: Spend more (subtract adjustment)
    • Income: Earn less (subtract adjustment)
  • Adjustment Formula: abs(amount) * volatility * 0.3 (30% multiplier)
  • Application: Only to future transactions (txDate == date)
  • Past Transactions: Same amount for all scenarios (already happened)

3. Noise Application

  • Applied To: Base scenario only
  • Formula: Random noise in range [-noisePercentage%, +noisePercentage%] of balance
  • Purpose: Add randomness to base scenario

4. Transaction Types Considered

  • Committed transactions (already happened)
  • Scheduled transactions (future, certain)
  • Periodic spends (user-defined, certain)
  • Past month simulated transactions (if enabled)

Issues Identified

  1. Volatility Calculation:

    • Only considers EXPENSE transactions, ignores INCOME volatility
    • Coefficient of variation can be misleading for skewed distributions
    • No consideration of transaction frequency patterns
    • Fixed lookback period (6 months) might not be optimal
  2. Scenario Generation:

    • Fixed 30% multiplier might not be appropriate for all categories
    • Doesn’t differentiate between certain (scheduled) vs uncertain (unscheduled) transactions
    • Same volatility logic for all transaction types
    • No consideration of transaction size (small vs large transactions)
  3. Noise Application:

    • Only applied to base scenario
    • Random noise doesn’t reflect realistic patterns
    • Should scenarios also have uncertainty?
  4. Missing Patterns:

    • No day-of-week patterns (e.g., weekend spending)
    • No day-of-month patterns (e.g., end-of-month bills)
    • No seasonal patterns
    • No consideration of transaction frequency

Implemented Improvements ✅

1. Enhanced Volatility Calculation

  • INCLUDE INCOME: Now considers both INCOME and EXPENSE transactions (previously only expenses)
  • Percentile-Based Approach: Uses Interquartile Range (IQR) / median instead of coefficient of variation
    • More robust to outliers
    • Better handles skewed distributions
    • Formula: (IQR / median) / 2 normalized to [0, 1]
  • Frequency Factor: Adjusts volatility based on transaction frequency
    • High frequency (≥20 transactions): 0.9x multiplier (more predictable)
    • Medium frequency (10-19): 1.0x (normal)
    • Low frequency (<10): 1.1x (less predictable)

2. Improved Scenario Generation

  • Certainty Factor: Differentiates between transaction types
    • Scheduled/Periodic: 0.5x volatility (50% - more certain)
    • Committed (future): 0.8x volatility (80% - already happened)
    • Simulated (past month): 0.7x volatility (70% - based on patterns)
    • Unknown: 1.0x volatility (100% - fully uncertain)
  • Size-Based Multipliers: Adjusts volatility based on transaction amount
    • Small (<$10): 0.5x (less volatile)
    • Medium ($10-$100): 0.8x
    • Large ($100-$1000): 1.0x
    • Very Large (>$1000): 1.2x (slightly more volatile)

3. Algorithm Flow

Per-date computation loop: certainty and volatility factors are applied per category before summing into scenario adjustments.

4. Key Improvements Summary

  • More Accurate Volatility: IQR-based calculation is more robust than stdDev/mean
  • Income Consideration: Now includes income volatility, not just expenses
  • Transaction Certainty: Scheduled transactions have lower scenario variance
  • Size Awareness: Small transactions are less volatile, very large ones slightly more
  • Frequency Awareness: More frequent transactions are more predictable

Future Improvements (Not Yet Implemented)

1. Pattern Recognition

  • Day-of-week patterns (e.g., weekend spending)
  • Day-of-month patterns (e.g., bills at month end)
  • Seasonal patterns
  • Time-of-day patterns

2. Advanced Uncertainty Model

  • Apply uncertainty to all scenarios, not just base
  • Use realistic patterns instead of pure randomness
  • Consider cumulative effects (uncertainty compounds over time)
  • Different uncertainty for different transaction types

3. Machine Learning Enhancements

  • Learn user-specific patterns
  • Adaptive volatility based on recent behavior
  • Anomaly detection for unusual spending
  • Personalized scenario multipliers