This UML Class Diagram shows the subset of the PPfA Model that pertains to supporting Fund Transfer transactions. 0..*

Transcription

1 This UML Class Diagram shows the subset of the PPfA Model that pertains to supporting Fund Transfer transactions. OLifE PolicyStatusCC -PolicyStatus : Integer FeatureTransactionProduct -TransType : Integer -ArrType : Integer -TransAvailableDate : Date FeatureProductInfo -FeatureCode : String -ProductCode : String PolicyProduct -CarrierCode : String -ProductCode : String -CusipNum : String 1..1 AnnuityProduct FeatureProduct -FeatureCode : String -FeatureMappingCode : Integer -ArrType : Integer InvestProduct -CarrierCode : String -ProductCode : String -InvestProductTypeCode : Integer -AssetClass : Integer InvestProductInfo -CarrierCode : String -ProductCode : String -MinDepositPct : Double -MaxDepositPct : Double AllocTypeProduct -SourceTransferAmtType : Integer -DestTransferAmtType : Integer -RoundingPrecision : Integer FeatureOptRequisite -FeatureCode : String -ProductCode : String FeatureOptConflict -FeatureCode : String -ProductCode : String 1..* FeatureOptProduct -ProductCode : String -Name : String -MinTransactionAmt : Decimal -MaxTransactionAmt : Decimal -MinTerm : Integer -MaxTerm : Integer -MinPct : Double -MaxPct : Double -ArrSubType : Integer -TermQualifier : Integer -MaxNumDestinationInvestProd : Integer -MinNumDestinationInvestments : Integer -MaxNumSourceInvestProducts : Integer -MinNumSourceInvestments : Integer ExclusionInvestProduct -CarrierCode : String -ProductCode : String SourceInvestProduct -CarrierCode : String -ProductCode : String -MinAmt : Decimal -MaxAmt : Decimal -MinPct : Double -MaxPct : Double DestInvestProduct -CarrierCode : String -ProductCode : String -MinAmt : Decimal -MaxAmt : Decimal -MinPct : Double -MaxPct : Double

2 This UML Class Diagram shows the subset of the TXLife Model that pertains to the DTCC IFT real-time messages: TX #212 - Values Inquiry TX #102 - Funds Transfer TXLife -@Version : String Organization -DTCCMemberCode : String {OR} Person -FirstName : String -LastName : String Producer -NIPRNumber : String Carrier -CarrierCode : String TXLifeRequest -TransRefGUID : String -CorrelationGUID : String -TransType : Integer -TransExeDate : Date -TransExeTime : Time -TransMode : Integer -TransEffDate : Date -PendingResponseOK : Boolean {OR} TXLifeResponse -TransRefGUID : String -CorrelationGUID : String -TransType : Integer -TransExeDate : Date -TransExeTime : Time -TransMode : Integer -TransEffDate : Date 1..1 Party -PartyTypeCode : Integer OLifE TransResult -ResultCode : Integer PartialIdentification -IdentificationPart : String -PartialIDType : Integer Policy -CarrierCode : String -ProductCode : String -PolNumber : String -Jurisdiction : Integer -EffDate : Date -PolicyStatus : Integer Annuity -QualPlanType : Integer Rider -RiderCode : String -RiderTypeCode : Integer -RelationRoleCode : Integer -OriginatingObjectType : Integer -RelatedObjectType : Integer Relation 1..1 Holding -HoldingTypeCode : Integer -AccountDesignation : Integer -DistributorClientAcctNum : String -AssetValue : Currency Arrangement -ArrType : Integer -ArrSubType : Integer -ProductCode : String -EndDate : Date -ModalAmt : Currency -ModalPct : Percent -SourceTransferAmtType : Integer -DestTransferAmtType : Integer RestrictionInfo -RestrictionCode : Integer -RestrictionReason : Integer Investment SubAccount ResultInfo -@ProblemRef : String -ResultInfoCode : Integer -ResultInfoDesc : String -SysMessageCode : String -CarrierCode : String -ProductCode : String -CurrNumberUnits : Double -TotValue : Currency -AvailableFundsAmt : Currency -TransferSendAllowedInd : Boolean -TransferDestAllowedInd : Boolean -FundRestrictReason : Integer -UnderlyingCusipNum : String Authorization -BusinessMethodCC : Integer -AuthorizationEntityCC : Integer 1..1 AuthorizationTransaction -AuthorizationMappingCodeInd : Boolean -AdministrativeTransaction : Integer -FinActivityType : Integer ArrSource -TransferAmt : Currency -TransferPct : Percent ArrDestination -TransferAmt : Currency -TransferPct : Percent

