OSDir


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

Re: Fineract Payment gateway


Hi Steve -

This is a really important project. Providing interoperability between
account systems at a national, regional, and global level is what is needed
ultimately.  Gone are the days when Mifos was just about managing the
"book" or portfolio of a single institution.  Mifos must participate in the
connective tissue of payments and movement of funds.  Thank you for all the
work you and the team have done.

When I look at this design, I have some key critiques and queries:

To start, in banking systems we have various ways of "routing" payments to
addresses.  This can be IBAN numbering, or credit card tokenized numbers
that link to virtual accounts, or SWIFT bank routing (wire transfers).  The
sending account and the receiving account need to be clearly identified to
the SWITCH in the middle but depending on the rules, the sending account
owner may not have full information about the receiving account.  Think of
sending PayPal or $Cash in the US - you have the Alias of the account, such
as the telephone number or the email address or $handle, to which you are
sending funds, but you do not have their underlying bank account
information.  As a sender you get some confirmation that says "yes, this is
the right person based on the information you've entered".  From what I can
see/understand in the code, you are expecting the sender to have a lot more
than the alias of the recipient, or the address that would be used in the
payment network.   ?  e.g.
https://github.com/conradsp/payment-gateway/blob/payment-gateway-core-functionality/src/main/java/org/apache/payment/gateway/service/TransactionsDataService.java


Second, it is generally accepted that a financial institution (FI)
participates in a payment SCHEME.  The scheme has rules which cover how
much can be transferred, what settlement rules there will be and how to
handle exceptions.  Generally the SWITCH in the middle handles the rule
enforcement although some rules are delegated to the sending or receiving
institution.  On the FI side there will be a stateless gateway that manages
the queue of transactions, basic data validation, and other key interop
functionality.

In many developing countries, the mobile wallet providers are unable to
connect to the banking SWITCH (e.g. they cannot get an IBAN ) and thus a
number of alternative models have developed, especially Aggregators, like
our example.  The short of this is that Aggregators have multiple *roles*
in the financial flows and this can create confusion in the design of
implementations.  I see some of these conceptual problems in the current
design.

I think it would be useful to review this Glossary of terms and concepts
from the ITU (the global association that governs Telecommunications):
https://www.itu.int/en/ITU-T/focusgroups/dfs/Documents/201701/ITU_FGDFS_DFS-Glossary.pdf
It came about because mobile wallets are becoming so ubiquitous but they -
unlike their counterparts in banking - are not yet offering good
interoperability. I'm happy to debate this point, but Aggregators don't
stand in adequately for a systemic approach to payments - they tend to
cherry pick the most profitable lines rather than offer a true *payment
rails*.

And, in particular, the use of the concept of "Vendor" is simply not right.
The concept should either be a payments network, a payments scheme, or some
combination.  Vendor may be applicable to a bulk sending provider (which
Aggregators also do), in which case you can have a Vendor offering a
processing service or a pre-processing service prior to submission of
payments to a payments network.  "Vendor" in the current design seems to
confound a number of concepts, including payment scheme, payment system,
processing entity, and data protocol to be used.

In terms of data protocols, again I would argue that Fineract MUST follow
international and globally emerging norms, as befits an Apache project
seeking global acceptance.  I am not yet in favor of ISO 20022 which is a
meta language where you have relatively heavy XML based vocabularies
(replacement of the ISO8583 "ATM Standard"), but neither am I in favor of
writing our own data standards.  I have strongly suggested that we get on
the bandwagon of the APIs developed by Mojaloop because they are the
culmination of work involving the major system providers in mobile wallets
and is open source.  They are also quite sensible. In this implementation
of the gateway our data payloads and the structure of the send, receive,
receipt are all non-standard, and unless I mis-understand, they are spread
out all over the place in the code.

Finally, in terms of structure, I'll say that clear roles for the different
pieces is super important. I'm glad you've been moving in that direction
with refactoring.  I am not exactly sure how to split out functional
domains, but in no particular order and mixing various levels, here are
some ideas:

