From user-return-542-archive-asf-public=cust-asf.ponee.io@fineract.apache.org Thu Feb 1 03:36:56 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 7DA33180662 for ; Thu, 1 Feb 2018 03:36:56 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6DAED160C56; Thu, 1 Feb 2018 02:36:56 +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 7639E160C42 for ; Thu, 1 Feb 2018 03:36:54 +0100 (CET) Received: (qmail 24790 invoked by uid 500); 1 Feb 2018 02:36:53 -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 24770 invoked by uid 99); 1 Feb 2018 02:36:52 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2018 02:36:52 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 9F2C5C055C; Thu, 1 Feb 2018 02:36:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.89 X-Spam-Level: * X-Spam-Status: No, score=1.89 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id s-3MukuYpBPf; Thu, 1 Feb 2018 02:36:44 +0000 (UTC) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 4B4125F1A0; Thu, 1 Feb 2018 02:36:43 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id t139so23859773lff.0; Wed, 31 Jan 2018 18:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9v8Dv2uvOJAUnor5MyqgHweLkrGo9Hl3F498/K0V4BU=; b=E1fWK+GpYuNNBg+NjXW3KIGNZQ4122R85yrL+FYyqaxFPwUVhl4LxhFvPYuQ2QjVln C0ptJRHCxa6c5K3/gcbueDBflsDIQEpWc10XqrRD+MjOse/4CdFpVyN7FYPc6rzaa/kd Rl+16R8PxruC+l1SihzYY6HPZwLwm4pqhqh4/2EomrcFwkOQzMLZzZONZ8sSLSOMgBMq zJ4Eh36AQFqrnX3qz9G5MIrkKxULVF3HRuxYKf7HCuxMJ5GolfE4uf8zJ0NT56kQlFT0 AYKbqC+1NjyvLdY/lUT3Wn+L3BUDXhJKyPy2qHoTvVKzf0/feP+Dq59uocDYa8KGOxal zfrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9v8Dv2uvOJAUnor5MyqgHweLkrGo9Hl3F498/K0V4BU=; b=WlZouMZfEOf929KLk1epdxS1VISaI1HZDoRL6gvrTAyO6LXeNKYRf7or9bLjYQnNvB Wli4RRXzCr/3EQTefUcP13yNFcjmAqpjXWq6qOn7IffP9pqHxUTvZluXcl8g1PyJ8J6W puZuQN6Ez8YshkUarW4mLmMUrFQjZKrOb3xM/X8t1UpuBqfTLPinKICMvbrzPPEFfL4N s4qqYl1oX0eB35icbfs2moA79GrL3H/swozViEu5z+6d9CikGHRy83vIk82z3Wwop1e7 eaKMM94K6Xv32C0ba9qrE6QZHhVpHVOK8nI/Y5VS7VnCAJz7iUj4EMAkmWW0BY91rwzc aS5g== X-Gm-Message-State: AKwxytc/DP+qhxTU62RSMSjSa8JShV0GhvZ4AfUStNAQ7qnzT89Q5spU Y5oqcsKlvB1rch8ry8GrkpAf/Ddoiu5e1OPj8fFoaQ== X-Google-Smtp-Source: AH8x224ZZc0AyrgajC4sqil2uDb3/rvj4eJ4E+HGejECslngmMADX6eqz0fecieMuOAxcuvGvNfRMXUzATUon000O0U= X-Received: by 10.46.16.210 with SMTP id 79mr15809238ljq.119.1517452601649; Wed, 31 Jan 2018 18:36:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.44.141 with HTTP; Wed, 31 Jan 2018 18:36:41 -0800 (PST) In-Reply-To: References: From: Stephen Agyepong Date: Wed, 31 Jan 2018 21:36:41 -0500 Message-ID: Subject: Re: [Mifos-users] Mifos/Stellar Integration WAS: [Fwd: My Intro and Mojaloop] To: user@fineract.apache.org Cc: "A good place to start for users or folks new to Mifos." , Mifos software development , Dev Content-Type: multipart/alternative; boundary="94eb2c1c049e48ed2205641d77e5" --94eb2c1c049e48ed2205641d77e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ed, I will be happy to hear from Tunde and their experience in Nigeria, which I believe will be very similar to Ghana. We have the chart of accounts setup for one micro-finance company. We are hoping to have another setup within 2 weeks. Any volunteers for the UI and mobile app? Thanks Stephen On Wed, Jan 31, 2018 at 2:14 PM, Ed Cable wrote: > Stephen, > > If you're not already connected with Tunde from the Stellar community let > me make an introduction as perhaps he can help you with some or the > regulatory challenges you're facing in Ghana. > > Stephen, since you seem pretty versed in the Stellar bridge, I'd love for > you to take up some of the outstanding work on it as a volunteer and > hopefully help us get some live use cases in place using the bridge. > > Myrle, thanks for providing that clarity to Stephen - hopefully if we get > someone like Stephen (or there are some other contributors interested) to > work on the remaining tasks for the bridge, you could give some guidance > and oversight. > > For all the users that expressed an interest in being pilot users, here's > the original pitch on what we're seeking: https://goo.gl/RiRxfC > > Right now the simplest use case that we'd like to focus on would involve > the following: > > In-Country > 1) Staff-Initiated money transfers via the Stellar protocol between the > savings accounts of members at two separate financial institutions both > using Fineract. Most of the functionality at back-end is in place we just > need to build out the UI in the front-end web app > 2) Client-initiated money transfers via the Stellar protocol via mobile > banking app from their savings account to savings account of another > individual at separate financial institution via stellar protocol. This > would involve building this out into mobile banking app - most of UI is > there just need to get bridge working > 3) Transfers from a member savings account of a Fineract user to an > external stellar wallet holder should also be possible but the focus of o= ur > pilots is on accountholders within Fineract. > > Cross-Border > 4) Ultimate use case is to leverage Stellar for reducing cost of > cross-border remittances and would aim to pilot this if regulatory > challenges can be surmounted. Stellar team has been making good connectio= ns > with anchors and market makers to facilitate currency exchange in the > remittance corridors relevant to our community. > > On Wed, Jan 31, 2018 at 6:22 AM, Stephen Agyepong < > stephenagyepong@gmail.com> wrote: > >> Myrle, >> >> It is a little complicated than this. >> The issue as I understand it is that the software to run money transfer >> has to be PCI/ISO 27001, etc certified >> According to our contacts, with the BOG warning, it is going to be >> difficult to get the necessary approval to proceed. >> We have not given up on it but it is a very slow process at this point. >> >> I have looked at/played with the Stellar/Fineract Bridge code. I will sa= y >> it is an outstanding piece of code. >> Thank you very much for putting out such a high quality software. >> >> Thanks >> >> Stephen >> >> On Wed, Jan 31, 2018 at 2:03 AM, Myrle Krantz wrote: >> >>> Hey Stephen, >>> >>> While it is possible to trade lumens (a crypto currency with some >>> properties similar to bitcoin) on the Stellar network, that=E2=80=99s n= ot the main >>> use case. The main use case is for tracking fiat currencies in a >>> transparent, safe way. >>> >>> Unless the Bank of Ghana is also objecting to old-fashioned check >>> writing or tracking debts in an SQL database, the text you cite would n= ot >>> apply to using Stellar for transferring fiat currencies. >>> >>> In the Stellar system, lumens are used as a currency-neutral reward >>> system for providing a piece of the distributed infrastructure. You wou= ld >>> only buy them to pay to make transactions (a fraction of a cent per >>> transaction). >>> >>> This may or may not change your approach to Stellar, but it was >>> important to me to set the record straight. >>> >>> Best Regards, >>> Myrle >>> The committer who did the work on the Mifos/Stellar bridge >>> >>> On Wed 31. Jan 2018 at 05:05 Stephen Agyepong >>> wrote: >>> >>>> Ed, >>>> >>>> We are currently in a state of flux given recent development in Ghana. >>>> Micro-finance companies are no longer allowed to engage in money trans= fer. >>>> The Bank of Ghana also recently cautioned the public on the use of vir= tual >>>> or digital currencies in the country. >>>> The central bank said it =E2=80=9Chas taken notice of recent developme= nts in >>>> the use, holding, and trading of virtual or digital currencies such as >>>> bitcion=E2=80=9D and =E2=80=9Cwishes to notify the general public that= these activities in >>>> digital currency are currently not licensed under the Payments System = Act >>>> 2003 (Act 662).=E2=80=9D >>>> >>>> I am hopeful things will change and we will be able to proceed. I will >>>> be happy to volunteer as the Full Stack Developer, since I have done >>>> work assessing the gaps and remaining work for the Stellar/Fineract br= idge. >>>> I looked at how we can bridge Fineract with other digital currencies w= ith >>>> Stellar as the default. >>>> >>>> Thanks >>>> >>>> Stephen >>>> >>>> >>>> On Tue, Jan 30, 2018 at 3:32 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 concret= e use >>>>> cases from pilot organizations identified. Since so much time is tran= spired >>>>> 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 t= o >>>>> pilot the integration to demonstrate a money transfer service - shoul= d be >>>>> two separate legal entities, within the same country, using or willin= g 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/co >>>>> nfluence/pages/viewpage.action?pageId=3D70256854 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 prog= ress >>>>>> but there is still much to be accomplished. We intend to make it pos= sible >>>>>> 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 mak= ing it >>>>>> public but if you are curious you can see it in action at: >>>>>> http://dcubedev.com/ and github at: https://github.com/dcubede >>>>>> v/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 par= t >>>>>>> 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 thi= s >>>>>>> wiki >>>>>>> page: https://cwiki.apache.org/confluence/pages/viewpage.act >>>>>>> ion?pageId=3D70256854 >>>>>>> >>>>>>> I've struggled over the past year to get contributors to wrap up th= e >>>>>>> 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 firs= t >>>>>>> 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 a= s >>>>>>> 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 Apac= he >>>>>>> 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 h= as >>>>>>> massive overlap with a different Ripple fork that we've seen in thi= s >>>>>>> community before: Stellar. >>>>>>> 4.) I agree that push payments, processed immediately, are the righ= t >>>>>>> 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 o= f >>>>>>> the Stellar network. (With the recent announcement that IBM and >>>>>>> Stellar will be partnering this may yet change) Is someone deployin= g >>>>>>> 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. = I >>>>>>> > formulated the Mifos project in 2001 when working at the Grameen >>>>>>> Technology >>>>>>> > Center and am current chair of the Mifos Initiative - which is th= e >>>>>>> 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 Gate= s >>>>>>> > 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 mo= re >>>>>>> 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/CentralD >>>>>>> irectory). >>>>>>> > 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/bloc >>>>>>> k-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 ne= w >>>>>>> > microservices architecture. I would suggest however that since >>>>>>> mojaloop >>>>>>> is >>>>>>> > primarily about the transfer of value and Fineract-CN is primaril= y >>>>>>> about >>>>>>> > the management of accounts and clients and access points, that th= e >>>>>>> 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'l= l >>>>>>> see. >>>>>>> > >>>>>>> > As an idea, when building the microservices, it may be possible t= o >>>>>>> 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 vie= w >>>>>>> - >>>>>>> > payments done right. That is, payments or transfer of value, occ= ur >>>>>>> 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/Central >>>>>>> Ledger ; >>>>>>> > https://github.com/LevelOneProject/Docs/tree/master/LevelOn >>>>>>> eClient ; >>>>>>> > 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 >>>>> <(484)%20477-8649> >>>>> >>>>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.or= g >>>>> >>>>> >>>>> >>>> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Mifos-users mailing list >> Mifos-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> >> > > > -- > *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 > > > --94eb2c1c049e48ed2205641d77e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ed,

