Paying off or Pre-closing a Protect Enabled Loan

Overview

There may be situations where a borrower repays the loan early, or makes a single payment to pay-off the loan. In such cases, the contract is marked for closure based on the payment if:

• the payment received from the borrower is equal to the payoff amount for that day, or,
• the sum of the payment amount + any rebate offered to the borrower on the protect fee, falls within the payoff tolerance specified for the contract.

If any of the conditions are met, when you save the payment transaction, the contract status changes to Active - Marked for Closure. In the next run of the SOD job, the Loan Closure job processes all such contracts and creates the following LPTs under Other Transactions:

• Rebate LPT. This transaction calculates the rebate payable to investors as per the protect split defined for the contract, and if the Is Investor Rebated at Payoff, or the Is Investor Rebated On Refinance, as applicable, is selected. This transaction is created with the same payment mode as that of the last transaction on the contract, and with the Rebate Payment checkbox selected. When the Investor Payout job runs, investors are paid out based on their investment share, from this amount. 

• Closure LPT. This transaction is created to adjust the difference in the outstanding amount and the borrower payment, that is attributable to the payoff tolerance. This transaction is created with the same payment mode as that of the last transaction on the contract, and with the Closure Tolerance Payment checkbox selected.

Example

Let us say there is a protect-enabled loan that has the following parameters and it is disbursed on the same day that it is created:

Let us say the borrower decides to pay off the loan on April 1, 2013. While trying to pay off the loan, the system calculates the payoff amount for the borrower as follows:

• Payoff amount = Total amount due - the rebate amount.

The system calculates the rebate amount as follows:

Rebate amount = [(f) x n x (n+1)] / [t x (t+1) ]

where:

• f is the protect fee = 500

• t is the total number of months in contract from disbursal date to maturity date = 12

• n is number of remaining months from payoff date to maturity date = 11

Thus, the rebate amount = (500 x 11 x 12)/(12 x 13) = 423.0769 = 423.08.

Thus, the principal amount that the borrower needs to pay = 10,500 - 423.08 = 10,0762.92.

Hence, when the borrower makes the payoff, the system creates a rebate LPT with the Payment Mode as Internal Transfer, for the rebate amount, as depicted in the following image:

(Here, the Payment Mode as Internal Transfer is applicable for Simple Loans and Amortization based loan products.)

The following image depicts the details of the Rebate type LPT created with Payment Mode as Internal Transfer:

(Here, the Payment Mode as Internal Transfer is applicable for Simple Loans and Amortization based loan products.)

The system then marks the loan in the Active - Marked for Closure status. On the next day, when the LoanClosureDynamicJob runs, the system closes the loan with the status, Closed - Obligations met.

Rebate calculation within the pre-bill period

Rebate calculation during payoff is dependent on the number of terms remaining on a contract. To correctly calculate the remaining terms for loans paid off between the bill generation date and bill due date, for example, during the pre-bill days, the system computes the next due date based on the current system date. It ignores the Next Due Date updated on the contract by the Billing job upon bill generation. For example, consider a loan with monthly payments created on January 4, with pre-bill days as 3. If the payoff occurs on February 3, the system considers February 4 as the next due date to calculate rebate and payoff amounts. The Billing job on the other hand, updates the Next Due Date in the contract to March 4 immediately upon generating the February bill, even though the current due date has not yet passed. 

The selected check boxes can be read by the ACH filegen job, which excludes such transactions from the NACHA file created for bank processing. Once these transactions are processed, the outstanding amounts are brought to zero and the contract is closed with status Closed - Obligations Met.