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 >
