We provide a reference mobile wallet application for consumers and merchants that has been developed by our  Google Summer of Code interns from 2017 to 2019. The mobile wallet provides an extensible mobile wallet framework to support the basic use cases of a mobile wallet as documented in the Level One Project mobile wallet requirements. This extensible framework should support both merchant and client use cases as well as be capable of integrating with a Fineract or Fineract CN back-end.

Over time, we would like Mifos X to be more generically a wallet management system and this reference application is a powerful tool to support that. 

In 2020 we aim to complete an MVP of a mobile wallet on top of the Fineract CN back-end so most of the major work will be around Fineract CN and Payment Hub integration and improving peer to peer and merchant transactions (initiating transactions to merchants, maintaining history of users with which recent transactions took place, adding deeplink support for unique payment links, payment related notifications using FCM). Payment Hub and Mojaloop integration will allow us to make payments across tenants and fineract deployments. A very basic integration of payment hub with mobile wallet is already in work but that will need to be extended to fully support all use cases.

By providing an extensible mobile wallet framework, allow partners a complete reference stack of back and front-end applications to offer digital financial services to clients.

2019 Mobile Wallet Progress: https://gist.github.com/shiv07tiwari/acb5a7266fe685e8332498fd32b00bf0

Mobile Wallet Framework: Source Code | Issue Tracker | Gitter Chatroom

See https://openmf.github.io/mobileapps.github.io/

Just as we have a mobile field operations app on Apache Fineract 1.0, we have recently built out on top of the brand new Apache Fineract CN micro-services architecture, an initial version of a mobile field operations app with an MVP architecture and material design. Given the flexibily of the new architecture and its ability to support different methodologies - MFIs, credit unions, cooperatives, savings groups, agent banking, etc - this mobile app will have different flavors and workflows and functionalities. 

In 2019, our Google Summer of Code intern worked on additional functionality in the Fineract CN mobile app. In 2020, the student will work on the following tasks:

• Add in support for creation of Centers
• Extend Kotlin support in app and continue changing the retrofit models in kotlin.
• Offline mode via Couchbase support
• Integrate with Payment Hub to enable disbursement via Mobile Money API
• Add GIS features like location tracking, dropping of pin into the app
• Add Task management features into the app. 
• Enable collection of data in field via the app.
• Build and design interface for bulk collections 

Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs.

To demonstrate these Open Banking APIs and use cases that third parties and fintechs can provide we would like to developer a reference mobile app to showcase a number of these features. We would like for the app to be cross-platform (framework/language to be chosen - React Native, NativeScript, Flutter, Kotlin, etc) and we will use the UK Open Banking API standard. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.)

The breadth and variety of apps that could be built leveraging these APIs from region to region is endless. We would like this app to be built in an extensible and modular fashion such that core libraries and components could be re-used across different use cases with this framework as the foundation and multiple reference apps on top. Applications include personal financial management apps aggregating information from multiple bank accounts in one place, wallet apps allowing payments to be made from different banks, lending apps, leveraging data and insight from multiple accounts, savings apps, etc.

By providing an extensible open banking fintech app framework, allow partners a complete stack of Open Banking APIs and reference front-end application to rapidly build innovation via Open Banking APIs.   

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e

See https://openmf.github.io/mobileapps.github.io/

Our AngularWeb App is the standard application on the Mifos X distribution that provides all the core functionality for the most common methods of financial inclusion and products and services. It's also the starting point for any partners looking to customize or extend the UI. It's constantly being improved based on user feedback, better performance, and to integrate new design standards.

In 2018, we made the decision to re-write the entire Mifos X web app from Angular 1.75 to Angular 6 providing cleaner Material design, access to brand new libraries, better theming/skinnability, and a more stable and modern codebase. In 2019 we continued the re-write and upgraded to Angular 7. We need to try and bring the rewrite to completion this year. You can see the in-progress new UI at https://openmf.github.io/web-app/ (mifos/password)

The entire web app needs to be re-written so a list of a few tickets of remaining work which will be part of project can be found at https://github.com/openMF/web-app/issues

The progress is being tracked here: https://docs.google.com/spreadsheets/d/1JxeJjG1GdZ3BNJi-sScCQLirfevSc8amFr8o3SfUj4U/edit?usp=sharing

Some additional work also includes adding in comprehensive keyboard shortcuts to enable power-users of the app and to ensure that the tabs and arrow keys work appropriately for navigating through the app.

Mifos X and Apache Fineract is widely used by financial institutions of all different sizes and methodologies around the world. With that widespread user base there is a vast array of different processes and procedures that would like to be supported as slight modifications over the common functionality provided. Over the past several years, we have captured these minor enhancements in our issue tracker as feature requests. Also included in this backlog or additional minor and less critical bugs that have been reported but have not been fixed yet.  This backlog has grown and it would be a very impactful project for an intern to work on completing as many of these bug fixes and minor enhancement as possible.

The difficult level of these issues ranges from low to higher and touch all componets of the platform - most don't require too much domain knowledge but some will. 

We have groomed the backlog and tagged issues and feature requests that are relevant for this project with the labels gsoc and/or Volunteer.  Priority level of tasks is measured by p1 being the highest priority. Tasks with an assigned fix version of either 1.4.0 or 1.5.0 have a higher priority. 

There are more than 120 tickets in the saved filter. You are not expected to complete all of the tasks in the backlog but throughout the internship you should fix as many issues/feature requests as possible. You will work with your mentor to deliver a plan for each sprint and adjust velocity as you get scaled up.

Issues to be worked on can be found at https://issues.apache.org/jira/issues/?filter=12345785 - the saved filter is named 2019 Intern Project. 

Better internal control and financial transparency

The Fineract 1.x code base powering Mifos X and dozen of cloud-based core banking and fintech solutions around the world supporting millions of clients is very robust and feature-rich. With the wide functional footprint, there comes greater complexity in the code that  makes maintainability more difficult. Additionally, as new features have been added the test coverage hasn't been extended at the same rate. The combination of these multiple factors - a large and varied user base that is reliant upon this vast codebase, the high maintenance burden, the need for increased testing coverage, and the need for a stable point for migration to the new architecture - merits this very important project will consist of these major tasks, documented in the following issues:

