As Self service functionality for an organization serving SME’s is quite different from those providing digital wallets or serving Agent networks, the bigger question here would be , What is the scope of the customer facing functionality and if offline first functionality makes sense for the same ?
On a sidebar, It would help to keep this scope minimal and ideally linked to a customer looking to take it to production and focus any additional dev cycles organizations like the Mifos Initiative can spare on deepening the portfolio / deposits and accounting modules which would have a significantly larger audience. Regards, Vishwas On Tuesday, February 12, 2019, Myrle Krantz <[email protected]> wrote: > My current thinking on customer facing functionality is that, for an > offline-first strategy, we should place a PouchDB/CouchDB database/cache > between the customer app and any APIs. Domain-driven design does not > (necessarily) mean that all self-service functionality must land in one > microservice. For example, customer authentication should probably be > handled in a service separately from retrieving account information (and > separately from back-office employee authentication). > > Best Regards, > Myrle > > On Tue, Feb 12, 2019 at 1:28 PM Vishwas Babu < > [email protected]> wrote: > > > Hi All, > > > > Adding some context based on our (Conflux Technologies) experiences with > > MifosX / Fineract 1.x and summarizing a recent discussion I had with a > > community member. > > > > When it comes to customer self-service, the kind of institutions that we > > have come across can be broadly divided into three categories > > > > Bucket 1: > > Traditional MFI's and Fintech lenders providing customers views of their > > accounts through online, USSD and IVR channels. These organizations also > > offer customers the ability to originate new accounts online. > > A majority of the current Fineract1.x users would fall into this bucket > > > > Bucket 2: > > Digital banks and Fintech companies which provide additional self-service > > capabilities including digital wallets, bill payments, money transfers > and > > remittances. Interesting needs in this sector include features like money > > transfers without an active internet connection through channels like > call > > back IVR. > > > > Bucket 3: > > Financial Institutions with agents and business correspondents who > > sometimes model their agents as customers with additional privileges and > > serve them through enhanced customer self-service apps. > > This sector occasionally has the need for offline functionality ( which > is > > robust only when combined with organization enforced business rules ) > > > > These applications themselves are built out independently and interface > > with Fineract 1.x through the available back-office API's (NOT the > > self-service API's which provide each customer a separate login) and > > webhook callbacks. Some of the reasoning behind this approach as against > > thin UI's talking directly to Fineract 1.x are listed below. With the > > architecture followed in Fineract-CN, when customer self-service API's > are > > exposed through a new microservice, a majority of these items would be > > automatically taken care of and we would then only have to contend with > the > > threat list that David alludes to. > > > > -> Back-office CBS and customer-self service has clearly demarcated > > boundaries > > Tying them up in a single deployable unit would hinder their ability to > > evolve independently. Organizations tend to be very opinionated about > > self-service channels and these apps follow short release cycles with > some > > amount of customization going into each new implementation. > > - A customer on the self-service app needn't necessarily be present on > the > > CBS. > > Ex: Self-service apps for organizations like Fintech lenders typically > > allow users to sign up, create a profile and apply for a loan. > > - Customer/loans/savings statuses and lifecycle on the self-service app > do > > not map directly with those on the CBS. > > For example, an application initiated by a customer goes through a > process > > of automated and manual sanity checks on the self-service apps, after > which > > they are moved to the CBS with a predefined state to join the regular > > workflow (de-duplication, eligibility and credit checks etc). This is > > typically different from the lifecycle of an application originated by a > > teller. > > - Fine-grained control is required on the granularity of information > > presented on the self-service apps, which is different from that > presented > > to the back office. Ex: All products in the CBS are not shown as options > in > > the self-service portal. Similarly, for the products that are shown, the > > granularity of information in the terms is a greatly reduced subset of > that > > available in the product definition at the CBS. > > > > -> Deployment and scalability scenarios > > While these issues can be easily addressed through a combination of code > > modifications on the self-service API's of Fineract 1.x and deployment > > configurations, they have been listed here for completeness. > > - Client facing apps need to be scaled independently of back-office > facing > > CBS and also need to have different configurations for rate limiting etc. > > - The client-facing apps should cache all lookup data fetched from the > CBS, > > route read traffic to a cluster of Fineract1.x servers talking to > > replicated databases etc to ensure that the traffic to the cluster > serving > > the back-office is kept to a minimum and remains largely unaffected by > > spikes in customer traffic. > > - Easy to turn off, monitor and audit client-self service happening > through > > a single login at Fineract 1.x > > > > -> Security implications > > While these issues can be easily addressed through a combination of code > > modifications on the self-service API's of Fineract 1.x and deployment > > configurations, they have been listed here for completeness. > > - Organizations might not want to expose their CBS outside of their VPN > > - The security needs of client facing apps are radically different from > > those of a back-office CBS and vary from organization to organization. > Ex: > > Organizations serving SME's need separate makers and approvers for each > > transaction, organizations need logged in users to enter separate > > transaction passwords + OTP's for authorizing each transaction etc. > > > > Regards, > > Vishwas > > > > > > > > On Mon, Jan 14, 2019 at 10:54 AM Ed Cable <[email protected]> wrote: > > > > > Thank you! Permissions granted. > > > > > > Ed > > > > > > On Mon, Jan 14, 2019 at 10:33 AM David Yahalomi <[email protected]> > > wrote: > > > > > > > Thanks Ed! > > > > > > > > My confluence ID is davidyaha. > > > > > > > > Best, > > > > David > > > > ᐧ > > > > > > > > On Mon, Jan 14, 2019 at 7:51 PM Ed Cable <[email protected]> wrote: > > > > > > > > > Hi David, > > > > > > > > > > Sorry for the delayed reply. I for some reason did not see your > email > > > > till > > > > > now. Thank you very much for weighing in and volunteering to > > document a > > > > > threats list. I too believe that is a good starting point and we > > might > > > > soon > > > > > have some others weighing in with their thoughts on the proper > > > > > architectural design. > > > > > > > > > > Sharing your knowledge in a both architecting a secure design in > > which > > > > to > > > > > connect via client/self-service A{Is as well as your > recommendations > > on > > > > > deployment architecture are gladly appreciated. > > > > > > > > > > If you can share with me your confluence ID for the fineract > > > confluence, > > > > I > > > > > will give you the proper permissions so you can create the > suggested > > > > page. > > > > > > > > > > Thanks, > > > > > > > > > > Ed > > > > > > > > > > On Sun, Jan 6, 2019 at 2:34 AM David Yahalomi <[email protected]> > > > wrote: > > > > > > > > > > > Hello Fineracters, > > > > > > > > > > > > *TL;DR*: Let's start with a threats list and discuss each threat > on > > > > it's > > > > > > own and in composition. > > > > > > > > > > > > I'm David from Articode and I've recently started setting up a > self > > > > > service > > > > > > fineract solution. > > > > > > In the past I've worked on developing a digital self service > branch > > > for > > > > > the > > > > > > 2nd biggest bank in Israel. Their core used T24 by the swiss > > company > > > > > > Temenos. > > > > > > I have recently been in contact with Ed and Fiter from the > fineract > > > > > > community, and I was asked by Ed to chime in this thread. > > > > > > > > > > > > In my experience, making a secure self service mobile application > > has > > > > > many > > > > > > concerns and requirements but most of those are addressed in > > > deployment > > > > > > architecture and the creation of a good audit and session > > management > > > > > tool. > > > > > > > > > > > > Is there a documented list of possible threats in having a self > > > service > > > > > > mobile app? > > > > > > > > > > > > If not, I think it will be a great first step. I would gladly > start > > > one > > > > > on > > > > > > the confluence. > > > > > > Once curated, we can introduce various solutions to defend > against > > > any > > > > of > > > > > > those threats in various environments, but I think that the list > > is a > > > > > > mandatory step. > > > > > > > > > > > > Best, > > > > > > David > > > > > > > > > > > > > > > > > > > > > -- > > > > > *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> > > > > > > -- Sent from my iPad