I will be happy to hear from=C2=A0 Tunde and their experience in Nigeria, which I b= elieve will be very similar to Ghana.
We have the chart of accounts setup for one micro-finance company. W= e are hoping to have another setup within 2 weeks.

Any vo= lunteers for the UI and mobile app?

Thanks

Stephen

On Wed, Jan 31, 2018 at 2:14 PM, Ed Cable &l= t;edcable@mifos.org<= /a>> wrote:
St= ephen,

If you're not already connected with Tunde fr= om the Stellar community let me make an introduction as perhaps he can help= you with some or the regulatory challenges you're facing in Ghana.

Stephen, since you seem pretty versed in the Stellar = bridge, I'd love for you to take up some of the outstanding work on it = as a volunteer and hopefully help us get some live use cases in place using= the bridge.

Myrle, thanks for providing that clar= ity to Stephen - hopefully if we get someone like Stephen (or there are som= e other contributors interested) to work on the remaining tasks for the bri= dge, you could give some guidance and oversight.


Right now the simplest use case that we'd like to focus on would = involve the following:

In-Country
1) Sta= ff-Initiated money transfers via the Stellar protocol between the savings a= ccounts of members at two separate financial institutions both using Finera= ct. Most of the functionality at back-end is in place we just need to build= out the UI in the front-end web app=C2=A0
2) Client-initiated mo= ney transfers via the Stellar protocol via mobile banking app from their sa= vings account to savings account of another individual at separate financia= l institution via stellar protocol. This would involve building this out in= to mobile banking app - most of UI is there just need to get bridge working=
3) Transfers from a member savings account of a Fineract user to= an external stellar wallet holder should also be possible but the focus of= our pilots is on accountholders within Fineract.

