Deletions:

---

Additions:

---

Additions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

Additions:

Deletions:

---

MIS Requirements Outline for MFIs

Everything that a Management Information System for micro-finance organizations should be…and more
Krishnan Mani, for the IFMR Foundation, Chennai
April 2009

Table of Contents
Motivation 5
Approach 5
Some ways to use this document 6
Responding to these requirements 6
Scope and exclusions 7
Some caveats 7
Requirements 8
1. Overview of the MIS system (function) 8
2. Value additions 10
3. Organization setup 11
4. User setup 11
5. Operating model 13
6. Financial products 18
6.1. Loan products 18
6.2. Deposit products 18
6.3. Compulsory savings 18
7. Charges 18
7.1. Interest 18
7.2. Fees 19
7.3. Caution amounts 19
7.4. Insurance premia 19
7.5. Penalties 19
7.6. Incentives 19
8. Customers 19
8.10. Customer accounts 20
8.11. Customer history 21
9. Groups and center locations 21
10. Micro-credit operations 22
10.1. Loan applications, loan application review, and loan sanctions 22
10.2. Loan disbursements 22
10.3. Loan repayment 23
10.4. Loan pre-payment 24
10.5. Loan moratoria/grace periods 24
10.6. Loan delinquency 24
10.7. Loan defaults 24
10.8. Insurance claims 25
10.9. Loan re-scheduling 25
10.10. Loan freeze 25
10.11. Sources of funds and funding lines 25
11. Operations Support 25
11.1. Center meetings 25
11.2. Demand sheets (a.k.a. “collection sheets”) 26
12. Accounting 26
12.16. Support for audits 28
13. Reporting 28
13.4. Scope and spread of operations 29
13.5. Customer base 29
13.6. Activity of associates and borrowers 30
13.7. Portfolio of loans and financial products 30
13.8. Finances 30
14. System monitoring and administration 30
15. Expectations concerning non-functional aspects 31
15.1. Usability 31
15.2. Users and user habits 32
15.3. Access 33
15.4. Security 33
15.5. Data integrity, data retention, and data portability 34
15.6. Migration and support 34
15.7. Reliability and availability 35
16. Appendix A- MFI operations- in a minute 35
17. Appendix B- Questionnaire used to solicit requirements 36
18. Appendix C- Data items for elements of MIS 37
Glossary 37
Sources and credits 37




Motivation
After looking at some of the available MIS offerings, engaging micro-finance institutions (aka MFIs) in the field, and reviewing some of the literature published, we came to some common conclusions summarized below:
* MFIs are lagging in the adoption and use of MIS software, resulting in issues of data quality, among others.
* While medium-to large MFIs can afford and are using pre-dominantly proprietary software solutions, smaller MFIs resort to spreadsheets or just pen-and-paper for record-keeping purposes.
* The software solutions available and in use are a handful in number, and span a wide spectrum of functionality, and price (from a few thousand rupees to several lakhs of rupees)
* There is no well-developed and competitive market for IT systems catering to the MIS needs of MFIs, and there is no wide choice of MIS systems that are consistently functional, useable, competitively-priced, and well-supported.

As a step towards addressing these issues, we decided to understand and document the generic software system requirements that any comprehensive MIS system would require to fulfill to meet “common needs” of MFIs. It is hoped that these will serve as the ‘common minimum set’ of requirements (and more) that any candidate MIS system should fulfill to be considered ‘feature-complete’ (at least on paper). While the scope of these requirements is not “ambitious”, very few, if any, MIS systems currently in use, fulfill these in their entirety.
Approach
This author visited several MFI organizations with several characteristics:
* Ranging in size from small to large, and in age from newly-established to long-established.
* Located in multiple states across the country
* Using multiple models of micro-finance including JLG, SHG, and individual loans
* Varying in the use of MIS systems, from no software used, to ones using vendor-provided solutions (and have used other solutions in the past), to ones that are using or developing their own in-house solutions

Initially, we hoped these visits would assume the form of a ‘routine’ software requirements gathering exercise, which proceeds somewhat along the following lines: the user community documents or otherwise specifies their needs in increasing levels of detail through structured mechanisms including interviews and discussions with teams of trained business analysts, who capture, refine, and analyze the same to produce requirements. In line with this approach, a questionnaire was mailed to the participants as a gentle introduction to a formal requirements exercise (see appendix)

However, (as anticipated) none of the participating MFIs have engaged in such exercise with either internal or external teams, now or in the past. Even the ones that have developed MIS systems in-house or evaluated multiple vendor-supplied MIS systems did not have (or may not have shared) a formal documented body of requirements, or demonstrated the existence of processes to arrive at one. This is not an unusual situation in itself, since only a small percentage of IT users (globally) formally manage requirements, and this approach requires considerable discipline on the part of both IT users and IT providers.

However, stating requirements unambiguously in a structured format is critical for IT teams and users to build and test successful solutions.

Therefore, the software requirements stated here were inferred indirectly by gathering information through interacting with management and staff at MFIs, and these requirements were confirmed by re-stating them in suitable language.

We looked at the current operations of the MFI in the field and at multiple branches and other office locations, their usage of any existing MIS system (as well as any MIS system deployed earlier); reviewed any perceived issues and shortcomings with the entire user experience, and collected feedback about desirable features. We spoke with both management and users including branch managers, field officers, data entry personnel, accountants, and the IT support staff.

The same information has now been captured here. Furthermore, this document will be reviewed with participants in the exercise to ensure their needs are reflected faithfully.

To use an illustrative example, users at MFIs did not provide information in a prescriptive format such as: “Any MIS system must seamlessly allow field staff to operate at the local branch or centre level, while at the same time allowing management easy consolidation of information across branches”

Instead, they indirectly pointed to requirements, while narrating issues and problems such as “Every month, in order to generate reports on the financial health of the organization as a whole, we manually consolidate data from individual database files for multiple branch installations, (or require data entry operators at our headquarters to feed them in if we haven’t received the necessary files). This is time-consuming, laborious, and error-prone”
Some ways to use this document
* For MFIs (and others assisting them)
.1. Use this as a starting point to consolidate your own custom requirements for MIS systems
.2. Use this as a guide to help evaluate available or proposed MIS offerings from vendors
.3. Contribute to the evolution of these requirements to help establish ‘fit-for-use’ standards for MIS systems that meet your needs and the needs of others in the same sphere of operations

* For IT providers
.1. Use this outline to help validate your offerings for MIS systems for MFIs
.2. Use this as a guide to help design your MIS offerings
.3. Help evolve these requirements to help create a common body of knowledge (CBOK) for MIS systems for MFIs. The publication of a CBOK is an indicator of the maturity of the market for systems in any domain
Responding to these requirements
Due to the nature of the exercise and the approach taken to merely outline the requirements (see the section on ‘caveats’ below), MIS solution providers have a great deal of latitude in responding to the requirements specified here. However, we have tried to ensure there is little ambiguity in the basic content of the requirements itself.

Two different (hypothetical) MIS systems may choose to implement the exact same requirement in different ways. Take the example of the requirement for the system to support user roles and privileges. One system may ship with a limited set of pre-defined user roles and privileges, and constrain the MFI to assign users to the available roles. Another may provide more flexibility by letting the MFI design custom roles on the system and assigning them arbitrary privileges. Arguably, both meet the requirements from the perspective of this document.

