fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Dailey <jamespdai...@gmail.com>
Subject Re: Discussion on Next Steps for Mobile Money Gateway
Date Thu, 12 Oct 2017 18:49:33 GMT
Hi All -

Vladimir  - good project documentation and thank you for your many efforts
here:
https://gist.github.com/vladimirfomene/37bd38a289d0e9a0570b132735002868

So, I would like to contribute some key understandings I have about
payments here, that I think are very important for this project and its
long term success.

*one*, we must separate out the signaling for a potential payment from the
payment itself.  This is becoming the accepted approach in modern payment
systems - that one signals the "set-up" of a payment first, and then the
payment itself is a simple transaction.  These are, in a quasi technical
sense, in different *namespaces*.   You would therefore have a signal
message such as "Payment for Loan Repayment" on loan: 1234 for period: xyz
and for amount:y, on this date:z, which is then received/acknowledge by the
client.  The client then references the signal (this could often be called
an invoice for payment) and sends the payment.  By making this separation
explicit, new distributed permissioned ledger technologies can be leveraged
for the payment piece, while the signal can be evolved separately.   TL;DR
but see
https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money


...and policy wise:  In the case where you don't have an invoice, the
customer must rely on the response from the Loan system for how the payment
was processed.  The customer may give some instruction for how they would
prefer the payment is to be applied. Ultimately, the creditor has the
contractual relationship and their internal logic for how payments are to
be applied; I think we cannot assume client payments are made with that
much instructional integrity.

*two*, when we have a payment, **who** places the payment in the *payment
system* determines whether it is a push or a pull transaction. In a pull
system, the authorized merchant enters the payor information into the
system and has his/her bank route authorization of payment to the payee's
bank (when I say bank = Regulated Financial Service Provider), and the
funds are effectively locked up and sent at that moment.  So, we want push
transactions.   In a push transaction, the payor (customer for ease of
understanding) enters the information into the payment scheme and their
bank sends the good funds to the payee's bank, hopefully in real time.

So, putting one and two together, the invoice is assumed to exist in the
recipient (payee) system and the customer's name is linked to that.  That
may work for 80% of the cases. i.e. Customer A makes a Payment X and they
only have one so we're good.   If the customer inputs a specific loan
number or specific payment (which could be part of the set up of the
payment on their device based on a record of what payments they've made),
then that specific payment reference number is provided to the recipient
system for confirmation.   I realize this changes the flow significantly,
but I think we have to look beyond the existing systems in the field today
and understand where things are going...

*three*, clearing is a word that has very little meaning today.  It used to
refer to the movement of paper from one desk to another, now it's just
anachronistic.  In modern systems, transactions are sent and arrive in
microseconds so the key thing is to understand how settlement works.
Settlement is basically when banks (FSPs), at the end of the day or every
few minutes, move funds from one acct to another in a centralized account
(often at the Central Bank) so that they no longer owe each other.  So,
it's vitally important that the ledgers remain clear on who has actually
paid what amounts from which mobile money providers (FSPs).  I bring this
up because the flag of source of funds is probably something that needs
careful attention. Perhaps this is what Beyonic is handling - so all you
need is "paymentMethodType" : "beyonic",  but I would want to have that in
writing as it were.  Perhaps the mmp value is the implicit source of
funds?

In payments of microfinance loans, if the mobile money account money is
held by a Mobile Network Operator in a regulated bank, then end of the day
they'd be sending funds and having a record of who sent what from what
banking entity is important.

I'm commenting on the example request below - just for generating ideas:

Example Request:

    POST http://localhost:8080/inbound/requests?tenant=default
    Content-Type: application/json
    Request Body:
    {
        "id" : 1,
        "transactType" : "LOAN_REPAYMENT",  // yes, super important,
let's make sure we use a known value set from payments nomeclature
        "paymentMethod" : "mobile money",
        "paymentMethodType" : "beyonic",
        "mmpId" : 1,
        "mfiId" : 1,
        "sourceRef" : "+233267881050",
        "destinationRef" : "+80000000001",
        "fineractAccNo" : "000000039",  // can we use an actual FSP
name here rather than the software name?
        "fineractClientId" : 1, // same
        "amount" : 10, // currency is ?
        "transactionReason" : "Test Beyonic",
        "externalSystId" : 0,
        "comments" : "outgoing payment",  // redundant message?  why
is this needed?
        "requestDtm" : "1503492596",
        "requestIpAddress" : "127.0.0.1", //part of metadata for
security, should be a wrapper?
        "inboundStatusId" : 0, // state management in the message? Is
there a state diagram?
        "inboundStatusDtm" : "1503492596"
   }


Looking at above, aside from my concerns about separating out signal from
payment, and ensuring that the flows are logically clear, the other issue
is with the message state management.  This could become very chatty on a
network level if the state management becomes highly detailed.  Sent,
received, failed is the easy version, but that can grow exponentially with
each hop in the sub-systems involved and multiple round-trips and every
error-out condition leading to a different state condition.

Also, we probably need a new glossary for fineract globally:
e.g. A payment system consists of all pre-processing and processing
components either at the bank or in a third party that touch the
transaction in route.  And I would make use of available globally
consistent definitions.
e.g. FSP = Financial Service Provider
which is probably the grist for another post to this group.   Later.

Thanks!

James Dailey
SEATTLE

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message