• 1 Overview
• 2 Loan Account Creation
• 2.1 Loan Account State Flow Diagram
• 2.2 Status History
• 2.3 Repayment Schedule
• 2.4 Interest Rate Formulae
• 3 Account Details
• 3.1 Next Payment Details
• 3.2 Installment Details
• 3.3 Account Summary
• 3.4 Repayment History
• 3.5 Performance Metrics
• 3.6 Change Logs
• 4 Loan Account Transactions
• 4.1 Applying Fees & Penalty
• 4.2 Loan Disbursal
• 4.3 Payment Received for the Applied Amounts
• 4.4 Early Repayment of Loan
• 4.5 Partial and Early Loan Repayment
• 4.6 Missed Installments
• 4.7 Adjustments
• 4.8 Waiving Fees and Penalty
• 4.9 Backdated Payments
• 4.10 Transaction History
• 4.11 Account Activity
• 5 Out of Scope for Version 1.0

Overview

Loan accounts can be created for the Active product instances in the system. These loan accounts inherit the rules and defaults from the product definition.

• Accounts can be created for either an individual or a group depending on whether the product instance is defined for clients or groups.
• A single account cannot be given to multiple groups or clients.
• A group or client can have multiple accounts.
• Account can be opened only for Approved or Active clients and groups present in the system.
• Individual client accounts cannot be converted to a group account.
• Accounts cannot be deleted.

Loan Account Creation

• A loan account can be created for all product instances, which are in the “Active” status.
• When an instance is selected for the client, system should validate whether the repayment frequency of the instance is equal to or a multiple of the client meeting frequency.
• Process flow:
• When a user tries to open a loan account for a client, system displays only those product instances whose frequencies are equal to or multiples of the client's meeting frequency.
• For example, a client with a meeting frequency of three weeks on a Monday is eligible for loan instances with a frequency of 3, 6, and 9 weeks. A client whose meeting frequency is the last Monday of every two months is eligible for loan instances with a frequency of 2, 4, and 6 etc months.
• If the above condition is met, user can proceed and open a loan account of that product instance for the client. The instance attributes are inherited from the product definition.
• The following attributes are displayed as Read Only information in the Accounts page:
• The attributes that cannot be overwritten at the account level
• The attributes specifying the range of allowed amounts or rates for the instance
• Attributes like default amount/rate, can be overwritten at account level There are no restrictions on the number of loans that a client or group can be part of. Any restrictions are a part of offline approval processes of the concerned MFI.
• Depending on the product instance chosen, the remaining fields are filled in as per the rules of the product instance specified during instance definition.

Loan Account State Flow Diagram

When the loan account is initiated, it has to go through the various state or statuses as depicted in the state flow diagram. Certain offline processes specific to the concerned MFI follow the status changes, before a loan can be approved and disbursed to the customer.

State Flow Diagram - Loan Account Creation

In case, both the optional states (Pending approval and Disbursed to LO) are not included in the system by the HO, the status flow diagram looks like:

Status Flow Diagram - Loan Account Creation (without Optional States)

The various statuses of loan accounts are described in the table below:

Table - Status Description for Loan Accounts

Notes:

• When asked to report/search “All Active loans”, by default the system consider both “Active in good standing” and “Active in bad standing” loans
• The user should, be allowed to filter Active in good standing OR Active in bad standing loans separately.
• The above logic also applies for “All Closed Loans” which include Closed- Obligation met and Closed- Written Off.
• There is no “Deleted” status. All accounts are kept in the system.
• There is no restriction on the number of times an account status can be changed.
• When an account is created, it can be either saved in Partial Application state or Pending Approval state. If Pending Approval (an optional state) is not included by the HO, new account can be saved in Approved state.
• A Checklist might be displayed before an account status is changed. This is to remind the users of the offline processes required before an account status can be changed.

Status History

Mifos automatically tracks changes in the loan/savings status. The first entry in this history should be the creation of the loan/savings and should show the change of status from New to Open, while the last entry should be the transition of the loan/savings to a final state of either Closed or Canceled.

This information can be used to track performance of the LO or efficiency of the MFI’s processes by tracking duration between loan/savings statuses.

