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> > > >
