subject:"Re\: Fineract savings account \- negative balance"

Re: Fineract savings account - negative balance

2026-02-12 Thread AYUSH SINGH

Hi Bharath and Mohammed,

Just a quick update that my JIRA account (ayushsingh) is now active. Thank
you for the assistance with the setup!

I am currently reviewing the permissions and integration tests in
SavingsAccountForceWithdrawalTest.java as Mohammed suggested. I'll be ready
to start on the Phase 2 Reason Codes and Notification triggers as soon as
the Core Engine (PR #5465) is merged.

Best regards,
Ayush Singh

On Tue, Feb 10, 2026, 3:02 PM Mohammed Saifulhuq <
[email protected]> wrote:

> Hi everyone,
>
> I have finalized the implementation for the "Force Withdrawal" feature (PR
> #5465).
>
> Following the latest review feedback, I have added the mandatory
> `FORCE_WITHDRAWAL_SAVINGSACCOUNT_CHECKER` permission to satisfy the
> Maker-Checker compliance requirements. The PR is now clean, tested, and
> ready for merge.
>
> Best regards,
> Mohammed Saifulhuq
>
> On Mon, Feb 9, 2026 at 6:04 PM AYUSH SINGH  wrote:
>
>> 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  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  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  
 


 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 
> 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:**

Re: Fineract savings account - negative balance

2026-02-10 Thread Mohammed Saifulhuq

Hi everyone,

I have finalized the implementation for the "Force Withdrawal" feature (PR
#5465).

Following the latest review feedback, I have added the mandatory
`FORCE_WITHDRAWAL_SAVINGSACCOUNT_CHECKER` permission to satisfy the
Maker-Checker compliance requirements. The PR is now clean, tested, and
ready for merge.

Best regards,
Mohammed Saifulhuq

On Mon, Feb 9, 2026 at 6:04 PM AYUSH SINGH  wrote:

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

Re: Fineract savings account - negative balance

2026-02-09 Thread AYUSH SINGH

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

Re: Fineract savings account - negative balance

2026-02-09 Thread AYUSH SINGH

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

Re: Fineract savings account - negative balance

2026-02-08 Thread Bharath Gowda

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  



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

Re: Fineract savings account - negative balance

2026-02-08 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-08 Thread AYUSH SINGH

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 
>> 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
>>>   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 
>>> wrote:
>>>
>>> Hi everyone,
>>>
>>> The discussion regarding "user confusion" vs. "accounting accuracy"

Re: Fineract savings account - negative balance

2026-02-07 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-06 Thread Campbell Burgess

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

Re: Fineract savings account - negative balance

2026-02-06 Thread Campbell Burgess


...I agree

On 2/5/2026 10:35 AM, AYUSH SINGH 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 
 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,
 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
 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,
 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Campbell Burgess

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,
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
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,
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 wrote:

Paul Very well

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi Ayush,

Glad we are aligned. I will proceed with Phase 1.

Regarding the JIRA account: I do not have the admin privileges to sponsor
or create accounts. *@Bharath* — since you are a PMC member, are you able
to assist Ayush with the account creation process?

Best, Mohammed

On Fri, Feb 6, 2026 at 8:04 PM AYUSH SINGH  wrote:

> Hi Mohammed and Bharath,
>
> I'll be ready to pick up the Phase 2 scope once the core engine is merged.
>
> P.S. Bharath/Mohammed: I am having some technical issues loading the ASF
> self-serve page to request a Jira account. Since I’ll be handling the Phase
> 2 implementation for FINERACT-2471, would you be able to assist in
> requesting or sponsoring an account for me? My preferred username is
> ayushsingh.
>
> Best,
> Ayush Singh
>
> On Fri, Feb 6, 2026, 7:09 PM AYUSH SINGH  wrote:
>
>> Hi Mohammed,
>>
>> This division of labor sounds perfect. Sequencing it this way will
>> definitely keep the PRs clean and easier to review.
>>
>> I'll wait for your ping once the Core Engine PR for FINERACT-2471 is up
>> so I can study the architecture before starting on the Phase 2 scope
>> (Standing Instructions and Validation logic).
>>
>> In the meantime, I'll start drafting the test cases for the validation
>> messages.
>>
>> Best,
>> Ayush Singh
>>
>> On Fri, Feb 6, 2026, 7:03 PM Mohammed Saifulhuq <
>> [email protected]> wrote:
>>
>>> Hi Adam,
>>> Thanks for the definitive green light! I am proceeding with the
>>> force-withdrawal command and Permission mapping immediately.
>>> Hi Bharath & Ayush,
>>> This is a great division of labor.
>>> @Ayush: Since the Standing Instructions and Transfer modifications will
>>> depend heavily on the Core Configuration and force-withdrawal command logic
>>> I am implementing in FINERACT-2471, let's sequence this as follows:
>>> Phase 1 (My Scope): I will implement the Core Engine (Global Configs,
>>> Permission Hierarchy, and the force-withdrawal API). I will ping you once
>>> my PR is up so you can see the architecture.
>>> Phase 2 (Your Scope): Once the Core is merged, you can pick up the
>>> Standing Instructions and Validation Message logic as a separate PR. This
>>> ensures you aren't blocked by missing backend configs.
>>> I’ll focus on shipping the Core strictly to keep the PR clean and
>>> reviewable.
>>> Best,
>>> Mohammed Saifulhuq
>>>
>>> On Fri, 6 Feb, 2026, 6:58 pm Bharath Gowda,  wrote:
>>>
 Hi Ayush,

 Thank you. I appreciate your contribution on the same.

 Regards,
 Bharath
 Lead Implementation Analyst | Mifos Initiative
 PMC Member | Apache Fineract
 Mobile: +91.7019635592
 http://mifos.org  
 


 On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH 
 wrote:

> Hi Bharath, Mohammed, and Ádám,
>
> Bharath, I strongly second your point about the validation message for
> the user.
>
> The ₹3000 auto-deduction scenario I mentioned earlier is a prime
> example of why this is needed. Without a clear validation message during
> the withdrawal attempt, the user (and even the teller) can be left
> completely confused as to why a deposit "vanished" or why a balance is
> lower than expected.
>
> To help implement this, I can work on the following:
>
> Drafting the Validation Logic: I can help define the logic that
> triggers the specific message you suggested: “Insufficient balance. Do you
> want to proceed with the withdrawal?” for accounts where force-withdrawal
> is enabled.
>
> Standing Instructions: I am happy to look into how we can extend this
> force-withdrawal flag to account transfers and standing instructions as 
> you
> proposed, ensuring consistency across all debit paths.
>
> Documentation: I’ll ensure these new validation states are clearly
> documented in the JIRA.
>
> I'm ready to start on these functional requirements in FINERACT-2471
> as soon as the core command is merged.
>
> Best,
> Ayush Singh
>
>
> On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:
>
>> Hi
>>
>> Sure, go ahead ;)
>>
>> Regarsd,
>> Adam
>>
>> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
>> [email protected]> wrote:
>>
>> Hi Adam,
>>
>> I agree—force-withdrawal is much cleaner and more intuitive than
>> withdrawal-force-debit. Let's adopt that name.
>>
>> Regarding the force: true flag suggestion: I technically prefer the
>> separate command (force-withdrawal) solely due to Permission Mapping.
>>
>> In Fineract's architecture, the platform security check typically
>> maps Command Name -> Permission before the service logic executes.
>>
>>-
>>
>>If we use the existing withdrawal command with a flag, the system
>>will apply the standard WITHDRAW_SAVINGSACCOUNT check by default.

Re: Fineract savings account - negative balance

2026-02-06 Thread AYUSH SINGH

Hi Mohammed and Bharath,

I'll be ready to pick up the Phase 2 scope once the core engine is merged.

P.S. Bharath/Mohammed: I am having some technical issues loading the ASF
self-serve page to request a Jira account. Since I’ll be handling the Phase
2 implementation for FINERACT-2471, would you be able to assist in
requesting or sponsoring an account for me? My preferred username is
ayushsingh.

Best,
Ayush Singh

On Fri, Feb 6, 2026, 7:09 PM AYUSH SINGH  wrote:

> Hi Mohammed,
>
> This division of labor sounds perfect. Sequencing it this way will
> definitely keep the PRs clean and easier to review.
>
> I'll wait for your ping once the Core Engine PR for FINERACT-2471 is up so
> I can study the architecture before starting on the Phase 2 scope (Standing
> Instructions and Validation logic).
>
> In the meantime, I'll start drafting the test cases for the validation
> messages.
>
> Best,
> Ayush Singh
>
> On Fri, Feb 6, 2026, 7:03 PM Mohammed Saifulhuq <
> [email protected]> wrote:
>
>> Hi Adam,
>> Thanks for the definitive green light! I am proceeding with the
>> force-withdrawal command and Permission mapping immediately.
>> Hi Bharath & Ayush,
>> This is a great division of labor.
>> @Ayush: Since the Standing Instructions and Transfer modifications will
>> depend heavily on the Core Configuration and force-withdrawal command logic
>> I am implementing in FINERACT-2471, let's sequence this as follows:
>> Phase 1 (My Scope): I will implement the Core Engine (Global Configs,
>> Permission Hierarchy, and the force-withdrawal API). I will ping you once
>> my PR is up so you can see the architecture.
>> Phase 2 (Your Scope): Once the Core is merged, you can pick up the
>> Standing Instructions and Validation Message logic as a separate PR. This
>> ensures you aren't blocked by missing backend configs.
>> I’ll focus on shipping the Core strictly to keep the PR clean and
>> reviewable.
>> Best,
>> Mohammed Saifulhuq
>>
>> On Fri, 6 Feb, 2026, 6:58 pm Bharath Gowda,  wrote:
>>
>>> Hi Ayush,
>>>
>>> Thank you. I appreciate your contribution on the same.
>>>
>>> Regards,
>>> Bharath
>>> Lead Implementation Analyst | Mifos Initiative
>>> PMC Member | Apache Fineract
>>> Mobile: +91.7019635592
>>> http://mifos.org  
>>> 
>>>
>>>
>>> On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH 
>>> wrote:
>>>
 Hi Bharath, Mohammed, and Ádám,

 Bharath, I strongly second your point about the validation message for
 the user.

 The ₹3000 auto-deduction scenario I mentioned earlier is a prime
 example of why this is needed. Without a clear validation message during
 the withdrawal attempt, the user (and even the teller) can be left
 completely confused as to why a deposit "vanished" or why a balance is
 lower than expected.

 To help implement this, I can work on the following:

 Drafting the Validation Logic: I can help define the logic that
 triggers the specific message you suggested: “Insufficient balance. Do you
 want to proceed with the withdrawal?” for accounts where force-withdrawal
 is enabled.

 Standing Instructions: I am happy to look into how we can extend this
 force-withdrawal flag to account transfers and standing instructions as you
 proposed, ensuring consistency across all debit paths.

 Documentation: I’ll ensure these new validation states are clearly
 documented in the JIRA.

 I'm ready to start on these functional requirements in FINERACT-2471 as
 soon as the core command is merged.

 Best,
 Ayush Singh

 On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:

> Hi
>
> Sure, go ahead ;)
>
> Regarsd,
> Adam
>
> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
> [email protected]> wrote:
>
> Hi Adam,
>
> I agree—force-withdrawal is much cleaner and more intuitive than
> withdrawal-force-debit. Let's adopt that name.
>
> Regarding the force: true flag suggestion: I technically prefer the
> separate command (force-withdrawal) solely due to Permission Mapping.
>
> In Fineract's architecture, the platform security check typically maps 
> Command
> Name -> Permission before the service logic executes.
>
>-
>
>If we use the existing withdrawal command with a flag, the system
>will apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
>-
>
>To enforce a stricter 'Manager-Only' permission for the forced
>transaction, we would have to bypass the standard check or implement 
> custom
>security logic inside the service implementation, which feels less
>declarative.
>
> Using the distinct force-withdrawal command allows us to map it
> cleanly to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the
> standard configuration.
>
> Does

Re: Fineract savings account - negative balance

2026-02-06 Thread AYUSH SINGH

Hi Mohammed,

This division of labor sounds perfect. Sequencing it this way will
definitely keep the PRs clean and easier to review.

I'll wait for your ping once the Core Engine PR for FINERACT-2471 is up so
I can study the architecture before starting on the Phase 2 scope (Standing
Instructions and Validation logic).

In the meantime, I'll start drafting the test cases for the validation
messages.

Best,
Ayush Singh

On Fri, Feb 6, 2026, 7:03 PM Mohammed Saifulhuq <
[email protected]> wrote:

> Hi Adam,
> Thanks for the definitive green light! I am proceeding with the
> force-withdrawal command and Permission mapping immediately.
> Hi Bharath & Ayush,
> This is a great division of labor.
> @Ayush: Since the Standing Instructions and Transfer modifications will
> depend heavily on the Core Configuration and force-withdrawal command logic
> I am implementing in FINERACT-2471, let's sequence this as follows:
> Phase 1 (My Scope): I will implement the Core Engine (Global Configs,
> Permission Hierarchy, and the force-withdrawal API). I will ping you once
> my PR is up so you can see the architecture.
> Phase 2 (Your Scope): Once the Core is merged, you can pick up the
> Standing Instructions and Validation Message logic as a separate PR. This
> ensures you aren't blocked by missing backend configs.
> I’ll focus on shipping the Core strictly to keep the PR clean and
> reviewable.
> Best,
> Mohammed Saifulhuq
>
> On Fri, 6 Feb, 2026, 6:58 pm Bharath Gowda,  wrote:
>
>> Hi Ayush,
>>
>> Thank you. I appreciate your contribution on the same.
>>
>> Regards,
>> Bharath
>> Lead Implementation Analyst | Mifos Initiative
>> PMC Member | Apache Fineract
>> Mobile: +91.7019635592
>> http://mifos.org  
>> 
>>
>>
>> On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH 
>> wrote:
>>
>>> Hi Bharath, Mohammed, and Ádám,
>>>
>>> Bharath, I strongly second your point about the validation message for
>>> the user.
>>>
>>> The ₹3000 auto-deduction scenario I mentioned earlier is a prime example
>>> of why this is needed. Without a clear validation message during the
>>> withdrawal attempt, the user (and even the teller) can be left completely
>>> confused as to why a deposit "vanished" or why a balance is lower than
>>> expected.
>>>
>>> To help implement this, I can work on the following:
>>>
>>> Drafting the Validation Logic: I can help define the logic that triggers
>>> the specific message you suggested: “Insufficient balance. Do you want to
>>> proceed with the withdrawal?” for accounts where force-withdrawal is
>>> enabled.
>>>
>>> Standing Instructions: I am happy to look into how we can extend this
>>> force-withdrawal flag to account transfers and standing instructions as you
>>> proposed, ensuring consistency across all debit paths.
>>>
>>> Documentation: I’ll ensure these new validation states are clearly
>>> documented in the JIRA.
>>>
>>> I'm ready to start on these functional requirements in FINERACT-2471 as
>>> soon as the core command is merged.
>>>
>>> Best,
>>> Ayush Singh
>>>
>>>
>>> On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:
>>>
 Hi

 Sure, go ahead ;)

 Regarsd,
 Adam

 On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
 [email protected]> wrote:

 Hi Adam,

 I agree—force-withdrawal is much cleaner and more intuitive than
 withdrawal-force-debit. Let's adopt that name.

 Regarding the force: true flag suggestion: I technically prefer the
 separate command (force-withdrawal) solely due to Permission Mapping.

 In Fineract's architecture, the platform security check typically maps 
 Command
 Name -> Permission before the service logic executes.

