Here are notes from our latest check-in on October 27. https://cwiki.apache.org/confluence/display/FINERACT/2017-10-27+Weekly+Check-In+Meeting
On Thu, Oct 12, 2017 at 1:44 PM, ayuk etta <[email protected]> wrote: > 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 <[email protected]> > 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 > > > -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
