[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fineract & Mojaloop payments hub

Hi Devs -

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
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.

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.

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)

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

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

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.

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

Thanks and I look forward to comments,


For more information, please see
A. previous emails


b. readings
"Payment Aspects of Financial Inclusion"

"Interoperability and financial inclusion"

"2016 Scan of Interoperability"