[Mifos-users] Status of Client Fees & Charges in Mifos X - MIFOSX-583

[Ed Cable]

Hey guys,

Support for adding client-level fees came up this morning as a blocker for one of Zayyad's customers.  Can you let the community know what the timeline is for adding this support?

Is it still targeted for one of the near-term upcoming releases?

https://mifosforge.jira.com/browse/MIFOSX-583

Thanks,

Ed

[Vishwas Babu]

Ed , Zayyad,

The last couple of releases added support for associating a default savings (current) account for a Client during client creation workflow.

So you can associate a current account with the appropriate accounting rules to a customer and then apply any fees you want to the current account (works exactly like client fees)

Regards,
Vishwas

------------------------------------------------------------------------------

_______________________________________________
Mifos-users mailing list
Mifos...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-users

[Ed Cable]

Vishwas,

I totally agree and now read over the approach that you and Keith discussed. Makes complete sense from an accounting perspective that fees should be associated with an actual account.  As Keith alluded to, let's make sure in the UI we start to explicitly call the current account by its name rather than just it being another savings account. 

In the old Mifos UI, the client fees/charges were summarized at the top level of the client record - Perhaps we could do the same by including a summary of the current account fees at the top level client record page?

Zayyad - will this approach around handling client fees at the current account level work for your customer? Read the comments on the issue linked to below.

Ed

--

Ed Cable

Mifos Community Manager

Director of Community Programs, Mifos Initiative

edc...@mifos.org | Skype: edcable | Mobile: 484.477.8649

Collectively Creating a World of 3 Billion Maries | http://openmf.org  

Note: As of Jan 1, 2014 my email has changed from edcable@openmf.org to edcable@mifos.org. Please update your address book accordingly.

[Binny Gopinath Sreevas]

I will wait for Zayyad and actual users to respond.

 

In my mind this is a functional limitation we are imposing based on our design.

 

-          In a large MFI (with say 500k customers or so), we will be forced to create 500k current accounts just to collect a client level fees, which I feel is unnecessary

 

-          In future, I can see a client onboarding workflow being implemented in Mifos. This could involve steps like:

o   Client application

o   Client Training on Group methodology and liabilities

o   Group test

o   Credit Verification etc.

So, the client may get rejected at any of these steps and never become an active client. And if the MFI wants to charge a client level upfront processing fees – how will we do this?

-          Home loans typically have a processing charge, which is applicable even if the loan application is rejected. In a normal bank, the home loan client need not have any other bank account to apply for a home loan.

 

Thanks
Binny

[srinivasa Rao Yedida]

Hi

I completely agree with Binny, before process of  the loan any stage member may chance to reject. Member Fee should required adding at client level in my case. and even this fee is one time and life time. for that purpose why we to open the other addition account and linkage to client. and again It is different from one to another organization.

Thank

Srinviasarao Yedida

[Ed Cable]

What is the level of effort involved with extending accounting with support at the client-level such that true client fees could be added. I do agree that we shouldn't impose a major functional limitation based on our design especially if creates major pain points for users as noted with the need to maintain actual accounts for an inactive client just to bill them fees. 

I do see how not having ability to directly add a fee to the client would be perceived as a major functional gap and having to set up a current account as being a cumbersome work around that doesn't match overall business process. 

I also see it being quite important to move towards supporting the tracking of the full client lifecycle starting from prospects/pre-clients, as Amit from Digamber has so often noted the strong need. 

[Sander van der Heyden]

Hi all,

Just wanted to quickly join in on this discussion. From a system perspective I can't see any harm in giving every client a current account when registering. I even think it is a requirement in situations whereby the moment of charging a fee, and the moment of paying it are not in sync, such as mobile money, ATMs etc. By using a current account the client can deposit the money during the initial meeting, or whenever he or she has it available. At the time the account is now setup and the charges applied the payment will be deducted. In the same way the current account can provide easy ways of having one cash-in/out point in your system and allow the other products to tap into that account. Obviously all the setup and creation of these accounts can be done completely automatically as part of the on-boarding process to reduce workload on the end-user. 

It is already possible to do most of this by setting up an account with a minimum opening balance, and by then applying a charge, the balance goes back to 0 assuming the loan officer took a (cash/cheque) payment from the client for the same amount as the opening balance. In terms of transparency to a client, it is also beneficial to have a current account which can be easily tracked with a variety of fees. Behind the screens a feature that is proposed here, should work this way anyway to maintain sufficient levels of tracking both on portfolio and accounting side (Vishwas, your thoughts?)