-

If we use the existing withdrawal command with a flag, the system
will apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
-

To enforce a stricter 'Manager-Only' permission for the forced
transaction, we would have to bypass the standard check or implement 
 custom
security logic inside the service implementation, which feels less
declarative.

 Using the distinct force-withdrawal command allows us to map it
 cleanly to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the
 standard configuration.

 Does that sound reasonable? If so, I will update the JIRA spec to use
 force-withdrawal.

 Best, Mohammed Saifulhuq

 On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:

> Hi
>
> I don’t believe we need to include “withdrawal” and “debit” in the
> command as well.
>
> What are your thoughts on using “force-withdrawal” instead of
> “withdrawal-force-debit”?
>
> Alternatively, we could simply add an additional field to the request,
> such as “force: true”.
>
> This approach would eliminate the need to introduce new API endpoints.
>

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi Adam,
Thanks for the definitive green light! I am proceeding with the
force-withdrawal command and Permission mapping immediately.
Hi Bharath & Ayush,
This is a great division of labor.
@Ayush: Since the Standing Instructions and Transfer modifications will
depend heavily on the Core Configuration and force-withdrawal command logic
I am implementing in FINERACT-2471, let's sequence this as follows:
Phase 1 (My Scope): I will implement the Core Engine (Global Configs,
Permission Hierarchy, and the force-withdrawal API). I will ping you once
my PR is up so you can see the architecture.
Phase 2 (Your Scope): Once the Core is merged, you can pick up the Standing
Instructions and Validation Message logic as a separate PR. This ensures
you aren't blocked by missing backend configs.
I’ll focus on shipping the Core strictly to keep the PR clean and
reviewable.
Best,
Mohammed Saifulhuq

On Fri, 6 Feb, 2026, 6:58 pm Bharath Gowda,  wrote:

> Hi Ayush,
>
> Thank you. I appreciate your contribution on the same.
>
> Regards,
> Bharath
> Lead Implementation Analyst | Mifos Initiative
> PMC Member | Apache Fineract
> Mobile: +91.7019635592
> http://mifos.org  
> 
>
>
> On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH  wrote:
>
>> Hi Bharath, Mohammed, and Ádám,
>>
>> Bharath, I strongly second your point about the validation message for
>> the user.
>>
>> The ₹3000 auto-deduction scenario I mentioned earlier is a prime example
>> of why this is needed. Without a clear validation message during the
>> withdrawal attempt, the user (and even the teller) can be left completely
>> confused as to why a deposit "vanished" or why a balance is lower than
>> expected.
>>
>> To help implement this, I can work on the following:
>>
>> Drafting the Validation Logic: I can help define the logic that triggers
>> the specific message you suggested: “Insufficient balance. Do you want to
>> proceed with the withdrawal?” for accounts where force-withdrawal is
>> enabled.
>>
>> Standing Instructions: I am happy to look into how we can extend this
>> force-withdrawal flag to account transfers and standing instructions as you
>> proposed, ensuring consistency across all debit paths.
>>
>> Documentation: I’ll ensure these new validation states are clearly
>> documented in the JIRA.
>>
>> I'm ready to start on these functional requirements in FINERACT-2471 as
>> soon as the core command is merged.
>>
>> Best,
>> Ayush Singh
>>
>>
>> On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:
>>
>>> Hi
>>>
>>> Sure, go ahead ;)
>>>
>>> Regarsd,
>>> Adam
>>>
>>> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
>>> [email protected]> wrote:
>>>
>>> Hi Adam,
>>>
>>> I agree—force-withdrawal is much cleaner and more intuitive than
>>> withdrawal-force-debit. Let's adopt that name.
>>>
>>> Regarding the force: true flag suggestion: I technically prefer the
>>> separate command (force-withdrawal) solely due to Permission Mapping.
>>>
>>> In Fineract's architecture, the platform security check typically maps 
>>> Command
>>> Name -> Permission before the service logic executes.
>>>
>>>-
>>>
>>>If we use the existing withdrawal command with a flag, the system
>>>will apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
>>>-
>>>
>>>To enforce a stricter 'Manager-Only' permission for the forced
>>>transaction, we would have to bypass the standard check or implement 
>>> custom
>>>security logic inside the service implementation, which feels less
>>>declarative.
>>>
>>> Using the distinct force-withdrawal command allows us to map it cleanly
>>> to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard
>>> configuration.
>>>
>>> Does that sound reasonable? If so, I will update the JIRA spec to use
>>> force-withdrawal.
>>>
>>> Best, Mohammed Saifulhuq
>>>
>>> On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:
>>>
 Hi

 I don’t believe we need to include “withdrawal” and “debit” in the
 command as well.

 What are your thoughts on using “force-withdrawal” instead of
 “withdrawal-force-debit”?

 Alternatively, we could simply add an additional field to the request,
 such as “force: true”.

 This approach would eliminate the need to introduce new API endpoints.

 What do you think?

 Regards,
 Adam

 On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq <
 [email protected]> wrote:

 Hi Anu,

 Thank you for the approval. I fully agree—'Force Debit' is the standard
 banking terminology and we should align with that. I will proceed with the
 implementation using the naming conventions you provided:

-

*API:* withdrawal-force-debit
-

*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
-

*Configs:* allow-force-debit-on-savings-account &
force-debit-on-savings-account-limit

 Hi

Re: Fineract savings account - negative balance

2026-02-06 Thread Bharath Gowda

Hi Ayush,

Thank you. I appreciate your contribution on the same.

Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
PMC Member | Apache Fineract
Mobile: +91.7019635592
http://mifos.org  



On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH  wrote:

> Hi Bharath, Mohammed, and Ádám,
>
> Bharath, I strongly second your point about the validation message for the
> user.
>
> The ₹3000 auto-deduction scenario I mentioned earlier is a prime example
> of why this is needed. Without a clear validation message during the
> withdrawal attempt, the user (and even the teller) can be left completely
> confused as to why a deposit "vanished" or why a balance is lower than
> expected.
>
> To help implement this, I can work on the following:
>
> Drafting the Validation Logic: I can help define the logic that triggers
> the specific message you suggested: “Insufficient balance. Do you want to
> proceed with the withdrawal?” for accounts where force-withdrawal is
> enabled.
>
> Standing Instructions: I am happy to look into how we can extend this
> force-withdrawal flag to account transfers and standing instructions as you
> proposed, ensuring consistency across all debit paths.
>
> Documentation: I’ll ensure these new validation states are clearly
> documented in the JIRA.
>
> I'm ready to start on these functional requirements in FINERACT-2471 as
> soon as the core command is merged.
>
> Best,
> Ayush Singh
>
>
> On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:
>
>> Hi
>>
>> Sure, go ahead ;)
>>
>> Regarsd,
>> Adam
>>
>> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
>> [email protected]> wrote:
>>
>> Hi Adam,
>>
>> I agree—force-withdrawal is much cleaner and more intuitive than
>> withdrawal-force-debit. Let's adopt that name.
>>
>> Regarding the force: true flag suggestion: I technically prefer the
>> separate command (force-withdrawal) solely due to Permission Mapping.
>>
>> In Fineract's architecture, the platform security check typically maps 
>> Command
>> Name -> Permission before the service logic executes.
>>
>>-
>>
>>If we use the existing withdrawal command with a flag, the system
>>will apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
>>-
>>
>>To enforce a stricter 'Manager-Only' permission for the forced
>>transaction, we would have to bypass the standard check or implement 
>> custom
>>security logic inside the service implementation, which feels less
>>declarative.
>>
>> Using the distinct force-withdrawal command allows us to map it cleanly
>> to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard
>> configuration.
>>
>> Does that sound reasonable? If so, I will update the JIRA spec to use
>> force-withdrawal.
>>
>> Best, Mohammed Saifulhuq
>>
>> On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:
>>
>>> Hi
>>>
>>> I don’t believe we need to include “withdrawal” and “debit” in the
>>> command as well.
>>>
>>> What are your thoughts on using “force-withdrawal” instead of
>>> “withdrawal-force-debit”?
>>>
>>> Alternatively, we could simply add an additional field to the request,
>>> such as “force: true”.
>>>
>>> This approach would eliminate the need to introduce new API endpoints.
>>>
>>> What do you think?
>>>
>>> Regards,
>>> Adam
>>>
>>> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq <
>>> [email protected]> wrote:
>>>
>>> Hi Anu,
>>>
>>> Thank you for the approval. I fully agree—'Force Debit' is the standard
>>> banking terminology and we should align with that. I will proceed with the
>>> implementation using the naming conventions you provided:
>>>
>>>-
>>>
>>>*API:* withdrawal-force-debit
>>>-
>>>
>>>*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>>>-
>>>
>>>*Configs:* allow-force-debit-on-savings-account &
>>>force-debit-on-savings-account-limit
>>>
>>> Hi Ayush, You are spot on regarding the *Command Processing Layer*.
>>> Checking limits at the accounting/closing job would be too late and would
>>> risk General Ledger inconsistency. We must validate strictly at the point
>>> of transaction.
>>>
>>> Regarding your suggestions on Reason Codes and Notifications: *Let's
>>> park those for Phase 2.* We need to get the Core Ledger logic and the
>>> force-debit Transaction Processing merged and stable first. Once the
>>> core engine is in develop, we can look at adding the notification
>>> layers on top.
>>>
>>> I am creating the JIRA ticket and starting the implementation now.
>>>
>>> Best, Mohammed Saifulhuq
>>>
>>> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH 
>>> wrote:
>>>
 Hi Mohammed,

 That’s a great question regarding the placement of the
 min-overdraft-limit check.
 In my view, handling this at the Command processing layer is the more
 robust choice for a few reasons:

 Immediate Feedback: It allows the system to reject a transaction
 instantly if it exceeds the configured limit, providing

Re: Fineract savings account - negative balance

2026-02-06 Thread AYUSH SINGH

Hi Bharath, Mohammed, and Ádám,

Bharath, I strongly second your point about the validation message for the
user.

The ₹3000 auto-deduction scenario I mentioned earlier is a prime example of
why this is needed. Without a clear validation message during the
withdrawal attempt, the user (and even the teller) can be left completely
confused as to why a deposit "vanished" or why a balance is lower than
expected.

To help implement this, I can work on the following:

Drafting the Validation Logic: I can help define the logic that triggers
the specific message you suggested: “Insufficient balance. Do you want to
proceed with the withdrawal?” for accounts where force-withdrawal is
enabled.

Standing Instructions: I am happy to look into how we can extend this
force-withdrawal flag to account transfers and standing instructions as you
proposed, ensuring consistency across all debit paths.

Documentation: I’ll ensure these new validation states are clearly
documented in the JIRA.

I'm ready to start on these functional requirements in FINERACT-2471 as
soon as the core command is merged.

Best,
Ayush Singh


On Fri, Feb 6, 2026, 6:33 PM Ádám Sághy  wrote:

> Hi
>
> Sure, go ahead ;)
>
> Regarsd,
> Adam
>
> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq <
> [email protected]> wrote:
>
> Hi Adam,
>
> I agree—force-withdrawal is much cleaner and more intuitive than
> withdrawal-force-debit. Let's adopt that name.
>
> Regarding the force: true flag suggestion: I technically prefer the
> separate command (force-withdrawal) solely due to Permission Mapping.
>
> In Fineract's architecture, the platform security check typically maps Command
> Name -> Permission before the service logic executes.
>
>-
>
>If we use the existing withdrawal command with a flag, the system will
>apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
>-
>
>To enforce a stricter 'Manager-Only' permission for the forced
>transaction, we would have to bypass the standard check or implement custom
>security logic inside the service implementation, which feels less
>declarative.
>
> Using the distinct force-withdrawal command allows us to map it cleanly
> to a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard
> configuration.
>
> Does that sound reasonable? If so, I will update the JIRA spec to use
> force-withdrawal.
>
> Best, Mohammed Saifulhuq
>
> On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:
>
>> Hi
>>
>> I don’t believe we need to include “withdrawal” and “debit” in the
>> command as well.
>>
>> What are your thoughts on using “force-withdrawal” instead of
>> “withdrawal-force-debit”?
>>
>> Alternatively, we could simply add an additional field to the request,
>> such as “force: true”.
>>
>> This approach would eliminate the need to introduce new API endpoints.
>>
>> What do you think?
>>
>> Regards,
>> Adam
>>
>> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq <
>> [email protected]> wrote:
>>
>> Hi Anu,
>>
>> Thank you for the approval. I fully agree—'Force Debit' is the standard
>> banking terminology and we should align with that. I will proceed with the
>> implementation using the naming conventions you provided:
>>
>>-
>>
>>*API:* withdrawal-force-debit
>>-
>>
>>*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>>-
>>
>>*Configs:* allow-force-debit-on-savings-account &
>>force-debit-on-savings-account-limit
>>
>> Hi Ayush, You are spot on regarding the *Command Processing Layer*.
>> Checking limits at the accounting/closing job would be too late and would
>> risk General Ledger inconsistency. We must validate strictly at the point
>> of transaction.
>>
>> Regarding your suggestions on Reason Codes and Notifications: *Let's
>> park those for Phase 2.* We need to get the Core Ledger logic and the
>> force-debit Transaction Processing merged and stable first. Once the
>> core engine is in develop, we can look at adding the notification layers
>> on top.
>>
>> I am creating the JIRA ticket and starting the implementation now.
>>
>> Best, Mohammed Saifulhuq
>>
>> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH 
>> wrote:
>>
>>> Hi Mohammed,
>>>
>>> That’s a great question regarding the placement of the
>>> min-overdraft-limit check.
>>> In my view, handling this at the Command processing layer is the more
>>> robust choice for a few reasons:
>>>
>>> Immediate Feedback: It allows the system to reject a transaction
>>> instantly if it exceeds the configured limit, providing a better experience
>>> for the bank staff/API consumer.
>>>
>>> Integrity: Checking during the Command layer prevents the General Ledger
>>> from ever entering an "invalid" state that the closing job would have to
>>> fix later, which aligns with the goal of GL accuracy.
>>>
>>> Complexity: Relying on the Accounting closing job might introduce
>>> concurrency issues if multiple force-posts happen between cycles.
>>> Regarding the implementation, I’ve also outlined some functional