* Bulk payment "pre-processing" should be separated out (bulk file
received, data validation, etc)
* Bulk payment retries and dashboards are also separate
* Join a payment scheme and network (become authenticated and authorized
participant as an institution)
* Use a payment system data standard (translate the data mapping)
* Enforce certain rules on FI (e.g. total settlement exposure on intra-day
period)
* On Receive, validate the payment recipient account (it exists and can
take funds, no flags) using alias
* On Send, validate funds are present (after built in authorization has
occurred)
* On Send, send payment amount to address (alias)
* On Send, expect a confirmation of amt received (receipt)
* Return information to customer on send

What not to do/include:
* Calculate net settlement positions (should be hand off to switch)
* Recognize funds received unless sending side has confirmed
* Write scheme rules into the core Fineract code

Fundamentally I do NOT believe Fineract or Mifos should be developing a
SWITCH, as Mojaloop.io has released that as open source.  At most we need a
gateway that can connect to different schemes, including mojaloop and a
standard ATM network, and perhaps also to various Aggregators (being
pragmatic as these do exist and will continue to for the near future).  It
is not uncommon for a Bank to have a connection to multiple schemes: i.e.
SWIFT, IBAN, ACH, LVT, etc.   We should NOT turn Mifos/fineract into a run
time fully stateful switch (ledger) in the middle.  It's role is the
backend system of record of a digital financial service provider (DFSP)
that connects to any number of payment schemes.

I am happy to discuss further and dig into this more.  Again, this is too
important not to get right. To bring Mifos/Fineract to a global audience we
have to address its role in the ecosystem of financial service providers
and how it connects to them all.

Let's have a convo with others who are involved via one of our
collaboration tools and report out to the listserv.  We should have others
review this in depth as to propose some more  specifics.  I would like a
high level architectural document view if that is also possible.

Thanks
James




On Sat, Oct 6, 2018 at 7:54 PM Steve Conrad <sconrad1@xxxxxxxxx> wrote:

> Hi all -
>
> I wanted to provide an update on the Fineract Payment gateway development
> that we have been working on over the past few months. A few different
> teams have been working on this functionality for some time, and we are
> continuing efforts to deliver functionality that will allow Fineract to
> work with other MFIs, MMPs and large scale projects like Mojaloop.
>
> Antony Omeri developed functionality that allows Fineract to interact with
> outside systems using ActiveMQ. The latest iteration of this development
> can be found here:
> https://github.com/conradsp/fineract/tree/payment-gateway-integration
> <
> https://www.google.com/url?q=https://github.com/conradsp/fineract/tree/payment-gateway-integration&sa=D&source=hangouts&ust=1538966323021000&usg=AFQjCNH9bUh4mSoaYAbRhOBamzmTeoPLvw
> >
>
> This past summer, Sanyam Goel (under the mentorship of Rahul Goel and
> myself) did some excellent work developing a middleware project that
> handles transactions between Fineract and other providers like Beyonic and
> Mojaloop. The latest iteration of this work can be found here:
>
> https://github.com/conradsp/payment-gateway/tree/payment-gateway-core-functionality
> <
> https://www.google.com/url?q=https://github.com/conradsp/payment-gateway/tree/payment-gateway-core-functionality&sa=D&source=hangouts&ust=1538966323021000&usg=AFQjCNGwy1RDZ7pn1SgoLEPQuFE-vcCUAA
> >
>
> After the summer, I did a bit of work to flesh out the connections between
> Fineract, the payment gateway, and a first outside provider, which was
> Beyonic. I have finished the implementation of some basic functionality,
> and created a document in Confluence which describes how to configure and
> use all of the various pieces. This document is located here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Payment+Gateway+Configuration
> <
> https://www.google.com/url?q=https://cwiki.apache.org/confluence/display/FINERACT/Payment%2BGateway%2BConfiguration&sa=D&source=hangouts&ust=1538966323021000&usg=AFQjCNF6bHAbrSYGX_h-NtLHSYLoF0Alcg
> >
>
> While we have established an architecture and implemented some basic flows,
> it is important that we validate that the architecture/design and approach
> are appropriate for what we would like to do long-term with Fineract and
> interacting with other platforms.
>
> I would invite the community to review, comment, and critique the work that
> has been done on this project. There may be a better design and
> architecture that will serve the long-term needs of Fineract. Or we may
> find that this architecture is one that we want to continue to build on and
> develop.
>
> Please feel free to respond with any questions or comments.
> Thanks,
> Steve
>