Hi Ayush, thanks. Regarding the implementation, do you think we should handle the 'min-overdraft-limit' check at the Command processing layer or strictly within the Accounting closing job? What are the trade-offs you see there?
On Fri, Feb 6, 2026 at 12:42 PM AYUSH SINGH <[email protected]> wrote: > Hi Mohammed, > > I'm glad the scenario was helpful in clarifying that risk. > > I fully support moving forward with the Negative Balance with Configurable > Limits approach. It seems to be the most balanced solution for maintaining > both General Ledger integrity and a transparent user experience. > > Looking forward to seeing the draft for the implementation plan! > > > Best, > Ayush > > On Fri, Feb 6, 2026, 10:09 AM Mohammed Saifulhuq < > [email protected]> wrote: > >> Hi Ayush, >> >> Thank you for sharing that real-world scenario. That is exactly the >> 'silent failure' risk we want to avoid. >> >> It seems we are converging on the *'Negative Balance with Limits'* >> approach as the most robust solution because: >> >> 1. >> >> *Accounting:* It respects GAAP/IFRS liability recognition immediately >> (General Ledger accuracy). >> 2. >> >> *Transparency:* As you noted, it prevents the 'missing money' >> confusion for the end-user. >> 3. >> >> *Safety:* The proposed min-overdraft-limit configuration prevents the >> infinite debt risk I mentioned earlier. >> >> @Anu / @Paul — seeing as we have consensus on both the technical and >> functional sides, are you happy for me to proceed with drafting the >> implementation plan for the *Negative Balance with Configurable Limits* >> model? >> >> Best, Mohammed Saifulhuq >> >> On Thu, Feb 5, 2026 at 10:07 PM AYUSH SINGH <[email protected]> >> wrote: >> >>> Hi everyone, >>> >>> The discussion regarding "user confusion" vs. "accounting accuracy" is >>> very relevant. I recently saw a real-world case where a user didn't >>> maintain a minimum balance, resulting in a -₹3,000 state due to bank >>> charges. >>> When they eventually deposited funds, the money was "auto-deducted" to >>> cover the debt. Because the system didn't make the negative balance >>> transparent, the user was left confused, thinking their deposit had simply >>> disappeared until they contacted the bank. >>> >>> This supports Mohammad's point about the importance of General Ledger >>> accuracy and transparency. If we use a "shadow" or "pending" balance as >>> Alberto suggested, we might actually increase user support tickets because >>> the debt isn't visible to the customer until their new deposit vanishes. >>> >>> I suggest we prioritize a model that reflects the true liability on the >>> user's dashboard to avoid this "missing money" experience. >>> >>> Best, >>> Ayush Singh >>> >>> >>> On Thu, Feb 5, 2026, 9:37 PM Mohammed Saifulhuq < >>> [email protected]> wrote: >>> >>>> Hi Alberto, >>>> That is an interesting approach, but I see a few architectural risks >>>> with a 'Pending Transaction' model versus a true 'Negative Balance' model >>>> for this specific use case: >>>> Regulatory Reality: When a 'Force Post' occurs (e.g., a tax levy or >>>> regulatory fee), the liability is often immediate. The customer is in debt >>>> to the bank at that exact second. Keeping the balance at 0 and hiding the >>>> debt in a 'pending' state might misrepresent the actual General Ledger (GL) >>>> position of the bank. >>>> Interest Calculation: If the account is effectively overdrawn, the bank >>>> usually needs to accrue interest on that debt immediately. Fineract's >>>> existing interest engine handles negative balances (overdrafts) naturally. >>>> If we use a 'pending' queue, we would need to rebuild the interest >>>> calculation logic to look at the 'shadow' balance, which adds significant >>>> complexity. >>>> Complexity on Deposit: Your approach requires a new event listener on >>>> every deposit to 'sweep' the pending queue. This introduces concurrency >>>> challenges. >>>> I believe the 'Negative Balance with Limits' approach stays closer to >>>> standard GAAP/IFRS accounting principles where a liability is recognized >>>> immediately on the ledger. >>>> Thoughts? >>>> >>>> Best, >>>> Mohammed Saifulhuq >>>> >>>> On Thu, 5 Feb, 2026, 9:27 pm Jose Alberto Hernandez, < >>>> [email protected]> wrote: >>>> >>>>> Hello! >>>>> >>>>> I would like to propose a more robust method: >>>>> >>>>> 1. Keep the Savings Account as is, don't update the allowed overdraft >>>>> or something else, >>>>> 2. Generate a new transaction type that will be applied once the >>>>> account has some balance, this can be added to the Savings Account with a >>>>> new command >>>>> 3. Include a new Balance amount, similar as we have now, totalBalance >>>>> amount and available amount, to include those transactions, this new >>>>> balance usually will be negative when the Savings Account has these >>>>> transactions to be applied >>>>> >>>>> The idea of this new transaction type is to record the different >>>>> pending stuff to be applied the next time the account has some deposit >>>>> >>>>> What do you think? >>>>> >>>>> Thanks and regards >>>>> Alberto >>>>> >>>>> On Wed, Feb 4, 2026 at 8:09 PM Mohammed Saifulhuq < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Anu and Campbell, >>>>>> This is a critical feature for regulatory compliance, especially for >>>>>> institutions handling automated service charges or tax deductions where >>>>>> rejecting the debit is not a legal option. >>>>>> I agree with Anu's architectural approach, particularly separating >>>>>> this into a distinct API command (withdrawal-force-post). Mixing this >>>>>> logic >>>>>> into the standard withdrawal flow could create dangerous loopholes where >>>>>> overdrafts happen accidentally. >>>>>> One additional consideration: >>>>>> If we enable allow-negative-balance, we should also consider if this >>>>>> requires a 'Limit' configuration (e.g., 'Max Overdraft Amount'). Allowing >>>>>> infinite negative balance might pose a risk if a force-post API is abused >>>>>> or looped. >>>>>> I am happy to pick up the implementation of the Global Configuration >>>>>> and the Permission structure if we have consensus on the design. >>>>>> Best, >>>>>> Mohammed Saifulhuq >>>>>> >>>>>> On Thu, 5 Feb, 2026, 6:08 am Anu Omotayo via dev, < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I had a similar discussion with my colleague on savings account with >>>>>>> negative balance about two weeks ago. The ask was to debit customer >>>>>>> savings >>>>>>> accounts for regulatory reasons even if the account balance is 0. >>>>>>> >>>>>>> Also, I had a negative balance in my account with a commercial bank >>>>>>> days ago due to a bank charge that I wasn't expecting. >>>>>>> >>>>>>> Below is a suggestion on how I think this feature can be implemented >>>>>>> in fineract. >>>>>>> >>>>>>> 1. An "allow-negative-balance-on-savings-account" can be added to >>>>>>> the global configuration to enable/disable this feature. >>>>>>> >>>>>>> 2. It should be implemented as a separate API due to its sensitive >>>>>>> nature e.g (e.g ~ >>>>>>> /fineract-provider/api/v1/savingsaccounts/14/transactions?command=withdrawal-force-post). >>>>>>> The "allow-negative-balance-on-savings-account" setting should be >>>>>>> checked before the transaction is posted. >>>>>>> >>>>>>> 3. New permissions such as WITHDRAW SAVINGSACCOUNT FORCE DEBIT, >>>>>>> WITHDRAW SAVINGSACCOUNT FORCE DEBIT CHECKER should be created and used >>>>>>> for >>>>>>> the new API. >>>>>>> >>>>>>> Regards >>>>>>> Anu Omotayo >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, January 11, 2026 at 01:12:07 AM GMT+1, Campbell Burgess < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> Paul.... Very well laid out. Thank you. >>>>>>> >>>>>>> Bottom line... negative consumer deposit (savings accounts in >>>>>>> Fineract) routinely go negative, with and without, formal arrangements >>>>>>> and >>>>>>> with (but also without) account holder opt-in. >>>>>>> >>>>>>> If what I am now guessing is correct, that Fineract does not readily >>>>>>> support a force-post, what is the best path forward. >>>>>>> >>>>>>> Again, we are happy to do all the lifting and contribute the work >>>>>>> product to the community, of course, expecting independent review and >>>>>>> oversight. >>>>>>> >>>>>>> Campbell >>>>>>> >>>>>>> >>>>>>> On 1/10/2026 10:37 AM, Paul wrote: >>>>>>> >>>>>>> *Regulation E (Electronic Fund Transfers):* For one-time debit card >>>>>>> and ATM transactions, banks cannot charge an overdraft fee unless the >>>>>>> consumer has explicitly *opted in*. However, even without an >>>>>>> opt-in, a bank is legally permitted to pay the transaction (creating a >>>>>>> negative balance) as long as it does *not* charge a fee. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Herring BANCORP ® >>>>>>> >>>>>>> >>>>>>> *C. Campbell Burgess *President/CEO >>>>>>> Office: (806) 373-3921 | Direct: (806) 242-3704 >>>>>>> >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> *Herring Bancorp* >>>>>>> 2201 Civic Circle, Suite 1000 >>>>>>> <https://www.google.com/maps/search/2201+Civic+Circle,+Suite+1000+%0D%0A++++++++++++Amarillo,+TX+79109?entry=gmail&source=g> >>>>>>> Amarillo, TX 79109 >>>>>>> <https://www.google.com/maps/search/2201+Civic+Circle,+Suite+1000+%0D%0A++++++++++++Amarillo,+TX+79109?entry=gmail&source=g> >>>>>>> >>>>>>> www.herringbank.com >>>>>>> >>>>>>> CONFIDENTIALITY NOTE: This e-mail is intended only for the use of >>>>>>> the individual or entity to which it is addressed and may contain >>>>>>> information that is privileged, confidential and exempt from disclosure >>>>>>> under applicable law. If the reader of this e-mail message is not the >>>>>>> intended recipient, or the employee or agent responsible for delivery of >>>>>>> the message to the intended recipient, you are hereby notified that any >>>>>>> dissemination, distribution or copying of this communication is >>>>>>> prohibited. >>>>>>> If you have received this e-mail in error, please notify us immediately >>>>>>> by >>>>>>> telephone at (303) 565-7001 and also indicate the sender's name. Thank >>>>>>> you. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>
