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