Re: Fineract savings account - negative balance

2026-02-06 Thread Bharath Gowda

I second Adam’s suggestion.

In addition, there are two more scenarios that we should handle as part of
this enhancement:

   1.

   Introducing a *force withdrawal* option at the *standing instruction*
   and *account transfer* configuration level (for both savings → loan and
   savings → savings transfers).
   2.

   When a customer initiates a withdrawal *without* force withdrawal
   enabled and the available balance is insufficient, the system should
   display a clear validation message to the user, such as:
   *“Insufficient balance. Do you want to proceed with the withdrawal?”*

Addressing these scenarios will help ensure a better user experience and
more controlled handling of negative balance situations.


Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
PMC Member | Apache Fineract
Mobile: +91.7019635592
http://mifos.org  



On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:

> Hi
>
>
> I don’t believe we need to include “withdrawal” and “debit” in the command
> as well.
>
>
> What are your thoughts on using “force-withdrawal” instead of
> “withdrawal-force-debit”?
>
>
> Alternatively, we could simply add an additional field to the request,
> such as “force: true”.
>
>
> This approach would eliminate the need to introduce new API endpoints.
>
>
> What do you think?
>
>
> Regards,
>
> Adam
>
> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq <
> [email protected]> wrote:
>
> Hi Anu,
>
> Thank you for the approval. I fully agree—'Force Debit' is the standard
> banking terminology and we should align with that. I will proceed with the
> implementation using the naming conventions you provided:
>
>-
>
>*API:* withdrawal-force-debit
>-
>
>*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>-
>
>*Configs:* allow-force-debit-on-savings-account &
>force-debit-on-savings-account-limit
>
> Hi Ayush, You are spot on regarding the *Command Processing Layer*.
> Checking limits at the accounting/closing job would be too late and would
> risk General Ledger inconsistency. We must validate strictly at the point
> of transaction.
>
> Regarding your suggestions on Reason Codes and Notifications: *Let's park
> those for Phase 2.* We need to get the Core Ledger logic and the
> force-debit Transaction Processing merged and stable first. Once the core
> engine is in develop, we can look at adding the notification layers on
> top.
>
> I am creating the JIRA ticket and starting the implementation now.
>
> Best, Mohammed Saifulhuq
>
> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH  wrote:
>
>> Hi Mohammed,
>>
>> That’s a great question regarding the placement of the
>> min-overdraft-limit check.
>> In my view, handling this at the Command processing layer is the more
>> robust choice for a few reasons:
>>
>> Immediate Feedback: It allows the system to reject a transaction
>> instantly if it exceeds the configured limit, providing a better experience
>> for the bank staff/API consumer.
>>
>> Integrity: Checking during the Command layer prevents the General Ledger
>> from ever entering an "invalid" state that the closing job would have to
>> fix later, which aligns with the goal of GL accuracy.
>>
>> Complexity: Relying on the Accounting closing job might introduce
>> concurrency issues if multiple force-posts happen between cycles.
>> Regarding the implementation, I’ve also outlined some functional areas
>> where I can contribute to support this transition:
>>
>> 1. Defined Reason Codes for Negative Balances
>> I propose we implement standard Reason Codes to help the system
>> distinguish between different "Force Debit" types:
>> MAINTENANCE_FEE: For missing minimum balances.
>> REGULATORY_LEVY: For mandated government deductions.
>> SYSTEM_REVERSAL: To correct erroneous credits.
>> INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.
>>
>> 2. User-Notification Logic
>> To prevent user confusion when these debits occur, I can draft the logic
>> for an automated notification trigger. This would alert the user
>> (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into
>> the negative.
>>
>> 3. Documentation & Next Steps
>> I am ready to help draft the functional overview for the Fineract Wiki,
>> including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API
>> conventions Anu mentioned.
>> I've already set up GPG signing for my commits as per Adam’s update.
>> Should I start by drafting these Reason Codes and notification requirements
>> into a formal document for the team to review?
>>
>> Best regards,
>> Ayush Singh
>>
>> On Fri, Feb 6, 2026, 5:03 PM 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Ádám Sághy

Hi

Sure, go ahead ;)

Regarsd,
Adam

