Hi Mohammed, This division of labor sounds perfect. Sequencing it this way will definitely keep the PRs clean and easier to review.
I'll wait for your ping once the Core Engine PR for FINERACT-2471 is up so I can study the architecture before starting on the Phase 2 scope (Standing Instructions and Validation logic). In the meantime, I'll start drafting the test cases for the validation messages. Best, Ayush Singh On Fri, Feb 6, 2026, 7:03 PM Mohammed Saifulhuq < [email protected]> wrote: > Hi Adam, > Thanks for the definitive green light! I am proceeding with the > force-withdrawal command and Permission mapping immediately. > Hi Bharath & Ayush, > This is a great division of labor. > @Ayush: Since the Standing Instructions and Transfer modifications will > depend heavily on the Core Configuration and force-withdrawal command logic > I am implementing in FINERACT-2471, let's sequence this as follows: > Phase 1 (My Scope): I will implement the Core Engine (Global Configs, > Permission Hierarchy, and the force-withdrawal API). I will ping you once > my PR is up so you can see the architecture. > Phase 2 (Your Scope): Once the Core is merged, you can pick up the > Standing Instructions and Validation Message logic as a separate PR. This > ensures you aren't blocked by missing backend configs. > I’ll focus on shipping the Core strictly to keep the PR clean and > reviewable. > Best, > Mohammed Saifulhuq > > On Fri, 6 Feb, 2026, 6:58 pm Bharath Gowda, <[email protected]> wrote: > >> Hi Ayush, >> >> Thank you. I appreciate your contribution on the same. >> >> 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 Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH <[email protected]> >> wrote: >> >>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>
