Methodology

Every number on this site comes from the same handful of calculation modules the calculator itself runs, not a separate marketing estimate. This page documents exactly how each one works: the formula, the worked example, and where the mechanism produces a result that's easy to miss if you only look at the final EMI figure. All worked examples use the site's own base case: a ₹1,00,00,000 loan at 7.5% over 20 years, ₹1.4 crore property against ₹1 crore in own funds where a strategy split is involved.

EMI: the reducing-balance formula

Every EMI on this site is computed with the standard reducing-balance formula:

P is the principal, r is the monthly interest rate (annual rate ÷ 12 ÷ 100, a plain division, not a compounding conversion), and n is the number of monthly instalments. This is the unique flat monthly payment that brings the balance to exactly zero after the last instalment, charging interest only on whatever principal is still outstanding.

On the base case: r = 7.5 ÷ 12 ÷ 100 = 0.625% monthly, n = 240 months. The formula returns ₹80,559 a month. One edge case worth stating plainly: if the rate is ever 0%, the formula divides by zero, so the code falls back to a flat P ÷ n instead. See the EMI guide for the plain-English walkthrough of why the naive loan ÷ months figure is wrong.

Amortisation: the month-by-month split, and how prepayment changes it

The EMI figure is one number, but the loan is simulated one month at a time, and this is where prepayment actually does its work. Each month, in order:

• Interest this month = outstanding balance × monthly rate.
• Principal this month = EMI − interest this month + any extra prepayment that month.
• The balance drops by that principal amount, clamped so it never goes negative.

Because interest is recalculated fresh each month on a shrinking balance, the interest share of every EMI payment shrinks over the loan's life on its own, with no extra input needed. Prepayment works by adding directly to step two, principal this month, which is why it shortens the loan rather than lowering the EMI: the EMI itself is computed once, at origination, from the original principal, rate, and tenure, and never recalculated afterward. Extra payments only make the balance hit zero sooner.

The engine supports three distinct prepayment mechanisms, and they compound differently:

• Extra monthly prepayment, a flat rupee amount added to principal every month.
• Step-up prepayment, a percentage the extra monthly amount rises by on each loan anniversary, e.g. an extra ₹8,900/month growing 3% a year for Balanced.
• Annual lump sum, a number of full EMI-equivalent payments knocked straight off the principal once every 12 months, on top of whatever the monthly mechanisms already did that year. Only the Tax-Optimized strategy uses this mode, at exactly 1 lump sum a year, instead of any monthly top-up.

The moment the balance reaches zero, the loan is marked paid off at that exact month, and everything after it (further prepayment, further interest) simply stops being simulated. See the prepay vs invest guide for what that means for your decision, not just the mechanism.

SWP simulation: the corpus, the tax, and how depletion is found

This is the calculation that produces results generic finance content can't, because it requires actually simulating a shrinking, growing, taxed balance month by month against a real EMI schedule, not applying a single formula.

Growth. The corpus's annual return is converted to a monthly-compounding equivalent rate: monthly rate = (1 + annual return)^(1/12) − 1. This is deliberately not the EMI side's plain division by 12; it's the exact geometric monthly rate that compounds to the stated annual return over 12 months. Each month, the corpus grows by this rate first, before anything is withdrawn.

The gain fraction, and the tax gross-up. An SWP withdrawal is a partial sale of fund units, and only the profit portion of that sale is taxed. Each month, the gain fraction is (current balance − remaining cost basis) ÷ current balance, clamped at zero. To net exactly the EMI amount after tax, the simulation grosses the withdrawal up: gross withdrawal = target EMI ÷ (1 − gain fraction × tax rate). The difference between the gross and target amounts is the tax paid that month, and the cost basis is reduced by the non-gain portion of what was withdrawn, so the gain fraction keeps climbing as more of the corpus becomes embedded profit.

On the base case (₹40,00,000 corpus, ₹80,559 EMI, 7.5% return, 12.5% capital-gains rate): month 1's gross withdrawal is ₹80,620, of which ₹488 is gain, taxed for ₹61, netting the full ₹80,559 EMI. That gain fraction is under 1% in month 1, because almost the whole balance is still original capital; it climbs past 25% within 4 years as growth outpaces the shrinking principal share.

Depletion. The corpus is checked every month it's still expected to fund an EMI (up to the loan's payoff month, not beyond). If a month's gross withdrawal would push the balance negative, that month is recorded as the depletion month, and the balance is frozen at zero for the rest of the simulation window rather than going negative or continuing to accrue. On the base case, this corpus depletes at month 58, not even 5 years into a 20-year loan, because a roughly 24%-a-year withdrawal rate comfortably outpaces 7.5% growth. Nothing about the simulation stops the loan from continuing after that; the model simply reports the corpus is gone and the EMI needs to come from elsewhere from that point on.

