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] > <mailto:[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] <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] <mailto:[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: >>>>> >>>>> Accounting: It respects GAAP/IFRS liability recognition immediately >>>>> (General Ledger accuracy). >>>>> >>>>> Transparency: As you noted, it prevents the 'missing money' confusion for >>>>> the end-user. >>>>> >>>>> 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] >>>>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 <http://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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>