= Cross-Border
4) Ultimate use case is to leverage Stellar for redu= cing cost of cross-border remittances and would aim to pilot this if regula= tory challenges can be surmounted. Stellar team has been making good connec= tions with anchors and market makers to facilitate currency exchange in the= remittance corridors relevant to our community.=C2=A0

On = Wed, Jan 31, 2018 at 6:22 AM, Stephen Agyepong <stephenagyepong@gm= ail.com> wrote:
Myrle,

It is a little complicate= d than this.
The issue as I und= erstand it is that the software to run money transfer has to be PCI/ISO 270= 01, etc certified
According to = our contacts, with the BOG warning, it is going to be difficult to get the = necessary approval to proceed.
= We have not given up on it but it is a very slow process at this point.

I have looked at/played with the Stellar/Fineract Bridge co= de. I will say it is an outstanding piece of code.
Thank you very much for putting out such a high quality= software.

Thanks

Stephen
<= /div>

On Wed, Jan 31, 2018 at 2:03 AM, Myrle Kran= tz <myrle@apache.org> wrote:
Hey Stephen,

While= it is possible to trade lumens (a crypto currency with some properties sim= ilar to bitcoin) on the Stellar network, that=E2=80=99s not the main use ca= se. The main use case is for tracking fiat currencies in a transparent, saf= e way.

