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