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 >
