Hi Adam and Bharath, Thank you for the guidance! The VPN did the trick. I have successfully submitted the JIRA account request, and it is now verified and awaiting project review.
I'll keep an eye on my inbox for the activation. In the meantime, I'm continuing my review of Mohammed's Phase 1 PR to prepare for the Phase 2 implementation. Best regards, Ayush Singh On Mon, Feb 9, 2026, 5:08 PM AYUSH SINGH <[email protected]> wrote: > Hi Bharath, > > Thank you for the follow-up!. > Unfortunately, I have tried the link on multiple browsers and devices, but > the page still fails to load for me (likely a regional ISP issue). > > Since I see others are successfully creating accounts, would it be > possible for an admin to manually initiate the account creation for me? > My preferred username is ayushsingh and my email is [email protected] > . > > Thank you for your patience as I get through these technical hurdles! > > On Mon, Feb 9, 2026, 11:43 AM Bharath Gowda <[email protected]> wrote: > >> Hi Ayush, >> >> I could see other contributors creating a JIRA request. Could you please >> try creating the account now? >> >> https://selfserve.apache.org/jira-account.html >> >> 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 Sun, Feb 8, 2026 at 9:17 PM Mohammed Saifulhuq < >> [email protected]> wrote: >> >>> Hi Ayush, >>> >>> Thanks. Yes, reviewing the Permission mapping and Global Limits in PR >>> #5465 is the correct first step. >>> >>> The integration tests in `SavingsAccountForceWithdrawalTest.java` >>> document exactly how the backend handles the limits and permissions. Please >>> use that as the reference contract for your UI/Notification logic. >>> >>> Once the maintainers merge this PR, the foundation will be stable for >>> you to open the Phase 2 PR. >>> >>> Best, >>> Mohammed >>> >>> On Sun, Feb 8, 2026 at 1:27 PM AYUSH SINGH <[email protected]> >>> wrote: >>> >>>> 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> >>>>>>> >>>>>>> <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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>