• Update Java from Version 8 to 11  (https://issues.apache.org/jira/browse/FINERACT-846)
• Measure Existing Code Coverage of Tests and Improve to at least 50% and Reduce Execution time (https://issues.apache.org/jira/browse/FINERACT-713)
• Ensure Fineract Codebase should pass PMD, Findbugs and Checkstyle analysis (https://issues.apache.org/jira/browse/FINERACT-712)

Improved functionality and increased stability of the core Fineract platform

Digital Identity is a pressing topic and for both generations of Fineract (1.x and CN), we'd like to have integration with emerging KYC and digital identity solutions.

KYC (Know your customer) is a fundamental banking concept. It refers to the process of identifying a new customer at the time of account opening, in compliance with law and regulation. The identification requirements may be lower for low value accounts ("Tiered KYC"). The term is also used in connection with regulatory requirements for a provider to understand, on an ongoing basis, who their customer is and how they are using their account. Most of the banks are mandated to perform basic/extensive KYC, before they can serve their customers.

Traditionally KYC is done in a centralised fashion where a central agency has the control over all the data. For example consider each bank like SBI, Deutsche, JP Morgan, etc. when creating a bank account, each of them requires a separate KYC process to be completed and all this data gets stored in their respective databases. Even the systems like Aadhar or social security number, etc. have the data stored in a central manner and maintained by the government. However, in recent times all these centralised identity servers continue to be hacked and the important and private data being stolen regularly.

With the advent of blockchain concepts and technologies, it is not ideal but imperative that we shift from the traditional identity management to a more secure decentralised claim-based identity management system. This kind of system has multiple benefits:

• Decentralised system means that no one person has control over sensitive data.

• It enables the re-use of KYC, i.e. each financial institution or in our case each customer using Fineract may not have to perform its own complete KYC, but re-use the KYC already performed by others (those who have the power as issuing authority for any kind of claim).

• Cryptographic security is the heart of blockchain technologies enhancing privacy.

• Claim-based system where the end user/customer has the control over his data.

See https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103093257 for details on the proof of concept 

P0 requirements

1. Setup and run an Hyperledger Indy Network with Stewards.
2. Opening a bank account scenario.
3. Applying for a loan scenario.

P1 requirements

1. Performing money transfer to a merchant online.

One of the most powerful aspects of the Apache Fineract platform and the Mifos X solution stack built on top of it, is the full set of APIs that are available to enable any third party to build new financial inclusion solutions on the platform. It is truly open source core banking software from the ground up. As part of an Apache Fineract project for GSOC in 2017, all of the API docs were converted from manually-generated API docs to live API docs based on the Swagger/OpenAPI format. Moving from our manually generated API docs to this live format would enable all the benefits such as easier testing through live examples, improved standardization, better sharing and portability, and increased automation of API-related processes. Documentation and learnings from that project can be found at https://goo.gl/rL3zdF

The majority of the conversion of the API docs was completed during GSOC and then finalised during GCI 2017. However, since then new APIs have been added and these have not been documented in the Swagger format. Likewise, Phase 2 tasks of the Swagger API work like leveraging Swagger Codegen to enable the creation of language-specific SDKs and client libraries through the Swagger format. Other additional work includes the ability to import Swagger APIs into Postman enable the creation of a Run in Postman button.

Full details of this project can be found at https://jira.apache.org/jira/browse/FINERACT-733

Goals and the tasks of the project include:

• Deprecate existing API docs and rewrite overview section so it's not reliant upon hyperlinks to the old API docs.
• Improve home page for Swagger Documentation with either a sidebar or a navbar (similar to the one in the existing documentation) which groups together related API's and provides hyperlinks to their swagger documentation (Can be done with the help of Angular or any suitable platform)
• Reflect entity description in the swagger documentation itself 
• Automatically generate swagger.json while building the Fineract.
• Ensure details and descriptions of fields like "transactionProcessingStrategyId" are carried over. Without this information, an API consumer would not understand what each of these (non-obvious) fields mean and how they are to be used.
• Ensure the amount of information present for an API in Swagger is equivalent to that of original API documentation (https://demo.openmf.org/api-docs/apiLive.htm#batch_api) Detailed description, possible errors, command strategies supported etc need to be migrated over. 
• Round of QA on all Swagger Docs.
• Convert remaining APIs that have been created since December 2017 into Swagger/OpenAPI format including new self-service APIs, APIs for data import.
• Utilize Swagger Codegen to enable the creation of language-specific SDKs and client libraries through the Swagger format such as for Java and Angular.
• Create a Run in Postman button by importing Swagger APIs into Postman.

Improved functionality and increased stability of the core Fineract platform

Now that we have a robust mobile banking and online banking application which allows for users to self-create their own accounts, we need to add better back-end administrative support for staff of the financial institution to manage their self-service operations including user management, notifications to clients, task management, logo uploads, etc. 

This project would involve front-end development of the new UI screens (some part has been already been implemented but may be enhanced) and development of additional APIs on the Apache Fineract back-end to support the following use cases:

• User Management - creation of new users, reset of user password, user activity tracking, searching of users, freezing/closing of self-service user accounts
• App configuration - upload of custom logo, look and feel, about app details.
• Customer Support/Communications - schedule campaigns to be delivered as in-app notifications, respond to incoming client support requests
• Task Management - view and respond to pending tasks - new loan applications, loan disbursements, etc.

We have released several versions of our Android app for field officers to go out in the field to process transactions, create clients, etc. Most recently in 2019, our Google Summer of Code intern, Moksh, added support for fingerprint authentication, bulk approval of tasks via Checker Inbox, migration of the project to Android X and support for Kotlin as well as a number of bug fixes and minor enhancements. 

For 2020, the focus would be on continuing additional refactoring and performance enhancements, along with building out new functionalities, UI enhancement to the application, and providing widespread coverage of automated testing throughout the app.   

Allows staff to go directly into the field to connect to the client. Reduces cost of operations by enabling organizations to go paperless and be more efficient.

2019 Progress: https://gist.github.com/moksh-mahajan/cf080d66b72659713dbc8336ca19976e

https://github.com/openMF/android-client

Mifos Mobile is a reference mobile banking app which enables clients to authenticate themselves, view and edit their account details. and make repayments or transactions between their own accounts. It is now possible for any It is now possible for any financial institution using Mifos to provide an omni-channel banking experience including  including smartphone-based mobile banking, USSD-based mobile banking, and online banking via a web app.

In 2019, our Google Summer of Code intern, Prashant, extended our mobile banking app, completing a mix of functional, architectural, and design improvements including improving the outbound notification system by migrating from GCM to FCM, initial integration with RocketChat for direct customer support between staff and clients, a dark theme and better support for skinning, and phase 1 of integration with Mojaloop via the payment hub.

With the payment hub and API Gateway now in place, next we look to add additional mobile money and payment system integrations into the app as well as having the app connect via the Open Banking API rather than the self-service APIs. This exercise of mapping the Fineract self-service APIs to the Open Banking APIs will be the major focus of this project. 

It was built on top of the Apache Fineract 1.x client-facing APIs to enable self-service channels for clients to interact with their own data and transact in a self-service manner.

By providing an extensible mobile banking app, allow a member/client in having a self-service channel allowing them more direct control and visibility into their financial livelihood.

User Stories - https://goo.gl/3xuUko

Wireframes - https://goo.gl/3xuUko

Customer Self Service APIs - https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service

UK Open Banking API Standard: https://standards.openbanking.org.uk/

Source Code: https://github.com/openMF/mifos-mobile

See: https://openmf.github.io/mobileapps.github.io/

Mifos Webinar on Open Banking API: 

Mifos Open Banking API Documentation: https://app.gitbook.com/@mifos/s/docs/

Mobile money is rapidly transforming financial inclusion by providing more immediate, impactful, affordable, and secure financial services to the client. Mobile money platforms like M-Pesa offer the client unparalleled value in terms of convenience, security and the possibility of new services and products that are more in line with real-world financial habits.  For financial institutions and their clients to fully scale mobile money and leverage its potential, it needs to be fully integrated with their core-banking system.

As part of our DIAL-funded project to integrate Mifos with the open source Mojaloop payments platform the team from DPC consulting built out a middleware component called the payment hub to enable the integration with the Mojaloop APIs. This middleware will also serve as the point of integration for all other external payment systems - the payment hub is extendable by additional payment connectors. This project would focus on adding the connector for the Beyonic APIs. Beyonic is a global mobile money aggregator which provides a common set of payment and collection APIs to seamlessly integrate with the leading mobile money platforms in East and West Africa. 

The payment hub built upon the work of previous interns, most recently the efforts on the Mifos Payment Gateway which were led by Sidhant Gupta in 2019.

This project will involve building the Beyonic connector and integrating with the specific Beyonic APIs for the mobile money use cases to be supported.

Great efficiency, reduced risk for clients, more impactful and relevant products & services.

• 2019 Progress: https://gist.github.com/sidhant-gupta-004/090a9e95b3066e5dd0f8f6005ea60d04
• Research & Data on Various Mobile Money Platforms  - http://goo.gl/XkSbdl
• Payment Hub Repository: https://github.com/openMF/payment-hub
• Overview of Payment Hub and How to Configure (See Section 5.6.3): https://docs.google.com/document/d/1XnAuWxmX-Fof7-o69IyU9ilwcmigqQ6dNHc9uNRx1r4/edit?usp=sharing
• Functional and Technical Specification on the Payment Hub: https://docs.google.com/document/d/1iVTgqljj5jW1eczpUcN_qykvWGh9bPKalxDayW8ZGcU/edit?usp=sharing
• Beyonic APIs: https://apidocs.beyonic.com/

Mobile money is rapidly transforming financial inclusion by providing more immediate, impactful, affordable, and secure financial services to the client. Mobile money platforms like M-Pesa offer the client unparalleled value in terms of convenience, security and the possibility of new services and products that are more in line with real-world financial habits.  For financial institutions and their clients to fully scale mobile money and leverage its potential, it needs to be fully integrated with their core-banking system.

As part of our DIAL-funded project to integrate Mifos with the open source Mojaloop payments platform the team from DPC consulting built out a middleware component called the payment hub to enable the integration with the Mojaloop APIs. This middleware will also serve as the point of integration for all other external payment systems - the payment hub is extendable by additional payment connectors. This project would focus on adding the connector for the GSMA Mobile Money API. In 2016 GSMA published a first set of harmonized mobile money APIs to "ensure best practice in API design, security design, and more and to "address the complexity and fragmentation that is apparent in the fast-growing industry. 

The GSMA Mobile Money APIs are OTT (Over the Top) APIs that have been designed to cater for a core set of mobile money use cases:

• Interoperability between mobile money and banks, or among mobile money providers
• Merchant payments, online and offline, including delegated authentication of transactions
• Bill payments and instant notification of payment
• Basic account management
• International transfers, including request for quotation
• Bulk transactions
• Cash in / Cash out

This project will extend the work started by Sidhant Gupta under the mentorship of Avik Ganguly in 2019. 

This project will involve building the GSMA Mobile Money API connector and integrating with the specific APIs for the mobile money use cases to be supported.

Great efficiency, reduced risk for clients, more impactful and relevant products & services.

• 2019 Progress: https://gist.github.com/sidhant-gupta-004/090a9e95b3066e5dd0f8f6005ea60d04
• Research & Data on Various Mobile Money Platforms  - http://goo.gl/XkSbdl
• Payment Hub Repository: https://github.com/openMF/payment-hub
• Overview of Payment Hub and How to Configure (See Section 5.6.3): https://docs.google.com/document/d/1XnAuWxmX-Fof7-o69IyU9ilwcmigqQ6dNHc9uNRx1r4/edit?usp=sharing
• Functional and Technical Specification on the Payment Hub: https://docs.google.com/document/d/1iVTgqljj5jW1eczpUcN_qykvWGh9bPKalxDayW8ZGcU/edit?usp=sharing
• GSMA Mobile Money API Developer Portal: https://developer.mobilemoneyapi.io/
• GSMA Mobile Money Design Principles: https://mmapi.gsma.com/

Mobile money is rapidly transforming financial inclusion by providing more immediate, impactful, affordable, and secure financial services to the client. Mobile money platforms like M-Pesa offer the client unparalleled value in terms of convenience, security and the possibility of new services and products that are more in line with real-world financial habits.  For financial institutions and their clients to fully scale mobile money and leverage its potential, it needs to be fully integrated with their core-banking system.

As part of the GSMA Inclusive Tech Lab, they are building an Interoperability Test Platform to test how service providers can connect to a mobile money system via the GSMA Mobile Money API and how MNOs and DFSPs can connect to a central switch/hub via the Mojaloop API. The Mifos Initiative has also built and configured a lab environment that provides an immersive user experience complete with rich user interfaces to test out various scenarios and transaction flows originated across Mojaloop and via GSMA mobile money APIs from the perspective of various DFSPs including MFIs, wallet providers, merchants, etc. GSMA has built a transformation layer on PHP to map the GSMA Mobile Money API to the Mojaloop Open API. We would like to incorporate this transformation layer into our lab environment and to do so must write the transformation layer in a more production-ready language like Java. This project would focus on writing that Java transformation layer and ensuring the GSMA Mobile Money API connector is in place for the payment hub and API gateway. 

In 2016 GSMA published a first set of harmonized mobile money APIs to "ensure best practice in API design, security design, and more and to "address the complexity and fragmentation that is apparent in the fast-growing industry. 

The GSMA Mobile Money APIs are OTT (Over the Top) APIs that have been designed to cater for a core set of mobile money use cases:

• Interoperability between mobile money and banks, or among mobile money providers
• Merchant payments, online and offline, including delegated authentication of transactions
• Bill payments and instant notification of payment
• Basic account management
• International transfers, including request for quotation
• Bulk transactions
• Cash in / Cash out

This project will extend the work started by Sidhant Gupta under the mentorship of Avik Ganguly in 2019. 

This project will involve building the GSMA Mobile Money API connector and integrating with the specific APIs for the mobile money use cases to be supported.

Great efficiency, reduced risk for clients, more impactful and relevant products & services.

• 2019 Progress: https://gist.github.com/sidhant-gupta-004/090a9e95b3066e5dd0f8f6005ea60d04
• Research & Data on Various Mobile Money Platforms  - http://goo.gl/XkSbdl
• GSMA Presentation from January 2020 Mojaloop Convening: bit.ly/2ujY26I
• GSMA Inclusive Tech Lab: https://www.gsma.com/mobilefordevelopment/mobile-money/gsma-inclusive-tech-lab/
• Payment Hub Repository: https://github.com/openMF/payment-hub
• Overview of Payment Hub and How to Configure (See Section 5.6.3): https://docs.google.com/document/d/1XnAuWxmX-Fof7-o69IyU9ilwcmigqQ6dNHc9uNRx1r4/edit?usp=sharing
• Functional and Technical Specification on the Payment Hub: https://docs.google.com/document/d/1iVTgqljj5jW1eczpUcN_qykvWGh9bPKalxDayW8ZGcU/edit?usp=sharing
• GSMA Mobile Money API Developer Portal: https://developer.mobilemoneyapi.io/
• GSMA Mobile Money Design Principles: https://mmapi.gsma.com/

Mobile money is rapidly transforming financial inclusion by providing more immediate, impactful, affordable, and secure financial services to the client. Mobile money platforms like M-Pesa offer the client unparalleled value in terms of convenience, security and the possibility of new services and products that are more in line with real-world financial habits.  For financial institutions and their clients to fully scale mobile money and leverage its potential, it needs to be fully integrated with their core-banking system.

As part of our DIAL-funded project to integrate Mifos with the open source Mojaloop payments platform the team from DPC consulting built out a middleware component called the payment hub to enable the integration with the Mojaloop APIs. This middleware will also serve as the point of integration for all other external payment systems - the payment hub is extendable by additional payment connectors. This project would focus on adding the connector for the Safaricom M-Pesa APIs. M-Pesa is the leading mobile money platform from Kenya. 

The payment hub built upon the work of previous interns, most recently the efforts on the Mifos Payment Gateway which were led by Sidhant Gupta in 2019.

This project will involve building the M-Pesa connector and integrating with the specific M-Pesa APIs for the mobile money use cases to be supported.

Great efficiency, reduced risk for clients, more impactful and relevant products & services.

• 2019 Progress: https://gist.github.com/sidhant-gupta-004/090a9e95b3066e5dd0f8f6005ea60d04
• Research & Data on Various Mobile Money Platforms  - http://goo.gl/XkSbdl
• Payment Hub Repository: https://github.com/openMF/payment-hub
• Overview of Payment Hub and How to Configure (See Section 5.6.3): https://docs.google.com/document/d/1XnAuWxmX-Fof7-o69IyU9ilwcmigqQ6dNHc9uNRx1r4/edit?usp=sharing
• Functional and Technical Specification on the Payment Hub: https://docs.google.com/document/d/1iVTgqljj5jW1eczpUcN_qykvWGh9bPKalxDayW8ZGcU/edit?usp=sharing
• Safaricom Developer Portal: https://developer.safaricom.co.ke/docs#introduction

In 2019, Appoorva built out the alpha version of this project including the initial app and machine learning model for image processing. The student for 2020 would extend the application and refine the model to achieve the original vision. Build out an AI-powered tool that leverages Machine Learning and Google's Cloud Vision to capture responses for the 10-question Poverty Probability Index (PPI) Scorecard using the simple image capture via a smartphone camera.   Social Performance Measurement is a critical tool for financial inclusion providers and the PPI is a widely-accepted tool for capturing it. Student would work on training the model for analyzing these images based on the scorecard requirements for multiple PPIs. 

The Poverty Probability Index (PPI^®) is a poverty measurement tool for organizations and businesses with a mission to serve the poor.  The PPI is statistically-sound, yet simple to use: the answers to 10 questions about a household’s characteristics and asset ownership are scored to compute the likelihood that the household is living below the poverty line.

Recording the answers to these 10 questions on initial onboarding of a client and at future period intervals is fraught with manual human error and data integrity issues. Leveraging Cloud Vision, a field officer would simply have to take a series of photos with their smartphone camera inside and outside of the house and then the Cloud Vision would be able to deduce based on the images the response to the 10 questions (i.e. the presence of soot on the walls would denote a coal-base stove is using, the image could easily depict what material the roof is made of, the image could detect the BMI of the family, the image could detect if there is a TV in the household. 

Cloud Vision won't be able to answer every single question in each 10-question scorecard but for some it would. 

Machine Learning, AI, Data Science, Statistics

2019 GSOC Project Resources

• Source Code: https://github.com/openMF/ppi-vision
• Summary: https://gist.github.com/apoorva-mk/a6661ca04b9b6b5d098e8bee41c35ddf

About the PPI

• https://www.povertyindex.org/about-ppi
• Getting Started with the PPI: https://www.povertyindex.org/get-started-ppi
• Sample Scorecard (India PPI based on 2016 data)

About Google's Cloud Vision

• https://cloud.google.com/vision/

As our product is core banking platform and our clients are financial institutions, we strive hard to make our code base as secure as possible. However, due to ever increasing security threats and vulnerabilities, it is the need of hour that we analyze our code base in depth for security vulnerabilities. During pull request merge process, we have a process in place wherein we do peer code review,QA and integration tests. This practice has been very effective and our community is already reaping the benefits of such a strong code review process. However, we should test our code against the standard vulnerabilities which have been identified by reputed organisations like Mitre to gain more confidence. It has become a critical part of independent and partner-led deployments

We can make use of opensource tools like Jlint, Findbugs , SonarQube or frameworks like  Total output Integration Framework (TOIF) - used by companies dedicated to produce military grade secure systems. As our environments become more containerized we can also utilize tools like: Anchore, Snyk.io, and Docker Bench for Security

It would be worthwhile, if we can dedicate one GSOC project for this analysis. The student would be responsible to analyse the findings, generate reports, identify if it is really a bug and then submit a fix after consultation from the community. Of course, the student needs to demonstrate some basic understanding of security vulnerabilities( like buffer overflow etc) and should have some academic level of experience working with static analysis tools.

Improved security keeping the integrity and privacy of the underbank's financial data intact.

As our product is core banking platform and our clients are financial institutions, we strive hard to make our code base as secure as possible. However, due to ever increasing security threats and vulnerabilities, it is the need of hour that we analyze our code base in depth for security vulnerabilities. During pull request merge process, we have a process in place wherein we do peer code review,QA and integration tests. This practice has been very effective and our community is already reaping the benefits of such a strong code review process. However, we should test our code against the standard vulnerabilities which have been identified by reputed organisations like Mitre to gain more confidence. It has become a critical part of independent and partner-led deployments

We can make use of opensource tools like Jlint, Findbugs , SonarQube or frameworks like  Total output Integration Framework (TOIF) - used by companies dedicated to produce military grade secure systems. As our environments become more containerized we can also utilize tools like: Anchore, Snyk.io, and Docker Bench for Security

It would be worthwhile, if we can dedicate one GSOC project for this analysis. The student would be responsible to analyse the findings, generate reports, identify if it is really a bug and then submit a fix after consultation from the community. Of course, the student needs to demonstrate some basic understanding of security vulnerabilities( like buffer overflow etc) and should have some academic level of experience working with static analysis tools.

Improved security keeping the integrity and privacy of the underbank's financial data intact.

Financial Organizations using Mifos/Fineract are depending on external agencies or their past experiences for evaluating credit scoring and identification of potential NPAs. Though information from external agencies is required, financial organizations can have an internal scorecard for evaluating loans so that preventive/proactive actions can be done along with external agencies reports. In industry, organizations are using rule based, Statistical and Machine learning methods for credit scoring, predicting potential NPAs, fraud detection and other activities. This project aims to implement a scorecard based on statistical and ML methods for credit scoring and identification of potential NPAs.

2019 Progress: https://gist.github.com/SupreethSudhakaranMenon/a20251271adb341f949dbfeb035191f7

https://gist.github.com/lalitsanagavarapu

For many of our users today, chat is a much more familiar form of user interface for them and it would be valuable to provide an extensible chatbot connected to Mifos/Fineract that could be used to both provide customer support as well as allow clients to directly interact with their accounts. See this post from ThitsaWorks for more: https://medium.com/@thitsaworks/chatbots-the-emergent-and-effective-tool-in-financial-education-f6e63baf9188

This project will focus on building on the latest version of the chatbot. In 2019, our GSOC intern, Anshul extended the Mifos Chatbot and Adapter with better authentication, improved Natural Language Processing, and integration with the Slack, Telegram and Facebook messenger platforms. 

The project will include both leveraging other open source libraries and components to build the chatbot and building the adapter to the chatbot for MIfos/Fineract which will act as the interaction between chatbot and Mifos. It will take the replies from chat and feed them into Mifos. The program will sit in between Mifos and Chat.

Main components needed are:

1. NLU (natural language understanding) /NLP (natural language processing)
   This componentcomponent is probably a good candidate for integrating a suitable existing OS project. 
2. Chat platform and/or protocols
   To establish the communication between user and the bot logic the project could either leverage (at least) one of the major chat platforms (e. g. Facebook messenger etc.) and/or use open source protocols like XMPP or IRC. It's probably best to evaluate existing chat frameworks/client libraries 
3. Fineract adapter
   This is the part where most of the student's attention is needed (see use cases below). The student would have to evaluate to which extent a chatbot framework could be integrated or if there are better arguments to develop something Mifos specific.

Note: only Apache license compatible libraries/frameworks/components can be used.

It will cover the following use cases: 

• Enquiry of Loan Details
  • Mifos/Chat adapter will allow authenticated user to enquiry details of loan based on loan ID.
  • Check user/client authentication
  • Get MFI name, 9-digits loan ID (xxxxxxxxx), 9-digits clients ID (xxxxxxxxx) if it is an authenticated user/client.
    • Allow authenticated user/client to query loan details:
    • Status of loan
    • Outstanding principal and interest
    • Next due date, due principal and interest
    • Previous payment date, principal and interest (the last transaction of loan)
    • Loan maturity date
    • Overdue loan principal and interest (if have)
    • Number of days in arrears for loan
    • Penalty fees/charges
    • Client activation date
    • Loan disbursed date/amount/interest
    • First repayment date
    • Saving balance
    • Saving interest (to date amount)
    • Next meeting date
  • Enquiry of Savings Details
    • Saving activated date
    • Saving balance
    • Saving interest (to date amount)
    • Last active transaction date
  • Notifications through Chat Adapter

    • Notification will be sent thru Mifos/Chat adapter to respective clients on the following events occur on their accounts. 

      • Client account activation
      • Client account rejection
      • Loan disbursal
      • Loan close
      • Next due principal and interest (1/2 days in advance)
      • Payment posted (there may have delay due to data entry)
      • Next meeting date
      • Saving deposit
      • Saving withdrawal
      • Saving close
      • Update/delete details of clients (address, phone number, NRIC number)
      • Update/delete details of group (group name, group leader, loan officer name)
      • Upload documents
  • Enquiry about Loan Products
    • Check user/client authentication
    • Get MFI name, 9-digits clients ID (xxxxxxxxx)
    • (Provide a list of available loan products of MFI)
    • Allow authenticated user/client to query loan product details based on selected product:
      • Loan term
      • Interest rate
      • Max and min allowed amount to borrow
      • Number of installments/repayments
  • Enquiry about Group Information
    • Mifos/Chat adapter will allow authenticated user (group leader) to enquiry on group member details.
    • Check user/client authentication.
    • Get MFI name, group leader name, group ID, center ID, branch name, (Is a group leader?)
    • Allow authenticated client(group leader) to query group details:
      • Next meeting date
      • Clients who have overdue loan
  • Enquiry about Branch Information
    • Mifos/Chat adapter will allow authenticated user(branch manager) to enquiry on branch details.
    • Check user/client authentication
    • Get MFI name, branch manager Name, user id/name, Branch Name, (Is a branch manager?)
    • Allow authenticated branch manager to query branch details:
      • Number of clients of his/her branch
      • Expected disbursement principal (today)
      • Outstanding principal and interest
      • Saving balance
      • Number of clients awaiting for disbursal (today)
      • New registered clients (today)
      • Prospective clients (as of today)
      • Number of clients (dormant) as of today
      • Number of village/bloc/ward in a branch

SQL, Java, Git, Spring, OpenJPA, Rest

Helpful: technical knowledge of (any) chat protocol (e. g. XMPP, IRC), experience with NPU/NLP

2019 Progress: https://gist.github.com/iosdev747/2b7de87cd9b028bb97433ee2e26ad18d

Source Code: https://github.com/openMF/mifos-chatbot

AI/NLU services
Google: https://dialogflow.com/
Facebook: https://wit.ai/
https://botkit.ai/
https://www.ambiverse.com/
https://github.com/ambi-verse/nlu-api-client-java

Frameworks
https://github.com/howdyai/botkit
https://github.com/nitroventures/bot4j
https://dev.botframework.com/
Has a lot of information on integration with chat platforms/protocols: https://github.com/BotMill

NLP/NLU components and tools
https://opennlp.apache.org/
https://deeplearning4j.org/java-ai
https://github.com/AIMLang/aiml-java-interpreter
https://nlu.rasa.ai/

Tutorials
https://dzone.com/articles/building-an-intelligent-chatbot-using-botkit-and-r
https://dzone.com/articles/beginners-guide-to-creating-chatbots-using-dialogf-1
https://tutorials.botsfloor.com/

Other
Extensive comparison: https://chatbotsjournal.com/25-chatbot-platforms-a-comparative-table-aeefc932eaff
Seems outdated, maybe helps with some insights/inspiration: http://www.zionsoftware.com/products/jbuddy/botframework/

By providing an extensible mobile banking app, allow a member/client in having a self-service channel allowing them more direct control and visibility into their financial livelihood.

Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client.Mifos X can be integrated with a popular CBs in India and from other regions (based on the demand).

During the 2016 Google Summer of Code, Nikhil Pawar, completed the credit bureau integration module with integrations for the major credit bureaus in India. This project will continue extending the functionality of the module and work on integrations with the major credit bureaus in Latin America and Sub-Saharan Africa.

The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client.

The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs.

For the scope of this project for 2019, see https://jira.apache.org/jira/browse/FINERACT-734

Detailed requirementshttps://goo.gl/aZWMZa

Mifos Credit bureau Integration. (Risk calibration Module -RCM)

Source Code: https://github.com/apache/incubator-fineract/pull/215

In 2019, we built out v3.0 of our online banking app, an Angular web app powered by self-service APIs allowing for account creation, logging in, viewing of account details, transferring between savings accounts, repaying loans via savings accounts, applying for new loans, and more.

This project will extend off that to focus on integrating with the newly created Open Banking API layer which replaces the self-service APIs mapping to the newly created  add new features and continue polishing the UI.

Allows a member/client in having a self-service channel allowing them more direct control and visibility into their financial livelihood.

While the current Mifos X stack caters to one operational methodology and has one distinct user interface and navigational flow, Fineract CN and it's broader applicability enables many different operational workflows to be supported and will have different flavors of the web UI. 

For the brand new Apache Fineract CN architecture, the web UI for the first use cases has been built out to support a teller-driven credit union operational methodology. The user interface and navigational flows for such an operational model is very different from that of a microfinance institutinon with group and center-based operations whereby the loan officer travels out to the customers rather than the customer goes to the branch office.

The UI that will be built out for this project will be very similar to the UI that was found in the current Gen 2 Mifos X web app as well as the original Gen 1 web app with support for viewing group and center hierachies, having a different drilldown navigational flow, etc. 

A number of these UI elements will still need the requisite support on the back-end. 

Intern will implement the front-end UI screens for the Fineract CN web UI for the following functionalities and use case:

• Center & Group Creation
• Center Summary and Details Page
• Group Summary and Details Page
• Group/Center Meeting Page
• Group, Center Listing View
• Drilldown navigation via Groups/Centers
• Collection sheet user interface
• Transferring clients between groups
• Group loan creation UI
• Group loan UI

As Mifos X has matured as a core banking platform, it's been adopted and used by larger institutions serving hundreds of thousands and even millions of clients. Partners operating cloud-hosted subscription models are also supporting hundreds of thousands of clients across their multi-tenant installations. Most recently, more and more digital-first fintechs are using the platforms for highly scalable wallet accounts needing hundreds and thousands of TPS. We need to benchmark, analyze and improve the performance and scalability of the system.

Enhancements to the back-end platform will include parallelization of all the jobs with a configurable amount of concurrency, look at the explain plans of the queries being used in the jobs, paginate input queries for jobs, put lazy fetching where required, node-aware scheduler and cache, office-wise configurable jobs to distribute job-load across servers and write some tests to prove that the concurrency will work for a decent amount of scale.

In addition, you'll provide some metrics which can help mid-sized MFIs (those having around a million active loans) in adopting Mifos X.

Develop ETL scripts to create OLAP cubes (fact and dimension tables in MySQL). This will allow managers to perform ad hoc slicing and dicing of their data 
to answer important questions about their operations.

• Create ETL scripts and tests
• Create a Mondrian schema to work with Saiku Analytics

This project would extend off of the work of a previous GSOC intern in building out integration with Saiku. 

The data and information housed in the centralized Mifos database is critical to the operations and management of a financial institution. While Mifos X ships with more than five dozen standard report and has multiple ways to build custom reports, non-technical staff who don’t know SQL queries nor the structure of the database struggle to be able to access new reports on the fly. Integration with Saiku would allow for ad-hoc reporting or more simply a drag and drop interface for management and non-technical staff to easily slice and dice and create reports on the fly.

Mifos X and the Apache Fineract platform already provide a range of sophisticated financial accounting needs, however for organizations that use it as both their core banking system and accounting system all in one, they continue to need other features. While Mifos X never intends to replace an ERP or accounting package, we do want to continue to add additional functionalities that provide the necessary integration with the portfolio and general accounting functionality to support a financial institution's core operations.

Several features have been requested by users and partners that we've grouped together as one task. Applicants should be familiar with the stack as well as the accounting and financial services domain.

Some of this work will include finalizing and incorporating existing pull requests and contributions that have been made by partners.

These enhancements will all be built into the Apache Fineract platform as part of or enhancements on top of the existing accounting module which provides full configuration of the chart of accounts, support for cash and accrual accounting, automated integration with the portfolio accounts and financial mappings, and single and compound journal entries to the general ledger. New enhancements include:

• Recurring Journal Entries (see spec below)
• Bank Reconciliation
• Fixed Asset Register
• Improved End of Period Processing

Better internal control and financial transparency

As financial inclusion evolves, more loan products are collateral-based and require more detailed tracking of the asset (gold, property, etc.) along with its value, and its depreciation.

Some institutions also require tracking collateral as off-balance sheet items.

The practice of putting up collateral in exchange for a loan is used as part of the lending process between businesses for some time now. The Collateral Management Module (CMM) implements the issuance, validation and processing of collateral transactions between two members of an MFI. In a swap transaction between Party A ( Lender ) and Party B (Borrower ),

1. Both parties make and agree to a collateral agreement ( Base Currency, Form of agreement, Quantify amounts such as minimum transfer amounts, Appropriate collateral, Delivery timing, Interest rates payable for cash collateral )
2. A makes a market-to-market (MtM) profit and B makes a corresponding MtM loss
3. Borrower presents collateral to Lender
4. Borrower redeems loan from Lender
5. Lender returns collateral to Borrower

Clients and Small Businesses are able to take out higher value loans when they can offer up different forms of collateral. This is essential as MFIs move beyond just group loans and to individual lending.

A crucial part of financial inclusion is micro-insurance and the ability for clients to safely manage risk in their lives. Mifos X will not fully handle the entire lifecycle of an insurance product but it should integrate with microinsurance system and track the key parts of the process that relate to the core banking system - collection and pass through of the premium and tracking claims and processing of these.

This project would involve building out a separate module that tracks claims being made by a client, likely leveraging the CRM functionality being build to track activities. It will integrate with APIs to enable processing of the claim and tracking what proceeds must be paid out to the client.

It will involve creating a new module with data model, UI screens and business logic that leverages Mifos X APIs

Tasks involved include:

1. Implementing a flag at the client level to denote if a person is deceased - if deceased, all loans would go into different status where all income, interest, fees, etc should stop accruing.
2. Utilize Data Tables to enable a user to initiate an insurance claim with details of the claim and corresponding updates to follow up on the claims process. Must limit this data table only to the clients with the corresponding flag so it's not displayed for all clients.
3. Processing of Claims - the insurance claim can either go directly to the client or directly to the Financial Institution. If directly to the FI, the outstanding amonst should be offset by the claim - it could be automatically applied using a new different payment of insurance claim. Corresponding accounting entries need to get passed as well.
   1. If there is money to be refunded to customer, they must have a savings account as can''t like journal entry to customer directly.
4. Closing of Account - once claim has been processed and outstanding balance settled, should implement a different status such as Closed - Deceased or Closed - Via Insurance Claim

This will also be helpful for intern;

An insurance claim is a formal request made to a Financial Institution asking for a payment based on the terms of an insurance policy. It would be nice for MFIs to provide a range of insurance products such as Health insurance, property insurance, casualty insurance, etc so that their members claim these. The insurance claims module has the following workflow;

1. Member claims insurance
2. MFIs verifies and validates member claims
3. MFI provides coverage/compensation to the insured.

Clients are able to lower their risk and have a much larger safety net when they have affordable access to insurance policies.

See http://www.openunderwriter.com/

See Insurance Product

• Getting Started Docs
• Fineract 1.0 Github Repo
• Investopia Article On Insurance Claims
• Insurance Claim Definitions

Financial Inclusion providers need a comprehensive view into the overall livelihood of their client both for better risk analysis, credit scoring, as well as social performance management.

We have the back-end in place for a surveys/social performance management framework that allows the import of XMLs for the PPI (progress out of poverty index) SPM scorecard. We need to implement a front-end UI for viewing and recording PPI surveys as well as a UI in which to create new surveys from scratch (similar to Question Groups in an older version of software).

1) Build out the UI for creating survey from available PPI scorecard
2) Capture/record surveys from a given entity in the web app
3) View recorded surveys from the web ap
4) Interface to create new surveys from scratch via the UI

See Resources below for specs/wireframes.

Ability to measure social impact and have one single point of information on a client within the platform.

Before booking a loan, the customer needs to require and assess the details of the loan he is enquiring for and there is no way to personally judge it, based on the parameters, Sales staff right now is using different external loan calculator and loan product schemes are not documented. We need a frontend experience service with personalized match to loan products.

https://docs.google.com/document/d/18rS0gVWkjQvNdRnNj40uKNl32zuTh-uuzNv161n6YrY/edit?usp=sharing

Microfinance institutions usually work with various external parties, such as funders or investors. Using the data that is available in MifosX we would like to offer those stakeholders a seperate portal showing accurate and high-level information about the institution that would otherwise be reported manually by the institution. This information helps them in their decision making processes, but also enables them to assess the broader impact they are having with their funding.

To develop a portal that aggregates information from different Mifos X deployments and report on predefined social and operational metrics

Objectives:

• Implement back-end logic in MifosX required to make information available to the client impact portal
• Implement UI and back-end logic of the Client impact portal

2014 GSOC Client Impact Portal Project

• Client Impact Portal User Guide
• GSoC 2014 - Client Impact Portal
• Source Code: https://github.com/openMF/mifosx/pull/1047

Vision for Generic SPM Framework for Mifos X (PPI)

Background on Client Impact Portal

• Client Impact Portal
• Data Analytics & Client Insight - Are we making an impact? (Client Impact Portal demo)
• Client Impact Portal POC - (mifos/password are login credentials)

Data migration can be one of the most challenging and time-consuming phases of an implementation of a core banking system. It's often a barrier to financial institutions moving on to new and better more modern systems. It's critical to cleanly migrate over the historical data of a client and their transactions. Often the legacy system data needs to be cleaned up and transformed before it can be migrated into Mifos X and is one of the most costly and time-consuming phases of a deployment. We have an existing data migration tool for migrating from Mifos 2 to Mifos X that utilizes the Pentaho Kettle ETL tool.

This project would extend the existing Mifos 2 to Mifos X Kettle-based migration tool to provide a standard migration tool from Loan Performer - a low-cost, widely adopted system in use by hundreds of microfinance institutions throughout Africa and Latin America. It would provide one standard tool that any partner or financial institution could use for migrating from that specific system - it wouldn't require new tools to be made each time a migration is done.

Extend the existing Kettle-based Mifos to Mifos X migration tool

• Write ETL scripts to get data and transform data it from Mambu format to Mifos format

It has many impacts

1. This drastically reduces the time to set up of initial configuration/data of Mifos X for organization adopting this system as MIS.
2. It widely opens the market that Mifos X is applicable for as it lessens the burden of converting from Loan Performer - a system that is widely used but not as modern and sophisticated as Mifos X.
3. It dramatically lowers the cost of implementing a system like Mifos X by reducing the complexity of the deployment
4. It increases transparency by ensuring financial institutions using Mifos can retain the full history for their clients.

https://github.com/Nayan/move-to-mifosx

https://github.com/openMF/move-to-mifosx

Right now Mifos X contains core client management functionalities including tracking basic demographic information, know your customer information, document management, and survey collection through data tables. As financial institutions, serving the poor begin to offer a more in-depth and diverse range of financial inclusion products, the need for more robust client management and in-depth client understanding has grown. Their core system needs to provide more and more CRM-type functionality that compliment the portfolio management and financial/social reporting that the Mifos X provides.

This project will work to deliver the initial set of customer relationship management functionalities including a module for tracking inquiries, complaints

This module will have a request management functionality. A request can be of 2 types: Complaints and Service Requests. Each request must be against a customer and optionally against an account of the customer. Each request will go through a simple workflow.

Actions that can be performed on a request:

Assign -> will change status to "assigned"

Start Work --> will change status to "in progress"

Close --> will change status to "closed" (with a sub-reason code)

At each step user can enter comments.

The customer summary screen will have a link to view the requests of the customer - along with a summary and current status - with options to click-through to get the complete history of each request.

Deepening the client relationship and ensuring fair, responsible, and transparent financial services to the poor is a core piece of the industry's roadmap for financial inclusion. Providing customers the ability to voice their concerns and feedback about the services they're receiving provides a simple yet powerful tool to protect the client. Empowering the financial institution with the ability to track these inquiries and overall maintain a more holistic relationship tracking entire lifecycle of their clients gives them a much better ability to understand their clients and respond to their needs with appropriately designed services and products.

• Apache Fineract Github Repo
• Odoo Open Source Business Apps Github Repo
• Odoo Third-party API And Demo
• Wikipedia Article on CRM
• What Is CRM ?
• CRM

We believe the Mifos X platform is super secure and impenetrable. Your mission, should you choose to accept it, is to prove us wrong, and help close gaps you may find.

Beyond a one time exercise, you should integrate (some of) the tools you've used into our build chain so that, even after you've gone, tools flag up future newly introduced potential vulnerabilities.

https://www.owasp.org/index.php/Main_Page

https://code.google.com/p/zaproxy/

http://wapiti.sourceforge.net

Run FindBugs & related tools for some serious static code analysis

http://en.wikipedia.org/wiki/Penetration_test

This project would seek to create one unified ID/login and profile for community members similar to the OpenMRS ID. It would achieve the following two primary objectives:

1. One unified profile and identity for community members in which they can share with the community who they are and also build reputation and recognition. This ability to discover and self-identify with other community members is difficult when we have so many different tools and profiles to maintain.
2. Single Sign On for our various collaboration and community infrastructure tools listed below.

1. Identifying a single sign-on authentication protocol that ties together authentication of our various community collaboration tools: 1) Atlassian Studio - JIRA, Confluence, JIRA Agile, 2) Social Q&A - AnswerHub 3) Mailing Lists - Mailman (administered through SourceForge 4) Source Code Version Control - GitHub 5) Continuous Integration - Jenkins 6) General Community Website (mifos.org) - Wordpress 7) Partner Directory
   1. This could be built out independently, tie into some OpenID protocol, or leverage one of our existing tools for this authentication - Atlassian Studio/Crowd or AnswerHub or another common OpenID protocol. 