However, (as always) it is for system designers to decide the preferred approach. We merely state the “normative” requirement that the MIS system must support user roles and privileges, and do not “prescribe” the spectrum that the requirement may assume, or take a stance as to how the requirement must be met.
Scope and exclusions
1.
2.
3.
4.
* We consider mostly micro-credit loans. None of the participating MFIs accepted deposits, although most MFIs consider deposits an inevitable addition to their product lines, sooner or later.
* MFIs carry out area surveys to identify suitable locations for credit operations. Information collected through surveys is multi-dimensional, and the criteria used to screen potential locations through surveys vary widely. We have not included any requirements around the conduct of surveys, or recording and review of survey information in an MIS. These generally include a significant element of decision-making by humans
* Some of the MIS systems seen include (rudimentary?) support for administrative or human resource functions such as payroll, and leave planning. In order to focus only on MIS needs, we exclude consideration for such features that may have utility value, but are likely to be served best by other systems better suited to the purpose.
* The outline approach fails for the reporting aspect of requirements, which is necessarily detail-oriented We suggest an initiative for MFIs to create and come to a consensus on a ‘common minimum reporting’ framework
Some caveats
* Since this is an “outline” of requirements, there is a very high “density” of requirements information ‘hidden’ within many of the ‘requirements’ in the document. For e.g., a single statement such as ‘Support temporary cancellation or re-scheduling of particular instances of center meetings’ says very little about:
o The actual mechanics of cancellation or re-scheduling
o The particular usage scenarios that occasion cancellation, re-scheduling, or cancellation versus re-scheduling
o The particular operating policies or business rules that are relevant to cancellation or re-scheduling
o The impact on various other elements within the system such as loan repayment schedules, or the work load of field officers, due to cancellation or re-scheduling
o The various user interactions and decisions, and the nature, amount, and form of information that is presented by the system during these operations
o The various configuration parameters or preferences available in the system that are relevant to these operations
o And so on, and so forth…
* In the interpretation of such details with respect to each requirement in this outline, lies the latitude available to MIS system providers to respond to the requirements
Requirements
An MFI's substantial needs from MIS are summarized as:
1. Describing the nature and scope of operations, including financial products, credit policies, operating models and parameters, locations, and so on.
2. Creating and maintaining information about borrowers
3. Tracking loan disbursements, repayments, and other credit operations
4. Performing accounting for monetary transactions
5. Reporting on operational parameters and financial health for decision-making by management, and to other audiences including funders, auditors, statutory agencies, sectoral bodies, and so on.
6. Ensuring staff as system users can view and update appropriate information as per their roles and responsibilities
7. Monitoring usage and administering the system to ensure effective use
We will attempt to cover all of these below.
1. Overview of the MIS system (function)
The following is a high-level overview of system function that is considered ‘basic’ to meet the needs of MFIs:
1.1. The MIS system serves the needs of an MFI organization (hereinafter, ‘organization’)
1.2. The organization sets up its administrative hierarchy, creates all of the locations it operates from, and assigns these locations into the administrative model
1.3. Some or all associates of the organization (including staff) are setup as users in the system. They are assigned user roles and privileges on the system
1.4. The system must be designed such that each user may access the system and perform operations in a secure manner, to view, create, and update information, as permitted by the user roles and privileges granted to the user.
1.5. The system lets the organization configure various parameters to define its particular operating model, the business policies and rules it follows, and the operating environment (such as time zones) it functions in.
1.6. The organization creates templates in the system for the financial products it will provide to customers (including, at least, micro-credit loans)
1.7. The organization captures information for its customers in the system, including information about identity, location, occupation.
1.7.1. The system also helps the organization capture customer information on demographics, economic status, and standards of living (including measures such as access to healthcare, education, drinking water, sanitation, etc.). This information can be used to measure the social impact of micro-credit (such as ‘progress out of poverty’), and help target customers better.
1.8. If the organization (as per prevailing models in micro-finance) organizes some or all of its customers into groups, the system captures information about groups, center locations, and group meetings at center locations.
1.9. The organization uses the system to record and track its micro-credit operations (including loan application, sanctions, disbursements, repayment, pre-payment, re-scheduling, delinquency, and default, as well as the collection of associated fees, penalties, caution amounts, and insurance premia)
1.9.1. The system assists micro-credit operations by helping schedule center meetings, generating demand sheets for the collection of loan payments, and capturing business transacted at center meetings
1.9.2. The system also records sources of funds such as loans from banks, and tracks the use of various funds to make loans
1.10. The organization uses the system to perform accounting for all monetary transactions arising from micro-finance operations (including disbursement of loans, receiving fees and other income, receiving principal and interest payments, booking loan losses, and so on).
1.11. The organization generates various reports from the system to aid its management and associates in decision-making and day-to-day operations. The system allows the organization to decide the scope and level of detail of information that is presented in reports.
1.12. The system also produces statements of account (such as balance sheet and profit and loss statements) as well as other information in the prescribed formats for audiences within and outside the organization
1.13. The system must be designed to help the organization monitor appropriate usage of the system, and ensure security of data in the system.
1.14. The system is administered by privileged users appointed by the organization. Administrative users perform various tasks, including (but not limited to):
1.14.1. Helping other users access the system at one or more locations and enabling them to perform their tasks effectively and efficiently in a secure manner
1.14.2. Reviewing logs of user actions and changes to data in the system
1.14.3. Ensuring business continuity through data backup and restoration, and ensuring availability through monitoring of system usage of resources.
1.15. The system must fulfill a number of expectations with respect to non-functional aspects including security, usability, reliability, availability, access, scalability, and data retention.
2. Value additions
The following system features augment function presented as basic in the ‘Overview…’ section. Several of these are immediately relevant, while others have no stated or implied demand as yet.
2.1. Support dashboards to provide relevant summary information “at a glance” updated at regular intervals and customized for each user as per their locations and roles. Potential contents of dashboards include performance indicators, goals, and progress against goals (as described later)
2.2. Support ‘setting and monitoring performance goals and performance-related incentives’ for associates (typically field officers and loan officers) such as the number of customers serviced, number of new customers or groups added every period, loan sanctions turned around, loan repayment performance, etc.
2.3. Allow forecasting of cash requirements and cash inflows at each administrative location taking into account anticipated loan disbursements and loan recoveries
2.4. Support the generation of loan documentation for borrowers using templates provided by the organization
2.5. Support notification to associates and/or customers (through communication media such as ‘short message service’ to customers’ mobile phones, or handheld devices used by field officers)
2.6. Support communication with portable devices used in the field by associates such as receipt printers (via online communications in real-time, or via offline modes such as synchronization at docking terminals). The communication may include information output from the system to the device about expected loan payments from customers on a particular date and/or information input from the device to the system such as actual transactions captured during a field visit, or information about customers that was captured to the device.
2.7. Provide certain forms of information via services that can be “queried” over the network by external ‘consumers’ such as banks and regulators