The following attributes are captured when the status is changed and saved. All these fields are mandatory, un-editable, and generated by Mifos system.

Note: All status changes, irrespective of number of times these statuses have been changed, are recorded in the status description table.

Table - Information stored in Status History

Attributes for Loan Accounts

Repayment Schedule

• Repayment schedule is generated based on the loan amount, interest rate, frequency, and the number of installments specified in the account.
• In case, the loan duration extends beyond the current year, system creates the repayment schedule for all years. However, system assumes that the subsequent years have no holidays.
• In version 1.0, repayment schedule will not be editable by the user. However, it is updated by the system when there is a change in any one of the parameters displayed in the Repayment Schedule Table.
• Once the loan amount is disbursed to the client, the repayment schedule is considered as the Original repayment schedule. The date of disbursement is used as the reference point.

The following information is displayed in the repayment schedule:

Rules for Repayment Schedule Generation

The following rules around disbursement terms are used to describe the repayment schedule generation:

1. Disbursement Date: planned disbursement date for a loan that is defined prior to the actual disbursement of the loan
2. Principal and Interest Due are calculated as defined in Appendix.

Clients with Defined Meetings

• If disbursement occurred on a meeting 
• Repayment Start Date is the frequency of loan repayment + grace period duration
• Succeeding Installment Due Date is calculated based on Previous Installment Due Date + Frequency Elapsed.

The following lists different scenarios where the Repayment Due Date, Principal Due, and Interest Due deviate from the said norm:

Interest is deducted at Disbursement

• The first installment has the following values:
• Installment Due Date = Disbursement Date
• Principal Due = 0
• Interest Due = Total Interest Due for the duration of the loan.
• The succeeding installment details are calculated as usual with interest = 0.
• Second installment date = disbursal date + frequency of installments.
• Grace period for repayments does not apply if interest is deducted at disbursement.
• This only applies to flat interest loans.    

Principal Due at the Last Payment

• Total interest is spread across the time period and the total principal amount is due at the last installment.
• For Flat interest loans, interest is spread out in equal installments. This is not a real use case, as MFIs do not really work this way. But, the system does not prevent this.
• Declining method—The client is charged full interest amount at each installment

Combination of “Interest is deducted at Disbursement” and “Principal due at the last payment”

• Though a rare scenario, this combination is allowed by the system. Interest is deducted during disbursement and principal is paid at the end of the loan duration.
• All rules around “Interest deducted at disbursement” and “Principal due at the last payment” are applicable here.

Note:  Also see http://groups.google.com/group/mifosfunctional/browse_thread/thread/7ca15f34dc937d9c for more details on how repayment schedules are created.

Scenarios for Repayment Schedule Generation

General Rules

1. After loan is disbursed to client, interest rate cannot be changed.
2. Grace period starts from the day the loan is disbursed to client.
3. Grace period for repayments does not apply if interest is deducted during disbursements.
4. Repayment day and meeting day should match.
5. Grace period can be modified:

• User can modify grace period for a loan account before the grace period ends for that account
• If grace period has not ended yet, it can be changed to future date (one or more installments)

Interest Rate Formulae

P = principal amount (initial amount)

r = annual rate of interest (as a decimal) Assumption: Number of decimals used for calculation will be the

same as that specified by HO.

A = amount of money accumulated including interest

n = number of times the interest is compounded per years

Periodic intervals: daily, monthly, quarterly, semiannually, or annually (This can be number of

days and number of weeks too.)

EMI Definition: EMI (Equated Monthly Installment) is the amount payable to the lending institution every month, till the loan is paid back in full. It consists of a portion of the interest as well as the principal.

Declining Balance Interest (EMI of Principal and Interest)

Declining Balance Definition: Interest is computed at periodic intervals on the amount of the original principal that has not yet been repaid. Since the borrower only pays interest on that amount of original principal that has not yet been repaid, interest paid is smaller every period. However, to make sure that the borrower sets EMI, the formula is:

EMI formula:

EMI = i*P / [1- (1+i)^-n]

Where,

P = Loan amount

r = Rate of interest per year

n = Term of the loan in periods

l = Length of a period (fraction of a year, i.e., 1/12 = 1 month, 14/360 = bi-weekly.)