2. Design and implement a dashboard to handle the creation of this unified ID
3. Design and create a common profile tied to this ID with basic information and photos that is searchable by the community.

Design a profile

Extra Credit:

• Gamification/Reputation Building - Tie into Open Badge system like Mozilla Open Badges http://openbadges.org/ or Ushahidi Badges: http://ushahidi.github.io/Badges/

Impact is two-fold:

• Common unified profile and identity can help to grow collaboration and participation in the community. By being able to simply share who you are or discover who's in your community, we can deepen the bonds of community which motivates each member to participate more often and invest personally in the health of the community. Building reputation and recognizing efforts of each type of community member (users, partners, volunteers, etc) in a tangible way also helps to increase participation.
• Single sign-on will it make much easier for community members to collaborate and communicate. Right now there is often a high barrier to signing up for the various tools - SSO will make that process easier but also encourage others to more regularly be involved.

Create a POC of a scalable MifosX implementation on OpenShift. Also publish a whitepaper with details of this set up.

Mifos X was built to be cloud ready from the ground up. One of the most popular deployment environments for MifosX has been on Amazon EC2, however due to country specific regulation, many implementors are forced to seek alternative models that can scale as effectively. The aim of this project is two-fold:

• Propose a scalable deployment model for Mifos on the OpenShift PaaS. Your application should highlight a starting point with some details of your planned deployment architecture, as Mentors would be not giving you step-by-step instructions in this project, just "nudge" you along; you would be expected to learn about how to deploy Mifos yourself and by autonomously using the documentation available and help from the public mailing list and IRC channel, and figure out the details of the Cloud deployment.

