lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Life insurance begins at inception


From: Greg Chicares
Subject: [lmi] Life insurance begins at inception
Date: Thu, 24 Sep 2015 18:41:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

If a contract has been in force for a day or two, is it an inforce contract
(as opposed to new business)?

Consider this code in 'ledger_invariant.cpp', which sets the 'IsInforce'
field used by '*.xsl' for formatting illustrations:

    IsInforce = 0 != b->yare_input_.InforceYear || 0 != 
b->yare_input_.InforceMonth;

which depends on the values set here:

void Input::set_inforce_durations_from_dates()
{
    std::pair<int,int> ym0 = years_and_months_since
        (EffectiveDate  .value()
        ,InforceAsOfDate.value()
        );
    InforceYear  = ym0.first;
    InforceMonth = ym0.second;

which calls years_and_months_since(), which is documented thus:

/// Full curtate years and months by which 'other_date' follows 'base_date'.
    ^^^^ ^^^^^^^ [emphasis added]

This answers our initial question, but it answers it "no". However, anyone
would agree that the answer is "yes": coverage begins at inception, so a
better test would compare the calendar dates:

    IsInforce = yare_input_.EffectiveDate < yare_input_.InforceAsOfDate;

(which is what I'm going to use for new code, specifically for determining
whether to permit illustrations on a closed policy form that can't be used
for new business [0]).

That's still not quite perfect--one minute after inception, the contract
is in force--but it's the best we can do with the data we have, because
we have only calendar dates, not times.

Many years ago, 'InforceYear' and 'InforceMonth' were GUI input fields,
and we had no 'InforceAsOfDate'; comparing both year and month to zero was
the best we could do in that era. We didn't update the test when we added
'InforceAsOfDate'. Probably we should update it...all in good time.

But not right now. We're busy with other things. But that's not what's
worrying me--it's how to do it. These things must be done delicately,
or you hurt the spell. Thorough testing would be needed. Meanwhile, I
tried running a one-day-old case, and got an assertion failure in some
taxation code, so I guess our exposure is not great if it can't be run
anyway. Still, I can't wait forever to get those shoes....

---------

[0] Of course, one might object that a 1980 CSO form, closed to new
business in 2009, should not be available for a day-old contract today,
six years later. We considered storing each form's no-longer-issued-since
date in the product database, which would let us enforce restrictions
like that. We decided against it on practical grounds. We don't know
exactly when each form was closed to new business. That probably depends
in part on when a replacement became available, which would vary by state.
False positives would create a nuisance if we set too early a cutoff date
or if a lawful underwriting exception was made without our knowledge. And
there's little value in this extra work, because inforce illustrations
get input from an admin system, so there's no real opportunity for an lmi
user to make a mistake here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]