3 Overview: A fund transfer PPfA showing the use of FeatureTransactionProduct, the Transfer Feature/Option, and 4 source invest products amd 3 destination (as modeled in PPfA 2.16). Overview - Basic FT : PolicyProduct : AnnuityProduct : PolicyStatusCC : FeatureTransactionProduct {ArrType = 1, TransAvailableDate = , : InvestProductInfo GumbyFund : InvestProduct {AssetClass = 2, CarrierCode = 12345, InvestProductTypeCode = 15, NoNewMoneyDate = , ProductCode = GUMBY, SaleExpirationDate = } FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} : FeatureProductInfo {FeatureCode = FT, ProductCode = SDFT} : InvestProductInfo YoYoFund : InvestProduct {AssetClass = 2, CarrierCode = DUNCAN, InvestProductTypeCode = 15, ProductCode = BFLY1} SDFT : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 4, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 1???, ProductCode = SDFT} : SourceInvestProduct ProductCode = GUMBY} : SourceInvestProduct {CarrierCode = DUNCAN, ProductCode = BFLY1} : FeatureProductInfo {FeatureCode = SW, ProductCode = SWIS98} : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 3} : DestInvestProduct {CarrierCode = DUNCAN, ProductCode = BFLY1} : InvestProductInfo : InvestProductInfo PlayDohFund : InvestProduct {AssetClass = 2, CarrierCode = HASBRO, InvestProductTypeCode = 15, ProductCode = YUMMY, SaleExpirationDate = , SoftCloseDate = } FrisbeeFixed : InvestProduct {AssetClass = 1, CarrierCode = WHAMO, InvestProductTypeCode = 15, ProductCode = 180G} : SourceInvestProduct {CarrierCode = HASBRO, ProductCode = YUMMY} : DestInvestProduct {CarrierCode = HASBRO, ProductCode = YUMMY} : SourceInvestProduct {CarrierCode = WHAMO, ProductCode = 180G} : DestInvestProduct {CarrierCode = WHAMO, ProductCode = 180G} FeatureProduct(s) {FeatureCode = SW, etc.} FeatureOptProduct(s) {ProductCode = SWIP97, etc.}