i = Interest rate per period (r*l)

Examples:

P=1000, r = 5/100, l = 6/12 n = 2, i = 0.025

EMI = 0.025 * 1000 / [1-(1+0.025)^-2]

EMI = $518.83

The way to apply payments is as follows:

• Calculate interest in the principal due: If balance = $1000, and i = 0.025, interest is $25
• Calculate the amount to principal which is the monthly payment minus the interest due: $518.83 - $25 = $493.83
• Calculate the principal remaining, which is the previous principal remaining minus the amount applied to principal: $1000 - $493.83 = $506.17 (remaining balance)
• Once next payment is received, repeat steps 1 to 3.

Note: Due to rounding of computed values, it could potentially be off by a maximum of N number of pennies after the full term of the loan. It will never be short if we round up, rather, principal could end up with a few more pennies. 

Declining Balance Interest – Interest in Periodic Payments; Principal at the End (or Earlier)

Declining Balance Definition: Interest is computed at periodic intervals on the amount of original principal that have not yet been repaid. Since the borrower only pays interest on that amount of original principal that has not yet been repaid, interest paid is smaller every period.

For this interest type, the client only needs to pay per period the interest and the complete principal at the end of the loan cycle. Thus, per period the client pays the same interest amount, unless he or she pays part of the principal ahead. If so, the future periodic payments are less the interest amount.

Note:

• Early payments of principal/interest will not be handled in version 1.0.
• If loan is disbursed in between two meetings, interest installments are not EMIs.

Formula:

For one period interest calculation: interest = P * (r/n)

Where,

P = loan amount- Use the Principal Remaining (which at one point is equal to the initial amount).

r = rate of interest (annual/100)

n = term of the loan

Examples:

P=1000, r = 3% monthly, n = 4

Interest = 1000 *(3/100) = 30

Monthly payments of 30

If client pays 300 of principal, then next payment will be of:

Interest = 700 *(3/100) = 21

Flat Interest

Definition: Flat interest refers to charging interest on the full original loan amount, rather than on the declining balance. For example, with group based loans, a common "interest rate" is "3% per month, flat, for four months". This means that a $100 principal amount lent is multiplied by 3%, and then by 4 months to come up with $12 in interest. Thus, $112 would be repaid over four months in equal installments.

This is the most common calculation used in Grameen Style MFIs (most MFIs). Also there is no incentive for repaying early, since customer still has to pay the total interest as was calculated at the start of the loan.

The use of "flat" interest rates is usually explained as facilitating understanding by poorly educated and illiterate clients. "Flat" interest is easier to calculate than “declining balance” interest. However, "flat" interest also disguises the "effective" interest rate (APR, or internal rate of return) to the loan. Based on how often the principal is collected (weekly, monthly or at the end of the term), and assuming there are no additional fees, the above loan has an APR of between 39% and 71%.

Formula:

P = loan amount- Initial amount

r = rate of interest

n = term of the loan

Examples:

P=100, r = 3/100 per month, n = 4

Interest = 100 *(3/100) * 4 = 12

Monthly payments of 112 / 4 = 28

Note: The above formula holds for loans disbursed in between two meetings also.

Account Details

Once an account is created, various operations like viewing of account information, editing, and modifying are facilitated through the Account Details page.

Account Details page contains the complete account information (as mentioned in the Loan Attributes Table). Given below are details present in each section on loan account details page.

Next Payment Details

This section will display the amount due on the next repayment date and will be updated when an installment/payment is made.

The amounts due for the following should be calculated as:

• Principal/Interest Calculation - The next installment amounts for Principal and Interest will be the same as calculated in the Repayment schedule (as explained in the Rules for Repayment Schedule Generation section). The system will update the principal and interest amounts in “Next payment” and “Repayment History”,
• if there has been an early or partial payment
• if the client has missed installments - Missed installments, however are recorded in the “Repayment history.”
• Fee Calculation - Fees due will be calculated as per the fee definition for that account.
• If an installment payment is missed, the amount should be clubbed with the next payment and displayed in this section.

The “Payment details” section of the UI will have the following information:

Note: When the details in “Amount Paid” section are entered and saved, transaction entries are required. The transaction entries required will be covered in the “Transaction” section of the document.

