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.
