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 <[email protected]> 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 <[email protected]> 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, <[email protected]> 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 <http://facebook.com/mifos> >>>> <http://www.twitter.com/mifos> >>>> >>>> >>>> On Fri, Feb 6, 2026 at 6:52 PM AYUSH SINGH <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> The discussion regarding "user confusion" vs. "accounting >>>>>>>>> accuracy" is very relevant. I recently saw a real-world case where a >>>>>>>>> user >>>>>>>>> didn't maintain a minimum balance, resulting in a -₹3,000 state due >>>>>>>>> to bank >>>>>>>>> charges. >>>>>>>>> When they eventually deposited funds, the money was >>>>>>>>> "auto-deducted" to cover the debt. Because the system didn't make the >>>>>>>>> negative balance transparent, the user was left confused, thinking >>>>>>>>> their >>>>>>>>> deposit had simply disappeared until they contacted the bank. >>>>>>>>> >>>>>>>>> This supports Mohammad's point about the importance of General >>>>>>>>> Ledger accuracy and transparency. If we use a "shadow" or "pending" >>>>>>>>> balance >>>>>>>>> as Alberto suggested, we might actually increase user support tickets >>>>>>>>> because the debt isn't visible to the customer until their new deposit >>>>>>>>> vanishes. >>>>>>>>> >>>>>>>>> I suggest we prioritize a model that reflects the true liability >>>>>>>>> on the user's dashboard to avoid this "missing money" experience. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Ayush Singh >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 5, 2026, 9:37 PM Mohammed Saifulhuq < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Alberto, >>>>>>>>> That is an interesting approach, but I see a few architectural >>>>>>>>> risks with a 'Pending Transaction' model versus a true 'Negative >>>>>>>>> Balance' >>>>>>>>> model for this specific use case: >>>>>>>>> Regulatory Reality: When a 'Force Post' occurs (e.g., a tax levy >>>>>>>>> or regulatory fee), the liability is often immediate. The customer is >>>>>>>>> in >>>>>>>>> debt to the bank at that exact second. Keeping the balance at 0 and >>>>>>>>> hiding >>>>>>>>> the debt in a 'pending' state might misrepresent the actual General >>>>>>>>> Ledger >>>>>>>>> (GL) position of the bank. >>>>>>>>> Interest Calculation: If the account is effectively overdrawn, the >>>>>>>>> bank usually needs to accrue interest on that debt immediately. >>>>>>>>> Fineract's >>>>>>>>> existing interest engine handles negative balances (overdrafts) >>>>>>>>> naturally. >>>>>>>>> If we use a 'pending' queue, we would need to rebuild the interest >>>>>>>>> calculation logic to look at the 'shadow' balance, which adds >>>>>>>>> significant >>>>>>>>> complexity. >>>>>>>>> Complexity on Deposit: Your approach requires a new event listener >>>>>>>>> on every deposit to 'sweep' the pending queue. This introduces >>>>>>>>> concurrency >>>>>>>>> challenges. >>>>>>>>> I believe the 'Negative Balance with Limits' approach stays closer >>>>>>>>> to standard GAAP/IFRS accounting principles where a liability is >>>>>>>>> recognized >>>>>>>>> immediately on the ledger. >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Mohammed Saifulhuq >>>>>>>>> >>>>>>>>> On Thu, 5 Feb, 2026, 9:27 pm Jose Alberto Hernandez, < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> I would like to propose a more robust method: >>>>>>>>> >>>>>>>>> 1. Keep the Savings Account as is, don't update the allowed >>>>>>>>> overdraft or something else, >>>>>>>>> 2. Generate a new transaction type that will be applied once the >>>>>>>>> account has some balance, this can be added to the Savings Account >>>>>>>>> with a >>>>>>>>> new command >>>>>>>>> 3. Include a new Balance amount, similar as we have now, >>>>>>>>> totalBalance amount and available amount, to include those >>>>>>>>> transactions, >>>>>>>>> this new balance usually will be negative when the Savings Account has >>>>>>>>> these transactions to be applied >>>>>>>>> >>>>>>>>> The idea of this new transaction type is to record the different >>>>>>>>> pending stuff to be applied the next time the account has some deposit >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Thanks and regards >>>>>>>>> Alberto >>>>>>>>> >>>>>>>>> On Wed, Feb 4, 2026 at 8:09 PM Mohammed Saifulhuq < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Anu and Campbell, >>>>>>>>> This is a critical feature for regulatory compliance, especially >>>>>>>>> for institutions handling automated service charges or tax deductions >>>>>>>>> where >>>>>>>>> rejecting the debit is not a legal option. >>>>>>>>> I agree with Anu's architectural approach, particularly separating >>>>>>>>> this into a distinct API command (withdrawal-force-post). Mixing this >>>>>>>>> logic >>>>>>>>> into the standard withdrawal flow could create dangerous loopholes >>>>>>>>> where >>>>>>>>> overdrafts happen accidentally. >>>>>>>>> One additional consideration: >>>>>>>>> If we enable allow-negative-balance, we should also consider if >>>>>>>>> this requires a 'Limit' configuration (e.g., 'Max Overdraft Amount'). >>>>>>>>> Allowing infinite negative balance might pose a risk if a force-post >>>>>>>>> API is >>>>>>>>> abused or looped. >>>>>>>>> I am happy to pick up the implementation of the Global >>>>>>>>> Configuration and the Permission structure if we have consensus on the >>>>>>>>> design. >>>>>>>>> Best, >>>>>>>>> Mohammed Saifulhuq >>>>>>>>> >>>>>>>>> On Thu, 5 Feb, 2026, 6:08 am Anu Omotayo via dev, < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I had a similar discussion with my colleague on savings account >>>>>>>>> with negative balance about two weeks ago. The ask was to debit >>>>>>>>> customer >>>>>>>>> savings accounts for regulatory reasons even if the account balance >>>>>>>>> is 0. >>>>>>>>> >>>>>>>>> Also, I had a negative balance in my account with a commercial >>>>>>>>> bank days ago due to a bank charge that I wasn't expecting. >>>>>>>>> >>>>>>>>> Below is a suggestion on how I think this feature can be >>>>>>>>> implemented in fineract. >>>>>>>>> >>>>>>>>> 1. An "allow-negative-balance-on-savings-account" can be added to >>>>>>>>> the global configuration to enable/disable this feature. >>>>>>>>> >>>>>>>>> 2. It should be implemented as a separate API due to its sensitive >>>>>>>>> nature e.g (e.g ~ >>>>>>>>> /fineract-provider/api/v1/savingsaccounts/14/transactions?command=withdrawal-force-post). >>>>>>>>> The "allow-negative-balance-on-savings-account" setting should be >>>>>>>>> checked before the transaction is posted. >>>>>>>>> >>>>>>>>> 3. New permissions such as WITHDRAW SAVINGSACCOUNT FORCE DEBIT, >>>>>>>>> WITHDRAW SAVINGSACCOUNT FORCE DEBIT CHECKER should be created and >>>>>>>>> used for >>>>>>>>> the new API. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Anu Omotayo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sunday, January 11, 2026 at 01:12:07 AM GMT+1, Campbell Burgess >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Paul.... Very well laid out. Thank you. >>>>>>>>> >>>>>>>>> Bottom line... negative consumer deposit (savings accounts in >>>>>>>>> Fineract) routinely go negative, with and without, formal >>>>>>>>> arrangements and >>>>>>>>> with (but also without) account holder opt-in. >>>>>>>>> >>>>>>>>> If what I am now guessing is correct, that Fineract does not >>>>>>>>> readily support a force-post, what is the best path forward. >>>>>>>>> >>>>>>>>> Again, we are happy to do all the lifting and contribute the work >>>>>>>>> product to the community, of course, expecting independent review and >>>>>>>>> oversight. >>>>>>>>> >>>>>>>>> Campbell >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/10/2026 10:37 AM, Paul wrote: >>>>>>>>> >>>>>>>>> *Regulation E (Electronic Fund Transfers):* For one-time debit >>>>>>>>> card and ATM transactions, banks cannot charge an overdraft fee >>>>>>>>> unless the >>>>>>>>> consumer has explicitly *opted in*. However, even without an >>>>>>>>> opt-in, a bank is legally permitted to pay the transaction (creating a >>>>>>>>> negative balance) as long as it does *not* charge a fee. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Herring BANCORP ® >>>>>>>>> >>>>>>>>> >>>>>>>>> *C. Campbell Burgess *President/CEO >>>>>>>>> Office: (806) 373-3921 | Direct: (806) 242-3704 >>>>>>>>> >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> *Herring Bancorp* >>>>>>>>> 2201 Civic Circle, Suite 1000 >>>>>>>>> <https://www.google.com/maps/search/2201+Civic+Circle,+Suite+1000+%0D%0A++++++++++++Amarillo,+TX+79109?entry=gmail&source=g> >>>>>>>>> Amarillo, TX 79109 >>>>>>>>> <https://www.google.com/maps/search/2201+Civic+Circle,+Suite+1000+%0D%0A++++++++++++Amarillo,+TX+79109?entry=gmail&source=g> >>>>>>>>> >>>>>>>>> www.herringbank.com >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>
