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.
Not sure if I am missing something here. 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? > > When implemented for mPesa, are you able to filter >20 million accounts > and their transactions in under 1 second? Maybe it’s not at that scale > yet? > > 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. >> >> 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 >
