Hi Anu, Thank you for the approval. I fully agree—'Force Debit' is the standard banking terminology and we should align with that. I will proceed with the implementation using the naming conventions you provided:
- *API:* withdrawal-force-debit - *Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT - *Configs:* allow-force-debit-on-savings-account & force-debit-on-savings-account-limit Hi Ayush, You are spot on regarding the *Command Processing Layer*. Checking limits at the accounting/closing job would be too late and would risk General Ledger inconsistency. We must validate strictly at the point of transaction. Regarding your suggestions on Reason Codes and Notifications: *Let's park those for Phase 2.* We need to get the Core Ledger logic and the force-debit Transaction Processing merged and stable first. Once the core engine is in develop, we can look at adding the notification layers on top. I am creating the JIRA ticket and starting the implementation now. Best, Mohammed Saifulhuq On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH <[email protected]> wrote: > Hi Mohammed, > > That’s a great question regarding the placement of the min-overdraft-limit > check. > In my view, handling this at the Command processing layer is the more > robust choice for a few reasons: > > Immediate Feedback: It allows the system to reject a transaction instantly > if it exceeds the configured limit, providing a better experience for the > bank staff/API consumer. > > Integrity: Checking during the Command layer prevents the General Ledger > from ever entering an "invalid" state that the closing job would have to > fix later, which aligns with the goal of GL accuracy. > > Complexity: Relying on the Accounting closing job might introduce > concurrency issues if multiple force-posts happen between cycles. > Regarding the implementation, I’ve also outlined some functional areas > where I can contribute to support this transition: > > 1. Defined Reason Codes for Negative Balances > I propose we implement standard Reason Codes to help the system > distinguish between different "Force Debit" types: > MAINTENANCE_FEE: For missing minimum balances. > REGULATORY_LEVY: For mandated government deductions. > SYSTEM_REVERSAL: To correct erroneous credits. > INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties. > > 2. User-Notification Logic > To prevent user confusion when these debits occur, I can draft the logic > for an automated notification trigger. This would alert the user > (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into > the negative. > > 3. Documentation & Next Steps > I am ready to help draft the functional overview for the Fineract Wiki, > including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API > conventions Anu mentioned. > I've already set up GPG signing for my commits as per Adam’s update. > Should I start by drafting these Reason Codes and notification requirements > into a formal document for the team to review? > > Best regards, > Ayush Singh > > On Fri, Feb 6, 2026, 5:03 PM 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. >> >> >> >> >> >> >> >> >>
