|
Hi Binny,
I spoke with Steven and Dayna on this topic today and I'll try to do justice to that dicussion with the following comments.
There are still some things to clear up on the details:
-
Is this a 'demand savings account' that is open ended with built in incentive for savers to keep money in loner, so not a fixed term account?. But one where a saver could withdraw money at end of year and still leave in a certain amount so they still meet product terms to qualify for increases interest rate as time goes on.
-
Does this work have to be done before Jananidhi Co op actually make a decision on signing up with conflux? Surely they can make a commitment without seeing this in place if this the only gap?
The #1 takeaway is that we (as in community) do want to do some fuller thinking around this product configuration and market segmentation areas of the domain. Whilst it would be great to get to an implementation that is fully flexibile in respect to these areas its probably best for now to break up this work at follows:
Stage 1) Meet the 80/20 need and support (COSM paid people can do this once we agree on whats to be done and if its really needed now.)
-
MIFOSX-668: ability to have interest rate bands defined for product based on the account balance
-
MIFOSX-???: extend MIFOX-668 to also support interest rate bands to take into account 'length of time of active account' (theres probably some min balance requirement here too)
In the above two items, the 'incentives' idea you talk about is managed purely from a product point of view. i.e
-
create standard savings product
-
create women & young persons savings product
-
create snr citizen savings product
With respect to interest rates, you may need to introduce a 'insituational interest rate' which acts as a base rate and products then are defined as that rate + x%.
Some thinking will have to done around the process of changing interest rates and impact on savings accounts.
No attempt is made in the information system in bringing in rules around checking the client/group properties like age or gender to validate/restrict someone entering new savings account application.
Stage 2) Fully Flexible rule driven approach between products and clients/groups (COSM paid people not to attempt do this for time being)
As a future piece of work we could look into what it takes to implement this idea of being able to setup configuration product rules that tie in the 'entiltlements' of customers. Before doing this though theres a need for the following:
-
to fully think/model out the ideas of this area, so Steve/Dayna may wish to setup this process with yourself and some of us techies
-
Understand if Jananidhi Co op (and/or others) are willing to pay for this extra work that satisfies the 20% and makes this a fuller solution
|