> On Feb 6, 2026, at 1:59 PM, Mohammed Saifulhuq  
> wrote:
> 
> Hi Adam,
> 
> I agree—force-withdrawal is much cleaner and more intuitive than 
> withdrawal-force-debit. Let's adopt that name.
> 
> Regarding the force: true flag suggestion: I technically prefer the separate 
> command (force-withdrawal) solely due to Permission Mapping.
> 
> In Fineract's architecture, the platform security check typically maps 
> Command Name -> Permission before the service logic executes.
> 
> If we use the existing withdrawal command with a flag, the system will apply 
> the standard WITHDRAW_SAVINGSACCOUNT check by default.
> 
> To enforce a stricter 'Manager-Only' permission for the forced transaction, 
> we would have to bypass the standard check or implement custom security logic 
> inside the service implementation, which feels less declarative.
> 
> Using the distinct force-withdrawal command allows us to map it cleanly to a 
> FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard configuration.
> 
> Does that sound reasonable? If so, I will update the JIRA spec to use 
> force-withdrawal.
> 
> Best, Mohammed Saifulhuq
> 
> 
> On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  > wrote:
>> Hi
>> 
>> I don’t believe we need to include “withdrawal” and “debit” in the command 
>> as well.
>> 
>> What are your thoughts on using “force-withdrawal” instead of 
>> “withdrawal-force-debit”?
>> 
>> Alternatively, we could simply add an additional field to the request, such 
>> as “force: true”.
>> 
>> This approach would eliminate the need to introduce new API endpoints.
>> 
>> What do you think?
>> 
>> Regards,
>> Adam
>> 
>>> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq 
>>> mailto:[email protected]>> wrote:
>>> 
>>> Hi Anu,
>>> 
>>> Thank you for the approval. I fully agree—'Force Debit' is the standard 
>>> banking terminology and we should align with that. I will proceed with the 
>>> implementation using the naming conventions you provided:
>>> 
>>> API: withdrawal-force-debit
>>> 
>>> Permissions: WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>>> 
>>> Configs: allow-force-debit-on-savings-account & 
>>> force-debit-on-savings-account-limit
>>> 
>>> Hi Ayush, You are spot on regarding the Command Processing Layer. Checking 
>>> limits at the accounting/closing job would be too late and would risk 
>>> General Ledger inconsistency. We must validate strictly at the point of 
>>> transaction.
>>> 
>>> Regarding your suggestions on Reason Codes and Notifications: Let's park 
>>> those for Phase 2. We need to get the Core Ledger logic and the force-debit 
>>> Transaction Processing merged and stable first. Once the core engine is in 
>>> develop, we can look at adding the notification layers on top.
>>> 
>>> I am creating the JIRA ticket and starting the implementation now.
>>> 
>>> Best, Mohammed Saifulhuq
>>> 
>>> 
>>> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH >> > wrote:
 Hi Mohammed,

 That’s a great question regarding the placement of the min-overdraft-limit 
 check.
 In my view, handling this at the Command processing layer is the more 
 robust choice for a few reasons:

 Immediate Feedback: It allows the system to reject a transaction instantly 
 if it exceeds the configured limit, providing a better experience for the 
 bank staff/API consumer.

 Integrity: Checking during the Command layer prevents the General Ledger 
 from ever entering an "invalid" state that the closing job would have to 
 fix later, which aligns with the goal of GL accuracy.

 Complexity: Relying on the Accounting closing job might introduce 
 concurrency issues if multiple force-posts happen between cycles.
 Regarding the implementation, I’ve also outlined some functional areas 
 where I can contribute to support this transition:

 1. Defined Reason Codes for Negative Balances
 I propose we implement standard Reason Codes to help the system 
 distinguish between different "Force Debit" types:
 MAINTENANCE_FEE: For missing minimum balances.
 REGULATORY_LEVY: For mandated government deductions.
 SYSTEM_REVERSAL: To correct erroneous credits.
 INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.

 2. User-Notification Logic
 To prevent user confusion when these debits occur, I can draft the logic 
 for an automated notification trigger. This would alert the user 
 (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into 
 the negative.

 3. Documentation & Next Steps
 I am ready to help draft the functional overview for the Fineract Wiki, 
 including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API 
 conventions Anu mentioned.
 I've already set up GPG signing for my commits as per Adam’s update. 
 Should I start by drafting these Reason Codes

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi Adam,

I agree—force-withdrawal is much cleaner and more intuitive than
withdrawal-force-debit. Let's adopt that name.

Regarding the force: true flag suggestion: I technically prefer the
separate command (force-withdrawal) solely due to Permission Mapping.

In Fineract's architecture, the platform security check typically maps Command
Name -> Permission before the service logic executes.

   -

   If we use the existing withdrawal command with a flag, the system will
   apply the standard WITHDRAW_SAVINGSACCOUNT check by default.
   -

   To enforce a stricter 'Manager-Only' permission for the forced
   transaction, we would have to bypass the standard check or implement custom
   security logic inside the service implementation, which feels less
   declarative.

Using the distinct force-withdrawal command allows us to map it cleanly to
a FORCE_WITHDRAWAL_SAVINGSACCOUNT permission in the standard configuration.

Does that sound reasonable? If so, I will update the JIRA spec to use
force-withdrawal.

Best, Mohammed Saifulhuq

On Fri, Feb 6, 2026 at 6:23 PM Ádám Sághy  wrote:

> Hi
>
>
> I don’t believe we need to include “withdrawal” and “debit” in the command
> as well.
>
>
> What are your thoughts on using “force-withdrawal” instead of
> “withdrawal-force-debit”?
>
>
> Alternatively, we could simply add an additional field to the request,
> such as “force: true”.
>
>
> This approach would eliminate the need to introduce new API endpoints.
>
>
> What do you think?
>
>
> Regards,
>
> Adam
>
> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq <
> [email protected]> wrote:
>
> Hi Anu,
>
> Thank you for the approval. I fully agree—'Force Debit' is the standard
> banking terminology and we should align with that. I will proceed with the
> implementation using the naming conventions you provided:
>
>-
>
>*API:* withdrawal-force-debit
>-
>
>*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>-
>
>*Configs:* allow-force-debit-on-savings-account &
>force-debit-on-savings-account-limit
>
> Hi Ayush, You are spot on regarding the *Command Processing Layer*.
> Checking limits at the accounting/closing job would be too late and would
> risk General Ledger inconsistency. We must validate strictly at the point
> of transaction.
>
> Regarding your suggestions on Reason Codes and Notifications: *Let's park
> those for Phase 2.* We need to get the Core Ledger logic and the
> force-debit Transaction Processing merged and stable first. Once the core
> engine is in develop, we can look at adding the notification layers on
> top.
>
> I am creating the JIRA ticket and starting the implementation now.
>
> Best, Mohammed Saifulhuq
>
> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH  wrote:
>
>> Hi Mohammed,
>>
>> That’s a great question regarding the placement of the
>> min-overdraft-limit check.
>> In my view, handling this at the Command processing layer is the more
>> robust choice for a few reasons:
>>
>> Immediate Feedback: It allows the system to reject a transaction
>> instantly if it exceeds the configured limit, providing a better experience
>> for the bank staff/API consumer.
>>
>> Integrity: Checking during the Command layer prevents the General Ledger
>> from ever entering an "invalid" state that the closing job would have to
>> fix later, which aligns with the goal of GL accuracy.
>>
>> Complexity: Relying on the Accounting closing job might introduce
>> concurrency issues if multiple force-posts happen between cycles.
>> Regarding the implementation, I’ve also outlined some functional areas
>> where I can contribute to support this transition:
>>
>> 1. Defined Reason Codes for Negative Balances
>> I propose we implement standard Reason Codes to help the system
>> distinguish between different "Force Debit" types:
>> MAINTENANCE_FEE: For missing minimum balances.
>> REGULATORY_LEVY: For mandated government deductions.
>> SYSTEM_REVERSAL: To correct erroneous credits.
>> INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.
>>
>> 2. User-Notification Logic
>> To prevent user confusion when these debits occur, I can draft the logic
>> for an automated notification trigger. This would alert the user
>> (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into
>> the negative.
>>
>> 3. Documentation & Next Steps
>> I am ready to help draft the functional overview for the Fineract Wiki,
>> including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API
>> conventions Anu mentioned.
>> I've already set up GPG signing for my commits as per Adam’s update.
>> Should I start by drafting these Reason Codes and notification requirements
>> into a formal document for the team to review?
>>
>> Best regards,
>> Ayush Singh
>>
>> On Fri, Feb 6, 2026, 5:03 PM 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:

Re: Fineract savings account - negative balance

2026-02-06 Thread AYUSH SINGH

Hi Mohammed and Bharath,

Mohammed, your point regarding Granular Permissions and Auditability is
very compelling.

While Bharath’s suggestion for a simpler API flow is efficient, the risk of
a "front-line teller" accidentally overdrawing an account simply because a
global config is on is a significant operational hazard.

>From an implementation standpoint, having a dedicated
withdrawal-force-debit command:
Ensures Intent: It clearly distinguishes between a customer-initiated
withdrawal and a bank-initiated regulatory levy.

Simplifies Auditing: It allows auditors to easily filter for transactions
that bypassed the standard balance check.

Future-Proofs for Phase 2: It provides the perfect "hook" for the Reason
Codes and Notifications we discussed earlier.

I believe the added security of the separate command outweighs the overhead
of a new API endpoint. I'm ready to help with the Unit Tests for this new
command layer to ensure the permission checks are rock-solid.

Best,
Ayush Singh


On Fri, Feb 6, 2026, 6:18 PM Mohammed Saifulhuq <
[email protected]> wrote:

> Hi Bharath,
>
> Thank you for the feedback and the kind words. I appreciate the guidance.
>
> I completely agree with the Acceptance Criteria regarding the 'Negative
> Balance' behavior and the global limits. However, I would like to
> double-check the approach regarding the Single API vs. Separate API
> decision, specifically regarding Permissions and Risk Management.
>
> While using the existing withdrawal API is cleaner implementation-wise,
> it introduces a significant security gap:
>
>1.
>
>Granular Permissions: If we use the standard withdrawal command, we
>rely on the standard WITHDRAW_SAVINGSACCOUNT permission. This means if
>we enable the Global Config, any front-line staff (Teller) could
>accidentally overdraft an account up to the global limit.
>2.
>
>Intent: As Anu mentioned, this feature is primarily for Regulatory
>Levies or Charges (Force Post), which is distinct from a customer-initiated
>withdrawal.
>3.
>
>Auditability: A separate withdrawal-force-debit command allows the
>Bank to explicitly audit *who* bypassed the balance check and *why*.
>
> My Recommendation: I propose we stick to the Separate Command (
> withdrawal-force-debit) strategy. This allows us to attach a specific
> WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permission to it.
>
>-
>
>Teller: Has WITHDRAW_SAVINGSACCOUNT. Can withdraw only if funds exist.
>-
>
>Manager/System: Has WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT. Can withdraw
>into negative (up to limit).
>
> If we merge them into one API, we lose this control layer. Does that align
> with your view on the security requirements?
>
> Best, Mohammed Saifulhuq
>
> On Fri, Feb 6, 2026 at 6:08 PM Bharath Gowda  wrote:
>
>> Hi All,
>>
>> This has been a very good discussion with great idea sharing around the
>> topic.
>> I really appreciate Mohammed for taking the initiative to work on this
>> enhancement.
>>
>> Could we please have a story created in Fineract JIRA with all the
>> required details captured?
>>
>> Regarding the acceptance criteria for this enhancement, I am aligned with
>> the following points:
>>
>>
>>- The system should allow debit transactions on a savings account
>>even when there is an insufficient balance.
>>- In such cases, the savings account should move into a negative
>>balance, and any further debit transactions on the same account should be
>>restricted until the negative balance is fully settled.
>>- There should be a global configuration named
>>allow-negative-balance-on-savings-account, which should be disabled by
>>default.
>>- There should be a configurable global limit on the maximum allowed
>>negative balance.
>>- Accounting behavior should remain unchanged and follow the existing
>>accounting configuration for savings product debit transactions.
>>
>>
>> My only concern is around introducing a new transaction type or a
>> separate API for this functionality. From a customer perspective, this is
>> still a standard withdrawal.
>>
>> Using the existing debit transaction flow should be sufficient and would
>> help avoid the following scenarios:
>>
>>
>>- Organizations must explicitly check account balances before
>>initiating debit transactions.
>>- Any additional complexity, when the existing configurations for
>>“allow-negative-balance-on-savings-account” and the "negative balance
>>limit" can already govern the behavior using current transaction types.
>>
>> So I believe the existing debit transaction mechanism with the above
>> configurations should address the requirement cleanly without new API or
>> new permissions for the same.
>>
>>
>>
>> Regards,
>> Bharath
>> Lead Implementation Analyst | Mifos Initiative
>> PMC Member | Apache Fineract
>> Mobile: +91.7019635592
>> http://mifos.org  
>>

Re: Fineract savings account - negative balance

2026-02-06 Thread Ádám Sághy

Hi

I don’t believe we need to include “withdrawal” and “debit” in the command as 
well.

What are your thoughts on using “force-withdrawal” instead of 
“withdrawal-force-debit”?

Alternatively, we could simply add an additional field to the request, such as 
“force: true”.

This approach would eliminate the need to introduce new API endpoints.

What do you think?

Regards,
Adam

> On Feb 6, 2026, at 1:27 PM, Mohammed Saifulhuq  
> wrote:
> 
> Hi Anu,
> 
> Thank you for the approval. I fully agree—'Force Debit' is the standard 
> banking terminology and we should align with that. I will proceed with the 
> implementation using the naming conventions you provided:
> 
> API: withdrawal-force-debit
> 
> Permissions: WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
> 
> Configs: allow-force-debit-on-savings-account & 
> force-debit-on-savings-account-limit
> 
> Hi Ayush, You are spot on regarding the Command Processing Layer. Checking 
> limits at the accounting/closing job would be too late and would risk General 
> Ledger inconsistency. We must validate strictly at the point of transaction.
> 
> Regarding your suggestions on Reason Codes and Notifications: Let's park 
> those for Phase 2. We need to get the Core Ledger logic and the force-debit 
> Transaction Processing merged and stable first. Once the core engine is in 
> develop, we can look at adding the notification layers on top.
> 
> I am creating the JIRA ticket and starting the implementation now.
> 
> Best, Mohammed Saifulhuq
> 
> 
> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH  > wrote:
>> Hi Mohammed,
>> 
>> That’s a great question regarding the placement of the min-overdraft-limit 
>> check.
>> In my view, handling this at the Command processing layer is the more robust 
>> choice for a few reasons:
>> 
>> Immediate Feedback: It allows the system to reject a transaction instantly 
>> if it exceeds the configured limit, providing a better experience for the 
>> bank staff/API consumer.
>> 
>> Integrity: Checking during the Command layer prevents the General Ledger 
>> from ever entering an "invalid" state that the closing job would have to fix 
>> later, which aligns with the goal of GL accuracy.
>> 
>> Complexity: Relying on the Accounting closing job might introduce 
>> concurrency issues if multiple force-posts happen between cycles.
>> Regarding the implementation, I’ve also outlined some functional areas where 
>> I can contribute to support this transition:
>> 
>> 1. Defined Reason Codes for Negative Balances
>> I propose we implement standard Reason Codes to help the system distinguish 
>> between different "Force Debit" types:
>> MAINTENANCE_FEE: For missing minimum balances.
>> REGULATORY_LEVY: For mandated government deductions.
>> SYSTEM_REVERSAL: To correct erroneous credits.
>> INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.
>> 
>> 2. User-Notification Logic
>> To prevent user confusion when these debits occur, I can draft the logic for 
>> an automated notification trigger. This would alert the user (SMS/Email) as 
>> soon as a withdrawal-force-debit pushes their balance into the negative.
>> 
>> 3. Documentation & Next Steps
>> I am ready to help draft the functional overview for the Fineract Wiki, 
>> including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API 
>> conventions Anu mentioned.
>> I've already set up GPG signing for my commits as per Adam’s update. Should 
>> I start by drafting these Reason Codes and notification requirements into a 
>> formal document for the team to review?
>> 
>> Best regards,
>> Ayush Singh 
>> 
>> On Fri, Feb 6, 2026, 5:03 PM 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 
>>> mailto:[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.
>>>

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi Bharath,

Thank you for the feedback and the kind words. I appreciate the guidance.

I completely agree with the Acceptance Criteria regarding the 'Negative
Balance' behavior and the global limits. However, I would like to
double-check the approach regarding the Single API vs. Separate API
decision, specifically regarding Permissions and Risk Management.

While using the existing withdrawal API is cleaner implementation-wise, it
introduces a significant security gap:

   1.

   Granular Permissions: If we use the standard withdrawal command, we rely
   on the standard WITHDRAW_SAVINGSACCOUNT permission. This means if we
   enable the Global Config, any front-line staff (Teller) could accidentally
   overdraft an account up to the global limit.
   2.

   Intent: As Anu mentioned, this feature is primarily for Regulatory
   Levies or Charges (Force Post), which is distinct from a customer-initiated
   withdrawal.
   3.

   Auditability: A separate withdrawal-force-debit command allows the Bank
   to explicitly audit *who* bypassed the balance check and *why*.

My Recommendation: I propose we stick to the Separate Command (
withdrawal-force-debit) strategy. This allows us to attach a specific
WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permission to it.

   -

   Teller: Has WITHDRAW_SAVINGSACCOUNT. Can withdraw only if funds exist.
   -

   Manager/System: Has WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT. Can withdraw
   into negative (up to limit).

If we merge them into one API, we lose this control layer. Does that align
with your view on the security requirements?

Best, Mohammed Saifulhuq

On Fri, Feb 6, 2026 at 6:08 PM Bharath Gowda  wrote:

> Hi All,
>
> This has been a very good discussion with great idea sharing around the
> topic.
> I really appreciate Mohammed for taking the initiative to work on this
> enhancement.
>
> Could we please have a story created in Fineract JIRA with all the
> required details captured?
>
> Regarding the acceptance criteria for this enhancement, I am aligned with
> the following points:
>
>
>- The system should allow debit transactions on a savings account even
>when there is an insufficient balance.
>- In such cases, the savings account should move into a negative
>balance, and any further debit transactions on the same account should be
>restricted until the negative balance is fully settled.
>- There should be a global configuration named
>allow-negative-balance-on-savings-account, which should be disabled by
>default.
>- There should be a configurable global limit on the maximum allowed
>negative balance.
>- Accounting behavior should remain unchanged and follow the existing
>accounting configuration for savings product debit transactions.
>
>
> My only concern is around introducing a new transaction type or a separate
> API for this functionality. From a customer perspective, this is still a
> standard withdrawal.
>
> Using the existing debit transaction flow should be sufficient and would
> help avoid the following scenarios:
>
>
>- Organizations must explicitly check account balances before
>initiating debit transactions.
>- Any additional complexity, when the existing configurations for
>“allow-negative-balance-on-savings-account” and the "negative balance
>limit" can already govern the behavior using current transaction types.
>
> So I believe the existing debit transaction mechanism with the above
> configurations should address the requirement cleanly without new API or
> new permissions for the same.
>
>
>
> Regards,
> Bharath
> Lead Implementation Analyst | Mifos Initiative
> PMC Member | Apache Fineract
> Mobile: +91.7019635592
> http://mifos.org  
> 
>
>
> On Fri, Feb 6, 2026 at 5:59 PM Paul  wrote:
>
>> Great team work. 👍
>> Thanks for the effort.
>>
>> --
>> Paul
>>
>> On Fri, Feb 6, 2026, 5:33 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]> 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Bharath Gowda

Hi All,

This has been a very good discussion with great idea sharing around the
topic.
I really appreciate Mohammed for taking the initiative to work on this
enhancement.

Could we please have a story created in Fineract JIRA with all the required
details captured?

Regarding the acceptance criteria for this enhancement, I am aligned with
the following points:


   - The system should allow debit transactions on a savings account even
   when there is an insufficient balance.
   - In such cases, the savings account should move into a negative
   balance, and any further debit transactions on the same account should be
   restricted until the negative balance is fully settled.
   - There should be a global configuration named
   allow-negative-balance-on-savings-account, which should be disabled by
   default.
   - There should be a configurable global limit on the maximum allowed
   negative balance.
   - Accounting behavior should remain unchanged and follow the existing
   accounting configuration for savings product debit transactions.


My only concern is around introducing a new transaction type or a separate
API for this functionality. From a customer perspective, this is still a
standard withdrawal.

Using the existing debit transaction flow should be sufficient and would
help avoid the following scenarios:


   - Organizations must explicitly check account balances before initiating
   debit transactions.
   - Any additional complexity, when the existing configurations for
   “allow-negative-balance-on-savings-account” and the "negative balance
   limit" can already govern the behavior using current transaction types.

So I believe the existing debit transaction mechanism with the above
configurations should address the requirement cleanly without new API or
new permissions for the same.



Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
PMC Member | Apache Fineract
Mobile: +91.7019635592
http://mifos.org  



On Fri, Feb 6, 2026 at 5:59 PM Paul  wrote:

> Great team work. 👍
> Thanks for the effort.
>
> --
> Paul
>
> On Fri, Feb 6, 2026, 5:33 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]> 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 
>> 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi All,

I have created the JIRA ticket to track this implementation: *[FINERACT-2471]
Implement 'Force Debit' functionality for Savings Accounts* Link:
https://issues.apache.org/jira/browse/FINERACT-2471


I will post the technical design updates directly on the ticket.

Best, Mohammed Saifulhuq

On Fri, Feb 6, 2026 at 5:57 PM Mohammed Saifulhuq <
[email protected]> wrote:

> Hi Anu,
>
> Thank you for the approval. I fully agree—'Force Debit' is the standard
> banking terminology and we should align with that. I will proceed with the
> implementation using the naming conventions you provided:
>
>-
>
>*API:* withdrawal-force-debit
>-
>
>*Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
>-
>
>*Configs:* allow-force-debit-on-savings-account &
>force-debit-on-savings-account-limit
>
> Hi Ayush, You are spot on regarding the *Command Processing Layer*.
> Checking limits at the accounting/closing job would be too late and would
> risk General Ledger inconsistency. We must validate strictly at the point
> of transaction.
>
> Regarding your suggestions on Reason Codes and Notifications: *Let's park
> those for Phase 2.* We need to get the Core Ledger logic and the
> force-debit Transaction Processing merged and stable first. Once the core
> engine is in develop, we can look at adding the notification layers on
> top.
>
> I am creating the JIRA ticket and starting the implementation now.
>
> Best, Mohammed Saifulhuq
>
> On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH  wrote:
>
>> Hi Mohammed,
>>
>> That’s a great question regarding the placement of the
>> min-overdraft-limit check.
>> In my view, handling this at the Command processing layer is the more
>> robust choice for a few reasons:
>>
>> Immediate Feedback: It allows the system to reject a transaction
>> instantly if it exceeds the configured limit, providing a better experience
>> for the bank staff/API consumer.
>>
>> Integrity: Checking during the Command layer prevents the General Ledger
>> from ever entering an "invalid" state that the closing job would have to
>> fix later, which aligns with the goal of GL accuracy.
>>
>> Complexity: Relying on the Accounting closing job might introduce
>> concurrency issues if multiple force-posts happen between cycles.
>> Regarding the implementation, I’ve also outlined some functional areas
>> where I can contribute to support this transition:
>>
>> 1. Defined Reason Codes for Negative Balances
>> I propose we implement standard Reason Codes to help the system
>> distinguish between different "Force Debit" types:
>> MAINTENANCE_FEE: For missing minimum balances.
>> REGULATORY_LEVY: For mandated government deductions.
>> SYSTEM_REVERSAL: To correct erroneous credits.
>> INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.
>>
>> 2. User-Notification Logic
>> To prevent user confusion when these debits occur, I can draft the logic
>> for an automated notification trigger. This would alert the user
>> (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into
>> the negative.
>>
>> 3. Documentation & Next Steps
>> I am ready to help draft the functional overview for the Fineract Wiki,
>> including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API
>> conventions Anu mentioned.
>> I've already set up GPG signing for my commits as per Adam’s update.
>> Should I start by drafting these Reason Codes and notification requirements
>> into a formal document for the team to review?
>>
>> Best regards,
>> Ayush Singh
>>
>> On Fri, Feb 6, 2026, 5:03 PM 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]> 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.

Re: Fineract savings account - negative balance

2026-02-06 Thread Paul

Great team work. 👍
Thanks for the effort.

--
Paul

On Fri, Feb 6, 2026, 5:33 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]> 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 
> 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Mohammed Saifulhuq

