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