AGAIN : Let me renew the call here: if you have invested lots of effort in designing a new Current or Checking or Share account for Fineract, I want to hear from you. If it was done for a client and you cannot share, I also want to know. If that means you need to reach out privately, please do so.
Ali and Zayyad - I appreciate your comments. My response to you inline. On Thu, Mar 23, 2023 at 6:59 AM Syed Muhammad Ali Abidy < [email protected]> wrote: > Hi James > > If you are referring to MPesa-Kenya, the request(B2C/C2B/C2C) always is > received with an account regardless of Savings/Current. I do not think any > parent account concept is necessary here. > So, I’m not speaking about specific use case flows but rather the destination acct in Fineract, which has gaps in functionality. When I originally wrote the specification for the system, the focus was 90% on the loan management system. Not sure if I am missing something here. > The parent account concept for wallets is not strictly necessary but many card based systems use that concept, so to be competitive there, seems like we should have more thinking around it. > The comments are based on my past experience not with Fineract. I am just > exploring Fineract for now. > > Regards > Ali > > > On Thu, Mar 23, 2023 at 11:14 AM James Dailey <[email protected]> > wrote: > >> So, to be clear, Zayyad, I know we have some of this functionality >> already in Fineract from MifosX but it is insufficient as it is, at least >> for what we have in mind. >> >> Ali - >> >> I’m not referring to account to customer logical design, which of course >> is where all account instances are siblings, but rather to the software >> modules that defines the logic and data object model. Am I >> missing something in your comment? How would you structure the Java >> modules? >> >> Or, as I suspect have you developed additional features not on the Git >> for Fineract? Dump the data to a separate data lake?! >> >> Thanks >> >> >> On Thu, Mar 23, 2023 at 10:50 AM Syed Muhammad Ali Abidy < >> [email protected]> wrote: >> >>> Hi >>> >>> Technically there are differences in savings/current also depends on >>> where the bank is incorporated. >>> >>> Normally account holder may earn interest on savings account but not on >>> current account. Cheque book is issued on current account and not on saving >>> account. O.D. may be given on current account not on savings. >>> >> there are some interest bearing current accounts but I haven’t seen them in US in 20 years Overdraft is a key difference- agree. >>> I think the idea of having either of account as parent is a design flaw >>> all accounts should be siblings which should be assigned to customer id. >>> >> >>> Regards >>> >>> >>> On Thu, 23 Mar 2023, 10:39 Zayyad A. Said, < >>> [email protected]> wrote: >>> >>>> Hi James, >>>> >>>> In Mifos X (Gen 2), we have used normal savings account to work as >>>> current/checking account as it provides both deposit and withdrawal >>>> functionality as well as overdraft ability. >>>> >>>> We have also been able to integrate the same with MPESA mobile money >>>> and USSD here in Kenya. >>>> >>>> I am curious to know whether the current account you are thinking of >>>> would have any difference in design from what is already provided for >>>> normal savings accounts? >>>> >>>> Regards, >>>> Zayyad A. Said >>>> >>>> On Thu, 23 Mar 2023, 07:52 James Dailey, <[email protected]> >>>> wrote: >>>> >>>>> Devs >>>>> >>>>> Has anyone built out the current account in a better way, perhaps on a >>>>> fork somewhere? >>>>> >>>>> I'd like to surface a discussion about better design around the >>>>> current account. You may call it "wallet" or "checking". >>>>> >>>>> In banking, the current account is the deposit account that can be >>>>> used for transactions large and small and in the US is synonymous with the >>>>> "checking account". In Credit Unions, the "Share Account" is one type of >>>>> current account. In mobile money, the wallet is a payment account that has >>>>> minimal functionality but is highly scalable. The wallet may also be >>>>> conceived of as a separate or sub account to the main current account. >>>>> These things share a lot of commonalities and should probably be aligned >>>>> in >>>>> the design. >>>>> >>>>> Unfortunately, In the MifosX system (2nd generation), contributed to >>>>> the now fineract system, the current account was extended from the savings >>>>> account, not the other way around. This design was, even at the time (YR >>>>> 2012) a bit of a hack and we need to replace, or revise/ update it. >>>>> >>>>> While I know that Fineract-CN did attempt to address this, this is not >>>>> currently integrated in the fineract project. IF that is the shortest >>>>> path, to advance the microservices strategy by deprecating some of the >>>>> code >>>>> in fineract and promoting the code in Fineract-CN, I would like an expert >>>>> opinion or two. Seems problematic on the surface. >>>>> >>>>> My main point in asking is to find out if someone has already solved >>>>> it, before we work on it ourselves. It is such an obvious weakness that >>>>> someone, surely, has done it already. >>>>> >>>>> At a high level, it should support inbound and outbound payment >>>>> transactions, pagination of transactions, interest paid (separate module), >>>>> fees charged (again, separate module), and scale to 10's of millions if >>>>> not >>>>> 100s of millions of accounts. It should leverage the ledger in Fineract or >>>>> have a clear relationship such that the General Ledger can be created. >>>>> The >>>>> performance needs to be in milliseconds and support all of the date and >>>>> business day logic now found in Fineract LMS. It should also stream >>>>> events >>>>> for observation. >>>>> >>>>> I know it is unlikely that someone has all of that, but still, asking >>>>> now and hoping some of it you have in your private repo and we can talk. >>>>> >>>>> Thank you, >>>>> James >>>>> >>>> -- >> Sent from Gmail Mobile >> > -- Sent from Gmail Mobile