Installment Details

The Installment Details section of the UI has the following information:

Account Summary

Account summary section gives an overview of the amount paid and due after the last transaction. This section is updated by the system and is not editable by the user. For the fields required in this section, refer to the Loan Attributes table

 This section is updated as soon as the system detects any of the following actions:

• Disbursal is done or a payment is made: amount paid and amount due should be adjusted accordingly.
• Changes in fee types: addition/removal/waiving of fee types/misc fee or misc penalty, change in fee amount etc. will change the Amount Due section.
• Note: Already charged fees, including unpaid fees should not be changed.
• Two amounts will be calculated and shown outside the table:
• Total amount due and date of next repayment. This total amount will be the sum of original installment and amount in arrears.
• Amount in arrears- This is the amount from previous installment(s) not received on the scheduled date

Repayment History

Repayment history records and displays the repayment details of the account. This is updated by the system as and when a transaction is made. The user is not allowed to make any modifications to the repayment history.

Repayment history contains the information given in the tables below:

Performance Metrics

The following parameters are used to track the performance of each loan account by the system:

Change Logs

Changes made to any of the attributes in the Accounts page should be logged in the change logs

Following information is available in the change logs:

• Account information changes
• Addition/removal of fee types
• Addition of notes

However, the change logs do not have details of any transactions made. Therefore, the following are not logged in the change logs:

• Payment of principal, interest, fee, and penalty
• Charging of fees
• Adjustments made
• Changes in repayment schedule due to change in different parameters.

Loan Account Transactions

After an account is in Approved status, transactions can be made to the account. These transactions include the following:

• Disbursement of loan amount
• Payment received for the amounts due
• Adjustments to the last transaction made to the account

Note:

• The transactions entries listed in this section are not included in the Change Logs.
• Each one of the transaction entries are made against the correct GL Code picked from the chart of accounts defined for that HO. The details on transaction entries in the database are part of the design document.

Applying Fees & Penalty

In addition to the fee types inherited by the loan account from product definition, user can apply other predefined fee types to the account and also apply a Misc fee to the account.
To calculate the next payment due, system will consider all the fee types applied to the account and the misc fee amount applied to the account, if any, and calculates the “Payment Due amounts”.

Notes:

• One time- upfront fee- if a one-time upfront fee is charged to the loan account- it will be added to the upcoming/today’s installment. The user can edit the amount of upfront fee, before it is applied.
• One-time fees can also be at “Time of disbursement” or “Due with first installment”. These should be charged with disbursal or first installment respectively. These fee types can be added till the day of disbursement/or first repayment respectively. For example, if 1st Jan is the disbursal date, “time of disbursement” fee can be added till 31st Dec irrespective of whether the disbursal was recorded in the system or not.
• Periodic fee- if a periodic fee is applied to the loan account; amount equal to one fee installment should be added to the upcoming loan installment. After the upcoming installment, the recurrent fee installments should be added to future loan installments as per the periodicity of fee type.
• Periodic fee can be removed from a loan account. If a fee is removed, it will be removed from all the future loan installments.
• If a periodic fee is applied before loan is disbursed, it should be first charged to the first installment. Thereafter, the fee should be charged as per the fee periodicity and aligned to the loan installments.
• The periodicity unit of recurrent fee and loan frequency should match. That is, if loan frequency is in months, recurrent fees with periodicity in months can be charged to the account but recurrent fee type where periodicity is in weeks cannot be charged to the account. Similarly a monthly fee cannot be charged to loan instances with loan frequency in weeks.

User can also apply a “Misc penalty” amount to the account. If a miscellaneous penalty amount is applied to the account, the same is included in the upcoming/today’s payment due for the account.

Note:

• Amount applied to the loan accounts is included in repayment schedule when the amount is charged. But this amount is not included in Transaction Table, until the payment for the same has been received.

Loan Disbursal

Loan disbursal requires transaction entries and change of account state. “Disburse loan” link will appear on GUI when the account reaches “Disburse to LO” state (“Approved” state in case “Disburse to LO” state is not included by HO). This link should not be visible in any other states.

