Great team work. 👍 Thanks for the effort. -- Paul
On Fri, Feb 6, 2026, 5:33 AM Anu Omotayo via dev <[email protected]> wrote: > Thanks Mohammed, you can go ahead please. > > In terms of naming convention, I think we should use "force debit" because > its a banking terminology: > > API: withdrawal-force-debit > > Permissions: WITHDRAW SAVINGSACCOUNT FORCE DEBIT, WITHDRAW SAVINGSACCOUNT > FORCE DEBIT CHECKER > > System configuration: allow-force-debit-on-savings-account, > force-debit-on-savings-account-limit > OR allow-negative-balance-on-savings-account, > negative-balance-on-savings-account-limit > > Regards > Anu Omotayo > > On Friday, February 6, 2026 at 05:39:58 AM GMT+1, 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. > > > > > > > > >
