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