Meetings and Microfinance IntroductionContents::
Microfinance methodologies vary from organization to organization, but a generally accepted principle is that the MFI staff goes to the village to meet with the customers/borrowers. This is done through regularly scheduled meetings, and at these meetings both payments and disbursements are made. Thus, the payment schedules become effectively linked to the meeting schedule, which generally stays static for the term of a loan. However, there are some MFIs that don't have meetings and operate under the "teller model". Under this model, clients visit the branch on or before their loan payment is due to make their payment to a "teller" at the branch.

Meeting Requirements and Logic in Mifos

Currently, all clients, groups, and centers (if they exist in the client hierarchy) must have a meeting associated with them. Mifos generates a meeting schedule for a client and based upon this schedule, generates the repayment schedule for loans, the schedule for mandatory savings deposits, and the schedule for fee payments. The essence of the rule is that all due dates for loan repayments and deposits fall on a meeting day. The information below describes what features use the meeting schedule and what dependencies must be removed if we're going to remove meetings as a requirement in Mifos. While there are certainly key changes that are required, Aditi estimated it as a "medium" amount of work to remove the meeting dependency. However, given their familiarity with Mifos, they may be underestimating the work involved for a new contributor on Mifos. Please also refer to the Meetings section in the Functional Spec. insert link or convert to wiki

Expected Repayments: Calculation of loan repayment schedule

• Use Case:

Customer creates a loan account by selecting a client, a loan product type (which has a loan frequency attached to it), and a proposed disbursal date.

• How does Mifos handle this:

When a loan is disbursed, Mifos generates a loan repayment schedule by assuming that the first payment falls on the first meeting after a period equal to the loan frequency assuming no grace period and calculates the second payment as first payment + loan frequency. Currently, a loan must be disbursed on a meeting day, although we were going to remove this restriction (not yet implemented). Once the loan repayment schedule is created, every other action (attaching fees, making payments, waiving fees, making adjustments) looks at this loan repayment schedule (and not the client meeting schedule). As long as different inputs are used to create this schedule-- the remaining loan functionality should work properly.

• If we remove meetings:

If we remove the meeting requirement, we need another method to determine the first repayment date. When creating a loan account, the user would need to specify either 1/ disbursal date and Mifos assumes the first repayment day is (disbursal day + loan frequency) or 2/ both disbursal date and first repayment date (since sometimes, in the case of Enda?, the first repayment date might not have a rigid alignment with disbursal date) and Mifos would calculate the second repayment date as (first repayment date + loan frequency). From these inputs, Mifos would generate the loan repayment schedule. Option #2 makes sense to me and provides more flexibility. To make the process of entering dates easier, there could be calendar select feature. Note that this use case is much easier to support when interest rates are flat because, under that interest schema, MFIs don't adjust interest charged based on more/less days between disbursement and repayment. Declining balance interest rates add a lot more complexity-- since MFIs might want the ability to calculate interest based on dates other than the period of disbursal through final payment. For example, an MFI may have a declining balance loan product with clients that repay this loan in monthly payments on the 10th 12th and 14th of each month. Disbursals, however, may all happen on the 10th of each month-- but the MFI may want the same interest to be charged to all clients. This is a heavily summarized scenario. We need to collect more data around these use cases.

Expected Deposits: Calculation of savings deposit schedule

• Use Case:

Some MFIs require their clients to make mandatory deposits at each meeting. Some MFIs also come up with savings plan for each client and determine target voluntary deposits a client should try to make periodically. These amounts need to appear on the collection sheet as expected amounts.

• How does Mifos handle this:

When expected deposits are specified for a savings account, Mifos assumes that these deposits are expected on a meeting day and it generates a savings schedule to capture these expected deposits.

• If we remove meetings:

If we are going to remove the meeting requirement, we would need to 1/ find a way to specify a deposit schedule for the client (perhaps by linking the deposit schedule to the loan schedule-- this is a common scenario-- even for MFIs that have meetings) or 2/ preventing clients w/o meetings from having "expected deposits" or 3/ capture frequency of deposits in savings product definition and generate a deposits schedule from savings account activation date (this will be less complex than option 1).

Expected Client Fees: Calculation of client/group/center fee schedule

• Use case:

MFI charges each client a weekly membership fee. The user specifies a "periodic" fee against the client account with the rule of to charge the client a weekly amount. This amount needs to appear on the collection sheet as an expected payment.

• How does Mifos handle this:

This periodic fee is "attached" to the client account. Every night, there is a batch job that runs and attaches the periodic fee to be due at the next meeting time. For example: A client has a meeting every monday and a client fee is due every monday. On the monday night at midnight, a batch job runs and specifies that at the next meeting, a client fee is expected.

• If we remove meetings:

If we remove the meeting requirement, we would need to find a way to specify the due dates for client fees. This could be done by 1/ tying to a loan account (would mean that no clients are collected if there is no outstanding loan) or 2/ specifying a first due date for the fees, after which the fee frequency would determine due date, or 3/ take client activation date as the reference date to generate savings schedule.

Changing Meeting Times

• Use Case:

Occassionally, a center (or group if no center hierarchy exists) will change it's meeting day. Instead of meeting weekly each Monday, for example, it will move its weekly meeting to Wednesday. When this happens, the dates for of the loan repayments, expected savings deposits, and fee payments need to change.

• How does Mifos handle this:

A center/group's meeting day can be changed, but not its frequency. For example, if a center meets weekly on Monday, the meeting time can change to weekly on Wednesday, but not to monthly on the first tuesday of the month (not a use case for MFIs). Similarly, if a center meetings on the 25th of every month, the meeting can be changed to the 1st of every month. Every night, a batch jump runs to check to see if any meetings have changed for a center and if so, the batch job will update the loan repayment schedule, expected savings deposit schedule, and expected fee deposit schedule asssociated with all clients within that center to align the expected payment dates with the new meeting dates. This change doesn't impact the value of the repayments (including interest)-- as this is not an MFI requirement.

Meetings should only be changed on a day AFTER the meeting has occurred. For example, if a meeting must be moved from Wednesday to Tuesday, change the meeting on Wednesday or later. Otherwise, you will end up with more than one meeting in a week.

Also, notice that changes to meeting times do not show up in the UI until the Batch jobs have run.

Other Misc Issues

If you remove the meeting time requirement, the following issues should also be addressed (not an exhaustive list):

• Meeting date/time will need to be removed from center, group, client detail pages
• Groups inherit meeting frequency from their centers and clients inherit the same from groups. This inheritance has to be removed.
• Edit meeting schedule feature on center page would be removed
• Attendance values (in bulk entry and client performance stats) become irrelevant.
• Collection sheet job that runs only for the centers with meeting on the next day needs to be modified.