[lmi] Illustrating separate-account charges and gross vs. net interest

[Greg Chicares]

We have a pressing need to depict separate-account products as if
the full gross rate were credited, and various charges were then
deducted. It's a reasonable depiction even though fund accounting
doesn't work exactly that way in admin-system practice. Changes
committed from 20080712T0037Z through 20080713T0936Z expose four
additional columns for use in supplemental reports. One or two
must be refined, and I'm not sure how to proceed with that final
step--Wendy, what do you think?

It's important to understand the distinction between two methods
of applying separate-account decrements:

 - Decrement the unit values that drive fund accounting. IMFs are
   probably always reflected in unit values received from a fund
   manager. An insurer can synthesize unit values that reflect
   its own charges for M&E and commission loading as well as fees
   for a stable-value guarantee.

 - Deduct a charge directly from account value after interest is
   credited. This might be done monthly. The motivating reason is
   that an explicit account-value load can be recognized in GPT
   calculations, subject to §7702(c)(3)(B)(ii), if it's specified
   in the contract.

A particular product may use either or both methods. Confusingly,
the term "M&E" is sometimes applied to most or all decrements,
and to both methods.

Now it is desired to depict the sum of all decrements, even IMF,
as a distinct charge--regardless of which method a product uses.
Three of the additional supplemental-report columns
  GrossIntCredited
  NetIntCredited
  SepAcctCharges
support this concept. A fourth, SpecAmtLoad, is straightforward,
but issues arise with the other three. (All four already existed;
they just hadn't been exposed for supplemental-report use.)

One issue is that GrossIntCredited was incorrectly zero whenever
the separate-account net interest rate happened to be zero. This
was an old defect carried over from the pre-2005 legacy system,
and should have been identified and fixed years ago:
  http://savannah.nongnu.org/bugs/?13787
  [see comment #1 dated 2005-07-14T03:10Z]
This might not seem to matter for the present purpose--a current-
basis supplemental report for a separate-account product--but the
new columns must be correct for general-account cases that might
code the separate-account rate as zero because it's irrelevant. A
correction to this problem is ready to be tested.

Another issue is that two xml stylesheets
  reg_d_individual.xsl
  variable_annuity.xsl
perform calculations that use the three columns under discussion.
It's generally an error to calculate columns in a stylesheet,
which should be used only for formatting. Both seem to calculate
  GrossIntCredited - NetIntCredited + SepAcctLoad
though in curiously-different ways. One calls it "Asset Charges";
the other assigns it to "SpecialIntCredited", which is printed as
"Monthly Charges". Although they'd presumably suffer from the
GrossIntCredited problem discussed in the preceding paragraph, I
would guess that both were intended to represent what today we
want to make available as a SepAcctCharges column.

There seems to be no desire to show the separate-account load
(which is deducted directly from account value) per se, so I've
changed the former SepAcctLoad column's name to SepAcctCharges.
It remains to change its meaning. The patch below would give it a
meaning that seems consonant with the stylesheets (from which the
on-the-fly calculation could then be removed). I prefer not to
apply it without prior discussion.

At any rate, these variables in monthiversary calculations
  NetIntCredited
  SepAcctLoad [not SepAcctCharges, which doesn't exist]
actually affect contract values, while this one
  GrossIntCredited
does not--it's just a notional value that helps depict values as
contemplated here. On the other hand, this output column
  NetIntCredited
represents an actual increment, whereas these two
  GrossIntCredited
  SepAcctCharges [not SepAcctLoad, which no longer exists]
are purely notional and can be defined any way we please. I think
the patch below follows this logic:
  unit_value_charge = GrossIntCredited - NetIntCredited
  SepAcctCharges = unit_value_charge + SepAcctLoad
Alternatively, we might want to establish
  SepAcctCharges = GrossIntCredited - NetIntCredited
but that would require adding SepAcctLoad to GrossIntCredited,
which latter would then no longer equal gross rate times assets.

It's important to understand that the Gross vs. Net distinction
applies only to separate-account interest. One might imagine that
general-account interest is notionally credited at an earned rate
and then a charge is deducted from account value, or even that a
loan is credited interest at the rate actually charged and then a
deduction is taken to recover the spread--but those ideas seem
rather contrived.

Index: ihs_acctval.cpp
===================================================================
RCS file: /sources/lmi/lmi/ihs_acctval.cpp,v
retrieving revision 1.115
diff -u -r1.115 ihs_acctval.cpp
--- ihs_acctval.cpp     13 Jul 2008 09:36:20 -0000      1.115
+++ ihs_acctval.cpp     13 Jul 2008 13:49:16 -0000
@@ -1405,7 +1405,13 @@
     VariantValues().PremTaxLoad       [Year] = YearsTotalPremTaxLoad      ;
     VariantValues().DacTaxLoad        [Year] = YearsTotalDacTaxLoad       ;
     VariantValues().SpecAmtLoad       [Year] = YearsTotalSpecAmtLoad      ;
-    VariantValues().SepAcctCharges    [Year] = YearsTotalSepAcctLoad      ;
+
+    double notional_sep_acct_charge =
+          YearsTotalSepAcctLoad
+        + YearsTotalGrossIntCredited
+        - YearsTotalNetIntCredited
+        ;
+    VariantValues().SepAcctCharges    [Year] = notional_sep_acct_charge   ;

     // Record dynamic interest rate in ledger object.
     //