From user-return-536-archive-asf-public=cust-asf.ponee.io@fineract.apache.org Tue Jan 30 17:39:28 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id E22F618061A for ; Tue, 30 Jan 2018 17:39:28 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D218C160C53; Tue, 30 Jan 2018 16:39:28 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5B619160C42 for ; Tue, 30 Jan 2018 17:39:27 +0100 (CET) Received: (qmail 10505 invoked by uid 500); 30 Jan 2018 16:39:26 -0000 Mailing-List: contact user-help@fineract.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@fineract.apache.org Delivered-To: mailing list user@fineract.apache.org Received: (qmail 10495 invoked by uid 99); 30 Jan 2018 16:39:26 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jan 2018 16:39:26 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0BA32180119 for ; Tue, 30 Jan 2018 16:39:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=mentorsinternational-org.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 1gxmRMwL8yuG for ; Tue, 30 Jan 2018 16:39:21 +0000 (UTC) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 7ED7160F8C for ; Tue, 30 Jan 2018 16:39:18 +0000 (UTC) Received: by mail-qk0-f177.google.com with SMTP id z12so10876448qkf.12 for ; Tue, 30 Jan 2018 08:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mentorsinternational-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ci7vGcOmGjjcgk2U9uxGGPz+XxIExBF7moSWsYdvAso=; b=0qWKSjwJRZpOqGi/VIMc/wBADhtPdznC545M3yv5wS7acc97WpAyflrmWPNR/EB6pe HFLiW78LqdPziHuE8m6TmyvQA6EeJP7cPADQDfuoxBfTYXAvdiZ8d5hnyGX+FEEvKhr7 +5CftuxRJHvYfBB5jAc/E9TWhSzQg/ENFuVlSYWiO4uY593jZsCggi+hRr7jcf86KF+g LzHw0HnZcHclWrtZeZWC8uXum3b4kdeETJ2J8ZSwcE/GIvAPPWeYikqvVQsuyP+4E21E VcuRyUnOzdSodmlPsFWJdi/Qk0nknAAVdd2t4ZdqgR2QU/xqzo/0NH3Y0C60jqeRQWli 1/xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ci7vGcOmGjjcgk2U9uxGGPz+XxIExBF7moSWsYdvAso=; b=d8PxCJwcFcNWLYK9x6GrGcE9AHK2lj0FYhcdjZF5EuKuPvNd8GL7PJ79Tv/lgx+ymT 96iMPMf12eXIsi8YlPMbyRlK+0KdGKK8sF6q6Xu8R9qwK39xEBKjzNGNKNF2NUgs+GmT w01LsYkF8WLOU9914nxgo325sSJxOZ6Ff+lYz6o5gAQ/pUeopIe6RcJGdb3+Q7UuekEE 9mKH+RaNbUUhkMPntUdaIFD8LkdR5w+vip8ZYfZBn6Jt0Wv3a2eY4jyWp8b0TuD7RLaO 37mMaM9I8CnU8XT00xzKciIOOYO5sYOORMR4q2cDKwi291rKvHg+z5G6jevf6KPEni/E +hUQ== X-Gm-Message-State: AKwxyteJANOvlPjSRg36K3TCuRktozMllhlsge0n8pO2Uf5ha1XE0fOC fqHKRTZ88FLiEIhp5KIPSoKMexMVqhz9Kh8gG797TQ== X-Google-Smtp-Source: AH8x224NkjZNc/WrHPmA9aJT725gAlR7/nG5c9vUgWNfb0aBKNR4RumKmfCjlDIpE44etEtuR6uNVB7DeMwJ+3H7g/Q= X-Received: by 10.55.247.5 with SMTP id q5mr43053530qkj.147.1517330357041; Tue, 30 Jan 2018 08:39:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nathan McClellan Date: Tue, 30 Jan 2018 16:39:06 +0000 Message-ID: Subject: Re: Mifos/Stellar Integration WAS: [Fwd: My Intro and Mojaloop] To: user@fineract.apache.org Cc: Dev , Mifos software development , mifos-users Content-Type: multipart/alternative; boundary="089e082d1f04f054c705640100ea" --089e082d1f04f054c705640100ea Content-Type: text/plain; charset="UTF-8" We may be able to be one of the pilot organization. Can I get some more details on what it would require? Thanks On Tue, Jan 30, 2018 at 1:33 AM Ed Cable wrote: > Since this thread has likely fallen below everyone's radars, I wanted to > bring it to attention once more as the community is still eager to see it > brought to completion. > > I had a recent conversation with Tunde from Stellar and their developers > are standing by, ready to assist once we have some concrete use cases from > pilot organizations identified. Since so much time is transpired we'll have > to identify how the points of integration with the Stellar SDK has changed. > > We have a number of outstanding tasks where we could use volunteers > > MFIs/Financial Institutions - we're still seeking two organizations to > pilot the integration to demonstrate a money transfer service - should be > two separate legal entities, within the same country, using or willing to > use Fineract, and willing to use Stellar > > 1) Full Stack Developer - Assess the gaps and remaining work for the > Stellar/Fineract bridge including changes in Stellar SDK between now and > time of creating bridge. > 2) Product Manager - translate these gaps into user stories for a > volunteer to implement > 3) Front-End Developer - implement the UI screens detailed in wireframes > and for additional use cases needed by pilot org > 4) Mobile Developer - complete UI flows for the initial use cases for > initiating transfer via mobile banking app. > > See the wiki page at > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=70256854 for > full background on the work to date and wireframes for the UI. > > Ed > > On Fri, Oct 20, 2017 at 8:05 AM, Stephen Agyepong < > stephenagyepong@gmail.com> wrote: > >> Ed, >> >> We are working on a Stellar wallet that we want to integrate with >> Fineract. Please see the attached screenshots. We made a lot of progress >> but there is still much to be accomplished. We intend to make it possible >> to do money transfers using an integrated Stellar/Fineract. We will be >> happy to pilot this work. We wanted to polish it up a bit before making it >> public but if you are curious you can see it in action at: >> http://dcubedev.com/ and github at: https://github.com/dcubedev/dcubeapp >> >> It is designed to work with any underlying payment platform not just >> Stellar though. >> >> Thanks >> >> Stephen >> >> On Fri, Oct 20, 2017 at 4:43 AM, Ed Cable wrote: >> >>> So as not to hijack James' thread on Mojaloop, I want to divert part of >>> the >>> conversation around our existing Stellar/Mifos bridge on Apache Fineract >>> 1.0 to a separate thread. >>> >>> As background, Myrle and Bartek invested a significant amount of effort >>> into the bridge but due to lack of concrete use cases to implement, >>> development was put on hold. >>> >>> Some additions to the bridge itself, and the front-end implementation of >>> the UI along with a solidified use cases were needed to proceed forward. >>> All of this project history and analysis has been documented on this wiki >>> page: https://cwiki.apache.org/confluence/pages/viewpage.act >>> ion?pageId=70256854 >>> >>> I've struggled over the past year to get contributors to wrap up the >>> remaining work and have cycle through a couple different volunteers who >>> were going to take it on. I'm now working with Denila to fully bake out >>> the >>> remaining work as clear user stories that a dev can pick up. >>> >>> I would still like to see this bridge get completed and work with some >>> users in the community who would like to test out this service. Since so >>> much time has elapsed we have missed our opportunity to be the first >>> financial inclusion use case on Stellar but I feel it's still a valuable >>> integration even if it's just for a proof concept. >>> >>> While I might be getting hung up on the sunk cost fallacy, and not >>> wanting >>> to let go of all the time and effort Myrle and team invested... >>> >>> 1) Should we continue trying to complete this integration with current >>> Apache Fineract 1.0 or turn attention towards a bridge that's compatible >>> with Fineract CN >>> 2) Are there users in the community that want to pilot this first as a >>> domestic money transfer service? There was a great deal of interest >>> previously but difficulty in getting concrete use cases. We'd require two >>> separate financial institutions running different instances of Apache >>> Fineract. >>> >>> Ed >>> ---------- Forwarded message ---------- >>> From: Myrle Krantz >>> Date: Fri, Oct 20, 2017 at 1:03 AM >>> Subject: Re: My Intro and Mojaloop >>> To: dev >>> >>> >>> 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. >>> 2.) As far as I can tell, as a payments transfer system, this has very >>> little functionality overlap with Fineract or Fineract CN. >>> 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. >>> 4.) I agree that push payments, processed immediately, are the right way >>> to >>> go. >>> >>> 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? >>> 2.) What, in your view, are the major differences between mojaloop and >>> Stellar? What are the advantages to mojaloop? >>> 3.) Is someone at LevelOne considering implementing a >>> Fineract-mojaloop bridge component similar to the Fineract-Stellar >>> bridge component we've already written? >>> >>> Best Regards, >>> Myrle >>> >>> >>> On Wed, Oct 18, 2017 at 9:31 PM, James Dailey >>> 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 >>> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 >>> <(484)%20477-8649> >>> >>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org >>> >>> >> >> > > > -- > *Ed Cable* > President/CEO, Mifos Initiative > edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 > <+1%20484-477-8649> > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > > > -- *Nathan McClellan* VP, International Operations 801.456.0715 Mentors International Join Our Community NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --089e082d1f04f054c705640100ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We may be able to be one of the pilot organization.=C2=A0<= div>Can I get some more details=C2=A0on what it would require?=C2=A0
<= div>
Thanks=C2=A0

