Hi again I want to highlight the design of some of the microservices under the mojaloop.io project as being useful for the mifos/fineract payments gateway thinking.
You can read about the Simple Payment Setup Protocol (SPSP) here: https://github.com/LevelOneProject/Docs/blob/master/Discovery.md To translate - in this description, the DFSP (digital financial service provider) could be running Mifos/Fineract as a payments bank, retail bank, microfinance institution, mobile money operator, or other regulated entity. For sending funds: Discovery of the receiver is a key element of how to properly go from one closed loop system to another. This is analogous to a Simple Mail Transfer Protocol (from which it gets its inspiration). Thus, a third party payments -processor is NOT strictly needed. So, the implication for the design work here is that we abstract the connection to a MifosX component (or microservice in Fineract CN) that is an endpoint for these types of processes: discovery being separate. Reactions? James On Fri, Oct 27, 2017 at 6:30 AM Ed Cable <edca...@mifos.org> wrote: > 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 <ettaa...@gmail.com> 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 <+237%206%2076%2010%2017%2085>* > > * +220 3681740 <+220%20368%201740>* > > *skype: **ayuketta2* > > > > > > > > > > > > On Thu, Oct 12, 2017 at 6:49 PM, James Dailey <jamespdai...@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 <+233%2026%20788%201050>", > > > "destinationRef" : "+80000000001 <+800%200000%200001>", > > > "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 > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 > <(484)%20477-8649> > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > <http://facebook.com/mifos> <http://www.twitter.com/mifos> >