Unless the Bank o= f Ghana is also objecting to old-fashioned check writing or tracking debts = in an SQL database, the text you cite would not apply to using Stellar for = transferring fiat currencies.

In the Stellar system, lumens are used as a currency-neutral reward s= ystem for providing a piece of the distributed infrastructure. You would on= ly buy them to pay to make transactions (a fraction of a cent per transacti= on).

This may or may not= change your approach to Stellar, but it was important to me to set the rec= ord straight.=C2=A0

Best= Regards,
Myrle
The committer= who did the work on the Mifos/Stellar bridge

On Wed 31. Jan 20= 18 at 05:05 Stephen Agyepong <stephenagyepong@gmail.com> wrote:
Ed,

We are currently in a state of flux giv= en recent development in Ghana. Micro-finance companies are no longer allow= ed to engage in money transfer.=C2=A0
The Bank of Ghana also= recently cautioned the public on the use of=20 virtual or digital currencies in the country.
The central bank said it =E2=80=9Chas taken notic= e of recent developments in the use, holding, and trading of virtual or dig= ital currencies such as bitcion=E2=80=9D and =E2=80=9Cwishes to notify the = general public that these activities in digital currency are currently not = licensed under the Payments System Act 2003 (Act 662).=E2=80=9D
<= br>
I am hopeful things will change and we will be able to procee= d. I will be happy to volunteer as the=C2=A0 Full Stack Developer, since I have done work ass= essing the gaps and remaining work for the Stellar/Fineract bridge. I looke= d at how we can bridge Fineract with other digital currencies with Stellar = as the default.

