Hi Bharath, Mohammed, and Ádám, Bharath, I strongly second your point about the validation message for the user.
The ₹3000 auto-deduction scenario I mentioned earlier is a prime example of why this is needed. Without a clear validation message during the withdrawal attempt, the user (and even the teller) can be left completely confused as to why a deposit "vanished" or why a balance is lower than expected. To help implement this, I can work on the following: Drafting the Validation Logic: I can help define the logic that triggers the specific message you suggested: “Insufficient balance. Do you want to proceed with the withdrawal?” for accounts where force-withdrawal is enabled. Standing Instructions: I am happy to look into how we can extend this force-withdrawal flag to account transfers and standing instructions as you proposed, ensuring consistency across all debit paths. Documentation: I’ll ensure these new validation states are clearly documented in the JIRA. I'm ready to start on these functional requirements in FINERACT-2471 as soon as the core command is merged. Best, Ayush Singh On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy <[email protected]> wrote: > Hi > > Sure, go ahead ;) > > Regarsd, > Adam > > On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq < > [email protected]> wrote: > > Hi Adam, > > I agree—force-withdrawal is much cleaner and more intuitive than > withdrawal-force-debit. Let's adopt that name. > > Regarding the force: true flag suggestion: I technically prefer the > separate command (force-withdrawal) solely due to Permission Mapping. > > In Fineract's architecture, the platform security check typically maps Command > Name -> Permission before the service logic executes. > > - > > If we use the existing withdrawal command with a flag, the system will > apply the standard WITHDRAW_SAVINGSACCOUNT check by default. > - > > To enforce a stricter 'Manager-Only' permission for the forced > transaction, we would have to bypass the standard check or implement custom > security logic inside the service implementation, which feels less > declarative. > > Using the distinct force-withdrawal command allows us to map it cleanly > to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard > configuration. > > Does that sound reasonable? If so, I will update the JIRA spec to use > force-withdrawal. > > Best, Mohammed Saifulhuq > > On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy <[email protected]> wrote: > >> Hi >> >> I don’t believe we need to include “withdrawal” and “debit” in the >> command as well. >> >> What are your thoughts on using “force-withdrawal” instead of >> “withdrawal-force-debit”? >> >> Alternatively, we could simply add an additional field to the request, >> such as “force: true”. >> >> This approach would eliminate the need to introduce new API endpoints. >> >> What do you think? >> >> Regards, >> Adam >> >> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq < >> [email protected]> wrote: >> >> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >
