Hi Mohammed and Bharath, I'll be ready to pick up the Phase 2 scope once the core engine is merged.
P.S. Bharath/Mohammed: I am having some technical issues loading the ASF self-serve page to request a Jira account. Since I’ll be handling the Phase 2 implementation for FINERACT-2471, would you be able to assist in requesting or sponsoring an account for me? My preferred username is ayushsingh. Best, Ayush Singh On Fri, Feb 6, 2026, 7:09 PM AYUSH SINGH <[email protected]> wrote: > 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>