<= div dir=3D"ltr">On Tue, Jan 30, 2018 at 1:33 AM Ed Cable <edcable@mifos.org> wrote:
Since this thread has likely fallen b= elow everyone's radars, I wanted to bring it to attention once more as = the community is still eager to see it brought to completion.=C2=A0
I had a recent conversation with Tunde from Stellar and their d= evelopers are standing by, ready to assist once we have some concrete use c= ases from pilot organizations identified. Since so much time is transpired = we'll have to identify how the points of integration with the Stellar S= DK has changed.

We have a number of outstanding ta= sks where we could use volunteers

MFIs/Financial I= nstitutions - we're still seeking two organizations to pilot the integr= ation to demonstrate a money transfer service - should be two separate lega= l entities, within the same country, using or willing to use Fineract, and = willing to use Stellar=C2=A0

1) Full Stack Develop= er - Assess the gaps and remaining work for the Stellar/Fineract bridge inc= luding changes in Stellar SDK between now and time of creating bridge.=C2= =A0
2) Product Manager - translate these gaps into user stories f= or a volunteer to implement
3) Front-End Developer - implement th= e UI screens detailed in wireframes and for additional use cases needed by = pilot org
4) Mobile Developer - complete UI flows for the initial= use cases for initiating transfer via mobile banking app. =C2=A0

