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