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