Hi Anu,

Thank you for the approval. I fully agree—'Force Debit' is the standard
banking terminology and we should align with that. I will proceed with the
implementation using the naming conventions you provided:

   -

   *API:* withdrawal-force-debit
   -

   *Permissions:* WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT
   -

   *Configs:* allow-force-debit-on-savings-account &
   force-debit-on-savings-account-limit

Hi Ayush, You are spot on regarding the *Command Processing Layer*.
Checking limits at the accounting/closing job would be too late and would
risk General Ledger inconsistency. We must validate strictly at the point
of transaction.

Regarding your suggestions on Reason Codes and Notifications: *Let's park
those for Phase 2.* We need to get the Core Ledger logic and the force-debit
Transaction Processing merged and stable first. Once the core engine is in
develop, we can look at adding the notification layers on top.

I am creating the JIRA ticket and starting the implementation now.

Best, Mohammed Saifulhuq

On Fri, Feb 6, 2026 at 5:17 PM AYUSH SINGH  wrote:

> Hi Mohammed,
>
> That’s a great question regarding the placement of the min-overdraft-limit
> check.
> In my view, handling this at the Command processing layer is the more
> robust choice for a few reasons:
>
> Immediate Feedback: It allows the system to reject a transaction instantly
> if it exceeds the configured limit, providing a better experience for the
> bank staff/API consumer.
>
> Integrity: Checking during the Command layer prevents the General Ledger
> from ever entering an "invalid" state that the closing job would have to
> fix later, which aligns with the goal of GL accuracy.
>
> Complexity: Relying on the Accounting closing job might introduce
> concurrency issues if multiple force-posts happen between cycles.
> Regarding the implementation, I’ve also outlined some functional areas
> where I can contribute to support this transition:
>
> 1. Defined Reason Codes for Negative Balances
> I propose we implement standard Reason Codes to help the system
> distinguish between different "Force Debit" types:
> MAINTENANCE_FEE: For missing minimum balances.
> REGULATORY_LEVY: For mandated government deductions.
> SYSTEM_REVERSAL: To correct erroneous credits.
> INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.
>
> 2. User-Notification Logic
> To prevent user confusion when these debits occur, I can draft the logic
> for an automated notification trigger. This would alert the user
> (SMS/Email) as soon as a withdrawal-force-debit pushes their balance into
> the negative.
>
> 3. Documentation & Next Steps
> I am ready to help draft the functional overview for the Fineract Wiki,
> including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API
> conventions Anu mentioned.
> I've already set up GPG signing for my commits as per Adam’s update.
> Should I start by drafting these Reason Codes and notification requirements
> into a formal document for the team to review?
>
> Best regards,
> Ayush Singh
>
> On Fri, Feb 6, 2026, 5:03 PM 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]> 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 
>> 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

