Re: [lmi] Experimental implementation of non-MEC solves

[Greg Chicares]

On 2009-02-17 13:34Z, Greg Chicares wrote:
> Use 20090217T0223Z HEAD to test an experimental implementation of
> non-MEC solves.

No longer experimental: ready to test since 20090228T2333Z.

> We aren't yet sure what the user interface should be, so this
> implementation temporarily hijacks another solve's interface.
> Type "idiosyncrasyN" in the "Comments" field to make the solve
> for tax basis perform a non-MEC solve instead.

Now there's a GUI instead of "idiosyncrasyN".

> Although this
> permits a target CSV and a target duration to be specified, those
> two fields are ignored for non-MEC solves: the "target" is simply
> to avoid a MEC for the lifetime of the policy.

What was gracelessly ignored should be handled through enablement:
ready to test.

> A non-MEC solve probably doesn't make sense for loans.

It's hard to see how that would be helpful, and easy to see how it
could be confusing, so it's forbidden.

> It might
> for withdrawals, but we aren't yet sure how to handle that.

Non-MEC solves for withdrawal and for withdrawal-then-loan are
permitted.

> We're focusing on CVAT today. Major changes will be needed for
> GPT MEC testing to reflect recent legal interpretations.

Yet I saw no good reason to forbid non-MEC solves with GPT.

> This non-MEC solve replaces the old feature that increases the
> specified amount to avoid a MEC. That old feature will soon be
> removed. It wasn't very practical, because requiring a (large)
> increase every seven years presumes future insurability. And the
> way we implemented it in 2002 left much to be desired: it fails
> to increase the initial specified amount when necessary, and it
> doesn't work at all for group carveout.

Coming soon. BTW, the new non-MEC solve does permit solving for the
amount of a single future increase. A series of increases is what
makes little sense to illustrate, and apparently nothing was ever
sold on that basis.