Hi Bharath and Mohammed, Just a quick update that my JIRA account (ayushsingh) is now active. Thank you for the assistance with the setup!
I am currently reviewing the permissions and integration tests in SavingsAccountForceWithdrawalTest.java as Mohammed suggested. I'll be ready to start on the Phase 2 Reason Codes and Notification triggers as soon as the Core Engine (PR #5465) is merged. Best regards, Ayush Singh On Tue, Feb 10, 2026, 3:02 PM Mohammed Saifulhuq < [email protected]> wrote: > Hi everyone, > > I have finalized the implementation for the "Force Withdrawal" feature (PR > #5465). > > Following the latest review feedback, I have added the mandatory > `FORCE_WITHDRAWAL_SAVINGSACCOUNT_CHECKER` permission to satisfy the > Maker-Checker compliance requirements. The PR is now clean, tested, and > ready for merge. > > Best regards, > Mohammed Saifulhuq > > On Mon, Feb 9, 2026 at 6:04 PM AYUSH SINGH <[email protected]> wrote: > >> Hi Adam and Bharath, >> >> Thank you for the guidance! The VPN did the trick. I have successfully >> submitted the JIRA account request, and it is now verified and awaiting >> project review. >> >> I'll keep an eye on my inbox for the activation. In the meantime, I'm >> continuing my review of Mohammed's Phase 1 PR to prepare for the Phase 2 >> implementation. >> >> Best regards, >> Ayush Singh >> >> >> On Mon, Feb 9, 2026, 5:08 PM AYUSH SINGH <[email protected]> wrote: >> >>> Hi Bharath, >>> >>> Thank you for the follow-up!. >>> Unfortunately, I have tried the link on multiple browsers and devices, >>> but the page still fails to load for me (likely a regional ISP issue). >>> >>> Since I see others are successfully creating accounts, would it be >>> possible for an admin to manually initiate the account creation for me? >>> My preferred username is ayushsingh and my email is >>> [email protected] . >>> >>> Thank you for your patience as I get through these technical hurdles! >>> >>> On Mon, Feb 9, 2026, 11:43 AM Bharath Gowda <[email protected]> wrote: >>> >>>> 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> >>>>>>>>> >>>>>>>>> <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> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>
