[Mifos-developer] Charge on a Fee

[zay...@intrasofttechnologies.com]

Devs,

 

We have a request from couple of our clients whose business processes requires this feature.

 

The request is they need to charge an interest on principal + fee charge OR have a fee with charge calculation type % Loan Amount + Charges which currently doesn’t exist in Mifos X.

 

For example:

 

Principal – 100,000

Margin Fee – 25,000

Total Loan – 125,000/=

Interest – 5% of 125,000 = 6,250/=

 

I have checked versions 17, 18, and also 21 and can’t find the solution. This probably needs to be added as an enhancement, was wondering if anyone has developed such a functionality or if there is a workaround to be able to achieve the same currently?

 

Thanks & Regards;

*******

Zayyad A. Said | Chairman & C.E.O

Cell No.: +254 716 615274 | Skype: zsaid2011

Email: zay...@intrasofttechnologies.com 

Schedule Meetings: https://calendly.com/zayyadsaid

 

[Francis Guchie]

Dear Zayad,

This is a non standard fee on loans. In my experience, I have seen clients levying such fees and later being stopped by their regulators. It would save you a lot of burden to find out if the law of the LAW allows them to do so. I recall one time in one southern African country where they were compounding interest on loans. These companies have long been closed by the Authorities because such acts create credit crunches and they hike the inflation rates of Countries. IMHO 

Read the stories below about Ghana in 2018 & 2019. Sometimes we just need to advise clients about standard operating procedures of the financial industry. 
https://www.centralbanking.com/central-banks/financial-stability/4241121/ghana-closes-72-of-its-microfinance-firms 
https://citinewsroom.com/2018/08/bog-merges-unibank-beige-and-3-other-struggling-banks/

My Kind Regards

Francis Guchie Kirago

Skype: francisguchie

Telegram: 232 79 19 44 07

Whatsapp: 232 79 19 44 07

LINKEDIN: https://www.linkedin.com/in/francis-guchie-kirago-a4379617/

twitter: @FrancisGuchie

Mifos-developer mailing list
mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

[James Dailey]

+1 on this response 

We deliberately have stayed away from enabling such designs in credit products on Mifos. Let’s keep it that way. 

--

Sent from Gmail Mobile

[sif...@skyburgsystems.org]

I’m with Zayyad on this. I’m sure that charging (fees applied in Installments) on (fees charged on disbursement) and also charging interest on (fees + loan) differs from compounding interest on interest. It is good that Fees and interest are clearly defined in MifosX and fees in some countries is counted as income not necessarily and it is allowed. World bank policies don’t seem to be admonish this either. However Laws differ from country to country and of late 90% of the MFIs we come across request this service.

 

The only issue we have found in developing such a feature is instructing the system which fee can have another fee charged to it, as it may become recursive. The solution to such may be a bit tasking.

[zay...@intrasofttechnologies.com]

Hi Francis & James,

 

The request made is to take care of a business process of a client and there is nothing nonstandard about it.

 

I will try give a glimpse of the user case:

 

• ABC Microfinance is in a business of selling items on credit to its members e.g. TV.
• The MFI will purchase this TV from a supplier at say 30,000/= (wholesale price) and book this in Mifos as Principal.
• MFI will add a small margin (flat amount) as their profit from the sale of the TV.
• MFI will give the member the TV at an agreed selling price i.e. Purchase Amount + Margin to repay at a later date or in installments with x% interest of the selling price.

 

How then can you book such a facility in Mifos X?

 

There is a dire need to be able to deliver solutions for different needs, the financial sector keeps on revolving and more innovative models are being introduced. The regulators can only reject such a facility if it is seen to be exploitative and goes against the client protection principles, otherwise it’s a product that is much needed and very common in the East African markets.

 

Regards;

*******

Zayyad A. Said | Chairman & C.E.O

Cell No.: +254 716 615274 | Skype: zsaid2011

Email: zay...@intrasofttechnologies.com 