Thanks
=

Stephen


On Tue, Jan 30, 2018 at 3:32 AM, Ed Cable <edcable@mifos.org><= /span> 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.=C2=A0

I had a recent conversation with Tunde from Stellar and their devel= opers are standing by, ready to assist once we have some concrete use cases= from pilot organizations identified. Since so much time is transpired we&#= 39;ll have to identify how the points of integration with the Stellar SDK h= as changed.

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

MFIs/Financial Insti= tutions - we're still seeking two organizations to pilot the integratio= n to demonstrate a money transfer service - should be two separate legal en= tities, within the same country, using or willing to use Fineract, and will= ing to use Stellar=C2=A0

1) Full Stack Developer -= Assess the gaps and remaining work for the Stellar/Fineract bridge includi= ng changes in Stellar SDK between now and time of creating bridge.=C2=A0
2) Product Manager - translate these gaps into user stories for a v= olunteer to implement
3) Front-End Developer - implement the UI s= creens detailed in wireframes and for additional use cases needed by pilot = org
4) Mobile Developer - complete UI flows for the initial use c= ases for initiating transfer via mobile banking app. =C2=A0

<= /div>
See the w= iki page at=C2=A0https://cwiki.apache.org/co= nfluence/pages/viewpage.action= ?pageId=3D70256854=C2=A0for full background on the work to date = and wireframes for the UI.=C2=A0

Ed
<= div class=3D"gmail_extra">

<= div class=3D"gmail_quote">On Fri, Oct 20, 2017 at 8:05 AM, Stephen Agyepong= <s= tephenagyepong@gmail.com> wrote:
Ed,

We are working on a St= ellar wallet that we want to integrate with Fineract. Please see the attach= ed screenshots. We made a lot of progress but there is still much to be acc= omplished. We intend to make it possible to do money transfers using an int= egrated 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:=C2=A0http://dcubedev.com/ and github at:=C2=A0https://github.com/dcubedev/dcu= beapp

It is designed to work with any underlyi= ng payment platform not just Stellar though.

Thank= s

Stephen
On Fri, Oct 20, 2017 at 4:43 AM, Ed Cable <edcable@mifos.org> wrote:
=
So as not to hij= ack 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=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/managedservic= es/number-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-= content/uploads/2015/04/The-
Level-One-Project-Guide-Designing-a-New-System-for-Financial-Incl= usion1.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/LevelOnePro= ject/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 Cable
President/CEO, Mifos Initiative=
edcable@mifos.org=C2=A0| Skyp= e: edcable | Mobile: +1.484.477.8649

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



------------------------------------------------------= ------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_________= ______________________________________
Mifos-users mailing list
Mifo= s-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/lis= tinfo/mifos-users




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

Collectively Creating a World of 3= Billion Maries |=C2=A0h= ttp://mifos.org=C2=A03D""=C2= =A0


--94eb2c1c049e48ed2205641d77e5--