Hi Devs - *Context* Proposal for new effort. I'd like to kick off further discussion and action on the mojaloop payments hub integration with fineract, and by that I mean both fineract1.x and fineractCN. Imagine that a customer named Marie using fineract-BankA is able to pay Alfred_Shop using fineract-BankB, and that Raul on TelcoX_running_ericcssonMTN can pay Marie on a p2p transfer, and that Marjolaine is able to receive a gov't benefit payment on bigBankC_runningFineractCN and then she can pay Alfred_Shop, and Alfred can pay his microfinance loan...anyone can pay anyone anywhere.
It has long been in the vision that fineract would be part of a vibrant ecosystem of providers that can connect to each other. In many parts of the world there is no existing interoperable payments switch (backend) that can easily connect all financial services providers in a country or a region - i.e. banks with or to telco "mobile money" wallets, with Microfinance Banks, and so on, - and yet electronic payments are a vital part of the story of financial inclusion. We started well with Steve's work - see https://cwiki.apache.org/confluence/display/FINERACT/Mojaloop+Integration and some use cases that could be demonstrated in a real live instance. This was a very promising set of explorations and demonstrations, and I believe it helped to kick off the effort well by also helping to define what is missing in fineract to connect to a payments switch. We're going to leverage that experience. Thank you again Steve and Raul. *Status* With this email I'd like to propose (and kick off?) a new design and implementation effort. We know of a software dev team that have deep experience with both fineract1.x and fineractCN - as in they are using both versions of the project code in production in the financial services industry - and they also have deep experience with payment architectures in Europe and Asia. Steve, Raul, Ed, and I just held a call with them and we want this dev process to be as visible and on-list as possible. That said, some of the anticipated work (e.g. dev ops for a "lab", front ends) is outside of the fineract project, and so we'll try to keep the details here to the relevant pieces for fineract. FYI Some of this will be hosted on the mifos infrastructure and available to the wider financial inclusion community and potentially useful to the financial service providers as well. *Design* We're already into a design & requirements document, the details of which I think are too much for email but should be posted to the wiki. Short-hand, we're proposing a Payment Hub component that sits on either (both and) Fineract1.*/ Fineract-CN that speaks to Mojaloop. In that component we'll implement the very detailed APIs that were proposed by Mojaloop which connect back-end to back-end of multitenant fineract instances. Diagrams like this may be helpful where you can think of Fineract as the DFSP (Digital Financial Service Provider) https://github.com/mojaloop/docs/blob/master/Diagrams/ArchitectureDiagrams/20180830-Mojaloop-End_to_End-PI3.pdf Then, from the component to fineract will be REST calls to existing APIs. Further, there will be some need for additional channel specific API calls (and call backs) that don't currently exist in either of the fineract projects. The backend of Fineract v1.0 and Fineract CN might need to be modified to be able to handle the required functionality, triggered by the Payment Hub. All communication between the Fineract and the Payment Hub will be implemented via synchronous REST API. I would point out that this perhaps has also shed a light on the need for front-end-channel APIs as completely different from back end switch-integration APIs and perhaps completely different from in-bank teller/fieldofficer APIs. For now, we're proposing to leave the APIs largely alone, but I think at some future point we do need to surface this and try to rationalize and normalize the way that this is designed in fineract. We are currently contemplating this as a new service on fineract-CN and with a kind of wrapper of that on fineract1.x although that idea needs some design advice. We'd like to avoid building the same thing twice and requiring it to be maintained in both places, although this may be unavoidable in some specifics as the two fineract projects are very different. We talked today about using camel.apache.org code inside a Spring framework, as this provides a way to express handling of events and triggers in an enterprise service bus way. The devs want to implement that in this one component, but this does not mean it would require changing anything in the core fineracts. The devs plan to show a snippet of that code on list so we can all see how that might work - we understand that it is mostly POJO, so hopefully not controversial. It might help that it is an apache project, no? @Myrle - hope you can comment. *Process* Mojaloop is a new open source project and, as we're working to implement something that relies on their design and their APIs, some of the conversation will necessarily happen on their infrastructure. We'll try to mirror that over here on the dev list when appropriate. When there are changes needed in Fineract, I am proposing that we follow the normal thing here and propose ideas, write them up, create jira tickets to capture the key proposed new functionality, and then provide links to active github repos that are forks of the fineract project, then do the PRs. We will need code reviewers and support from infra at some point. If there is no objection we'll assume this is all looking good and continue apace. Thanks and I look forward to comments, James @jdailey67 For more information, please see A. previous emails https://markmail.org/search/?q=list%3Aorg.apache.fineract.dev+order%3Adate-backward+mojaloop#query:list%3Aorg.apache.fineract.dev%20order%3Adate-backward%20mojaloop+page:11+mid:r7lwkjl2v6x674sq+state:results and https://markmail.org/search/?q=list%3Aorg.apache.fineract.dev+order%3Adate-backward+mojaloop#query:list%3Aorg.apache.fineract.dev%20order%3Adate-backward%20mojaloop+page:1+mid:ck7fkrzmjweodfp5+state:results b. readings "Payment Aspects of Financial Inclusion" http://www.worldbank.org/en/topic/financialinclusion/brief/pafi-task-force-and-report and "Interoperability and financial inclusion" http://www.cgap.org/blog/interoperability-and-financial-inclusion-regulators-role and "2016 Scan of Interoperability" https://www.cgap.org/sites/default/files/researches/documents/interoperability.pdf