NOTE on language
In the sections that follow, for the sake of brevity, please assume ‘The system…’ as an automatic prefix to requirements that begin with verbs such as: “Allow/support/track…”, etc.
For e.g.: “Allow the organization to assign privileges to users” should be read as “The system allows the organization to assign privileges to users”3. Organization setup
3.1. Support creation of the administrative hierarchy (with an arbitrary number of levels) of the organization to represent various operating locations (such as headquarters, zonal offices, regional offices, branch offices, etc.) and allow the organization to use its own terminology for the same
3.2. Support the configuration of administrative relationships between various operating locations, as well as the various operations supported at each of the locations. Some examples of operations that may be performed at each location are as follows:
3.2.1. To administer specific financial products.
3.2.2. To admit customers and groups at a location
3.2.3. To devise specific schemes and campaigns targeted at the particular needs of customers within the purview of the location
3.3. The administrative relationships setup between locations can facilitate use of the system in many ways, for example:
3.3.1. To consolidate monetary transactions appropriately from each location for the overall impact on the organization’s finances
3.3.2. To aggregate information concerning operations such as the number of customers, groups, loans made, and loan amounts outstanding for each location, and within an administrative division such as a regional office
3.3.3. To assign ‘natural’ relationships of command (such as peer, subordinate, or superior) between associates of the organization that are functioning at different locations
3.3.4. To assign privileges in a ‘natural’ fashion, and restrict the visibility to information depending upon the position of an administrative location and its associates within the hierarchy
3.4. Support the input and formatting of branding information including logos, titles, statements of goals, and ‘boiler-plate’ information to be included in screens, reports, and elsewhere
3.5. Support the input and display of any legal, jurisdictional, and policy information. Support the input, display, and user acknowledgement within the system of any operational procedures, system usage, and disclaimer information
4. User setup
4.1. Micro-finance organizations employ a large number of people, including (but not limited to) the following:
* Field officers (aka ‘committee coordinators’) that are the primary interface with customers
* Loan officers that administer loans and review credit operations
* Tellers that accept and distribute cash and other payments for deposits made by customers, etc.
* Branch managers and managers at district, regional, or zonal offices that oversee operations, manage teams, and enforce organization policies
* Management that determines the strategy and formulates policies and plans for execution of the same
* Accountants that book monetary transactions and report the financial health of the organization
* Auditors that scrutinize the books of account and verify operations to ensure compliance with policies
* Data entry operators and system support staff that update information systems (often on behalf of other users) and assist users as needed to perform system operations
4.1.1. Allow the creation of users for associates of the organization that require identification within the system
4.2. Authenticate users using suitable security measures before granting access (please see the section on non-functional requirements for further guidelines concerning security)
4.3. Allow the organization to assign privileges to users. Privileges reflect the ability to perform certain actions in the system. Privileges also govern the information that may be accessed, viewed, and edited by users. By granting privileges to user roles, the organization mirrors the responsibilities and powers of action vested in the users.
4.4. Allow the organization to safeguard against moral hazard and financial fraud by implementing concepts such as the separation of duties, ‘maker-checker’ concepts, and appropriate visibility to information for each associate, by creating privileges and granting them to users
4.5. Support the creation and administration of coarse-grained or fine-grained privileges as desired by the organization
4.6. Support simple workflow mechanisms to help progress business processes that require coordinated action by users with different sets of privileges, such as:
4.6.1. The proofing of customer data by another user, after data is input by another associate
4.6.2. The review and sanction of loan applications by a loan officer, sandwiched between the submission of a loan application and loan disbursement by a field officer
4.6.3. Any delegation of responsibilities such as the temporary re-assignment of center meetings to an alternative field officer, when the organization stipulates that the same must be authorized by a manager
4.7. Track all access to the system and maintain logs of all actions performed by users as themselves or on behalf of other users or associates of the organization.
4.7.1. Provide the ability to report on user access and actions, for audits and investigation
4.8. An action may be performed on the system by an associate of the organization (such as a data entry operator) on behalf of another associate (such as a field officer that collected loan payments). In such cases, the system should record the identity of both the user that performed the actual transaction, as well as the user that recorded it on the system
5. Operating model
The organization specifies particular ‘preferences and defaults’ in the system to characterize its operating model
5.1. Functional preferences
5.1.1. Choice of time zones
5.1.2. Choice of languages used in the system
5.1.3. Choice of currencies and exchange rates for transactions
5.1.4. Choice of precision and rounding rules applicable to various money amounts and rates
5.1.5. Choice of accounting periods
5.1.6. Specify the legal jurisdiction over operations of the organization
Please see the section on ‘non-functional expectations’ for other ‘preferences and defaults’ that must be supported via configuration (such as ‘display-only’ aspects of localization)
5.2. Operating calendar
5.2.1. Business and non-business days of the week, business hours, holidays
5.2.2. Custom operating calendars by region for organizations operating across large spread of geographies (to accommodate local holidays, business hours, etc.)
5.3. Customer profiles
5.3.1. Age limits for customers at enrollment
5.3.2. Any gender restrictions
5.3.3. Whether loans will be made only to borrowers in groups, or to individual borrowers, or only to groups, or to all of these
5.4. Customer mobility
5.4.1. Restrictions on the movement of customers between groups, centers, and locations
5.4.2. Impact (if any) of customer mobility on customer credit history with the organization
5.5. Groups and group composition
5.5.1. The types of groups supported (such as JLG, SHG)
5.5.2. Minimum and maximum group sizes for different types of groups
5.5.3. Norms concerning group formation, such as savings history requirements for SHG groups
5.5.4. Norms for co-signing of loans and shared loan liability in groups
5.6. Group mobility
5.6.1. Norms for movement of groups between centers
5.7. Center locations
5.7.1. Number of groups that may meet at one center during a given duration of time
5.8. Center meetings
5.8.1. Time of day limits on center meetings
5.8.2. No of center meetings that can be conducted at any center during a particular duration of time
5.8.3. Norms concerning the temporary re-scheduling of center meetings including cancelation, pre-ponement, and postponement
5.8.4. Norms concerning the permanent re-scheduling of center meetings to a different time or day of week (date of month, etc.), or both
5.9. Meeting attendance norms
5.9.1. Set general and specific norms for attendance of customers at group meetings
5.10. Fees
5.10.1. Set limits to fee amounts
5.10.2. Norms for when fee amounts may be collected
5.11. Penalties
5.11.1. Set limits to penalties
5.11.2. Norms for when penalties may be levied
5.12. Caution amounts
5.12.1. Set limits to caution amounts
5.12.2. Norms for when caution amounts may be collected
5.12.3. Norms for return of caution amounts to customers
5.12.4. Norms for forfeit of caution amounts by the organization
5.13. Insurance premia
5.13.1. Specify the particular products eligible for insurance
5.13.2. Specify the mode of collection of insurance premia, whether upfront or in installments
5.14. Deposits and deposit interest rates
5.14.1. Specify whether the organization may accept deposits
5.14.2. Specify limits on deposit rates
5.14.3. Specify limits on deposit amounts
5.14.4. Specify limits on deposit tenures
5.14.5. Specify modes of payment of interest on deposits and limits on deposit interest rates
5.15. Compulsory savings
5.15.1. Specify whether compulsory savings are required from borrowers
5.15.2. Specify the rates of interest paid on compulsory savings
5.15.3. Specify restrictions on the withdrawal of compulsory savings while loans are still outstanding
5.15.4. Specify the extent to which the organization has lien over amounts in compulsory savings
5.16. Credit policies
5.16.1. Specify the minimum and maximum loan amounts allowed and any limits on total loan amounts outstanding to a single borrower
5.16.2. Specify whether loan applicants may re-apply for loans after a loan applications was declined, and any applicable cooling period between loan applications
5.16.3. Specify whether additional loans may be extended to a borrower while some loans are still outstanding
5.16.4. Specify criteria in terms of number of loans paid up (or in terms of age of existing loans, or as a percentage of existing loans paid up, etc.) before additional loans may be considered.
5.17. Loan moratoria/grace periods
5.17.1. Specify whether loan moratoria are allowed and the maximum allowed duration of loan moratoria
5.17.2. Specify whether grace periods are allowed and the maximum grace periods allowed
5.17.3. Specify whether moratoria or grace periods may be suspended or modified for individual loans at the discretion of loan officers or other responsible associates
5.18. Loan eligibility
5.18.1. Specify eligibility criteria in terms of customer profile characteristics
5.18.2. Specify eligibility criteria for subsequent loans or additional loans in terms of loan repayment history
5.19. Loan applications
5.19.1. Specify any criteria such as minimum time elapsed since formation of groups, or since a borrower joined a group, before loan applications are solicited
5.20. Loan sanction
5.20.1. Specify guidelines such as the loan amount sanctioned as a multiple of savings history demonstrated (for SHGs)
5.20.2. Specify permitted increases for subsequent loan amounts over previous loan amounts
5.20.3. Specify lists of valid reasons for declining loans
5.21. Loan disbursements
5.21.1. Specify whether partial disbursements are permitted, the number of partial loan disbursements and limits on the amounts partially disbursed as a proportion of loan amounts sanctioned
5.22. Loan delinquency
5.22.1. Specify fees and penalties that are applicable in the event of delinquency
5.22.2. Specify the impact of loan delinquency on customer credit history
5.23. Loan defaults
5.23.1. Specify aging criteria for loans to be classified as a defaulted loan
5.23.2. Specify the impact of loan default on customer credit history
5.24. Loan pre-payment or loan pre-settlement
5.24.1. Specify whether loan pre-payment or pre-settlement are permitted
5.24.2. Specify criteria in terms of when pre-payment or pre-settlement is permitted during the tenure of a loan in terms of percentage of principal amounts outstanding, or number of installments completed
5.24.3. Specify whether some or all interest will be payable as computed for the normal tenure of the loan, in the event of pre-payment or pre-settlement
5.24.4. Specify whether any penalties or fees will be levied on pre-payment or pre-settlement, and when these will be collected
5.25. Loan re-scheduling
5.25.1. Specify norms for when loan re-scheduling will be permitted
5.25.2. Specify any penalties that will be levied for loan re-scheduling, and when such penalties will be collected
5.25.3. Specify any principal or interest amounts from existing outstanding loans that will be carried over to the re-scheduled loan
5.25.4. Specify any changes to the interest rate, tenure, repayment frequency, or other aspects of the re-scheduled loan with respect to the earlier loan
5.26. Loan freeze
5.26.1. Specify whether freezing of loans is permitted and the permissible duration for freezing loans
5.26.2. Specify whether interest will continue to accrue and the rates of interest to be accrued, during the time a loan is frozen
5.26.3. Specify any penalties or fees that are charged due to loan freeze
5.26.4. Specify the impact of loan freeze on customer credit history
5.27. Invoking loan insurance
5.27.1. Specify the loan products subscribe loan insurance
5.27.2. Specify the scenarios under which the organization or the borrower will make an insurance claim
5.28. Interest rates
5.28.1. Specify limits on interest rates
5.29. Interest calculation and accrual
5.29.1. Specify the allowed modes of interest calculation including declining balance, flat interest, etc.
5.29.2. Specify the calculation and accrual of interest to deposits made by customers on a periodic basis, or on demand, or at the time of withdrawal of deposits, or all of the above
5.30. Allocation of amounts to principal and interest
5.30.1. Specify the proportion in which advance amounts (amounts paid ahead of scheduled installments) or overdue amounts (delayed payments) must be allocated between principal and interest
6. Financial products
6.1. Loan products
6.1.1. Allow the creation of loan products that serve as templates for loans that will be made by the organization
6.1.2. Loan products are identified by name and capture “standardized” information about loan amounts, loan tenures and frequency of repayment, interest rates, mechanism of interest calculation, fees, intended purpose of loans, sources of funds, loan insurance, and loan product validity. [TO BE ADDED…see appendix on data items]
6.1.3. Allow the loan products to be assigned particular charges such as fees, caution amounts, penalties, and insurance premia
6.1.4. Allow the assignment of loan products to sanctioned loans
6.2. Deposit products
6.2.1. Allow the creation of deposit products that serve as templates for deposits accepted by the organization
6.2.2. Deposit products are identified by name and capture “standardized” information about deposit minimum amounts, deposit tenures, rates of interest, modes of interest payment including simple or compound interest, interest accrual periods, deposit withdrawal restrictions, deposit renewal modes, and deposit product validity. [TO BE ADDED…see appendix on data items]
6.2.3. Allow the assignment of deposit products to accepted deposits
6.3. Compulsory savings
6.3.1. Allow the creation of compulsory savings products by borrowers (a form of deposit product that cannot be withdrawn while loans are outstanding)
6.3.2. Support the recovery of outstanding loan amounts from compulsory savings by the borrower to the extent of the lien held by the organization
7. Charges
7.1. Interest
7.1.1. Support indexing of interest rates to benchmark interest rates controlled by the organization
7.1.2. Support multiple mechanisms for computation of interest (such as declining balance, flat interest, etc.)
7.1.3. Support the accrual of interest to loan accounts as well as deposits
7.2. Fees
7.2.1. Support the creation of fee templates for fee income collected by the organization
7.2.2. The fee templates may include the name of the fee, the incidence of the fee (i.e., when the fee is collected), the fee as an absolute amount or percentage of another amount, whether the fee is charged one-time or on a recurring basis, and whether the fee is refundable.
7.3. Caution amounts
7.3.1. Allow the creation of templates for caution amounts collected by the organization
7.3.2. The templates for caution amounts may indicate when caution amounts are collected and returned, the amounts as absolute amounts or percentages of other amounts, whether or not the organization pays interest or incentives on caution amounts, and the rates of interest, or amounts of incentives paid.
7.4. Insurance premia
7.4.1. Allow the creation of templates for insurance premia collected
7.4.2. The templates for premia may indicate the underlying insurance product for the premium, when premia are collected (whether upfront or as installments alongside loan payments), and the premia amounts
7.5. Penalties
7.5.1. Allow the creation of templates for penalties levied on customers
7.5.2. The templates for penalties may indicate the cause for the penalty to be levied, when and how the penalty is collected, and the amounts of penalties
7.6. Incentives
7.6.1. Allow the creation of templates for incentives paid to customers
7.6.2. The templates for incentives may indicate the reasons for incentives, when and how the incentive amounts are paid, and the amounts of incentives
8. Customers
8.1. Allow the capture of information for customers that is required to fulfill “Know-your-customer” (KYC) norms as stipulated by a regulatory agency and/or by the organization
8.1.1. Allow the generation of custom reports to demonstrate compliance with KYC norms
8.1.2. Allow the maintenance of customer information with respect to changes in KYC norms over a period of time, without requiring substantial rework
8.2. Notwithstanding the requirements for KYC compliance, allow the capture of customer information for:
8.2.1. Identity (including visual identification)
8.2.2. Residence and domicile
8.2.3. Occupation
8.2.4. Demographics
8.2.5. Economic status (assets, sources of income, etc.)
8.2.6. Standards of living (including measures such as access to healthcare, education, drinking water, sanitation, etc.)
[TO BE ADDED…see appendix on data items]
8.3. Allow manifests itemizing and describing documentation that was collected from customers
8.4. (Optionally) Allow two-stage input and verification of customer information to ensure accuracy
8.5. Allow the organization the ability to control whether certain information about customers (which may be sensitive or confidential) is to be screened from search or display of customer information
8.6. Allow the incremental updates of certain aspects of customer information while restricting edits to “invariant” aspects of customer information
For e.g., when customers move from one residence to another, the system allows additions to address information, however, a ‘date of birth’ cannot be edited.
8.7. Qualify the customer status with respect to customer activity vis-à-vis microfinance, such as an active, dormant, or inactive customer, etc.
8.8. Support mechanisms to identify potential instances where an individual may have been registered multiple times with the organization due to error or attempted fraud. (Comment: Such mechanisms may require the incorporation of methods of biometric identification of individuals)
8.9. Support “audit” mechanisms for the organization to identify subsets of customers whose information must be reviewed, verified, and updated in a timely manner (author’s comment: This is a vague requirement that needs to be elaborated)
8.10. Customer accounts
8.10.1. Support customer accounts that reflect the customer’s associations with particular loans and other financial products that a customer uses.
8.10.2. Support the view of all transactions involving the customer via the customer account or accounts
8.11. Customer history
8.11.1. Customer credit history
8.11.1.1. Maintain a complete record of all loan activity as well as any incidents of loan delinquency or loan default
8.11.1.2. Allow scoring of credit history using simple rules that are assigned by the organization
8.11.2. Measuring social impact (or measuring “progress out of poverty”)
8.11.2.1. Allow scoring (or computation of indicators) of the socio-economic status of borrowers
8.11.2.2. Compute the scores from time-to-time and preserve the history of the same
9. Groups and center locations
9.1. Add center locations identified by name, location, date of formation, associated field officers and loan officers (if any), and the associated branch or other administrative locations [TO BE ADDED…see appendix on data items]
9.2. Add groups classified by the allowed types of groups
9.3. Capture information about events of significance in the evolution of groups (such as dates of formation, and date of resolution by SHG groups)
9.4. Allow the maintenance of financial information for groups (such as bank passbook balances for SHG groups)
9.5. Associate groups with center locations
9.6. Specify the frequency of group meetings at center locations and the day of the week, date of the month, or other indicative schedule for center meetings
9.7. Specify the nominal timing and duration of group meetings in terms of start and end times on meeting dates. Alert the organization to potential meeting conflicts with the nominal schedules for other center meetings
9.8. Specify the start date of group meetings
9.9. Identify customers as members of groups
9.10. Assign titles within groups (such as group leaders, secretary, or book-keeper) and specify the customers that are assigned these titles (from time to time)
9.11. Support movement of groups between center locations, if permitted
9.12. Support movement of borrowers between groups, if permitted
9.13. Re-assign field officers, loan officers, or other associates to groups, when needed
10. Micro-credit operations
10.1. Loan applications, loan application review, and loan sanctions
10.1.1. Allow users to record loan applications for customers including loan amount, loan tenure, loan purpose, loan application date, manifests of documentation, and the field officer or other representative that accepted the loan application [TO BE ADDED… see appendix on data items]
10.1.2. (Optionally) If an associate is responsible for verifying information provided by the applicant, allow the associate to indicate the outcome of verification
10.1.3. Allow review of loan applications for decisions on loan sanction. Enable easy navigation to information about the applicant and the applicant’s financial record to help answer questions during loan application review, such as:
* Are there any loans currently outstanding to the applicant?
* What is the repayment history of the applicant on past loans from the organization?
* Is the stated loan purpose consistent with the occupation of the applicant?
* If the applicant is a member of a self-help group, what is the savings record of the applicant?
10.1.3.1. Record a decision on loan sanction, reasons for the decision, and any annotations made by the reviewer to the loan application. Annotations may include:
10.1.3.1.1. Sanctioning a loan amount that is different from the loan amount applied for
10.1.3.1.2. Specifying the need for additional or alternative documentation to be made available
10.1.3.2. For sanctioned loans, allow assignment of loan product by the reviewer
10.1.3.3. Record the review decision in a history of loan applications for the customer
10.1.3.4. For sanctioned loans, allow the assignment of default or custom deadlines for disbursement of loan amounts and commencement of loan tenure.
10.1.3.5. (Optionally) Allow deferring the decision of loan review subject to the request of additional information (specified through annotations on the loan application) by speaker such case, allow further editing of the loan application before it is reviewed again.
10.2. Loan disbursements
10.2.1. Record the disbursements of loans in full, or in parts and ensure that the sum of partial disbursements do not exceed sanctioned loan amounts
10.3. Loan repayment
10.3.1. Generate the (nominal) amortization schedule for loan amounts disbursed taking into account the following:
10.3.1.1. The loan amount disbursed
10.3.1.2. The rate of interest and the mode of interest computation
10.3.1.3. The loan tenure
10.3.1.4. The frequency of repayment
10.3.1.5. Any moratorium or grace periods
10.3.2. Allow custom editing of the nominal amortization schedule to suit the collection practices of the organization. Once such edits are complete, the amortization schedule thus created may be associated with particular loans and loan products as the ‘effective’ amortization schedule (as opposed to the ‘nominal’ amortization schedules computed by the system)
10.3.3. Support the computation and display of effective interest rates, loan tenures, and other loan characteristics for the effective amortization schedules used by the organization
10.3.4. Supply the anticipated principal and interest payments (as per the amortization schedule) for loans as an input to the generation of collection sheets to be used by field officers (or other representatives) responsible for collecting loan principal and interest payments
10.3.4.1. Supply any anticipated fees, caution amounts, penalties, and other amounts to be collected from (or returned to) borrowers from time to time
10.3.5. Record the actual amounts of principal and interest payments received from time to time
10.3.5.1. If the organization issues numbered receipts to borrowers when collecting loan payments, allow recording of serial numbers of the vouchers issued.
10.3.5.2. Support updates to the loan amounts received to reflect the loan amounts anticipated using the convention ‘received, unless otherwise indicated’, before edits are made to record actual amounts. (Comment: loan repayments on time are the norm in micro-finance, and minimum effort must be expended to record payments). Similarly, the system should efficiently support ‘bulk updates’ such as “sanction loans applied for by all borrowers in group X” in a manner that does not require a user to repetitively sanction loans for each borrower in group X.
10.3.6. Record the actual amounts of fees, caution amounts, penalties and other amounts collected from (or paid to) borrowers
10.3.7. Record instances of non-payment, underpayment, and overpayment
10.3.8. Update the loan outstanding principal amount and interest received amounts, and accumulate delays in payment
10.3.9. In the event of advance or delayed payments, allocate amounts received towards principal and interest in the specified proportions
10.3.10. Supply any changes in anticipated principal and interest amounts, as well as overdue amounts to the generation of collection sheets
10.3.10.1. Supply any new fees, penalties, or other amounts that are due from customers due to delinquency
10.3.11. Record the closure of loans and report any excess amounts received from customers to be refunded, as well as any other amounts that must be returned to customers (such as caution amounts)
10.4. Loan pre-payment
10.4.1. Allow the computation of the principal amount, interest amount, and any penalties or fees to be collected, to be used as estimated amounts due from customers when pre-paying loans
10.4.2. Record the principal, interest, and other amounts received as pre-payment
10.4.3. Close the loan if all outstanding amounts are paid in full. Else, re-calculate the outstanding loan principal and interest amounts and when required, regenerate the amortization schedule for the remainder of the loan
10.5. Loan moratoria/grace periods
10.5.1. Take into account any loan moratoria or grace periods that are in effect to compute the principal and interest payments due as particular installments when generating demand sheets
10.5.2. Accrue interest payable during loan moratoria or grace periods according to the specified norms
10.5.3. [TO BE ADDED…]
10.6. Loan delinquency
10.6.1. Record instances when a loan payment due is not paid on time or not paid in full
10.6.2. Adjust the anticipated principal and interest payments due and apply any penalties and fees
10.6.3. [TO BE ADDED…]
10.7. Loan defaults
10.7.1. When it is determined that a loan is in default, write off the loan and book losses as per the accounting norms (discussed later)
10.7.2. Recover any principal and interest due from available caution amounts
10.7.3. Update the credit history of the borrower that defaulted the loan to include the default event
10.7.4. [TO BE ADDED…]
10.8. Insurance claims
10.8.1. Support filing claims for insurance in the course of repayment of loans (when a borrower is rendered temporarily or permanently unable to repay the loan due to disability or death)
10.8.2. Appropriate any outstanding loan amounts from the insurance proceeds (as prescribed by norms) and process the closure of the loan
10.9. Loan re-scheduling
10.9.1. Support re-scheduling loans as per the specified norms for re-scheduling
10.9.2. [TO BE ADDED]
10.10. Loan freeze
10.10.1. Support freezing loans as per the specified norms for loan freeze
10.10.2. [TO BE ADDED]
10.11. Sources of funds and funding lines
10.11.1. Allow the registration of specific sources of funds (such as banks, grant-giving organizations, or internal accruals) made available for on-lending to micro-credit borrowers
10.11.2. Allow the creation of funding lines representing particular fund amounts provided by one or more sources of funds
10.11.3. Allow stipulations on the use of funding lines for specific purposes or loans
10.11.4. Allow the assignment of funding lines to specific loan products
11. Operations Support
11.1. Center meetings
11.1.1. Generate schedules for center meetings using the meeting frequency, appointed day of the week/date of the month, and start and end-times registered for the meeting, and field officers and other representatives that are responsible for transacting business at the center meetings
11.1.2. Support temporary cancellation or re-scheduling of particular instances of center meetings on account of holidays, etc.
11.1.3. Support permanent re-scheduling of center meetings to different dates and times
11.1.4. Support temporary delegation between field officers of the need to represent the organization at center meetings and transact business concerning loans, etc.
11.1.5. Capture attendance for borrowers at center meetings, as per the attendance norms stipulated by the organization
11.2. Demand sheets (a.k.a. “collection sheets”)
11.2.1. Generate demand sheets for the anticipated loan disbursements, principal, interest, overdue amounts, fees, caution amounts, penalties to be collected or paid out at center meetings for the day
11.2.2. Demand sheets must take into account known information about center meeting schedules (including temporary cancellation or re-scheduling), the field officers assigned to the center meetings, and the groups and borrowers that must make payments on the day.
11.2.3. Record the transactions arising from completed demand sheets submitted by field officers after the conclusion of center meetings as well as other information such as attendance of borrowers at group meetings
12. Accounting
12.1. Allow the setup of chart of accounts for the organization
12.2. Allow the creation of individual accounts with the associated account code used to identify the account in the general ledger
12.3. Allow the setup of account heads (such as assets, liabilities, and revenues) and assign each individual account to account heads at the general ledger and sub-ledgers.
12.4. Allow the organization to specify the level of detail at which ledgers are maintained such as loan ledgers for groups of borrowers as a whole or loan ledgers for individual borrowers, and the particular locations (offices) that ledgers are created for.
12.5. Allow the organization to specify accounting periods for the consolidation of books of accounts. Also allow the organization to allow or disallow new accounting entries to be posted to particular dates or ranges of dates.
12.6. Allow the organization to specify and control various other parameters that are relevant to accounting, such as the choice and application of rounding rules in the computation of money amounts
12.7. Allow opening balances to be set for all accounts
12.8. Allow the organization to configure rules to be used by the system to automatically generate the corresponding accounting entries for all of the monetary transactions performed in micro-credit operations. (Comment: Such rules simplify the task of accounting by suggesting and using suitable defaults for book-keeping entries)
12.8.1. Each rule consists of instructions to generate balancing credits and debits to particular accounts (using the double-entry system of book-keeping) for all monetary transactions associated with micro-credit operations
12.8.2. Each rule also includes information to identify the particular ledgers and accounts to update, as well as the date and time, amount, and text to use for narrations, based on information such as the location, group, customer, or associate of the organization that is involved in the transaction
For e.g., for principal received during loan repayment, the system credits the loan ledger for the client (or group) and debits the appropriate cash account for the branch of the organization that administers the borrower or group
12.9. Allow editing the particular accounting entries that will be made for each monetary transaction, overriding any defaults inferred from the rules configured
12.10. Allow direct accounting entries to be made for bank transactions, vouchers, debit notes, credit notes, journal entries, etc.
12.11. A (partial) list of monetary transactions arising from micro-credit operations is given below:
12.11.1. Loan disbursed
12.11.2. Various fees collected from borrowers
12.11.3. Caution amounts collected from, or returned to borrowers
12.11.4. Principal repayment by borrowers
12.11.5. Interest payment by borrowers
12.11.6. Excess money refunded to borrowers
12.11.7. Incentives paid to borrowers
12.11.8. Outstanding loan amounts settled using money received against insurance claims
12.11.9. Money received against insurance claims paid to borrower or survivors
12.11.10. Pre-payment of loan by borrowers
12.11.11. Loan write-off
12.11.12. Penalties collected from borrowers
12.11.13. Funds received from or paid to a source of funding
12.11.14. Interest amounts paid to sources of funding
12.11.15. Cash received or paid out for various sundry purposes
12.11.16. Banking transactions including deposits, withdrawals, and money transfers in bank accounts
12.11.17. Transfers of money between various branches of the same organization
12.11.18. Temporary excess or shortfall in money amounts resulting from adjustments of money paid or charged to borrowers due to rounding rules
12.12. Allow ad-hoc journal entries to be made
12.13. Generate trial balances on demand for arbitrary accounts
12.14. Generate accounting statements include balance sheets and profit and loss statements for administrative sub-divisions or for the organization as a whole for particular accounting periods
12.15. Permit both the import and export of the chart of accounts, as well as the accounting entries between the system and other accounting systems in commonly accepted and open formats
12.16. Support for audits
12.16.1. [TO BE ADDED…]
13. Reporting
13.1. Allow searching, selecting, aggregating, correlating, comparing, merging, organizing, sorting, tabulating, summarizing, and presenting data within the system in order to generate reports and compute indicators conveying information on the following functional aspects (at the very least): scope and spread of operations, customer base, activity of associates, portfolio of loans and other financial products, and financial health
13.2. Support the computation and display (for e.g., via dashboards) of various indicators used to track various aspects of organization performance. The various categories of indicators with some examples of each are given below:
13.2.1. Portfolio quality: Portfolio-at-risk, loan loss reserve ratio
13.2.2. Profitability: Return on assets, Return on equity
13.2.3. Financial solvency: Debt-to-equity ratio, net interest margin
13.2.4. Growth: Growth in portfolio, growth in borrowers
13.2.5. Outreach: number of active clients, dropout rate
13.2.6. Productivity: active borrowers per loan officer, active borrower groups per loan officer
13.3. Support the design of reports that take into account the following aspects concerning the intended use of the report:
13.3.1. Audience for the report
13.3.1.1. Field officers, loan officers, and their managers need operational information for day-to-day execution
13.3.1.2. Management needs strategic information
13.3.1.3. External audiences including auditors, regulators, and sectoral bodies need summary information, sometimes in specific formats
13.3.2. Desired level of detail or aggregation
13.3.2.1. Information that drills down to individual field officers, borrowers, branches, centers, groups, or loans, etc.
13.3.2.2. Aggregates across branches, associates, centers, groups, loans, etc.
13.3.3. Time scope
13.3.3.1. Duration of time represented in the report: point-in-time, trend with time, year-on-year, etc.
13.3.3.2. Frequency with which reports must be re-generated: daily, weekly, monthly, etc.
13.3.4. Presentation formats
13.3.4.1. Text-based and tabular
13.3.4.2. Graphs and charts
More comments on the usability of reports will be provided in the section on non-functional aspects of the system
13.4. Scope and spread of operations
13.4.1. Number and growth of administrative locations including divisions and branches
13.4.2. Number and growth of centers, groups, borrowers; trends including new borrowers, dropout borrowers, etc.
13.4.3. Number of centers, groups, borrowers by field officers, loan officers, branches, and divisions, and by loan portfolio size
13.4.4. Concentration of centers, groups, borrowers
13.4.5. Information on groups and borrowers including attendance
13.4.6. Number and growth of associates by role and by location
13.5. Customer base
13.5.1. Profiles of members indexed along various parameters (such as occupation, age, gender, income levels, location, ethnicity, etc.) and trends
13.5.2. Socio-economic status and trends, correlation if any with operations of the organization
13.6. Activity of associates and borrowers
13.6.1. Employee case load, measures of productivity as well as loan performance
13.6.2. Applied, sanctioned, and disbursed loans by branches, loan officers, field officers
13.6.3. Demand and collections reports, demand vs. collection
13.6.4. Staff incentive report
13.6.5. Group membership report
13.7. Portfolio of loans and financial products
13.7.1. Total loan portfolio, loans outstanding
13.7.2. Comparison of loan sizes, average loan size, loans by cycle
13.7.3. Delinquent loans, aging of delinquent loans
13.8. Finances
13.8.1. Daily payments and receipts
13.8.2. Aging of portfolio at risk
13.8.3. Balance sheet
13.8.4. Income statement (Profit and loss statement)
13.8.5. Cash flow statement
14. System monitoring and administration
14.1. Support the logging and monitoring of all access by users and user activity in the system
14.2. Support the logging and monitoring of all financial activity
14.3. Support the logging and monitoring of changes to the elements of data within the system such as customers, groups, centers, loans, etc.
14.4. Support the administration of users including the creation of users, user roles, privileges, and the assignment of privileges to users by granting them user roles.
14.5. Support the administration of user access to the system including enabling, disabling, or revoking user access, and user authentication
14.6. Support the performance of all of the monitoring and administration actions via administrative privileges that are only available to a subset of users via administrative user roles, and manage the membership of users in such administrative roles.
15. Expectations concerning non-functional aspects
(Note: This section is work-in-progress)
Even when functional needs are substantially met, systems must perform well on non-functional aspects so that users may exploit the functionality of a system to its fullest. The non-functional characteristics of the system, therefore, impinge on the functional needs in more ways than one.
To practitioners in IT systems, many of the following may read like self-evident and automatic expectations from production-ready software systems. However, the fact remains that most MIS systems currently in use by MFIs fall short on more counts than one.
15.1. Usability
15.1.1. Branding
15.1.1.1. Support the configuration and display of branding information for the organization
15.1.2. Display-related aspects of localization
15.1.2.1. Support the specification of default and user-specific choices for information such as the display of dates, times, numbers, money amounts, currencies, etc.
15.1.3. Searching
15.1.3.1. Support searching over all the significant data elements in the system including customers, groups, centers, offices, users, products, transactions, etc. to rapidly locate and retrieve information
15.1.4. Navigating and viewing data
15.1.4.1. Guide user actions and choices, and alert users to business constraints that forbid certain actions before they are attempted (to the extent possible)
15.1.4.2. Support easy navigation of large amounts of data through mechanisms like sorting, filtering, preview, pagination, and ‘hyper-linking’
15.1.5. Classifying and enumerating information
15.1.5.1. As an example, consider the need to standardize lists of occupation of borrowers. Such lists evidently vary from organization to organization and also change over time. The system should enable the organization to create, administer, and re-use such lists as needed.
15.1.6. Customizable user experience via user preferences
15.1.6.1. Allow users to choose display sizes, formats, layout, language, navigation, and other aspects of user experience and preserve these across user sessions via preferences
15.1.6.2. Allow users to set session-specific information such as current user role, transaction dates and formats for data input, and other contextual information that are required repeatedly by the system
15.1.7. Using and navigating reports
15.1.7.1. Ensure that reports include context information such as when the report was generated and for what durations of time, the scope (data ranges that are reported on, and the parameters used as bounds or filters, significant annotations, disclosures, and disclaimers with cross-references), and other aspects such as branding, and meta-information (such as the number of pages, etc.)
15.1.7.2. Allow the reproduction of the report in various formats (including print-friendly ones such as PDF)
15.2. Users and user habits
15.2.1. The field officers perform most of the credit operations including identifying borrowers, forming groups, creating centers, obtaining loan application, disbursing loans, and collecting loan repayments. Field officers spend the majority of their day in the field traveling between centre locations and some time at the branch or office location completing paperwork and meeting with other staff.
15.2.2. In many instances, the field officers themselves may login to and input the data required by the MIS system, usually as and when time permits, or at convenient intervals, such as once a week. Frequently, an administrative assistant is responsible for operating the system on behalf of field officers and other staff at a branch location.
15.2.3. In the event that the MIS system is inaccessible to a field officer, many MFIs make do by sending a dispatch of the necessary statements (such as loan demand sheets) to field officers, and the field officers send completed paperwork and other documentation (including information for new borrowers, loan applications, bank deposit counterfoils, etc.) back to the headquarters or other location for data entry, once every few weeks or so.
15.2.4. Several MFIs had small teams of data entry operators and other IT support staff at the head office to care for the MIS system. Besides assisting with ensuring that data in the MIS system is updated, the support staff was also responsible for responding to management’s needs for all kinds of reports, consolidating data from multiple system installations, backing up data, responding to support requests from other locations, and so on.
15.2.5. In many cases, any MIS system in use is the only computer system that the staff is exposed to. (That is, the MIS system is generally not used alongside other systems prevalent in corporate environments elsewhere, such as word processing, Intranets, e-mail, payroll, etc.) In our opinion, this is both unfortunate as well as a lost opportunity (till date). This is unfortunate, in that all of the MIS systems that we came across were dismal with respect to usability. This is an opportunity, in that user expectations are not molded by exposure to other software, and the MIS system is free to introduce its own idioms of usage.
15.3. Access
15.3.1. Ideally, the system consists of a single installation that is accessed more or less in the same way by associates at all locations, either locally or remotely. This greatly simplifies the task of maintaining data across the organization, consolidating data for review, and administering all of the operations and usage of the system.
15.3.2. If this is not considered feasible, practical, or cost-effective, the organization may require multiple installations of the MIS at each location that requires access, or is able to provide substantial access to an installation.
15.3.3. If there are multiple installations of the MIS system, with each installation housing data for only some subset of the organization’s operations, the system should support seamless “merging” of some or all of the data from all of these installations at one or more places to provide a comprehensive view of the complete operations, and enable direct reporting over all of the operations.
15.3.3.1. Such merging should require no manual intervention (or minimal manual intervention): manual intervention scales poorly with increasing number of installations, and inevitably results in costly and difficult-to-detect errors.
15.3.4. In any case, the system should not impose limitations such as each installation supporting only a branch, division, or other artificial subset of the MFI’s operations and data.
15.3.5. (Contrary to some perceptions or, perhaps hype?) There is no stated or implied need for continuously available power or internet connectivity to enable the use of a modern MIS system. We do not even assume that handheld or other mobile devices compensate by providing some form of “ubiquitous access”. A small window of time during which the system is available every day or even every few days was adequate in most cases to meet the needs of obtaining data from or supplying data to any particular field location.
15.4. Security
15.4.1. Include mature authentication support (including enforcing strong passwords, encryption of passwords, user lockout, logging of all access, last login time display, self-service password reset, etc.)
15.4.2. Support secure access over networks
15.4.3. Support the logging of all actions by users and the search and display of such logs
15.4.4. Support self-service functions such as password reset to allow legitimate users to regain access. The presence of ‘back-doors’ that were known to everyone (and their neighbors) in the MIS systems we reviewed makes a mockery of user authentication.
15.5. Data integrity, data retention, and data portability
15.5.1. Systems must support “versioning” of data.
A customer when admitted to the MFI may take several loans over long periods of time, as a member of different groups and interact with different associates of the organization, especially if she moves home during this time. Furthermore, she may experience changes with respect to socio-economic status, her ability or need to borrow or repay, and occupations that she engages in. The loan products and credit policies of the organization may evolve and differ greatly over a period of time. The scope and spread of its operations may wax and wane. Field officers and loan officers move between branches or leave the organization.
However, every MIS system we looked at modeled all of these elements and the associations between them using a static perspective with respect to display and data storage. For example, a customer has a single profile, is a member of a single group that is administered by a single field officer at every point in time. Any changes to the information did not preserve a history of older information.
15.5.2. Issues with quality of data do not result from any lack of “always on” access. Rather, we suspect that they result from the inflexible and short-sighted design of the MIS systems. For e.g., one MIS system was incapable of tracking loans to a detail finer than the SHG that loans were extended to. It simply had no provision to track customers as individuals.
15.5.3. Support “automatic” data backup and restore requiring minimal manual intervention
15.5.4. Support requirements for data retention (such as preserving customer KYC records online for ‘m’ years, and in offline storage for ‘n’ years, the choice of m and n being made by the organization as per policy)
15.6. Migration and support
15.6.1. The system should ship with suitable templates and appropriate defaults for system configuration that help the organization to better configure the system for their needs
15.6.2. Ensure that new system adoption and data migration exercises consume minimal windows of time. It was observed that if the time taken to adopt a new system (due to typical activities including setup, configuration, data input and migration, user setup, training, testing, and roll-out) exceeds several times the pre-dominant frequency of repayment for loans made by the MFI (such as weekly or monthly); by the time the new system is ready for use, there is already a backlog of data to be updated from operations in the interim period. Smaller organizations may lack the stamina and the resources to play catch-up.
15.6.3. Ensure upgrades are smooth and involve the minimum outages and downtime.
15.6.4. Ensure that regular report (re-)design and proofing for existing and new reports can be performed by trained users without requiring intervention of technical personnel. For e.g., use of the popular ‘Crystal Reports’ reporting tool requires ‘compilation’ of report designs and is a task best left to programmers.
15.6.5. Enable user self-service through the provision of adequate documentation and training resources that are kept current with further releases
15.6.6. Provide both remote and on-site support via a number of channels (such as e-mail, telephonic, etc.) to help resolve system issues with good turnaround times
15.6.7. Incorporate mechanisms within the system to capture information about errors that can be communicated to a remote technical support team to assist with troubleshooting, and to recreate errors.
15.7. Reliability and availability
15.7.1. Ensure that the system has a mechanism to trap known and unknown errors, displays intelligible error messages and troubleshooting information, and allows users to save and recover their work to the extent possible, in the event that the system cannot recover from certain errors and must shut down
15.7.2. Ensure that the system is architected in a way that allows the organization to scale with their needs by adding system resources without the need to re-configure the system or port data to a different data store
16. Appendix A- MFI operations- in a minute
For the person that may not be familiar with the functioning of MFIs in India, the following is a whirlwind introduction to typical operations of an MFI organization. (Caution: this account is deliberately oversimplified and will not help understand all of the various scenarios encountered by MFIs in day-to-day operations.)
* The MIS system primarily serves the needs of an MFI organization (hereinafter, simply referred to as organization)
* The organization may function in a wide geographical area, setting up offices, branches, and other administrative locations.
* The organization employs staff including managers, loan officers, field officers, accountants, auditors, etc., to carry out its operations.
* The organization chooses commonly accepted models in micro-finance such as JLG (joint-liability group) or SHG (self-help group) to bring together borrowers in groups. SHG groups differ from JLG significantly in one respect, that members of SHG groups must collectively demonstrate a history of consistent savings by opening an account with a local bank branch.
* Field officers identify borrowers, help organize them into groups, and provide necessary orientation, at locations in the field that are called ‘centers’. MFIs may also lend to individual borrowers that are not a member of any group.
* A center is a temporary meeting place (usually the residence of a borrower) at which all of the interactions between field officers and borrowers take place. Multiple groups typically meet briefly at centers at scheduled times on a regular basis, such as once a week.
* Borrowers apply to the organization for loans, and their loan applications are scrutinized and physical verification completed (including residence, occupation, etc.) before loans are sanctioned.
* Once loans are sanctioned and disbursed, the field officers collect regular principal and interest payments from borrowers at center meetings, until the loans are fully paid up.
* Borrowers may opt to take higher loan amounts in subsequent loans up to limits imposed by the organization.
* The organization in turn, raises funds for credit operations through grants or loans from banks, etc.
17. Appendix B- Questionnaire used to solicit requirements
Note: The following questionnaire was submitted (via e-mail) to the concerned persons at MFIs that the author visited to solicit their requirements from MIS systems
1) What are the key benefits to me from using an MIS system?
For e.g.: save paperwork for field staff, produce reports easily, etc.

