You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <ja...@gmail.com> on 2017/11/02 23:17:20 UTC
Re: Notes from Mobile Money Gateway Check-In on on October 27
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 <ed...@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 <et...@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 <ja...@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
> edcable@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>
>
Re: Charge as a penalt in Mifos Release 17.07.01.RELEASE compared
to 16.12.01.RELEASE
Posted by Boniphace Fredrick <bo...@singo.africa>.
Thanks for your help,
I found that %Aproved Amount is the principal due amount, But there MFI's charge penalty based on the whole disbursed amount. And this feature no longer exist in 17.07.01.RELEASE
----- Original Message -----
From: "Santosh Math" <sa...@confluxtechnologies.com>
To: "dev" <de...@fineract.apache.org>
Sent: Friday, November 10, 2017 3:59:33 PM
Subject: Re: Charge as a penalt in Mifos Release 17.07.01.RELEASE compared to 16.12.01.RELEASE
Hi Boniphace,
%Aproved Amount in 17.07.1 is same as %Amount. Did you test with penalty
calculation for this for arrear loans and running scheduler job 'Apply
penalty to overdue loans'?
.
Santosh
On Fri, Nov 10, 2017 at 4:47 PM, Boniphace Fredrick <bo...@singo.africa>
wrote:
> Hello Devs;
> 1.I have a concern about charge calculation as an overdue fees.
> In the new Release ie, Release 17.07.01.RELEASE charge calculation as
> %Amount
> is no longer existing as compared to previous Release ie, 16.12.01.RELEASE.
> Consider the screenshot bellow.
> So is this a bug or that's how is suppose to be.
>
> 2.If it must be included, I need some clarification on the business logic
> regarding charge calculation for an overdue fee as a penalty, if we
> consider it as %Amount does it take the percentage of the installment
> amount(ie, principle and interest of the installment amount) or otherwise.
>
> Boniphace Fredrick
> Software Developer
> Research & Development
>
> Office: +255 22 261 8511 | Mobile: +255 718 212 834
>
> Singo Africa Limited
> Block G, Mbezi Beach B | 7Nakawale Road | P.O BOX 78908 | 14121 Dar es
> salaam
>
> singo.africa | amala.co.tz
>
> Let's grow together
Re: Charge as a penalt in Mifos Release 17.07.01.RELEASE compared to 16.12.01.RELEASE
Posted by Santosh Math <sa...@confluxtechnologies.com>.
Hi Boniphace,
%Aproved Amount in 17.07.1 is same as %Amount. Did you test with penalty
calculation for this for arrear loans and running scheduler job 'Apply
penalty to overdue loans'?
.
Santosh
On Fri, Nov 10, 2017 at 4:47 PM, Boniphace Fredrick <bo...@singo.africa>
wrote:
> Hello Devs;
> 1.I have a concern about charge calculation as an overdue fees.
> In the new Release ie, Release 17.07.01.RELEASE charge calculation as
> %Amount
> is no longer existing as compared to previous Release ie, 16.12.01.RELEASE.
> Consider the screenshot bellow.
> So is this a bug or that's how is suppose to be.
>
> 2.If it must be included, I need some clarification on the business logic
> regarding charge calculation for an overdue fee as a penalty, if we
> consider it as %Amount does it take the percentage of the installment
> amount(ie, principle and interest of the installment amount) or otherwise.
>
> Boniphace Fredrick
> Software Developer
> Research & Development
>
> Office: +255 22 261 8511 | Mobile: +255 718 212 834
>
> Singo Africa Limited
> Block G, Mbezi Beach B | 7Nakawale Road | P.O BOX 78908 | 14121 Dar es
> salaam
>
> singo.africa | amala.co.tz
>
> Let's grow together
Charge as a penalt in Mifos Release 17.07.01.RELEASE compared to
16.12.01.RELEASE
Posted by Boniphace Fredrick <bo...@singo.africa>.
Hello Devs;
1.I have a concern about charge calculation as an overdue fees.
In the new Release ie, Release 17.07.01.RELEASE charge calculation as %Amount
is no longer existing as compared to previous Release ie, 16.12.01.RELEASE.
Consider the screenshot bellow.
So is this a bug or that's how is suppose to be.
2.If it must be included, I need some clarification on the business logic regarding charge calculation for an overdue fee as a penalty, if we consider it as %Amount does it take the percentage of the installment amount(ie, principle and interest of the installment amount) or otherwise.
Boniphace Fredrick
Software Developer
Research & Development
Office: +255 22 261 8511 | Mobile: +255 718 212 834
Singo Africa Limited
Block G, Mbezi Beach B | 7Nakawale Road | P.O BOX 78908 | 14121 Dar es
salaam
singo.africa | amala.co.tz
Let's grow together