• The following details will be captured when the loan is disbursed:
• Disbursal Date- by default, this is the date specified in proposed disbursal date in account details. If the date is modified during loan disbursal, it should be updated and the repayment schedule should be regenerated accordingly.
• Mode of payment, Receipt ID and Receipt Date for loan amount and for interest (if interest is deducted at disbursement) and fees (if applicable).
• Mode of payment- for disbursal and interest (if interest is deducted at disbursement) and fees (if applicable).
• If interest is deducted at disbursement- a fee charged at “Time of disbursement” or “Time of first loan repayment” will be added to the payment required at the time of disbursement. Misc fee or misc penalty charged to the account before disbursal, will be added to the amount required to be paid during disbursement since it is also the “first installment”
• If interest is not deducted at disbursement- misc fee or misc penalty charged to the account before disbursal will be added to the first installment
• Actions required when the disbursal entry is made:
• Account summary, account activity should be updated
• Repayment dates in repayment schedule should be updated as per the date of disbursal
• Disbursal date should be updated and changed to the date entered by the user.
• Transaction entries should be made for loan amount.
• If any payment (interest and/or fees) is paid during disbursement, transaction entries for the same should be made.
• Status of loan account should be changed to “Active in good standing”
• Disbursals are done in one shot only.
• Disbursals can also be done through bulk entry.
• The disbursals should appear in the collection sheet/bulk entry after the account has been marked as “Disbursed to LO” or “Approved”.
• The loan should be considered as “not disbursed” if the value entered from bulk entry is zero. The bulk entry will keep displaying the amount to be disbursed until the loan disbursal happens.
• Grace period starts when the client account reaches Active in good standing state for the first time.

Payment Received for the Applied Amounts

Payments can be made for the amount that has been applied to the account. For details, refer the Next Payment due section.

The total amount paid is broken by the system internally into the following attributes: (In version 1.0, the amounts do not surface in the UI.)

• Principal due and principal overdue
• Interest due and interest overdue
• Fees due and fees overdue
• Penalty due and penalty overdue

When a payment is received, the user specifies the following:

• Total Amount Paid
• Date of payment
• Mode of payment
• Receipt ID and Date (optional)

Once the entries are made, the following actions are taken:

• The payment received is broken into the components - principal, interest, fees, and penalty (as applicable).
• Update the transactions table
• Update the Account Balance Details section
• Update Amount Paid and Total Amount Remaining
• Update Next Payment Details sections.

Early Repayment of Loan

After a loan is disbursed, it can be repaid completely at any point. If client/group wants to repay the complete amount, following flow will be supported by the system:

• There will be a separate UI flow for early repayment of loan.
• System will calculate the amount due as of the current date. This amount should include principal, interest, fees and penalty due on this account.
• Principal- sum of total principal due in unpaid, due and future installments
• Interest- For flat and declining interest type- Interest for all future installments will not be included but interest for all past unpaid installments and current installment will be included.  Example if the loan is for 12 months and is paid monthly, and the client wants to repay the complete loan on her 4th installment date, interest calculated will be the interest for the 4th month. If the client misses the 4th installment and wants to repay the loan in between 4th and 5th installments, interest for 4th and 5th installments should be included.
• Scenario: in case a holiday is added after disbursal of loan and the original calculation of the repayment schedule, one installment can be shifted to the next repayment date. Example, payment on 1st Jan is shifted to 1st Feb. In this case, if an early repayment is done on or before 31st Jan, it will not consider the interest amount, which would have been due on 1st Jan if Jan 1st were not a holiday. 
• Fees- Similar to interest calculation, fees remaining to be paid as per the fee types attached to the account on the current date and due till the last installment. The fee amount will be calculated till the last installment and the remaining loan duration will be ignored. In the above example- the fee calculated will consider only the amount to be paid till the 4th installment. Remaining 8 months will be ignored. In the same example, if the client wants to repay the loan in between 4th and 5th installment, fee due till the 5th installment will be considered due. 
• Penalty- Misc penalty and penalty due to late repayments (if any) to be paid. Misc penalty to be paid till the last installment and for the current installment will be considered due. Penalty due to late repayment will be taken till the last night. 
• The user will specify the transactional details- Mode of payment, Receipt ID and date.
• The system will make the required transactional entries for principal, interest, fees and penalty and update the account summary.
• The system will make an “activity” entry as “Payment” with all the details and change the state of the account to “Closed- obligation met”.

