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 <edca...@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 <sendoro@singo.africa>
> wrote:
>
> > 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>
> >
>
>
> --
> *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>
>

Reply via email to