I can see that this might run into problems whereby a client needs to be active in the system before they can pay fees. However I've not yet come across situations where a client would be paying fees if they were not registered with the institution, same thing for applying for credit, this normally follows after registering with the institution. So in these cases there is always the option to close the client if the decision is made not to fund them. We could avoid this by already allowing certain products (by configuration) to be given in pending approval stages of the client. It works the same way in regular banks, where even clients who are declined for a product will already go through an on boarding process and will be fully registered in the system and have to be given (internal) accounts to work with these fees. 

@Binny: I think the different worklow-statuss'es you mention are the way to go forward, however they will be organisation specific, and should not become a burden and clutter in the system for organisations who do not want to use it. The way I've seen it work in other systems is that you can use your workflows to map certain client-types/client-statuses to actual system statuses.  For instance during the Application, Group test etc the client remains pending approval from a system perspective, but just gets different (customisable) labels as they proceed (this is a different feature requirement obv). After completing they can become active, and the same type of labelling can be applied to differentiate between active funded, active non-funded, dormant, non-performing etc clients. All of them are active, but can just have different labels at the time. A good example is the way the JIRA workflows can be setup. The statuses in there are also just mapping of the 4/5 system defined to organisation specific workflows. But maybe we should park this one for the speccing out of the workflows feature ;-)

To get back to this feature, I think that the current backend platform already provides the features to fulfil 95% of the requirements that are currently there in the request, and anything that needs to be added in the future can easily be done. The adjustments (if any) could  therefore be a UI thing to make sure the look and feel align with the expectations. That should be pretty easy and can be part of the modifications done during implementation for this (prospective) client. 

--

Sander van der Heyden

CTO Musoni Services

Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter! 
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands

[Binny Gopinath Sreevas]

I am not for using an explicit current account to capture client level fees –

 

certain types of MFI organizations (non-banking financial companies, NBFCs) are not permitted by regulators to accept deposits – in such cases, the approach will need UI customization for these organizations (for example to not show these accounts as real deposits, but as a pseudo-account to gather fees) … and reporting customizations – so that these don’t appear as savings accounts to auditors – the effort will not be trivial ..

 

Regarding client on-boarding workflow, yes, the idea is to make it configurable so that organizations which do not want to follow any workflow will not need to use such workflows.

 

Thanks and Regards
Binny Gopinath Sreevas

+91-98861 39498
Skype: binny.gopinath

 

[Sander van der Heyden]

Hi Binny,

I agree with you on the regulatory issue, however this is very much a matter of presentation and reporting, and we've not seen any issues in this area with our clients and their respective regulatory bodies. In the East and West african regions it is also not allowed to take deposits, however everyone does take security collateral. These collaterals need to be held seperate to the working capital (all accounting/ auditing rules), but can be tapped in situations where fees are due or to transfer overpayments into and obviously whenever the client defaults. We have clients whereby all fees come from the collateral account, including loan fees etc. In the same way the current account could be emptied using a standing orders feature into the security collateral account, or both could be the same. The current approach works for 2 of our clients, who are non-regulated and use the savings account functionality combined with the charges in the system for this purpose. 

My main worry with the proposed client level fees is that in a situation of digital payments, such as mobile money, or any other form of EFT it is difficult to integrate when there is no way to handle people paying too much, too little, in instalments etc. Secondly the impact on the portfolio side of the system and the technical implementation will be significant (even compared to UI and reporting tweaks). Not only does it require a new type of charges, it also requires adjustments to the collection sheets, new API's to handle the charges, the payment of the charges, reversals etc. All features that are already there on the savings side and therefore very easy to blend them into the existing situation using UI tweaks instead of platform development. By leveraging on features like the 'tagging' that was introduced on the accounting side or maybe some extra params on the savings product configuration, situations like you described can easily be differentiated in both the UI and report customisations.

Sander 

--

Sander van der Heyden

CTO Musoni Services

Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter! 
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands

On 1 Apr 2014, at 03:20, Binny Gopinath Sreevas <binny.g...@gmail.com> wrote:

I am not for using an explicit current account to capture client level fees –

 

certain types of MFI organizations (non-banking financial companies, NBFCs) are not permitted by regulators to accept deposits – in such cases, the approach will need UI customization for these organizations (for example to not show these accounts as real deposits, but as a pseudo-account to gather fees) … and reporting customizations – so that these don’t appear as savings accounts to auditors – the effort will not be trivial ..

 

Regarding client on-boarding workflow, yes, the idea is to make it configurable so that organizations which do not want to follow any workflow will not need to use such workflows.

 

Thanks and Regards
Binny Gopinath Sreevas

+91-98861 39498
Skype: binny.gopinath

 

 