2) Which of my business processes can be automated by the MIS system?
For e.g.: capturing borrower profile, approving loans, printing collection sheets, etc.

3) Who will be the regular users of the system?
For e.g.: field officers, loan administrators, management, auditors, etc.

4) What will make the system popular with these users?
For e.g.: quick and easy operation, choice of languages, access from the field, etc.

5) What financial products, models, etc. must the system support?
For e.g.:
Financial products are micro-credit, savings, etc.
Models are JLG, SHG, individual loans, etc.

6) What are the specific paper and other forms, reporting formats, etc. that are used to be modeled by the system? Kindly gather samples for illustration.
For e.g.: loan application form, dashboard for management, etc.

7) With any existing system being used or evaluated, what are the features and capabilities that are highly useful?

8) With any existing system being used or evaluated, what are the opportunities for improvements and enhancements?

9) What are the system operating restrictions to keep in mind?
For e.g., less infrastructure, unstable power or internet access, etc.

10) What are the needs and concerns about performance, reliability, data backup, security, etc.?
For e.g., stability of system, privacy of borrower data, audit trail of changes, etc.

11) What are the other systems or processes the system must integrate with?
For e.g., accounting software, e-mail, etc.

And please add any other concerns or needs that were not addressed by these questions...
18. Appendix C- Data items for elements of MIS
Data item
Description
Remarks
Data element: Customer
[TO BE ADDED…]

Glossary
Term
Explanation
[TO BE ADDED…]
Sources and credits
* This list of initial participants and supporters (in reverse alphabetical order) is partial at best: Suyash Rai, Smitha Ram, Shivaprakash Devaiah, Sanjeev Yadav, S P Meher, Ritesh, Ramakrishna N K, Nagendra N, Manoj Mahapatra, Manjunath, K C Mallick, IFMR Foundation, Hepsiba Bala, Ganesh E K, Doug Johnson, Debabrata Mallick, Chandra Balan, Bindu Ananth, Anup, Anand Sahasranaman
* Several MIS systems including ones sold by vendors as well as others developed in-house by MFIs were reviewed during this exercise. We have decided not to name these proprietary systems or identify their users directly, as we do not intend to publish a review of these systems with or without the consent of their vendors or users.
* MIFOS- the open-source MIS system for MFIs (by the Grameen Foundation, USA) was also reviewed.
* Concepts and examples for the section on reporting were sourced extensively from: Management Information Systems for Microfinance Institutions- A Handbook, by Charles Waterfield and Nick Ramsing (Technical Tool Series No. 1, February 1998 published by CGAP/World Bank)
Requirements Outline for an MIS system for MFIs in India