Partial and Early Loan Repayment

At all times, client may not pay the exact amount which is due as on the current date. If a client is short of cash, she might not be able to repay the complete installment amount and may plead to repay partially.
On the other hand, if a client has a surplus, she might pay some extra amount and would want the same to be adjusted in a future installment.
The system, at present, restricts partial or over repayment for loans. The intent of this feature is to remove this restriction.

Feature summary
System should allow partial payments through the “Apply payment” pipeline and through bulk entry. In case a partial payment is received, system should break down the amount received into penalty, fee, interest and principal as per the logic defined.

Primary Flow- partial payment

• User: clicks on “apply payment” link in loan details page.
• User: modifies the default amount and enters an amount less than the expected amount.
• User: click on “review transaction”.
• System: brings up the “Preview” page with the information entered.
• User: clicks on “submit” to save the transaction.
• System: submits the amount received. The amount should be first paid against the penalty due. After penalty payment, if there is an excess, the amount should be saved against the fee due, followed by interest due and then the principal.
• System: Account activity and transaction history entries are logged.
• System: “view repayment schedule’ is updated to depict the status of each component (penalty, fee, interest and principal). The partially paid installment should be displayed in both “Installments paid” and “installments due” sections with the amounts paid and due respectively. The “Date paid” should only be displayed when the entire installment is paid off.     

Primary Flow- early payment

• User: clicks on “apply payment” link in loan details page.
• User: modifies the default amount and enters an amount greater than the expected amount.
• User: click on “review transaction”.
• System: validates that the date of transaction is between the last payment date and current date.
• System: should validate that the amount entered is not greater than the total amount outstanding on that account.
• System: brings up the “Preview” page with the information entered.
• User: clicks on “submit” to save the transaction.
• System: submits the amount received. The amount should be first saved against the installments due. The excess amount should then be saved against the penalty due, if any, for the next installment. After penalty payment, if there is an excess, the amount should be saved against the fee due, followed by interest due and then the principal.
• Preview page should be displayed for the next installment if there is an excess.
• System: Account activity and transaction history entries are logged.
• System: “view repayment schedule’ is updated to depict the status of each component and installment (penalty, fee, interest and principal).

Alternate Flow 1

• User: clicks on “make payment” link in loan details page.
• User: modifies the date of transaction to a past date.
• User: modifies default amount and enters an amount less than the expected amount.
• User: clicks on “Review transaction”.
• System: Validates that the date of transaction is between the last payment date and the current date.
• System: brings up the “Preview” page with the information entered.
• User: clicks on “submit” to save the transaction.
• System: submits the amount received. The system should pick the oldest unpaid installment and pay the amount against the penalty due for that installment. After penalty payment, if there is an excess, the amount should be saved against the fee due, followed by interest due and then the principal.
• System: should repeat step 8 for all the unpaid installments till the amount become 0.
• System: Account activity and transaction history entries are logged.
• System: “View repayment schedule’ is updated to depict the status of each component (penalty, fee, interest and principal).

Alternate Flow 2

• User: Makes a complete payment of Rs. 100 on 1st Jan.
• User: clicks on “Apply adjustment” link on loan details page on 15th Jan and nullifies the last transaction.
• System: completes the adjustment flow.
• User: clicks on “make payment” link in loan details page on 16th Jan.
• User: modifies the date of transaction to 10th Jan.
• User: makes a partial payment and saves the transaction. 
• System: should consider the amount due as Rs. 100 and complete the partial payment flow.

Alternate Flow 3

• User: clicks on “Enter collection sheet data” link.
• User: selects the center.
• System: generates the bulk entry for the selected center and meeting date.
• System: in “collections” section, system gets the loan amount due as of the meeting date.
• User: modifies the default loan amount and enters an amount less than the expected amount.
• User: clicks on preview.
• System: displays the partially paid amount in RED in the preview page.
• User: clicks on submit.
• System: submits the amount received. The amount should be first paid against the penalty due. After penalty payment, if there is an excess, the amount should be saved against the fee due, followed by interest due and then the principal.
• System: Account activity and transaction history entries are logged.
• System: “view repayment schedule’ is updated to depict the status of each component (penalty, fee, interest and principal).