4 Use Case 0A: Values Inquiry (TX #212) REQUEST. In the request message, the distributor needs to identify the policy (by providing CarrierCode and Policy Number), the Carrier (via DTCC Member code and NAIC code), the Distributor (via DTCC Member Code), the Owner (via name and partial SNN), the Annuitant (via name and Partial SNN) and the Agent requesting the Transfer (via name and partial SNN). Issue for IFT WG: Should carrier, distibutor, and other party names be required (to make XML more readible)? Values_Inquiry_Request Request PendingResponseOK = FALSE, TransExeTime = 15:59:23-04:00, TransRefGUID = AB34391F-24AC-12ED-732A-B0B052D2F8E1, TransSubType = 21207, TransType {DistributorClientAcctNum = , HoldingTypeCode = 2} : Policy PolNumber Carrier : Party {PartyTypeCode = 2} : Organization {DTCCMemberCode = 1234} : Carrier {CarrierCode = 12345} : Relation {RelationRoleCode = 38} : Relation {RelationRoleCode = 8} : Relation {RelationRodeCode : Relation {RelationRoleCode = Distributor : Party {PartyTypeCode = 2} Agent : Party {PartyTypeCode = OwnerAnnuitant : Party {PartyTypeCode = 1} : Organization {DTCCMemberCode = 6789} : Person : PartialIdentification {IdentificationPart = 0007, PartialIDType = 1} : Person : PartialIdentification {IdentificationPart = 1234, PartialIDType = 1} : Producer {NIPRNumber = }

5 Use Case 0B: Values Inquiry (TX #212) RESPONSE. In the response message, the carrier will return the positions information on the in-force policy. In this example, the policy has positions on 3 funds: two variable funds, and one SDCA fixed fund. A 4th fund -- PlayDoh -- has no position, but has a fund transfer restriction, and thus is included in the values inquiry. The policy has two riders: (1) a stepped-up death benefit rider and (2) a hardship (SC Waiver) rider. The policy has two arrangements: (1) An SDCA moving money from the fixed fund to Gumby and YoYo, and (2) standing allocations. Values_Inquiry_Response Response TransExeTime = 15:59:29-04:00, TransRefGUID = AB34391F-24AC-12ED-732A-B0B052D2F8E1, TransSubType = 21207, TransType = 212} : TransResult {ResultCode = 1} Note: Parties and relations from 212 REQUEST are echoed in the 212 RESPONSE. : Relation(s) : : Authorization {AuthorizationEntityCC = 38, BusinessMethodCC = 12} : AuthorizationTransaction {AdministrativeTransaction = 102, AuthorizationMappingCode = TRUE} {AssetValue = , DistributorClientAcctNum = , HoldingTypeCode = 2} : Policy EffDate = , PolicyStatus = 1, PolNumber = AK, ProductCode = Z } DB : Rider {RiderCode = DBSUP90, RiderSubTypeCode = 4, RiderTypeCode = 206} SCWaiver : Rider {RiderCode = TILL19X, RiderSubTypeCode = 17, RiderTypeCode = 202} : Annuity SDCA : Arrangement {ArrSubType = 3, ArrType = 2, EndDate = , ModalAmt = , ProductCode = SDCA12} StandingAllocations : Arrangement {ArrSubType = 21, ArrType = 37, ProductCode = STDALC} : RestrictionInfo {RestrictionCode = 1 (None)} : Investment {TransferPct = 75%} {TransferPct = 25%} GumbyFund : SubAccount {AvailableFundsAmt = , CarrierCode = 12345, CurrNumberUnits = 52.67, ProductCode = GUMBY, TotValue = , TransferDestAllowedInd = 1, TransferSendAllowedInd = 1} YoYoFund : SubAccount {AvailableFundsAmt = , CarrierCode = DUNCAN, CurrNumberUnits = , FundRestrictReason = , ProductCode = BFLY1, TotValue = , TransferDestAllowedInd = 0, TransferSendAllowedInd = 1} PlayDohFund : SubAccount {AvailableFundsAmt = 0.00, CarrierCode = HASBRO, CurrNumberUnits = 0, FundRestrictReason = NEW, ProductCode = YUMMY, TotValue = 0.0, TransferDestAllowedInd = 1, TransferSendAllowedInd = 0} FrisbeeFixed : SubAccount {AvailableFundsAmt = , CarrierCode = WHAMO, CurrNumberUnits = , ProductCode = 180G, TotValue = , TransferDestAllowedInd = 1, TransferSendAllowedInd = 1}

6 Use Case 0C: Values Inquiry (TX #212) RESPONSE. In this example, there is a policy-level restriction on fund transfer. In this case, detailed positions information will NOT be sent. In this example, the restriction is due to an enrollment conflict with the Systematic Withdrawal arrangement. In this case, the Arrangement (or Rider) should also be returned to better explain the reason for the restriction. Values_Inquiry_Response Response TransExeTime = 15:59:29-04:00, TransRefGUID = AB34391F-24AC-12ED-732A-B0B052D2F8E1, TransSubType = 21207, TransType = 212} : TransResult {ResultCode = {DistributorClientAcctNum = , HoldingTypeCode = 2} : RestrictionInfo {RestrictionCode = , RestrictionReason = } : Arrangement {ArrSubType = 7, ArrType = 38, ProductCode = SWSA2003}

7 Use Case 0D: Values Inquiry (TX #212) FAILURE Response. In this example, the policy number provided in the Request is not recognized by the carrier. In this case, the carrier responds with a ResultCode of 5 (Failure). Therefore, detailed positions information will NOT be sent. The problem is reported in <ResultInfo> with a code of 3026 (Unknown Policy Number). Values_Inquiry_Response Response TransExeTime = 15:59:29-04:00, TransRefGUID = AB34391F-24AC-12ED-732A-B0B052D2F8E1, TransSubType = 21207, TransType = 212} : TransResult {ResultCode = : ResultInfo {ResultInfoCode = 2040, ResultInfoDesc = "Unknown Policy Number"} {DistributorClientAcctNum = , HoldingTypeCode = 2} Note: If the carrier is unable to process the Values Inquiry Request, respond with <ResultCode> of "failure" (5). Also provide the reason why the transaction could not be processed in <ResultInfoCode>. : Policy PolNumber = AK}

8 Use Case 0E: Values Inquiry (TX #212) RESPONSE. In this example, there is a policy-level restriction on fund transfer (ReasonCode = "Not Authorized"). In this example, the restriction is due to a lack of fund transfer authorization for the agent listed in the 212 request. In this case, the Agent Party should also be returned to better explain the reason for the restriction. Note the lack of the <Authorization> object in the response. Values_Inquiry_Response Response TransExeTime = 15:59:29-04:00, TransRefGUID = AB34391F-24AC-12ED-732A-B0B052D2F8E1, TransSubType = 21207, TransType = 212} : TransResult {ResultCode = {DistributorClientAcctNum = , HoldingTypeCode = : RestrictionInfo {RestrictionCode = , RestrictionReason = } : Relation {RelationRoleCode = Agent : Party {PartyTypeCode = 1} : Person : PartialIdentification {IdentificationPart = 0007, PartialIDType = 1}

9 Use Case 1A: A fund transfer PPfA showing the use of FeatureOptProduct.ArrSubType of (Speficied Amount Transfer). Candidate Source and Destination funds are specified with SourceInvestProduct and DestInvestProduct. The PPfA needs to indicate (in AllocTypeProduct) each combination of allocation types (dollars, percent, pro rata, etc.) that are allowed. 1A - Specifed Amount Transfer - PPfA : PolicyProduct : AnnuityProduct FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} SpecifiedAmountXfer : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 4, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 1, MinTransactionAmt = $500, ProductCode = SAFT} Amt-to-Amt : AllocTypeProduct {DestTransferAmtType = 2, SourceTransferAmtType = 2} Amt-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 2} Pct-to-Amt : AllocTypeProduct {DestTransferAmtType = 2, SourceTransferAmtType = 3} Pct-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 3} : SourceInvestProduct ProductCode = ABCDE} : DestInvestProduct ProductCode = VWXYZ}

