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