Re: Fineract savings account - negative balance

2026-02-06 Thread AYUSH SINGH

Hi Mohammed,

That’s a great question regarding the placement of the min-overdraft-limit
check.
In my view, handling this at the Command processing layer is the more
robust choice for a few reasons:

Immediate Feedback: It allows the system to reject a transaction instantly
if it exceeds the configured limit, providing a better experience for the
bank staff/API consumer.

Integrity: Checking during the Command layer prevents the General Ledger
from ever entering an "invalid" state that the closing job would have to
fix later, which aligns with the goal of GL accuracy.

Complexity: Relying on the Accounting closing job might introduce
concurrency issues if multiple force-posts happen between cycles.
Regarding the implementation, I’ve also outlined some functional areas
where I can contribute to support this transition:

1. Defined Reason Codes for Negative Balances
I propose we implement standard Reason Codes to help the system distinguish
between different "Force Debit" types:
MAINTENANCE_FEE: For missing minimum balances.
REGULATORY_LEVY: For mandated government deductions.
SYSTEM_REVERSAL: To correct erroneous credits.
INSUFFICIENT_FUNDS_FEE: For failed over-withdrawal penalties.

2. User-Notification Logic
To prevent user confusion when these debits occur, I can draft the logic
for an automated notification trigger. This would alert the user
(SMS/Email) as soon as a withdrawal-force-debit pushes their balance into
the negative.

3. Documentation & Next Steps
I am ready to help draft the functional overview for the Fineract Wiki,
including the new WITHDRAW_SAVINGSACCOUNT_FORCE_DEBIT permissions and API
conventions Anu mentioned.
I've already set up GPG signing for my commits as per Adam’s update. Should
I start by drafting these Reason Codes and notification requirements into a
formal document for the team to review?

Best regards,
Ayush Singh

On Fri, Feb 6, 2026, 5:03 PM 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]> 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 
> 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

Re: Fineract savings account - negative balance

2026-02-06 Thread Anu Omotayo via dev

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

Re: Fineract savings account - negative balance

2026-02-05 Thread Mohammed Saifulhuq

Hi Ayush, thanks. Regarding the implementation, do you think we should
handle the 'min-overdraft-limit' check at the Command processing layer or
strictly within the Accounting closing job? What are the trade-offs you see
there?

On Fri, Feb 6, 2026 at 12:42 PM AYUSH SINGH  wrote:

> Hi Mohammed,
>
> I'm glad the scenario was helpful in clarifying that risk.
>
> I fully support moving forward with the Negative Balance with Configurable
> Limits approach. It seems to be the most balanced solution for maintaining
> both General Ledger integrity and a transparent user experience.
>
> Looking forward to seeing the draft for the implementation plan!
>
>
> Best,
> Ayush
>
> On Fri, Feb 6, 2026, 10:09 AM 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 
>> 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

Re: Fineract savings account - negative balance

2026-02-05 Thread AYUSH SINGH

Hi Mohammed,

I'm glad the scenario was helpful in clarifying that risk.

I fully support moving forward with the Negative Balance with Configurable
Limits approach. It seems to be the most balanced solution for maintaining
both General Ledger integrity and a transparent user experience.

Looking forward to seeing the draft for the implementation plan!


Best,
Ayush

On Fri, Feb 6, 2026, 10:09 AM 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 
> 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

Re: Fineract savings account - negative balance

2026-02-05 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-05 Thread AYUSH SINGH

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

Re: Fineract savings account - negative balance

2026-02-05 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-05 Thread Jose Alberto Hernandez

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

Re: Fineract savings account - negative balance

2026-02-04 Thread Mohammed Saifulhuq

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

Re: Fineract savings account - negative balance

2026-02-04 Thread Anu Omotayo via dev

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

Re: Fineract savings account - negative balance

2026-01-11 Thread Bharath Gowda

Hi Campbell and Paul,

Thank you for sharing the business requirements and the need to allow
*force-post* on regular savings accounts in Apache Fineract. I believe this
is a valid enhancement and would be a good addition to Fineract. You are
welcome to contribute this feature to the upstream project.

One request, however, is to ensure that this capability is *configurable*,
so that only authorized or required users can enable and use the force-post
functionality.

What do you think @Ádám Sághy  @Victor Manuel Romero
Rodriguez   ?