10 Use Case 1B: A fund transfer request (TX #102) using the "Speficied Amount Transfer" sub-type of the Fund Transfer Arrangment. This option requires that the total amount of the transfer ($50,000) be stated in Arrangement.ModalAmt. To illustrate how the allocation types work, I have elected to specify the source funds in dollar amounts, and the destination funds in percentages. 1B - Specified Amount - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = Note: The <TransRefGUID> for the Fund Transfer (TX #102) is different than the Values Inquiry (TX #212). However, the <CorrelationGUID> is the same. : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment Note: The <TransferAmt> elements of the ArrSource collection add up to the <ModalAmt> of the Arrangement ($50,000). Note: The <TransferPct> elements of the ArrDestination collection add up to 100%. : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ModalAmt = $50,000, ProductCode = SAFT, SourceTransferAmtType = 2} {TransferAmt = $20,000} {TransferAmt = $30,000} {TransferPct = 60%} {TransferPct = 40%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: The amount transferred to the PlayDoh fund will be $30,000 (60% of $50,000). Note: The amount transferred to the Frisbee fund will be $20,000 (40% of $50,000).

11 Use Case 2A: A fund transfer PPfA showing the use of FeatureOptProduct.ArrSubType of (Percent of CV Transfer). The presence of MinPct and MaxPct within the FeatureOptProduct indicates that Arrangement.ModalPct will be required. Candidate Source and Destination funds are specified with SourceInvestProduct and DestInvestProduct. This this scenario, the only allocation types that make sense are "Percent" and "Pro Rata Selected". 2A - Percent of CV Transfer - PPfA : PolicyProduct : AnnuityProduct FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} PercentOfCVXfer : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 4, MaxPct = 100%, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 1, MinPct = 5%, ProductCode = PCVFT} ProRata-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 4} Pct-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 3} : SourceInvestProduct ProductCode = ABCDE} : DestInvestProduct ProductCode = VWXYZ}

12 Use Case 2B: A fund transfer request (TX #102) using the "Percent of Contract Value" sub-type of the Fund Transfer Arrangment. This option requires that the contract value percentage (19%) be stated in Arrangement.ModalPct. Based on the Values Inquiry response from Use Case 0B, this would imply a transfer of $16, (19% of $86,107.96). To illustrate how the allocation types work, I have elected to remove this amount PRO RATA from the selected source funds, and deposit it into the destination funds based on percentages. 2B - Percent of CV - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment : Annuity Note: When a <SourceTransferAmtType> of "Pro Rata" (4) is used, neither <TransferAmt> nor <TransferPct> is specified. Note: The amount transferred from the Gumby fund would be $ , calculated as: * Gumby / (Gumby + YoYo) : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ModalPct = 19%, ProductCode = PCVFT, SourceTransferAmtType = 4} {TransferPct = 75%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: The amount transferred from the YoYo fund would be $12,463.68, calculated as: * YoYo / (Gumby + YoYo) {TransferPct = 25%} Note: The <TransferPct> elements of the ArrDestination collection add up to 100%. Note: The amount transferred to the PlayDoh fund would be $12, (75% of $16,360.51). Note: The amount transferred to the Frisbee fund would be $ (25% of $16,360.51).

13 Use Case 3A: A fund transfer PPfA showing the use of FeatureOptProduct.ArrSubType of (Fund Balance Transfer). Candidate Source and Destination funds are specified with SourceInvestProduct and DestInvestProduct. Note that neither MinTransactAmt nor MinPct/MaxPct are specified for the FeatureOptProduct. In this scenario, the allocation types that make sense are "percent" and "amount" for the source, and "percent" and "pro rata" for the destination. 3A - Fund Balance Transfer - PPfA : PolicyProduct : AnnuityProduct FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} Amt-to-ProRata : AllocTypeProduct {DestTransferAmtType = 4, SourceTransferAmtType = 2} FundBalanceXfer : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 4, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 1, ProductCode = FBFT} Amt-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 2} Pct-to-ProRata : AllocTypeProduct {DestTransferAmtType = 4, SourceTransferAmtType = 3} Pct-to-Pct : AllocTypeProduct {DestTransferAmtType = 3, SourceTransferAmtType = 3} : SourceInvestProduct ProductCode = ABCDE} : DestInvestProduct ProductCode = VWXYZ}