See the wiki page at=C2=A0ht= tps://cwiki.apache.org/confluence/pages/viewpage.action?pageId=3D70256854=C2=A0for full background on th= e work to date and wireframes for the UI.=C2=A0

Ed

On Fri, Oct 20,= 2017 at 8:05 AM, Stephen Agyepong <stephenagyepong@gmail.com&= gt; wrote:
Ed,

We are working on a Stellar wallet that= we want to integrate with Fineract. Please see the attached screenshots. W= e made a lot of progress but there is still much to be accomplished. We int= end to make it possible to do money transfers using an integrated Stellar/F= ineract. We will be happy to pilot this work. We wanted to polish it up a b= it before making it public but if you are curious you can see it in action = at:=C2=A0http://dcubedev= .com/ and github at:=C2=A0https://github.com/dcubedev/dcubeapp
It is designed to work with any underlying payment platform no= t just Stellar though.

Thanks

=
Stephen

On Fri, Oct 20, 2= 017 at 4:43 AM, Ed Cable <edcable@mifos.org> wrote:
So as not to hijack James' thread on M= ojaloop, I want to divert part of the
conversation around our existing Stellar/Mifos bridge on Apache Fineract 1.0 to a separate thread.

As background, Myrle and Bartek invested a significant amount of effort
into the bridge but due to lack of concrete use cases to implement,
development was put on hold.

Some additions to the bridge itself, and the front-end implementation of the UI along with a solidified use cases were needed to proceed forward. All of this project history and analysis has been documented on this wiki page: https://cwiki.apache.org/confluence/page= s/viewpage.act
ion?pageId=3D70256854

I've struggled over the past year to get contributors to wrap up the remaining work and have cycle through a couple different volunteers who
were going to take it on. I'm now working with Denila to fully bake out= the
remaining work as clear user stories that a dev can pick up.

I would still like to see this bridge get completed and work with some
users in the community who would like to test out this service. Since so much time has elapsed we have missed our opportunity to be the first
financial inclusion use case on Stellar but I feel it's still a valuabl= e
integration even if it's just for a proof concept.

While I might be getting hung up on the sunk cost fallacy, and not wanting<= br> to let go of all the time and effort Myrle and team invested...

1) Should we continue trying to complete this integration with current
Apache Fineract 1.0 or turn attention towards a bridge that's compatibl= e
with Fineract CN
2) Are there users in the community that want to pilot this first as a
domestic money transfer service? There was a great deal of interest
previously but difficulty in getting concrete use cases. We'd require t= wo
separate financial institutions running different instances of Apache
Fineract.

Ed
---------- Forwarded message ----------
From: Myrle Krantz <myrle@apache.org>
Date: Fri, Oct 20, 2017 at 1:03 AM
Subject: Re: My Intro and Mojaloop
To: dev <de= v@fineract.apache.org>


Hey James,

Now I've had the chance to take a closer look.=C2=A0 It's an intere= sting
project.=C2=A0 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.=C2=A0 Not all of them, but several of them.
2.) As far as I can tell, as a payments transfer system, this has very
little functionality overlap with Fineract or Fineract CN.
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.
4.) I agree that push payments, processed immediately, are the right way to=
go.

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.=C2=A0 (With the recent announcement that IBM and
Stellar will be partnering this may yet change) Is someone deploying
mojaloop?
2.) What, in your view, are the major differences between mojaloop and
Stellar? What are the advantages to mojaloop?
3.) Is someone at LevelOne considering implementing a
Fineract-mojaloop bridge component similar to the Fineract-Stellar
bridge component we've already written?