Schedule Meetings: https://calendly.com/zayyadsaid

 

From: James Dailey <jamesp...@gmail.com>
Sent: Sunday, February 13, 2022 8:34 PM
To: d...@fineract.apache.org
Cc: Mifos software development <mifos-d...@lists.sourceforge.net>
Subject: Re: [Mifos-developer] Charge on a Fee

 

+1 on this response 

[Ankit Muellner]

+1 on statements by Francis & James.

"generally maintaining IFRS (International Financial Reporting Standards) which can perhaps be translatable to local Fees regulations." 

(one example -Tax association of Charge.. which tells the system's accounting process, how  a "posted Charge" is being recorded as an income in a jurisdiction?) and the advanced accounting rules mapping that charge's corresponding txn to a CoA, thus leaving a trail. 

 

IMO Fee on a fee is not appropriate and may expose the system for regulatory vulnerabilities, we should not promote such behaviour in the source code. 

Having said that, Zayad, you are right that such change requests exist, mostly in subvention loans, line of credits, BNPL schemes, bullet term loans and short term working capital features of evolving microfinance.

So, if the charge computation direly needs to be enhanced, something like Surcharge should be computed only on the "Overdue" component of Fees.

Surcharge C = Charge A(%(OverdueFees) + Charge B(%Loan Amount) ..... should be computed as a Charge C. This distinction approach lets system's accounting be regulatory resilient and relevant, by componentizing the charge calculation and allowing the system to record associated txns for grouped (charges A,B)(in accounting) for future audit reasons by a regulatory body.

Thanks 

Ankit

Independent Board

Muellners Foundation, Denmark

Impressum- Muellners® Inc; Copenhagen, Denmark CVR: 41548304; Foundation EU CVR:41008407   

              
This mail is governed by Muellners®  IT policy.
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.

[Bharath Gowda]

  Hi Zayyad,

Thank you for posting the use-case scenario it helped in understanding your initial request.

I do not think it is advisable to incorporate the use-case(MFI and Wholesaler relation ) into the OOB application, especially at the loan account level, 

Even though the use-case is an acceptable and standard business model, the approach of having interest calculated based on (Principal + Fee) is actually non-standard

However, there is a workaround where you could use the TAX component feature

Example:

> MFI buys tv for 30,000

> MFI sells the TV for 35,000 (considering 5,000 is a small margin) to the Member

> Member will pay back 35000 + interest on 35,000

You can use the tax component to charge interest on the FLAT charge (1% on 5000) and normal interest on the principal amount (1% on  30,000), which would give you the right % of interest amount to be collected, However, accounting, JE entries and reports handling could get complex and have to be verified thoroughly.

The best way to handle this is tracking only loan-related relations in Fineract (MFI and Member relation )

So the best fit in the application is 

1. Disbursement amount should be 35,000 (which is the actual amount you are selling the TV at)

2. Interest % should be  on Disbursement amount (i.e 35,000)

Since the relation between MFI and Wholeseller is purely a purchase transaction,  I feel the best way we can track this is at the accounting level using Manual JE entries(could use accounting rules feature for easier entries as well).

Regards,

Bharath

Lead Implementation Analyst | Mifos Initiative

Skype: live:cbharath4| Mobile: +91.7019635592

http://mifos.org  

[Francis Guchie]

Dear Zayad,

I have addressed this issue in a very simple way but first let me give you a similar use case scenario

ACTB in Freetown Sierra Leone, sells TukTuk to its customers on hire purchase. The TukTuk (3 wheeler) has a factory price, licence fees (Revenue Authority), Number plate fees + Transfer fees at end of the loan (Roads Authority) As you can see they have

more than one fee on top of the factory / purchase price price even before a sales margin is added. So they bundle all these into one amount and charge set it up as the Loan Principal amount. 
The client signs a document that clearly states why and how much they are taking as a loan. They are even allowed to make a down payment which is deducted from the Principal amount before the loan is created in the system.

Their accounts department will handle the dynamics of liabilities (fees and purchase price) and all is smooth since they just have to pass lumpsum fees.

My experience has it that there are MFIs that do not have strong Accounts departments and so they demand that the Core Banking Application does all their accounting work. IMO 

Nevertheless, like @sif...@skyburgsystems.org  said, this can be done but will create more issues (one of them is how to handle a reversal / deletion). Given that we all want Apache-Fineract to be globally recognised  as a state of the art application across all countries,
there are going to be some compromises we shall have to make here and there. And having worked with another software before, I have had bad experiences in providing and responding to such demands of a few clients (in one or 2 countries)

I strongly recommend you expedite all other options before this change is added to apache-fineract. I will go with the majority vote and will be happy to test in case it is voted for. 

[sif...@skyburgsystems.org]

Thank you Ankit for your contribution.

 

I’m not entirely sure that compounding fees or interest is a non-standard feature as some if not most banks are already applying. Compound interest is standard in finance and economics. https://en.wikipedia.org/wiki/Compound_interest

I stand corrected but I have not come across an Act or a Law that completely admonishes the application of interest or penalty on a loan that has for example already had an origination fee applied to it.

[sif...@skyburgsystems.org]

I agree with you and franci...@gmail.com in that the application of this may be very complex. But as you inferred, TAX is being applied similarly to how we would want this fee to operate.

 

From: Bharath Gowda <bgo...@mifos.org>

Sent: Monday, 14 February 2022 3:23 PM
To: Mifos software development <mifos-d...@lists.sourceforge.net>

[Ankit Muellner]

+1 on Francis' statement on taking a cautious approach on re-engineering such feature requests.

a. For emerging economies: Please read Section 3.2.2.  [ADB]. [2016]. [Impact of Restrictions on Interest rates in Microfinance]. [Philippines]: [Publisher]. © ADB. [https://www.adb.org/sites/default/files/publication/200141/sdwp-045.pdf][CC BY 3.0 IGO]. There are also some indicators on Usury controls and restrictions in this.

b. For EU: (2021) Anti Usury Legislations & Micro credit regulations, Pg11 and 12: 14, 15, 16 https://www.european-microfinance.org/sites/default/files/document/file/mr_2021_FP.pdf

c. Pg 565  https://scholarlycommons.law.northwestern.edu/cgi/viewcontent.cgi?article=1678&context=njilb

d. This may also help. https://www.jstor.org/stable/25072920

" A core banking technology plays a very systematic role in settling "best practices" for sustainable micro lending."  

If the feature is direly needed, please design in such a way that this computation component of "COMPOUNDED FEE" is clearly auditable in Fineract, to ensure project's transparency and accountability to global anti usury legislations.

Thanks

[zay...@intrasofttechnologies.com]

Hello Francis,

 

While you are saying is true, we should also not be rigid in understanding clients business requirements. The requests we have received are very much genuine and it’s important for them to be able to track margin and interest for each loan due to internal reporting requirements and incentivizing their agents. Combining purchase price with margin as principal will not help them track that properly.

 

We have received same request from clients operating in Kenya as well as Tanzania and that’s why I raised it here as it seemed to be a requirement that is gaining increased interest from our users.

 

Since the community doesn’t see the importance of having that requirement implemented, we shall look for a possibility to an inhouse enhancement to be able to meet the needs of our clients.

 

Should anyone be interested in such a feature then we can have a further discussion on the same.

 

Best Regards;

*******

Zayyad A. Said | Chairman & C.E.O

Cell No.: +254 716 615274 | Skype: zsaid2011

Email: zay...@intrasofttechnologies.com 

Schedule Meetings: https://calendly.com/zayyadsaid

 

[Francis Guchie]

Dear Zayyad,

I do understand your point of view. I am only sharing my experience. Nevertheless, I am ready to support, especially in testing in case the community votes. I will go with the majority