• Propose how the above proposed model could be contributed to Mifos in the form of e.g. ready-to-run "configurations" etc. allowing ANYONE to deploy THE LATEST VERSION of Mifos in the Cloud themselves, and then implement this approach in practice. (Contrast this with a "one-off exercise", e.g. taking the current Mifos X WAR file, and UI, and manually making some changes to it, and then manually deploying that to some Cloud PaaS - this would not be sufficient for this project's expectations.)

• Implement a Continuous Deployment "Devops" EXAMPLE instance of this scalable blueprint using the latest nightly Mifos build artifacts.

• Publish a high level whitepaper of the same, which can be used as a reference for local implementors, who would additionally take care of provisioning their own hardware. This documentation should be ideally high-level, and what it described much be automated; only providing lengthy step-by-step manual instructions would not be sufficient for this project's expectations.

To prepare for this project, applying students must demonstrate at least that they have already successfully locally built and ran a Mifos X REST back-end server and UI, populated the database etc. as well as provided a simple pull request proposing some minimal deployment related improvement.

Note that we now believe that a Platform as a Service (PaaS) is a more suitable foundation for this project than a raw Cloud Infrastructure as a Service (IaaS) platform (such as Openstack, offered by public cloud provider such as e.g. Rackspace; or Azure, or raw Amazon EC2). This is because a PaaS, such OpenShift, already come with relevant features such as built-in, managed, supported and monitored HTTP load balancing (e.g. OpenShift comes with HAProxy).

We are aware that OpenShift out-of-the-box currently does not provide supported clustering for the MariaDB/mysql database used by Mifos (there is documentation for un-supported example based on an OpenShift template and suggested descriptions on blog posts, or also this one based on Severalnines.com; similarly one could deploy the commercial Percona XtraDB Cluster product). However at this point we believe that this would not be required, and that proper configuration on OpenStack of the already existing cache facility (incl. distributed cache invalidation) available in Mifos X will add more value at signficantly less operational complexity.

You may need to develop some minor "adjustments" for Mifos X to work well in a PaaS. For example, writeable directories may be limited, and configuration changes may be needed to pick up allowed data directories from an environment variable configuration (but consider multi node distribution in this cluster setup!). Also a cloud PaaS like OpenShift may not support "always running" instances, and scheduled jobs may have to be configured to be kicked off via an explicit HTTP "wake up" request from a cron job.

While OpenShift should already take care of automatic distribution of Mifos code (WAR) updates among nodes in the cluster, you may also have to consider distributed configuration in a cluster. Normally all Mifos X configuration should reside 100% fully in the database only, and as such this may be a non-issue. If however there are any customized configuration files, then perhaps something like the Spring Cloud project could be of interest to ease distributed configuration management.

We are aware of other PaaS product similar to OpenShift, such as notably Cloud Foundry, or even Heroku (closed source..) but would suggest to use OpenShift.

OpenShift https://www.openshift.com

Old Mifos mailing list posts related to related things, search e.g. "mifos google app engine", and find as this one as well as this one.

Mifos X today is typically used on Tomcat (with Jetty known to work). For a certain class of users, testing it on "Enterprise Stack" application servers (meaning IBM WebSphere and Oracle WebLogic) is desirable - this project would properly test Mifos X on these configurations, make any adaptations to the code which may be required, and produce easy to follow documentation or even small tools helping future users how to go about this.

This project could be combined with and taken up by the same candidate as the Enterprise database project.

Java, Application Server configuration, WAS classloading crap tricks, documentation writing.

Use Cargo, Arquillian etc. for automated testing against WAS & WLS containers?

Vendor pages