Before starting development, please create an *enhancement story in
Fineract JIRA*, capturing all details, including the use case,
configuration requirements, and any access-control considerations. This
will help align expectations and facilitate a smoother review and
discussion with the community.

Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
PMC Member | Apache Fineract
Mobile: +91.7019635592
http://mifos.org  

On Sun, Jan 11, 2026 at 5:42 AM Campbell Burgess 
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.
>
>
>
>
>
>
>
>

Re: Fineract savings account - negative balance

2026-01-10 Thread Campbell Burgess


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.

Re: Fineract savings account - negative balance

2026-01-10 Thread Paul

Let's lean on rules since 2020 to guide any efforts. Savings mimic checking
accounts (my words, not the reg) in many ways on this issue. Since then,
savings in the US and multiple types of settlement outside it, need to
FULLY support negative balances.

Below is a breakdown of the rules and mechanics which seems to support use
cases.
Regulatory Framework for Negative Balances

While there is no federal law prohibiting a negative balance, the process
is ruled by how the transaction is classified and how fees are assessed.

   -

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

  CFPB Regulation E Summary

  -

   *The "Force-Post" Right:* Under the *Uniform Commercial Code (UCC) §
   4-401*, a bank may charge a customer's account for any item that is
   otherwise properly payable *even if the charge creates an overdraft.*
   This is the legal "bedrock" for force-posting.
   -

   *APS N (Authorize Positive, Settle Negative):* Recent *FDIC and OCC
   guidance* (2023) warns against "unfair" practices where a bank
   authorizes a transaction when the balance is positive but charges a fee
   when it settles negative due to intervening transactions.

Non-Discretionary Force-Posting

*Zero Balance Accounts (ZBAs)* and external funding failures
(Plaid/Mastercard Send) falls into the category where the bank often has no
choice but to accept a negative balance:

   -

   *Guaranteed Authorizations:* If a card network transaction was
   previously authorized, the bank is contractually obligated to the network
   to settle it. If the simultaneous funding (via Plaid/ACH/Other) fails
   later, the bank must "force-post" the settlement, resulting in a negative
   balance.
   -

   *Returned Deposits:* Per *Regulation CC*, if a deposited item is
   returned unpaid (like an ACH return from an external account), the bank has
   the right to "charge back" the account. If the current balance is zero,
   this creates a negative balance as a *matter of accounting reality.*

My opinion of Community Effort Needed.

*The "force-post" function is essentially an accounting override that
allows a ledger to reflect a debt owed to the institution rather than a
credit held by the customer.* If this feature isn't in Fineract or its NOT
rock solid in performance that squares with rules, this is where the
community can work a solution back to the regs.

Implementing a global configuration for "force-posting" or allowing
negative balances without an explicit overdraft facility makes sense for
Fineract IMO, particularly for institutions operating in the US or those
handling real-time card networks.

Current Fineract environment appears to have savings accounts strictly
validated against a $0$ balance unless an Overdraft Facility is enabled.
However, your ZBA (Zero Balance Account) use case highlights a gap where a
negative balance is an *operational reality* (e.g., a funding failure)
rather than a *requested credit product*.
Value for Commercial Use in Fineract for the US.

   -

   *Ledger Integrity:*
   -

   *Operational Flexibility:*
   -

   *Market Compliance:*Supports US-specific behaviors like *APS N
   (Authorize Positive, Settle Negative)* and *Regulation CC* chargebacks,
   where the bank is legally required to post an item regardless of the
   current balance.
   -

   *Would expect global configuration for the feature. *

*Paul Christison*
*Core Banking / Lending Compliance*

On Fri, Jan 9, 2026 at 9:06 AM Campbell Burgess 
wrote:

> Adam:
>
> Let me answer for Hitesh.
>
> There are essentially 3 use cases here in the United States whereby a
> customer savings account would go into overdraft.
>
>1. The customer has received a prior approved overdraft limit.  (I
>think this is the current supported use case)
>2. The institution *has discretion* to decline, but makes the decision
>to pay.
>   1. Examples: Paying a check (or any) item manually presented, but
>   not wanting to extend "formal" OD protection
>3. The institution *does not have discretion* to decline
>   1. Examples:
>  1. A deposit returned unpaid (for any reason)
>  2. A network card transaction (where the bank previously
>  authorized, guaranteed, the transaction)
>  3. Mistakes
>
> In our particular use case, we have a number of ZBAs (Zero Balance
> Accounts) that have external funding accounts attached.
>
> Transactions are presented on those accounts primarily from our own
> merchant terminals, but also from card networks like Mastercard, VISA and
> other debit networks.
>
> Using services like Plaid, we are making a

Re: Fineract savings account - negative balance

2026-01-09 Thread Campbell Burgess


Adam:

Let me answer for Hitesh.

There are essentially 3 use cases here in the United States whereby a 
customer savings account would go into overdraft.


1. The customer has received a prior approved overdraft limit. (I think
   this is the current supported use case)
2. The institution *_has discretion_* to decline, but makes the
   decision to pay.
1. Examples: Paying a check (or any) item manually presented, but
   not wanting to extend "formal" OD protection
3. The institution *_does not have discretion_* to decline
1. Examples:
1. A deposit returned unpaid (for any reason)
2. A network card transaction (where the bank previously
   authorized, guaranteed, the transaction)
3. Mistakes

In our particular use case, we have a number of ZBAs (Zero Balance 
Accounts) that have external funding accounts attached.


Transactions are presented on those accounts primarily from our own 
merchant terminals, but also from card networks like Mastercard, VISA 
and other debit networks.


Using services like Plaid, we are making a simultaneous deposit to the 
account at the moment we approve the external transaction.


We also make simultaneous deposits using services like Mastercard Send 
(similar to Venmo).


External funding accounts typically have anywhere from .10% to .50% 
failure rate, for a myriad of reasons.


That means that we have to force post that declined/returned/failed 
transaction back to the account (just like we have done in banking for 
100 years).


(Of course, we then have other risk measures to recover the funds and 
return the account to at least -0-)


Hitesh tells me that the "force-post" function is not presently available.

If this feature is valuable to the community, we are happy to contribute 
it to the community.


(we are really happy to contribute everything we do to the community... 
this would help us learn how to do that).


Campbell



On 1/7/2026 11:50 AM, Ádám Sághy wrote:

Hi Hitesh,

Can you elaborate on why should we support negative balance without overdraft 
facility?

In my understanding negative balance of the savings account in fact means it 
goes into overdraft (if enabled) and rejected otherwise.

Am I missing something here?

Regards,
Adam

Sent from my iPhone


On 7 Jan 2026, at 18:19, hitesh prajapati 
wrote:


Hi All,

Apache fineract doesn't allow withdrawal when account balance is 0 because of 
insufficient funds by design. And we can have the savings account to have a 
negative balance by enabling an overdraft facility for that savings product and 
savings account.

We have a use case where we want to post withdrawal transactions to the savings 
account when the balance is zero and allow negative balance to the savings 
account without enabling overdraft facility for that account.

Can we have global configuration in fineract that will allow the savings 
account with negative balance  and by default we can have it OFF and when we 
make it ON, we should allow the savings account balance to go negative without 
enabling overdraft to it.

Please advise, does this make sense to add this feature in finreact community 
version

Thanks,
Hitesh

--

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.

Re: Fineract savings account - negative balance

2026-01-07 Thread Ádám Sághy

Hi Hitesh,

Can you elaborate on why should we support negative balance without overdraft 
facility?

In my understanding negative balance of the savings account in fact means it 
goes into overdraft (if enabled) and rejected otherwise.

Am I missing something here?

Regards,
Adam

Sent from my iPhone

> On 7 Jan 2026, at 18:19, hitesh prajapati  
> wrote:
> 
> 
> Hi All,
> 
> Apache fineract doesn't allow withdrawal when account balance is 0 because of 
> insufficient funds by design. And we can have the savings account to have a 
> negative balance by enabling an overdraft facility for that savings product 
> and savings account.
> 
> We have a use case where we want to post withdrawal transactions to the 
> savings account when the balance is zero and allow negative balance to the 
> savings account without enabling overdraft facility for that account. 
> 
> Can we have global configuration in fineract that will allow the savings 
> account with negative balance  and by default we can have it OFF and when we 
> make it ON, we should allow the savings account balance to go negative 
> without enabling overdraft to it. 
> 
> Please advise, does this make sense to add this feature in finreact community 
> version
> 
> Thanks,
> Hitesh

Re: Fineract savings account - negative balance

2026-01-07 Thread VICTOR MANUEL ROMERO RODRIGUEZ

Hello,

I think that it should be able to be configured in the savings product, but
not in a global configuration.

Regards

Victor

El mié, 7 ene 2026 a las 11:19, hitesh prajapati (<
[email protected]>) escribió:

> Hi All,
>
> Apache fineract doesn't allow withdrawal when account balance is 0 because
> of insufficient funds by design. And we can have the savings account to
> have a negative balance by enabling an overdraft facility for that savings
> product and savings account.
>
> We have a use case where we want to post withdrawal transactions to the
> savings account when the balance is zero and allow negative balance to the
> savings account without enabling overdraft facility for that account.
>
> Can we have global configuration in fineract that will allow the savings
> account with negative balance  and by default we can have it OFF and when
> we make it ON, we should allow the savings account balance to go negative
> without enabling overdraft to it.
>
> Please advise, does this make sense to add this feature in finreact
> community version
>
> Thanks,
> Hitesh
>

44 matches

Mail list logo