Mailing-List: contact dev-help@fineract.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.apache.org
MIME-Version: 1.0
In-Reply-To: <CANMpf87Q+-+MP+e_Lu1g8ozXS8XNxJthegKgPVZwS7Ehr18V3w@mail.gmail.com>
References: <CANMpf87Q+-+MP+e_Lu1g8ozXS8XNxJthegKgPVZwS7Ehr18V3w@mail.gmail.com>
From: ayuk etta <ettaayuk@gmail.com>
Date: Thu, 12 Oct 2017 20:44:38 +0000
Message-ID: <CAP7+G88SCJ+KFP+nvsRP=wZdEgs38E_RgYiRGrwdVVp-UCXQxA@mail.gmail.com>
Subject: Re: Discussion on Next Steps for Mobile Money Gateway
To: dev@fineract.apache.org
Content-Type: multipart/alternative; boundary="f403045dc012e7c210055b5f9bdc"
archived-at: Thu, 12 Oct 2017 20:44:47 -0000

--f403045dc012e7c210055b5f9bdc
Content-Type: text/plain; charset="UTF-8"

Hi James,

Thanks for the insight. Its great to have you contributing payments
knowledge here, we needed it.

*Ayuk Etta A.*
*CEO/Founder, Skylabase, Inc*
*Business Development Director Africa, Kuelap, Inc.*
*Global Partner, Mifos Initiative *
*Tel: +237 676101785*
*     +220 3681740*
*skype: **ayuketta2*


On Thu, Oct 12, 2017 at 6:49 PM, James Dailey <jamespdailey@gmail.com>
wrote:

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

--f403045dc012e7c210055b5f9bdc--