My comments below is related to item no.2 not 3 ----- Original Message ----- From: "Sendoro Juma" <sendoro@singo.africa> To: "dev" <dev@fineract.apache.org> Cc: "mifos-developer" <mifos-develo...@lists.sourceforge.net> Sent: Wednesday, March 21, 2018 8:07:34 AM Subject: Re: Self-Service Access for Client-Facing Apps on Apache Fineract CN
Hello Ed, Dev On item no. 3 on registration verification I think mobile phone verification is even more important than email nowadays, so it can be both email and phone.. it should be added and I suggest to be a MUST. Regards Sendoro ----- Original Message ----- From: "Ed Cable" <edca...@mifos.org> To: "dev" <dev@fineract.apache.org> Cc: "mifos-developer" <mifos-develo...@lists.sourceforge.net> Sent: Wednesday, March 21, 2018 5:40:22 AM Subject: Re: Self-Service Access for Client-Facing Apps on Apache Fineract CN Hi all, As a follow-up to this thread, Sundari has fleshed out some more details supporting the use cases Nayan had proposed for a client-facing digital credit app at https://cwiki.apache.org/confluence/display/FINERACT/Digital+Credit+App Markus, Myrle, or others - it'd be great to get your input as to how you'd securely enable clients to access the data needed in such an app. Ed On Fri, Jan 26, 2018 at 6:20 PM, Ed Cable <edca...@mifos.org> wrote: > Hi Markus, > > Thanks for your replies. > > For the rest of the community, > > While I know that with the previous iteration of self-service apps, we > focused on implementing the back-end first and then allowing front-end use > cases to follow, a good approach this time around would be to get some > solid client-facing use cases identified and then design the back-end and > integration with the data to support those use cases. Nayan from RuPie has > shared some initial use cases he has. I'm working with a Mifos volunteer, > Sundari Swami, to flesh these out further but wanted to share the initial > use cases Nayan had presented to stimulate further discussion on what the > best approach to supporting a client-facing app on Apache Fineract CN that > would support adequately: > > From customer side > > UC 1. Client signup with basic data, and spot verification either with OTP > to mobile number or Aadhaar verification > UC 2. Customer can enter customer's other details like address, family, > work, income/expense details, once this data is verified from back office, > customer can't edit any of these data > UC 3. Apply for loans > UC 4. Repay EMI > UC 5. Preclose his/her loans > UC 6. Log support request > UC 7. Upload documents like photo of electricity bills, voter id, passport > etc, once documents are verified and accepted from back office customer > cab't edit , delete the verified documents, but customer can upload new > documents > > From organization point of view > > UC 1, Offer loan products based below criteria > > > - Location ( Example, Bengaluru has P1 and P2 products where as jaipur > has P2 and P3 products ) > - Based on customer work profile ( for salaried person offer personal > loans, for business person offer working capital ) > - based gander, income etc > > UC 2. User management, (In Rupie's case they have around six thousand self > service users, need effective user management suite, search user, user > activity tracking etc) > - So user management has to be a lot more robust than user management from > the perspective of staff users. > UC 3. Push ad-hoc/rule based/event based notification to users > > Ed > > On Tue, Jan 16, 2018 at 11:58 AM, Markus Geiss <m...@apache.org> wrote: > >> Dear Ed, >> >> We at Kuelap have no plans because believe we should never give members, >> agents, or other third parties direct access to the financial >> institution's >> data. >> Aside from any regulatory standpoint this is a huge flaw in the current >> system. >> >> My company is working on two offline-first clients that we think are more >> secure >> architecture; one will provide a reduced set of functionalities for >> employees >> working in remote areas; The second one will provide mobile banking >> functionalities for members of financial institutions. >> >> Once the company feels the time is right to share our work, we may propose >> these apps or at least the secure architecture to the community, but we >> are >> not nearly far enough along to do that now. >> >> Cheers >> >> Markus >> >> .::Yagni likes a DRY KISS::. >> >> >> On Tue, Jan 16, 2018 at 3:54 PM Ed Cable <edca...@mifos.org> wrote: >> >> > Markus, Mark or others who could best respond, >> > >> > What is the planned design for enabling third parties (i.e. non-staff) >> such >> > as clients, agents, etc to authenticate themselves and access data >> within >> > Apache Fineract CN. >> > >> > From what I recalled, you were planning to take a more secure approach >> than >> > simply providing a self-service API that has access to the full >> production >> > database but rather have a separate data layer for self-service users? >> > >> > Could you update the community on what the plans are for providing >> access >> > to enable these client-facing applications? Is it documented anywhere? >> > >> > One reason I ask is it that as the Mifos Initiative thinks about GSOC >> 2018, >> > I'd like to consider a project on building out an initial mobile banking >> > app on top of Apache Fineract CN. >> > >> > Thanks, >> > >> > Ed >> > >> > > > > -- > *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> > > -- *Ed Cable* President/CEO, Mifos Initiative edca...@mifos.org | 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>
