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