14 Use Case 3B: A fund transfer request (TX #102) using the "Fund Balance" sub-type of the Fund Transfer Arrangment. In this use case, I have elected to move all of the money out of the Frisbee fund, and deposit it pro-rata into Gumby and YoYo. 3B - Fund Balance - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment Note: When a <DestTransferAmtType> of "Pro Rata" (4) is used, neither <TransferAmt> nor <TransferPct> is specified. : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 4, ProductCode = FBFT, SourceTransferAmtType = 3} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: The amount transferred to the Gumby fund would be $ , calculated as: * Gumby / (Gumby + YoYo) Note: The amount transferred to the YoYo fund would be $19,798.14, calculated as: * YoYo / (Gumby + YoYo) {TransferPct = 100%} Note: In order to completely liquidate a fund, an allocation PERCENT must be used. An AMOUNT cannot be used. Note: The amount transferred from the Frisbee fund would be $25, (100%).

15 Use Case 3C: A fund transfer request (TX #102) using the "Fund Balance" sub-type of the Fund Transfer Arrangment. In this use case, I have elected to move 10% of the balance of the Gumby fund and 15% of the balance of Yoyo fund, and deposit it equally between the PlayDoh and Frisbee funds. 3C - Fund Balance - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment Note: When the ArrSubType is "Fund Balance Transfer" (27), the SOURCE <TransferPct>'s do NOT need to add to 100%. That is because these percentages are interpreted to be relative to each fund's balance, not the total transfer amount. Note: The amount transferred from the Gumby fund would be $1, (10% of $14,319.69). : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ProductCode = FBFT, SourceTransferAmtType = 3} {TransferPct = 10%} {TransferPct = 15%} {TransferPct = 50%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: The amount transferred from the YoYo fund would be $6, (15% of $45,800.12). {TransferPct = 50%} Note: Even though the ArrSubType is "Fund Balance Transfer" (27), the DESTINATION <TransferPct>'s still need to add to 100%. That is because these percentages are interpreted to be relative to the total transfer amount. Note: The amount transferred to both the PlayDoh and Frisbee funds would be $ , calculated as: 50% of ( ).

16 Use Case 4A: A fund transfer PPfA showing the use of FeatureOptProduct.ArrSubType of (Full Rebalance). Note that neither MinTransactAmt nor MinPct/MaxPct are specified for the FeatureOptProduct. In this scenario, only Destination funds are specified with DestInvestProduct. In this scenario, the only allocation types that make sense are "Percent" (3) and "Standing Allocations" (10). 4A - End Result Transfer - PPfA : PolicyProduct : AnnuityProduct FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} PercentOfCVXfer : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 0, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 0, ProductCode = FRBFT} PctRebal : AllocTypeProduct {DestTransferAmtType = 3} StndAlloc : AllocTypeProduct {DestTransferAmtType = 10} : DestInvestProduct ProductCode = VWXYZ}

17 Use Case 4B: A fund transfer PPfA showing the use of InvestProductExclude to make this option unavailable. In this scenario, there is a Fixed Fund (ProductCode = "FIXED1") with which this FeatureOptProduct is unavailable. 4B - End Result Transfer - PPfA : PolicyProduct : AnnuityProduct FT : FeatureProduct {ArrType = 1, FeatureCode = FT, FeatureMappingCode = 89} : ExclusionInvestProduct ProductCode = FIXED1} PercentOfCVXfer : FeatureOptProduct {ArrSubType = , MaxNumDestinationInvestProd = 3, MaxNumSourceInvestProd = 0, MinNumDestinationInvestments = 1, MinNumSourceInvestments = 0, ProductCode = FRBFT} PctRebal : AllocTypeProduct {DestTransferAmtType = 3} ExclusionInvestProduct references funds that make this FeatureOptProduct unavailable. FixedFunds : DestInvestProduct ProductCode = FIXED1} VariableFunds: DestInvestProdu ct ProductCode = VWXYZ}

