Hi Myrle - thanks for taking a look. comments/response inline ... but first I should emphasize that my comments are my own.... we don't represent orgs in the Apache world but in particular I'm not representing Mojaloop to Fineract. I'm merely introducing it based on the publically available information.
On Fri, Oct 20, 2017 at 1:03 AM Myrle Krantz <[email protected]> wrote: > Hey James, > > Now I've had the chance to take a closer look. It's an interesting > project. I have a few comments and then a few questions: > > Comments: > 1.) Unfortunately several of the GitHub links you included were not > reachable for me. Not all of them, but several of them. > Hmm... I will try to find out about the github code access. My understanding is that it is all available as a public repo, but I think you're correct in that some links to github code are not working from mojaloop.io when I'm not logged into github. > 2.) As far as I can tell, as a payments transfer system, this has very > little functionality overlap with Fineract or Fineract CN. > Yes, although I suppose that hypothetically there is a way to create a payments switch using FineractCN and to build some if not all of the functionality of the central directory and fraud management.... just differently. I would propose that Fineract NOT go that direction as a deliberate choice and instead leverage this and other open projects... and perhaps include the code where appropriate as libraries/or incorporate into a microservices architecture deliberately. > 3.) Since this is a Ripple fork, it should be no surprise that it has > massive overlap with a different Ripple fork that we've seen in this > community before: Stellar. > While the Ripple lab derivative piece is there, don't get too focused on the Interledger. Note the Dwolla pieces as well - https://www.dwolla.com/updates/gates-foundation-partners-with-dwolla-project-global-payments/ . > 4.) I agree that push payments, processed immediately, are the right way > to go. > Yeah! > > Questions: > 1.) When we wrote the Stellar bridge one of the reasons it never > reached deployment was the lack of existing deployments and users of > the Stellar network. (With the recent announcement that IBM and > Stellar will be partnering this may yet change) Is someone deploying > mojaloop? > I think Ed has explained the current state of play there with Stellar. When we first discussed Stellar on the Mifos side, my advice to the team was to focus on things that would be useful to the Fineract code that could also be leveraged for other interfaces. That is, don't get too tightly coupled with one provider as there are multiple interfaces and platforms coming. As for a mojaloop deployment, I'd suggest watch that space. > 2.) What, in your view, are the major differences between mojaloop and > Stellar? What are the advantages to mojaloop? That is a very intriguing question. To start, I actually don't see much in common between Stellar and mojaloop but let's go through a few thought exercises: (A.) Broad vision: both Stellar and mojaloop (as well as Fineract/Mifos) seek broad financial inclusion. I think there is excellent overlap which has a high alignment index. (B.) Broad subject domain: both Stellar and mojaloop work at the level of value transfer and seek to derisk this for users and providers. (C.) More specific domains: My understanding is that Stellar is primarily oriented around blockchain and specifically distributed permissioned ledgers and incentives to keep the blockchain running. Mojaloop has - in my view - taken a broader view of the challenges, looking toward addressing/routing (see pathfinder) and fraud management and scheme rule management, and seeking to address them with a range of tools. Moreover, open loop implies the ability to connect, the lack of barriers to participate, and non-exclusivity with other payment schemes. Mojaloop implements open loop and the other design principles as seen in the Leveloneproject.org. (D.) Role in the market: mojaloop was released under Share Alike 4.0 and there was an explicit appeal to other payment processing providers and those providing mobile money systems to take a look and find out if there is something that can be used. It seems on first glance that Stellar is trying be both the provider of technology and the operator but maybe that is changing. It think mojaloop is more similar to Apache Fineract than Stellar in terms of the role in market. > 3.) Is someone at LevelOne considering implementing a > Fineract-mojaloop bridge component similar to the Fineract-Stellar > bridge component we've already written? > I think that would be a fine idea. But, we don't need a top down direction to give it a try. > > Best Regards, > Myrle > > > On Wed, Oct 18, 2017 at 9: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 >
