Mohammed is correct.  However, there is really no functional limit.  The customer owes what the customer owes... often by accident. Much of the driver of the "force" post is just that... it is not anticipated with forethought... and it is a forcepost.

Great discussion.

On 2/5/2026 10:06 AM, Mohammed Saifulhuq 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.





--

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



Reply via email to