18 Use Case 4C: A fund transfer request (TX #102) using the "Full Re-Balance" sub-type of the Fund Transfer Arrangment. In this use case, I decided to completely reorganize my portfolio so that the final result looks like: Gumby - 10%, Yoyo - 20%, PlayDoh - 30%, and Frisbee - 40%. This is sometimes referred to as an "End Result" transfer. 4C - Full Rebalance Pct - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment Note: After the rebalance, the Gumby fund would have a balance of $8, (10% of $86,107.96). Note: After the rebalance, the Yoyo fund would have a balance of $17, (20% of $86,107.96). : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ProductCode = FRBFT} {TransferPct = 10%} {TransferPct = 20%} {TransferPct = 30%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: After the rebalance, the PlayDoh fund would have a balance of $25, (30% of $86,107.96). {TransferPct = 40%} Note: After the rebalance, the Frisbee fund would have a balance of $34, (40% of $86,107.96).

19 Use Case 4D: A fund transfer request (TX #102) using the "Full Re-Balance" sub-type of the Fund Transfer Arrangment. In this use case, I decided to rebalance my portfolio back to my "Standing Allocations" (on record with the carrier). 4D - Full Rebalance StdAlloc - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 10, ProductCode = FRBFT} Note: After the rebalance, the Gumby fund would have a balance of $0 (as it is not referenced in the standing allocations). Note: After the rebalance, the Yoyo fund would have a balance of $64, (75% of $86,107.96). Note: After the rebalance, the PlayDoh fund would have a balance of $21, (25% of $86,107.96). Note: After the rebalance, the Frisbee fund would have a balance of $0 (as it is not referenced in the standing allocations).

20 Use Case 5A: Fund Transfer (TX #102) Day-1 PENDING response. In the response message, the receiver will return <ResultCode> element to indication the status of the processed transaction. In this example, the fund transfer request has passed the carrier's day-one edits, and is queued for processing tonight. In this case, the TX102 response contains a "Pending" (3) <ResultCode>. Fund_Transfer_Response Response TransExeTime = 15:59:29-04:00, : TransResult {ResultCode = 3}

21 Use Case 5B: Fund Transfer (TX #102) Day-1 FAILURE response. In the response message, the receiver will return <ResultCode> element to indication the status of the processed transaction. In this example, the fund transfer request has FAILED the carrier's day-one edits, and thus is rejected and will NOT be processed. In this case, the TX102 response contains a "Failure" (5) <ResultCode>. The <ResultInfo> collection will indicate the specific problem(s) that caused the request to fail. In this example, the error is that the "Frisbee Fixed" fund is the source fund for an active SDCA arrangement, and the original request did not adjust or terminate the SDCA (reject code 2015). Fund_Transfer_Response Response TransExeTime = 15:59:29-04:00, : TransResult {ResultCode = 5} Note: When the <ResultCode> is "Failure" (5), the response should echo the <OLifE> element from the original TX102 request. This is necesary to support references from the <ResultInfo> element(s) : ResultInfo {ResultInfoCode = 2015, ResultInfoDesc = "Blah, blah, blah..."} : Policy PolNumber = AK, {HoldingTypeCode = 2} Note: Standard Usage is not well-established. DTCC IFT WG will need to determine guidelines for its use. : Investment : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 4, ProductCode = FBFT, SourceTransferAmtType = GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} {TransferPct = 100%}

22 Use Case 5C: Fund Transfer (TX #102) Day-1 PENDING WITH INFO response. In the response message, the receiver will return <ResultCode> element to indication the status of the processed transaction. In this example, the fund transfer request has PASSED the carrier's day-one edits, and has been queued for processing that night. However, there is something about the request that the carrier would like to bring to the FA's attention. In this case, the TX102 response contains a "Pending With Info" (4) <ResultCode>. The <ResultInfo> collection will indicate the specific issue(s) that the carrier would like to communicate to the distributor. In this example, the issue is that there is a limit to the number of "free" transfers per month, and the owner has exceeded that limit (and thus will be subject to a transfer fee of $35). ::TXLife Fund_Transfer_Response ::TXLifeResponse TransExeTime = 15:59:29-04:00, ::TransResult {ResultCode = 4} Note: When the <ResultCode> is "Pending w/info" (4), the response should echo the <OLifE> element from the original TX102 request. This is necesary to support references from the <ResultInfo> element(s) ::OLifE : ResultInfo {ResultInfoCode =????, ResultInfoDesc = "Subject to $35 fee."} ::Policy PolNumber = AK, ::Holding {HoldingTypeCode = ::Investment ::Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 4, ProductCode = FBFT, SourceTransferAmtType = 3} ::ArrDestination ::ArrSource GumbyFund ::SubAccount ProductCode = GUMBY} YoYoFund ::SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} FrisbeeFixed ::SubAccount {CarrierCode = WHAMO, ProductCode = 180G} ::ArrSource {TransferPct = 100%}

23 Use Case 6A: Fund Transfer (TX #102) Day-2 SUCCESS response. In the response message, the receiver will return <ResultCode> element to indication the status of the processed transaction. In this example, the fund transfer request was processed successfully in the overnight batch run. In this case, the day-2 TX102 response contains a "Success" (1) <ResultCode>. Fund Transfer Response Response TransExeDate = , TransExeTime = 03:15: , : TransResult {ResultCode = 1} Note: the <CorrelatationGUID> and <TransRefGUID> match those of the original TX #102 request. Note: All responses from the prior night's processing should be "batched" together in a single XML document with a single <TXLife> element. Each individual response will be contained within a separate <TXLifeResponse> element.

24 Use Case 6B: Fund Transfer (TX #102) Day-2 FAILURE response. In the day-2 response message, the receiver will return <ResultCode> element to indication the status of the processed transaction. In this example, the fund transfer request has FAILED during the carrier's batch cycle, and thus was rejected and NOT processed. In this case, the TX102 response contains a "Failure" (5) <ResultCode>. The <ResultInfo> collection will indicate the specific problem(s) that caused the transfer to fail in batch. In this example, the pending transaction was cancelled by the owner (outside of the IFT automated system). (Code: ) Fund Transfer Response Response TramsExeTime = 03:15: , TransExeDate = , : TransResult {ResultCode = 5} : ResultInfo {ResultInfoCode = , ResultInfoDesc = "Cancelled by Mr. Doe"} Note: Normally in TXLife, a failure response will echo the <OLifE> element from the original TX102 request. However, in the DTCC IFT implementation, this will not be done (in order to keep the size of the day-2 responses small). Note: Both "success" and "failure" responses should be sent together.

25 Use Case 7A: A fund transfer request (TX #102) that illustrates how to TERMINATE an in-force Arrangement. Consider the original use case 3A (move all of the money out of the Frisbee fund, and deposit it pro-rata into Gumby and YoYo.) That use case would be NIGO, becasue the Frisbee fund is the source fund for the SDCA arrangement. One way to resolve this conflict is to terminate the SDCA arrangement (shown here). 7A - Terminate Arrangement- TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment SDCA : Arrangement {ArrSubType = 3, ArrType = 2, EndDate = , ModalAmt = , ProductCode = SDCA12} : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 4, ProductCode = FBFT, SourceTransferAmtType = 3} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} Note: In order to terminate an in-force arrangement, the arrangement's identifying information <ProductCode> must be provided, along with an <EndDate> equal to the TXLifeRequest's <TransExeDate>. Additional details about the arrangement (ArrSource, ArrDestination) are not required. {TransferPct = 100%}

26 Use Case 7B: A fund transfer request (TX #102) that illustrates how to ADJUST an in-force Arrangement. Consider this use case: move all of the money out of the Frisbee fund, and deposit it into the PlayDoh fund. This use case would be NIGO, becasue the Frisbee fund is the source fund for the SDCA arrangement. One way to resolve this conflict is to change the source fund of the SDCA from Frisbee to PlayDoh (shown here). 7B - Adjust Arrangement- TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment SDCA : Arrangement {ArrSubType = 3, ArrType = 2, EndDate = , ModalAmt = , ProductCode = SDCA12} : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ProductCode = FBFT, SourceTransferAmtType = 3} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} {TransferPct = 100%} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} {TransferPct = 100%} Note: In order to adjust an in-force arrangement, the arrangement's identifying information <ProductCode> must be provided, along with a new picture of what the arrangement's allocations (ArrSource and ArrDestination) should look like. In this example, the DCA source fund is changed from Frisbee to PlayDoh.

27 Use Case 7C: A fund transfer request (TX #102) that illustrates how to CONFIRM an in-force Arrangement. Consider the original use case 3C (move 10% of the money from the Gumby fund, and 15% from the YoYo fund.) If the in-force policy had a Systematic Withdrawal arrangement that used Gumby and YoYo as source funds, the TX102 must reaffirm the desire to continue the SW feature using those funds (or else the FT request is NIGO). 7C - Confirm Arrangement - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment SW : Arrangement {ArrSubType = 4, ArrType = 38, EndDate = , ProductCode = SWSA05, SourceTransferAmtType = 3} {TransferPct = 40%} {TransferPct = 60%} FT : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ProductCode = FBFT, SourceTransferAmtType = 3} {TransferPct = 10%} {TransferPct = 15%} {TransferPct = 50%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} {TransferPct = 50%} Note: To confirm the continuation of an arrangement whose source or destination funds have been affected by the fund transfer, the message should identify the arrangement <ProductCode>, reiterate the <EndDate> as unchanged (from the Values Inquiry), and reconfirm the fund allocations (ArrSource and/or ArrDestination).

28 Use Case 7D: A fund transfer request (TX #102) that illustrates how to also change Standing Allocations. Consider the original use case 4C (Full Rebalance to specified percentages). If the FA also wants to reconfigure the policy's Standing Allocations to those percentages, then a Standing Allocatoin arrangement (ArrType = 31) should be included that references the same funds and percentages. 7D - Adjust Standing Allocs - TX102 Request PendingResponseOK = TRUE, TransExeTime = 15:59:23-04:00, TransMode = : Policy PolNumber = AK, {HoldingTypeCode = 2} : Investment STDALLOC : Arrangement {ArrSubType = 21, ArrType = 37, DestTransferAmtType = 3, ProductCode = STDALC} : Arrangement {ArrSubType = , ArrType = 1, DestTransferAmtType = 3, ProductCode = FRBFT} {TransferPct = 10%} {TransferPct = 20%} {TransferPct = 30%} {TransferPct = 10%} {TransferPct = 20%} {TransferPct = 30%} GumbyFund : SubAccount ProductCode = GUMBY} YoYoFund : SubAccount {CarrierCode = DUNCAN, ProductCode = BFLY1} PlayDohFund : SubAccount {CarrierCode = HASBRO, ProductCode = YUMMY} FrisbeeFixed : SubAccount {CarrierCode = WHAMO, ProductCode = 180G} {TransferPct = 40%} {TransferPct = 40%} Note: Standing Allocations are not automatically changed when a Fund Transfer is requested. To also change the Standing Allocations, an explicit request must be included in the Fund Transfer message.

29 Use Case 8A: A request to cancel a pending Fund Transfer request (TX#102). In this use case, a prior TXLife Request has already been submitted, and the carrier responded with "Pending" (3). Now, be FA has changed their mind, and wishes to cancel the request before it is processed. A cancellation request must be time stamped before market close (4:00pm), and must be received by the carrier before the original request is actually processed. 8A - Cancellation Request - TX102 Request PendingResponseOK = FALSE, TransExeTime = 15:59:23-04:00, TransMode = 6, Note: To cancel a pending fund transfer request, submit a TX #102 <TXLifeRequest> containing the same <TransRefGUID> as the original TXLife Request, and a <TransMode> value of "Cancel" (6). This is a real-time request, to which the carrier will respond either "success" (transaction cancelled) or "failure" (transaction couldn't be cancelled).

30 Use Case 8B: A positive response to a request to cancel a pending Fund Transfer request (TX#102). Assuming the cancellation request is in good order, the carrier will respond "Success" (1), which is interpreted to mean: "Pending Transaction Cancelled". 8B - Cancellation Resonse Success - TX102 Response TransExeTime = 15:59:23-04:00, TransMode = 6, : TransResult {ResultCode = 1} Note: To acknowledge the successful cancellation of a pending TX102 transaction, respond with <ResultCode> of "success" (1).

31 Use Case 8C: A negative response to a request to cancel a pending Fund Transfer request (TX#102). If the cancellation request is NIGO, the carrier will respond "Failure" (5), which is interpreted to mean: "Pending Transaction CANNOT be Cancelled". The response will also include the reason why the transaction could not be cancelled. 8B - Cancellation Resonse Success - TX102 Response TransExeTime = 16:01:19-04:00, TransMode = 6, : TransResult {ResultCode = 5} : ResultInfo {ResultInfoCode = 2040, ResultInfoDesc = "Sorry, that train already left..."} Note: To reject the cancellation of a pending TX102 transaction, respond with <ResultCode> of "failure" (5). Also provide the reason why the transaction could not be cancelled.