James, Thanks for formally introducing yourself to the community and your longstanding and important role. None of us would be here today if it wasn't for you!
Thank you also for neatly articulating Mojaloop and its various points of intersection with Apache Fineract and Mifos. I will work to identify partners and/or users in the community who have near-term opportunities to leverage this modern payments infrastructure in tandem with Apache Fineract. As you have already done on the separate thread, I do want you to continue sharing your expertise on how this fits in, replaces, or could become a part of the ongoing work on the mifos payment gateway/bridge. Ed On Wed, Oct 18, 2017 at 12:31 PM, James Dailey <[email protected]> wrote: > Fineract'rs: > > I joined this list recently and would like to introduce myself. I > formulated the Mifos project in 2001 when working at the Grameen Technology > Center and am current chair of the Mifos Initiative - which is the group > that contributed the Fineract Code. While I don't code myself, I have > contributed time and energy over the past 16 years to make financial > inclusion via open source work for the poor. In that time, I've also had > the privilege of consulting on mobile money businesses, shared microfinance > platforms, and financial inclusion strategies in dozens of countries around > the world. For the past three and a half years I've worked as a (contract) > member of the LevelOneProject.org team at the Bill & Melinda Gates > Foundation. > > I had an early role in articulating the case for what released this week as > open source code. http://mojaloop.io/ I'd like to do a little context > setting here - all of this is on the leveloneproject.org or on mojaloop.io > , > but perhaps I am in a good position to explain how the Fineract code base > could relate to the Mojaloop code. I suspect Markus is already thinking > about this... as are others. ;) > > Mojaloop has as its main domain the transfer of value. Fundamentally, a way > to include people in the formal financial world is to create a more vibrant > ecosystem of operators providing different services to customers where the > friction in payments is removed. e.g. Rather than having to walk or a take > a bus hours to make a payment for the kids school - you use the mobile > device to move funds. In the Mojaloop world, the DFSPs (Digital Financial > Service Providers) running a current version of Fineract could be the > source and the destination for funds. > > While the world of payments can be arcane, one needs the ability to route > the payment to a specific account address and the ability to ensure that > the payment settles at end of day or sooner (as soon as real time). > Mojaloop has a novel approach for both of these. In the first, mojaloop > leverages Pathfinder ( > https://github.com/LevelOneProject/Docs/tree/master/CentralDirectory). > Pathfinder is a service of GSMA > https://www.gsma.com/managedservices/number-portability-services/about- > pathfinder/ > . > This innovation is important because it brings a different approach to > routing that is compatible with mobile telephony identity. This code ( > https://github.com/LevelOneProject/pathfinder-provisioning-client.) seems > like a good way to understand how this works. In the second, Mojaloop uses > work by Ripple Labs on the Interledger Protocol (ILP) ( > https://interledger.org/) to settle across different payment schemes or > within a network of ledgers and for the mojaloop that is quintessially the > Central Hub. > https://github.com/LevelOneProject/Docs/blob/master/ILP/block-diagram.png > . > This explanation is better than what I could write: > https://github.com/LevelOneProject/Docs/tree/master/ILP > > So, those two novel things are interesting and could be leveraged by the > Fineract project today I would hazard. I would suggest that one proof > point for compatibility would be to attempt to set up two instances of > Fineract (running with a mifos front end) and one instance of the mojaloop > Central Hub that allows for transfers to occur. > https://github.com/LevelOneProject/Docs/blob/master/L1P%20Architecture% > 20and%20Payment%20Flow.pdf > It would likely require some additional work to make the APIs compatible. > > Also, the centralized fraud service and scheme rules setting are also > useful and not likely to be an overlap with the existing Fineract > direction, although do set me straight if I am wrong. > > In the Fineract-CN proposed code evolution (see other threads on this), we > have a need to understand how the Mojaloop intersects with the new > microservices architecture. I would suggest however that since mojaloop is > primarily about the transfer of value and Fineract-CN is primarily about > the management of accounts and clients and access points, that the overlap > is minimal. Dare I compare this to chocolate and peanut butter and the > wonderful collision which is the Reese's Peanut Butter Cup? We'll see. > > As an idea, when building the microservices, it may be possible to wrap > some of the libraries or services that were released under mojaloop - if > licenses are compatible of course. On that the mojaloop team choose > Creative Commons Share Alike 4.0. If there is a mentor who can answer that > - it would be good to know. > > There is also a need to understand the flows that are - in my view - > payments done right. That is, payments or transfer of value, occur outside > of the signaling for those payments and are push and process immediately. > I've addressed this in another post recently but basically the flows are > well documented and the APIs are using the latest and greatest - Fineract > could benefit from simply reviewing that documentation. > https://leveloneproject.org/wp-content/uploads/2015/04/ > The-Level-One-Project-Guide-Designing-a-New-System-for- > Financial-Inclusion1.pdf > > https://github.com/LevelOneProject/Docs/tree/master/CentralLedger ; > https://github.com/LevelOneProject/Docs/tree/master/LevelOneClient ; > https://github.com/LevelOneProject/Docs/blob/master/Interop%20Services% > 20and%20Mule/PaymentFlow.png > > i'm trying to find the API documentation -- it's a big project, maybe the > subject of another email. > > Finally, there are a lot of highly qualified people on this listserv who > could help identify some of the paths that would lead to some win-wins on > this front. I look forward to the conversation. > > - James Dailey > Seattle > -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