Best Regards,
Myrle


On Wed, Oct 18, 2017 at 9:31 PM, James Dailey <jamespdailey@gmail.com>
wrote:
> Fineract'rs:
>
> I joined this list recently and would like to introduce myself.=C2=A0 = 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 gro= up
> that contributed the Fineract Code.=C2=A0 While I don't code mysel= f, 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 al= so 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 (c= ontract)
> 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 we= ek
as
> open source code.=C2=A0 http://mojaloop.io/=C2=A0 =C2=A0I'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 b= ase
> could relate to the Mojaloop code. I suspect Markus is already thinkin= g
> 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 Financ= ial
> Service Providers) running a current version of Fineract could be the<= br> > source and the destination for funds.
>
> While the world of payments can be arcane, one needs the ability to ro= ute
> the payment to a specific account address and the ability to ensure th= at
> the payment settles at end of day or sooner (as soon as real time). > Mojaloop has a novel approach for both of these.=C2=A0 In the first, m= ojaloop
> leverages Pathfinder (
> https://github.com/LevelOne= Project/Docs/tree/master/CentralDirectory).
> Pathfinder is a service of GSMA
> https://www.gsma.com/managedservices/nu= mber-portability-
services/about-pathfinder/
> .
> This innovation is important because it brings a different approach to=
> routing that is compatible with mobile telephony identity.=C2=A0 This = code (
> https://github.com/LevelOnePro= ject/pathfinder-provisioning-client.) seems
> like a good way to understand how this works.=C2=A0 In the second, Moj= aloop
uses
> work by Ripple Labs on the Interledger Protocol (ILP) (
> https://interledger.org/) to settle across different payment scheme= s or
> within a network of ledgers and for the mojaloop that is quintessially= the
> Central Hub.
> https://github.com/Lev= elOneProject/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 t= he
> Fineract project today I would hazard.=C2=A0 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 moja= loop
> 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 compatib= le.
>
> Also, the centralized fraud service and scheme rules setting are also<= br> > 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.=C2=A0 I would suggest however that since m= ojaloop
is
> primarily about the transfer of value and Fineract-CN is primarily abo= ut
> the management of accounts and clients and access points, that the ove= rlap
> is minimal.=C2=A0 Dare I compare this to chocolate and peanut butter a= nd the
> wonderful collision which is the Reese's Peanut Butter Cup?=C2=A0 = We'll see.
>
> As an idea, when building the microservices, it may be possible to wra= p
> some of the libraries or services that were released under mojaloop - = if
> licenses are compatible of course.=C2=A0 On that the mojaloop team cho= ose
> Creative Commons Share Alike 4.0.=C2=A0 If there is a mentor who can a= nswer
that
> - it would be good to know.
>
> There is also a need to understand the flows that are - in my view - > payments done right.=C2=A0 That is, payments or transfer of value, occ= ur
outside
> of the signaling for those payments and are push and process immediate= ly.
> I've addressed this in another post recently but basically the flo= ws are
> well documented and the APIs are using the latest and greatest - Finer= act
> could benefit from simply reviewing that documentation.
> https://leveloneproject.org/wp-conte= nt/uploads/2015/04/The-
Level-One-Project-Guide-Designing-a-New-System-for-Financial-Inclusion1.pdf=
>
>=C2=A0 =C2=A0https://github.com= /LevelOneProject/Docs/tree/master/CentralLedger=C2=A0 ;
>=C2=A0 =C2=A0https://github.co= m/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 w= ho
> could help identify some of the paths that would lead to some win-wins= on
> this front.=C2=A0 I look forward to the conversation.
>
> - James Dailey
> Seattle



--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
<(484)%20477-8649>

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos>=C2=A0 <http://www.twitter.com/m= ifos>




--
Ed Cabl= e
President/CEO= , Mifos Initiative
edcable@mifos= .org=C2=A0| Skype: edcable | Mobile: +1.484.477.8649

Collective= ly Creating a World of 3 Billion Maries |=C2=A0http://mifos.org=C2=A03D""=C2=A0<= /div>

--
Nathan McC= lellan
=

VP, International Operations=C2=A0

801.456.0715

Mentors International<= /a>


Join Our Community

NO= TICE: This email message is for the sole use of the intended recipient(s) a= nd may contain confidential and privileged information. Any unauthorized re= view, use, disclosure or distribution is prohibited. If you are not the int= ended recipient,=C2=A0please contact the sender by reply email and destroy = all copies of the original message.

--089e082d1f04f054c705640100ea--