Hi Ayush, I could see other contributors creating a JIRA request. Could you please try creating the account now?
https://selfserve.apache.org/jira-account.html Regards, Bharath Lead Implementation Analyst | Mifos Initiative PMC Member | Apache Fineract Mobile: +91.7019635592 http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Sun, Feb 8, 2026 at 9:17 PM Mohammed Saifulhuq < [email protected]> wrote: > Hi Ayush, > > Thanks. Yes, reviewing the Permission mapping and Global Limits in PR > #5465 is the correct first step. > > The integration tests in `SavingsAccountForceWithdrawalTest.java` document > exactly how the backend handles the limits and permissions. Please use that > as the reference contract for your UI/Notification logic. > > Once the maintainers merge this PR, the foundation will be stable for you > to open the Phase 2 PR. > > Best, > Mohammed > > On Sun, Feb 8, 2026 at 1:27 PM AYUSH SINGH <[email protected]> wrote: > >> Hi Mohammed, >> >> Great work on completing Phase 1! It’s exciting to see the Core Engine PR >> live. >> >> I will start by reviewing your PR (#5465) to understand how you’ve >> implemented the FORCE_WITHDRAWAL_SAVINGSACCOUNT permission and the global >> limits. This will help me ensure that my work on Phase 2 (Standing >> Instructions, Transfers, and Validation Logic) is perfectly aligned with >> your core logic. >> >> @Bharath: Once you have a moment to assist with the JIRA account, I'll be >> ready to document the Phase 2 requirements there. >> >> Best, >> Ayush Singh >> >> >> On Sun, Feb 8, 2026, 12:43 PM Mohammed Saifulhuq < >> [email protected]> wrote: >> >>> Hi All, >>> >>> I am happy to report that the implementation for Phase 1 (Core Engine) >>> is complete and the PR is ready for review. >>> >>> Per our discussion (Ádám, Bharath, Campbell), I have adhered to the >>> strict architectural requirements: >>> >>> 1. **API Design:** Used the specific command `force-withdrawal` to align >>> with the Transaction Enum, keeping the backend clean while supporting the >>> "Force Debit" functional requirement. >>> >>> 2. **Safety:** Implemented Global Configurations for limits to prevent >>> unlimited overdrafts. >>> >>> 3. **Security:** Added a distinct Granular Permission >>> (`FORCE_WITHDRAWAL_SAVINGSACCOUNT`) so this capability can be audited >>> separately from standard withdrawals. >>> >>> The PR includes comprehensive Integration Tests that cover the "Happy >>> Path" (successful force withdrawal) and the "Limit Path" (blocking >>> withdrawals exceeding the overdraft limit). >>> >>> **PR Link:** https://github.com/apache/fineract/pull/5465 >>> **Build Status:** Passing (MariaDB, PostgreSQL, MySQL) >>> >>> @Ayush — The core logic is now stable. Once this is merged, the >>> foundation is ready for you to begin Phase 2 (Reason Codes & Notifications). >>> >>> Best regards, >>> Mohammed Saifulhuq >>> >>> >>> On Fri, Feb 6, 2026 at 9:37 PM Mohammed Saifulhuq < >>> [email protected]> wrote: >>> >>>> Hi Campbell, >>>> >>>> That is a very keen distinction. You are absolutely right—functionally, >>>> this is a generic 'Debit' (often back-office driven) rather than a >>>> customer-initiated 'Withdrawal'. >>>> >>>> However, to keep the technical implementation clean, we decided to >>>> stick with force-withdrawal for the API Command to align with >>>> Fineract's existing transactionType enum (WITHDRAWAL). Introducing a >>>> new DEBIT transaction type at the platform level would require massive >>>> refactoring of reports and accounting mapping. >>>> >>>> That said, for the Permission Name and UI Label, we can certainly use >>>> the term 'Force Debit' to be semantically accurate for the users. >>>> >>>> Best, Mohammed >>>> >>>> On Fri, Feb 6, 2026 at 8:39 PM Campbell Burgess <[email protected]> >>>> wrote: >>>> >>>>> Anu... if I may suggest "Debit Savings Account Force Debit, Debit >>>>> Savings Account Force Debit Checker" or something like that. >>>>> >>>>> ...to split hairs, a "Withdrawal" by the customer is really the >>>>> functional trigger to a debit. >>>>> >>>>> In this situation, the functional trigger is often not a customer >>>>> initiated "Withdrawal". >>>>> >>>>> It could be... but many times is not. It could be a fee, a penalty, >>>>> an online transaction of some sort. >>>>> >>>>> Withdrawal is obviously fine as a descriptor, but "Debit" will be more >>>>> precise. >>>>> On 2/6/2026 5:32 AM, Anu Omotayo via dev 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]> <[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> >>>>> >>>>> <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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>