From: Sander van der Heyden [mailto:sandervan...@musoni.eu] 
Sent: 31 March 2014 12:46
To: A good place to start for users or folks new to Mifos.
Cc: Zayyad Said; Vishwas Babu; Binny Gopinath
Subject: Re: [Mifos-users] Status of Client Fees & Charges in Mifos X - MIFOSX-583

 

Hi all,

 

Just wanted to quickly join in on this discussion. From a system perspective I can't see any harm in giving every client a current account when registering. I even think it is a requirement in situations whereby the moment of charging a fee, and the moment of paying it are not in sync, such as mobile money, ATMs etc. By using a current account the client can deposit the money during the initial meeting, or whenever he or she has it available. At the time the account is now setup and the charges applied the payment will be deducted. In the same way the current account can provide easy ways of having one cash-in/out point in your system and allow the other products to tap into that account. Obviously all the setup and creation of these accounts can be done completely automatically as part of the on-boarding process to reduce workload on the end-user. 

 

It is already possible to do most of this by setting up an account with a minimum opening balance, and by then applying a charge, the balance goes back to 0 assuming the loan officer took a (cash/cheque) payment from the client for the same amount as the opening balance. In terms of transparency to a client, it is also beneficial to have a current account which can be easily tracked with a variety of fees. Behind the screens a feature that is proposed here, should work this way anyway to maintain sufficient levels of tracking both on portfolio and accounting side (Vishwas, your thoughts?)

 

I can see that this might run into problems whereby a client needs to be active in the system before they can pay fees. However I've not yet come across situations where a client would be paying fees if they were not registered with the institution, same thing for applying for credit, this normally follows after registering with the institution. So in these cases there is always the option to close the client if the decision is made not to fund them. We could avoid this by already allowing certain products (by configuration) to be given in pending approval stages of the client. It works the same way in regular banks, where even clients who are declined for a product will already go through an on boarding process and will be fully registered in the system and have to be given (internal) accounts to work with these fees. 

 

@Binny: I think the different worklow-statuss'es you mention are the way to go forward, however they will be organisation specific, and should not become a burden and clutter in the system for organisations who do not want to use it. The way I've seen it work in other systems is that you can use your workflows to map certain client-types/client-statuses to actual system statuses.  For instance during the Application, Group test etc the client remains pending approval from a system perspective, but just gets different (customisable) labels as they proceed (this is a different feature requirement obv). After completing they can become active, and the same type of labelling can be applied to differentiate between active funded, active non-funded, dormant, non-performing etc clients. All of them are active, but can just have different labels at the time. A good example is the way the JIRA workflows can be setup. The statuses in there are also just mapping of the 4/5 system defined to organisation specific workflows. But maybe we should park this one for the speccing out of the workflows feature ;-)

 

To get back to this feature, I think that the current backend platform already provides the features to fulfil 95% of the requirements that are currently there in the request, and anything that needs to be added in the future can easily be done. The adjustments (if any) could  therefore be a UI thing to make sure the look and feel align with the expectations. That should be pretty easy and can be part of the modifications done during implementation for this (prospective) client. 

 

--

Sander van der Heyden

CTO Musoni Services

<image001.png>

[Binny Gopinath Sreevas]

Zayyad,

 

For your implementation though, I am assuming that you can still go ahead by collecting client level fees from a default current account that gets opened for a client. As Africa region will not have restrictions around opening zero balance current accounts with zero interest. I am assuming that this is not a blocker for you. Please confirm if you can progress on your implementation by using a current account?

 

Adding the feature for client level fees without having to open a current account – is  a much larger development effort and this is not something I too would like to spend effort on right away ... And in my opinion, there are quite a few more important features that are required – like accrual accounting and true interest recalculation etc. So would like to spend efforts on these features in the immediate future ..

 

Thanks
Binny

 

[Nayan Ambali]

Hi Binny,

I see one more potential issue with proposed solution is, all the transaction shown as deposit to the saving account and later deducted towards fees.

By doing this way, system is recording false deposits and withdrawals and from accounting point of view also it does not reflect the exact business events.

The solution for this is saving accounts should be able to collect fees/charges directly as cash or other form apart from deducting directly from the s/b account.

Thanks

Nayan Ambali

 

Thanks and Regards,
Nayan Ambali

+91 9591996042

skype: nayangambali

[Nayan Ambali]

Binny,

One more point we need to consider.

Right now Saving account charge/fees can't be removed from s/b account, if you are recommending this as alternative to membership fees then remove charge feature should be given to saving account charges.

Thanks

Nayan Ambali

Thanks and Regards,
Nayan Ambali

+91 9591996042

skype: nayangambali