Rechner für Hypotheken-Recast

Führt einen Recast einer Hypothek durch, indem lump_sum vom Saldo abgezogen und über dieselbe months_remaining zum unveränderten annual_rate neu amortisiert wird; zurückgegeben werden payment_before, payment_after, payment_delta, payment_delta_percent sowie die gesamten interest_saved.

Recast versus Refinanzierung

Da die Laufzeit konstant gehalten wird, ist die monatliche Entlastung proportional zum Anteil der getilgten Darlehenssumme. Anders als eine Refinanzierung lässt ein Recast Ihren Zinssatz und Ihre Restlaufzeit unangetastet und amortisiert nach einer einmaligen lump_sum lediglich eine kleinere Darlehenssumme neu. new_principal entspricht balance minus lump_sum, und sowohl die alte als auch die neue Rate verwenden die Annuitätenformel payment = P·i·(1+i)^n / ((1+i)^n − 1) mit i = annual_rate/1200 und n = months_remaining. Bei einem Saldo von 200.000 $ zu 4 % mit noch 240 Monaten senkt eine Sonderzahlung von 20.000 $ die Rate von 1.211,96 $ auf 1.090,76 $ — ein payment_delta von 121,20 $ oder ein payment_delta_percent von 10,00. Rundet annual_rate auf null, geht die Formel in principal geteilt durch months über, sodass ein zinsfreies Darlehen weiterhin sinnvolle Werte liefert, statt durch null zu teilen.

Eingesparte Zinsen und die Ausgabefelder

Über die niedrigere Rate hinaus summiert das Werkzeug die Zinsen über die gesamte Laufzeit für beide Szenarien. interest_before entspricht payment_before mal months_remaining minus dem ursprünglichen balance, und interest_after wendet dieselbe Identität auf new_principal an, sodass interest_saved deren Differenz ist — 90.870,56 $ minus 81.783,50 $ ergibt 9.087,06 $ beim Beispieldarlehen. Alle dreizehn Ausgabefelder, von new_principal bis interest_saved, werden genau einmal mit einer half-up-Regel auf den Parameter decimals gerundet, der standardmäßig 2 beträgt. payment_delta ist payment_before minus payment_after, und payment_delta_percent drückt dies als Anteil der ursprünglichen Rate aus; beide leiten sich aus ungerundeten Zwischenwerten ab, sodass der Prozentsatz und die Dollarbeträge intern stimmig bleiben und bei der Anzeige nicht um einen Cent auseinanderdriften.

Validierung und sichere Integration

balance muss eine endliche Zahl über null sein, annual_rate null oder mehr und months_remaining eine positive Ganzzahl; jeder Fehler liefert einen typisierten invalid_input-Fehler, der das Feld benennt. Der entscheidende Schutz ist lump_sum: es hat den Standardwert 0 und muss mindestens null und echt kleiner als balance sein — Sie können keinen Recast durchführen, indem Sie das Darlehen vollständig ablösen — andernfalls erhalten Sie invalid_input statt einer unsinnigen Rate von null. Das macht den Endpunkt sicher für den Einsatz hinter einem Verwaltungsportal, in dem Kreditnehmer beliebige Beträge eintippen. Fehlgeschlagene Aufgaben werden nie berechnet, und das Prepaid-Guthaben wird ausschließlich für erfolgreiche API-Aufrufe zum veröffentlichten Grundpreis verbraucht, was massenhafte Was-wäre-wenn-Analysen günstig hält.