You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Ed Cable <ed...@mifos.org> on 2018/01/16 14:54:19 UTC
Self-Service Access for Client-Facing Apps on Apache Fineract CN
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
Re: DISCUSS: Architecture/Design for Enabling External Apps to
securely access data on Apache Fineract CN
Posted by Ed Cable <ed...@mifos.org>.
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 <ma...@apache.org> 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 <ed...@mifos.org> 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 <se...@singo.africa>
> > wrote:
> >
> > > My comments below is related to item no.2 not 3
> > >
> > > ----- Original Message -----
> > > From: "Sendoro Juma" <se...@singo.africa>
> > > To: "dev" <de...@fineract.apache.org>
> > > Cc: "mifos-developer" <mi...@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" <ed...@mifos.org>
> > > To: "dev" <de...@fineract.apache.org>
> > > Cc: "mifos-developer" <mi...@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 <ed...@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 <ma...@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 <ed...@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
> > > > 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>
> > > >
> > > >
> > >
> > >
> > > --
> > > *Ed Cable*
> > > President/CEO, Mifos Initiative
> > > edcable@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>
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edcable@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>
> >
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@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>
Re: DISCUSS: Architecture/Design for Enabling External Apps to
securely access data on Apache Fineract CN
Posted by Markus Geiss <ma...@apache.org>.
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 <ed...@mifos.org> 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 <se...@singo.africa>
> wrote:
>
> > My comments below is related to item no.2 not 3
> >
> > ----- Original Message -----
> > From: "Sendoro Juma" <se...@singo.africa>
> > To: "dev" <de...@fineract.apache.org>
> > Cc: "mifos-developer" <mi...@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" <ed...@mifos.org>
> > To: "dev" <de...@fineract.apache.org>
> > Cc: "mifos-developer" <mi...@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 <ed...@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 <ma...@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 <ed...@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
> > > 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>
> > >
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edcable@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>
> >
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edcable@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>
>
DISCUSS: Architecture/Design for Enabling External Apps to securely
access data on Apache Fineract CN
Posted by Ed Cable <ed...@mifos.org>.
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 <se...@singo.africa> wrote:
> My comments below is related to item no.2 not 3
>
> ----- Original Message -----
> From: "Sendoro Juma" <se...@singo.africa>
> To: "dev" <de...@fineract.apache.org>
> Cc: "mifos-developer" <mi...@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" <ed...@mifos.org>
> To: "dev" <de...@fineract.apache.org>
> Cc: "mifos-developer" <mi...@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 <ed...@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 <ma...@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 <ed...@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
> > 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>
> >
> >
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edcable@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>
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@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>
Re: Self-Service Access for Client-Facing Apps on Apache Fineract
CN
Posted by Sendoro Juma <se...@singo.africa>.
My comments below is related to item no.2 not 3
----- Original Message -----
From: "Sendoro Juma" <se...@singo.africa>
To: "dev" <de...@fineract.apache.org>
Cc: "mifos-developer" <mi...@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" <ed...@mifos.org>
To: "dev" <de...@fineract.apache.org>
Cc: "mifos-developer" <mi...@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 <ed...@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 <ma...@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 <ed...@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
> 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>
>
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@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>
Re: Self-Service Access for Client-Facing Apps on Apache Fineract
CN
Posted by Sendoro Juma <se...@singo.africa>.
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" <ed...@mifos.org>
To: "dev" <de...@fineract.apache.org>
Cc: "mifos-developer" <mi...@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 <ed...@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 <ma...@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 <ed...@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
> 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>
>
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@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>
Re: Self-Service Access for Client-Facing Apps on Apache Fineract CN
Posted by Ed Cable <ed...@mifos.org>.
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 <ed...@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 <ma...@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 <ed...@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
> 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>
>
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@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>
Re: Self-Service Access for Client-Facing Apps on Apache Fineract CN
Posted by Ed Cable <ed...@mifos.org>.
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 <ma...@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 <ed...@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
edcable@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>
Re: Self-Service Access for Client-Facing Apps on Apache Fineract CN
Posted by Markus Geiss <ma...@apache.org>.
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 <ed...@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
>