Additional information

• If adjustment is done after a partial payment, the complete amount paid in last transaction should be nullified. For example,
• User records a partial payment of 20 rs.
• User then makes an adjustment on last transaction.
• The payment of the entire 20 rupees is adjusted.
• If fee due = fee 1 + fee 2, fee 1= 20 and fee 2= 30, and the amount paid = 25- system should not have a logic to distribute the partial amount into various fee types. For example-
• Client owes 150 Rs.-  25 in penalty, 25 in fees across 3 different fee types, and 50 in interest and 50 in principal.
• Client makes payment of 35 Rs.
• System accepts 25Rs to cover penalty and 10Rs to cover fees partially.
• Repayment schedule will display 10 Rs as paid fees and 15 Rs as unpaid fees.
• System will not how the partial payment is disbursed across the various fee types.
• The partially paid fee and/or penalty can be waived by the user.
• If an installment is partially paid, it should be considered as a “missed payment” for performance metrics.
• If an account is in “Active in bad standing” state, the state should be changed to “Active in good standing” only on complete payment of due amount.
• Even for backdated transactions, “amount due” displayed by the system should be as of current date
• Early payment- if the client pays complete amount for one future installment and then an upfront fee is applied to the account- this fee should be applied to the first unpaid installment.
• Early payment- if an adjustment is done after an early payment, system should nullify the transaction and revert the transaction like a normal adjustment.
• If a client/group has 2 or more loan accounts of the same product instance, system will not allow early/partial payment from bulk entry.
  System will validate that the amount entered is not greater than the total amount outstanding. This amount will be more than the amount calculated by the system through “repay loan”. The assumption is that if the user wants to completely repay the loan, “Repay loan” will be used and not “apply payment” or bulk entry.

Missed Installments

• If the payment is missed for installments, the same is included in the Next Payment Details and displayed as the Overdue amounts. The Total Amount Due contains the missed installments. Refer Next Payment details section, which talks about recording missed installment amounts and missed repayment date.
• For example, the client has to repay $100 (principal = $80 and Interest = $20) every month, and she defaults for the month of August. For the month of September, the following amounts are displayed in the Next Payment Details:
• Principal Due= $80
• Interest Due = $20
• Penalty Due = $2 (for the missed/defaulted installment)
• Principal Overdue= $80 (for the missed/defaulted installment)
• Interest Overdue = $20 (for the missed/defaulted installment)
• Total Amount Due= $202
• While the payment is entered, the system accepts either $202 or no payment at all.

Adjustments

To rectify errors, adjustments will be supported by the system.

• The full amount of the last amount paid can be nullified. If the amount is nullified, system is required to make reverse transaction entries for the amount.
• A “note” is mandatory when an adjustment is made. This will keep a record of the reason for adjustment. 
• Once an adjustment is made, system should break down the last amount paid into its components and update the respective amounts where required. Example, if the last amount was paid for principal, interest and fees together, system should break the total amount into these amounts and reduce it from the principal paid till date, interest paid till date and fee paid till date.
• More updation will be required (and done by the system) at the following locations-
• Account summary should be updated
• Installment details should be updated
• Adjustment is an activity- therefore recent activity and account activity sections should be updated
• Repayments schedule should give a correct picture of the installments, paid, due and future after the adjustment. Example, an adjustment of a payment can mean that an installment should now be displayed as “not paid” in the repayments schedule.
• Transaction history will have entries for all the related transactions that will be reversed due to the adjustment entry.

Waiving Fees and Penalty

Fee installments and penalty installments can be waived and the same amount will be reduced from the next installment details

