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:
-
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]> 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 regardsAlberto
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
Amarillo, TX 79109
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.