Bank-account mode works the same way, structurally, with one difference. The corpus still grows and is still drawn down against the EMI schedule with the same depletion check, but there's no gain fraction: every rupee of interest is taxed in full, every month, at the full income tax rate, the same "Income from Other Sources" treatment described in the SWP guide. That's a meaningfully higher tax bill per rupee of interest than the SWP's gains-only treatment, though the SWP guide already shows why that gap narrows and can even reverse as the two corpora age differently.

Tax calculation: Section 24(b), Section 80C, and the two funding-mode tax models

Two entirely separate tax calculations run in this tool, and it's worth being clear they don't interact: the home loan's own interest/principal deduction, and whichever tax treatment applies to the corpus funding the EMI (capital-gains for SWP, slab-rate for a bank account, both covered above).

The loan deduction. Walking the amortisation schedule year by year, each year's interest and principal are summed separately, then capped independently: interest is deductible under Section 24(b) up to ₹2,00,000 for that year, principal under Section 80C up to ₹1,50,000, and the tax saved for that year is (deductible interest + deductible principal) × your income tax rate. This only applies under India's old tax regime, for a self-occupied property; the new regime, the default since AY 2024-25, allows none of it. The engine flushes this calculation every 12 months as it walks the schedule, or immediately at the loan's actual payoff month if that falls mid-year, so a partial final year isn't dropped or rolled into a year that never happens.

On the base case, under the old regime at a 30% slab: total tax saved across all 20 years comes to ₹20,13,096, against ₹93,34,237 in total interest, working out to an effective interest rate of approximately 5.88%. These figures, and the full year-by-year breakdown of where the ₹2,00,000 and ₹1,50,000 caps bind, are already verified in the tax benefits guide; this page describes the mechanism, that page has the full walkthrough.

Section 24(b) and Section 80C are the citations used throughout this site. For why, given the Income-tax Act, 2025's pending renumbering, see the closing note in the tax benefits guide; this page defers to that note rather than restating it.

Strategy allocation: how each of the 4 strategies picks its split

The homepage's "How this works" section explains what each strategy trades off. This section covers one level deeper: the actual mechanism that decides the numbers.

Every strategy follows the same shape. First, it resolves a capital stack (down payment, mutual fund lumpsum, funding corpus) from your property price and own funds, according to that strategy's own rules. Then it searches a small grid of variations on that stack, monthly prepayment amount, and sometimes down payment or corpus size, simulating every combination through the exact amortisation and corpus engines described above. Finally, it picks the single best candidate according to that strategy's own objective: filter to candidates that satisfy the strategy's feasibility rule, then pick whichever remaining candidate minimizes (or maximizes) that strategy's own metric. If no candidate satisfies the feasibility rule, the engine doesn't relax the rule or fall back to a default. It picks whichever candidate's corpus survives longest, an honest "best available" rather than a silent violation. Every rupee figure in the grid is rounded to the nearest ₹100 before it's simulated, not after, so the number a strategy card displays always matches what was actually simulated.

Safety First sizes down payment (~77.5-82.5% of own funds, searched) and a small mutual-fund slice (~5-7.5% of own funds, searched) directly from own funds, with everything left over becoming a bank-funded buffer. Its feasibility rule is a hard one: the buffer must never deplete before payoff. Among candidates that clear that bar, it picks whichever has the lowest total interest. At the site's own default inputs, no candidate in the search grid actually clears that bar, so the engine falls back to the latest-depleting option, which still runs dry at month 38 of a 216-month payoff, the same finding already disclosed in "What this model assumes."

Balanced targets a medium down payment (40-50% of own funds) and a fixed 12% of own funds to the mutual fund, then sizes an SWP corpus for a 36-48-month runway (searched), funded from whatever's left after down payment and MF. Anything still left over becomes extra down payment, not idle cash. Its feasibility rule is softer: the corpus should last at least 60 months, a preference rather than a hard floor, and it minimizes total interest among candidates meeting it.

Aggressive Payoff pins down payment near the site's 20-25% floor and a thin, fixed 12-month corpus, then sends 75% of whatever's left to the mutual fund and converts the remaining 25% into an extra monthly prepayment, spread evenly across the loan's original tenure and added on top of its own separate prepayment search. It has no feasibility filter at all: every candidate is eligible, and the winner is simply whichever pays off fastest, tie-broken by lowest total interest. Net wealth is still reported on the result but never used to choose the winner, because this strategy's corpus reliably drains within the first year regardless of how hard the loan is prepaid, which would make "maximize net wealth" pick almost randomly among the prepayment options instead of reflecting a real trade-off.

Tax-Optimized Payoff is the only one of the four with no search grid at all: down payment is fixed at the 20% floor, mutual fund at 18% of own funds, and the corpus at a fixed 24-month runway, with any leftover again routed into extra down payment. Extra monthly prepayment is fixed at zero; instead, exactly one full EMI-equivalent lump sum is paid once a year, and the tax-deduction calculation described above runs directly against the resulting schedule to report the tax saved and the net effective interest cost.