• Following amounts can be waived:
• The fee due in next installment can be waived
• Note- System will allow waiving of total amount of fees due (i.e. all fee types + misc fee). Waiving of individual fee amount will not be permitted.
• The fee overdue (due to missed installments) can be waived i.e. the total fee overdue till the current date can be waived but partial amount or individual components of fee cannot be waived.
• Penalty due in next installment- That is, if any misc penalty has been charged to the account, it will be part of the next installment. This misc penalty, which is charged to the account and is due in the next payment, can be waived. 
• Penalty overdue- Misc penalty charged during previous installments which were not paid, can be waived.
  Note: waiving of partial fees/penalty will not be allowed. Also, waiving a particular component of penalty overdue (example, misc penalty, or penalty for installment #1 etc) will not be supported.  
• Once an amount is waived, it will require following update
• Installment details
• Account summary
• Repayment schedule- In case, fee is waived, the amount under fee column should be updated

Notes

• “Waiving” is an activity and should be recorded in “Recent activity” and “Account activity”
• Transaction entry is not required when an amount is waived.

Backdated Payments

• System should allow backdated payments. The total amount due calculates amount due as of current date. If a backdated payment is paid, total amount due should equal to the amount due “as of <the date entered>”The date of payment can be between the date of last meeting and current date.
• By default, the current date and amount due as of current date should be displayed in the “Apply payment” screen.
• Date and amount can be modified

Transaction History 

Transaction entry is required for the following cases:

• Loan disbursal
• Loan repayment
• Adjustment made

For details, refer to accounting requirements.

Account Activity

Recent Activity

Last 3 activities will be displayed in the main loan details page. Following will be displayed under “recent account activity”-

Complete Account Activity

Complete account activity will be viewed on a separate page and the following information has to be recorded and displayed:

Activities

• Following activities will be logged in the account activity
• Fee charged- Activity name should be “<fee name> charged”. One time fee should be charged to the next/today’s installment as soon as it is applied. Periodic fee should be charged with an amount equal to one installment every time system adds this amount to the “Next installment due”.
• Misc Fee charged- Activity name should be “Misc fee charged”
• Misc Penalty charged- Activity name should be “Misc penalty charged”
• Fee waived- activity name should be “Fee waived”
• Penalty waived- activity name should be “Penalty waived”
• Recurrent fee removed- Activity name should be “<fee name> removed”. The amount will be equal to the summation of all fee installments to be paid in the future installments.
• Loan disbursed- Activity name should be “Loan disbrsd”
• Payment received- Activity name should be “Payment recd”. This should include principal, interest, fee and penalty and the break up should be displayed under respective columns.
  Notes
• In case a loan is repaid fully, say amount for 4 installments is paid in one shot- in account activity- this will be recorded as one activity called “payment” but in transaction history, this will be recorded as 4 records with same payment ID and different transaction ID since they are made for different installment numbers.
• During loan account creation, admin set fees and “additional charges” applied will be logged as separate activities. That is, if 2 admin set fees and 3 additional fees are applied to the account- this will mean 5 entries in the “account activity” since a fee is logged with the fee name in the activity.

Out of Scope for Version 1.0

• Periodic and Partial disbursements of loans
• Flexible interest rate calculations: Different rates charged on the first $100 vs. second $100 of the loan amount.
• Calculation of loan amounts and the expected default amortization schedule for being able to set the order of applying partial payments received to account types (penalties, late interest, interest due, principal due, principal) at a product level. Partial/Overpayments are handled as an “ad hoc transaction”. For details, see accounts section.
• Definition and tracking “affiliated parties” associated with a loan. However, this is kept in data model for future use.
• Payment vacation where payments are pushed out for specified period of time, but interest still accumulates and is factored into overall repayment schedule. Although common in the banking world, this is not used by MFIs.
• Combination of grace period.
• Intelligence around collateral.
• Determination whether or not amount of loan exceed collateral amount.
• Rescheduling of loan
• Editing repayment schedule
• Adjustments except nullifying of last (one) amount paid
• Adjustment of loan disbursed and interest deducted at disbursement
• Partial waiving of fees/penalty- Example if the fee overdue (due to 3 missed installments) is 300, the complete amount can be waived. Amount less/greater than 300 cannot be waived.
• Allowing attaching of fee with frequency defined in weeks with loan instances with frequency defined in months. And allowing fee with frequency defined in months with loan instances with frequency defined in weeks.
• Waiving of a fee amount, which is due to be paid with loan disbursement.
• Interest recalculation for late repayments for declining interest types.
• Status change in bulk for any other status and/or entity except for approval of loan accounts.