Hi Markus, Thanks for sharing this insight on the list. I will pass this on to the teams that are going to start doing some work with some external front-ends and will make sure they ask questions and interact with you on-list.
Ed On Mon, Dec 3, 2018 at 6:43 AM Markus Geiss <[email protected]> wrote: > Hey Fineracters, > > we have chosen to use a clean and clear separation of concerns. This mean > we will use separate data stores and services from the back office to serve > front office/client facing apps. This also includes separate user > management > for those apps and a special API user to sync between both solutions. > > Depending on the use case we are going to use an offline-first solution > based on on CouchDB/PouchDB to synchronize data to the devices, > or offer a specialized service for real time processing. If the former is > used we are going to use CouchDB sync gateway to keep the data > back and front office services in sync. > > In both cases there will be a sort of mediator service to sync data between > the separated front the back office services. For this we are using > both integrations, direct API access and event based messaging. > > Given Fineract CN already comes with Active MQ it is simple to integrate > any type of foreign component via the build in pub/sub model. > > Cheers > > Markus > > .:: YAGNI likes a DRY KISS ::. > > > On Fri, Nov 30, 2018 at 2:35 PM Ed Cable <[email protected]> wrote: > > > Markus and others, > > > > I wanted to bring this back to top of mind. There are a number of efforts > > in the community moving forward where external, client-facing apps might > > soon be moving into actual production usage. Discussion on this thread > > should be valuable happening in parallel to the thread that James started > > on architecture/design for payments integration via Mojaloop. > > > > Markus - at this point, are you able to share what secure > > architecture/design pattern you all chose in which to implement external > > apps that is secure and not giving direct access to the financial > > institution's data. > > > > For the community at large, especially those with deep experience > > implementing these systems, we welcome your valuable input to help get > this > > right for Fineract CN. > > > > Ed > > > > On Tue, Mar 20, 2018 at 11:26 PM Sendoro Juma <[email protected]> > > wrote: > > > > > My comments below is related to item no.2 not 3 > > > > > > ----- Original Message ----- > > > From: "Sendoro Juma" <[email protected]> > > > To: "dev" <[email protected]> > > > Cc: "mifos-developer" <[email protected]> > > > 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" <[email protected]> > > > To: "dev" <[email protected]> > > > Cc: "mifos-developer" <[email protected]> > > > 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 > > > > [email protected] | 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 > > > [email protected] | 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> > > > > > > > > > -- > > *Ed Cable* > > President/CEO, Mifos Initiative > > [email protected] | 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> > > > -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | 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>
