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 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
