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