IFT Fund Transfers

Summary of Requirements

AFFIRM wants to provide Broker Dealer customers with the ability for their Financial Advisors to perform Fund Transfer requests on behalf of their clients, without the need to call Carriers for information about contract eligibility or execution of the Fund Transfer transaction.

The focus of this effort is to implement new self-service automated Fund Transfer program functionality that will enable Financial Advisors to process Fund Transfer requests electronically for an existing annuity contract. The Fund Transfer transaction will be integrated into an Inforce Transaction platform that will later include other features like Asset Rebalancing, DCA, and policy level change transactions.

This InForce Transaction platform is available for the users via integration into the Contract Values Utility screen. The iPipeline base system will be modeled after industry standards developed in conjunction with distributors, carriers, and the DTCC. The Fund Transfer initiate transaction will be automated and supported on the iPipeline platform based upon a range of eligibility standards.

The users will initiate the Fund Transfer transaction using the AFFIRM system by selecting the desired policy from the Book of Business and navigating to the Contract Values Utility screen. The FA will validate the contract desired is eligible for a transaction and launch a Values Inquiry (VI) call through DTCC to the carrier to obtain the most up-to-date contract information, including Fund Transfer options available.

From here, the FA will be able to select and execute the applicable transaction as allowed and modeled in the Carrier PPFA thus triggering alerts and approval process prior to submission to carrier through DTCC. The Carrier then processes this transaction at their end and informs the distributor once the change is complete.

All Annuity policies can be populated in Book of Business search, however, only those policies eligible for Fund Transfer will be allowed to be selected by the user to initiate the transaction from the Contract Values Utility screen. Eligibility will be defined by PPFA, DPfA and VI.

PPfA, Values Inquiry Response, and Shell Rider Restrictions Determine Available Funds 

PPfA

The PPfA includes the “superset” of product funds that are available for use in transactions for contracts.

• PPfA SourceInvestProduct is the list of funds that can be specified as a transfer source for a feature.
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/SourceInve stProduct
• PPfA DestInvestProduct is the list of funds that can be transferred into for a feature.
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/DestInvest Product
  • Note: For Fund Transfers, funds selected as sources on the prior Current Allocation screen will NOT be included as possible destination funds for the transfer.

21207 Response

Fund information for a policy is returned in the DTCC 21207 response. The funds in the response will be a subset of the funds listed in the PPfA.

• /TXLife/TXLifeResponse/OLifE/Holding/Investment/SubAccount
  • Information found here includes:
    • ProductFullName
    • TotValue
    • TransferSendAllowedInd
    • TransferDestAllowedInd
• There are infrequent instances where a fund can be returned in the 21207 response, even though it does not exist in the PPfA.
  • If the fund does not have a dollar value, it will not be displayed in AFFIRM.
  • If the fund does have a dollar value, the fund and value information will display in AFFIRM, but user input for these values is disabled.
  • NOTE: When the data is pulled from the 21207 response, it will be different from the PPfA data. These rows could appear differently (examples include some missing data values, or data appearing in all caps).

Rider Restrictions

Shell Riders can be used within the PPfA to specify:

• Asset Allocation Models containing collections of funds
• Restrictions for ArrSubType actions (ex. Fund Transfer subtypes) via FeatureOptProduct ProductCode conflicts

Shell Riders for Asset Allocation Models, Complex Allocations

AFFIRM will determine what subaccounts and min/max amounts are available in categories for complex allocations. AFFIRM will look at the 21207 VI response and any complex allocations will be returned within:

• Holding/Policy/Annuity/Rider/RiderCode

If there is a shell feature for the fund restrictions related to the complex models (in the example PPfA images the ProductCode=IFIRN and IFIRY) must be modelled in the FeatureTransactionProduct as a ProductCode. The example below shows them modelled for Asset Rebalancing Arrangement:

AFFIRM will next check against the PPfA looking at:

• OLife/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/ProductCode

In this example, possible RiderCode values that could have the model restrictions:

• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=215]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=336]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=204]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=202]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=206]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=2067/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=210]/FeatureOptProduct/ProductCode
• OLife/PolicyProduct/AnnuityProduct/FeatureProduct[RiderCode=211]/FeatureOptProduct/ProductCode

If there is a ProductCode that matches (IR21 in this case) AFFIRM will look in the PPfA to find ProductCode values that exist within any RequisiteInvestProduct values for that code:

• OLife/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/RequisisteInvestProduct/ProductCode

The ProductCode values within the RequisiteInvestProduct (in the example above, LBYO_IR21_2N and LCYO_IR21_2N) are matched against values in the PPfA at:

• OLife/InvestProduct/ProductCode

These funds will be Models. For each model, find what funds are available for investment in that model by looking within the product code:

• OLife/InvestProduct/ProductCode=LCYO_IR21_2N/InvestProductInfo

The model level is where any MinDepositPct and MinDepositPct limits exist for each model. Only percentages will be supported by AFFIRM for minimums and maximums for Asset Rebalancing and Fund Transfers (complex allocations are not supported for Fund Transfer Dollar-to-Dollar transactions).

In the screenshot below LCYO_IR21_2N has an InvestProductInfo with a ProductCode of a fund category:

And looking within IR21_2N_100 shows what funds are truly available under this model. This example would have 35 funds that then need to match against the 21207 response subaccounts:

The above example would cause display of one subaccount column that has 35 investment options that can be up to 100% invested.

The same thing is done for the other fund LBYO_IR21_2N and this model has two different ProductCode values:

Following the same logic, look at IR21_2N_20 and IR21_2N_80 in InvestProduct/ProductCode to find out the InvestProductInfo values available:

After looking through the complex allocations here there would be two different models. The user would need to choose one of the models to work within AFFIRM.

• Model 1 – LCYO_IR21_2N/IR21_2N_100 – 35 funds where the user can have 0-100% invested.
• Model 2 – LBYO_IR21_2N/IR21_2N_20 – 10 funds where the user can have 20-100% invested. If this model is used for investment, the user must invest 20% at minimum.
• Model 2 – LBYO_IR21_2N/IR21_2N_80 – 66 funds where the user can have 0-80% invested. If this model is used for investment, the user can invest 80% as a maximum.

Finally, AFFIRM checks the 111 funds against the 21207 response to confirm they are returned as subaccounts. If a fund is included in the 21207 VI response, it will be displayed as a subaccount in the AFFIRM IFT screens. A fund in the PPfA but not included in the 21207 VI response will not be displayed in AFFIRM.

Since AFFIRM is looking for available funds to match in three places (PPfA within FeatureOptProduct, 21207 Response, PPfA for Complex Allocations), AFFIRM will not check ExclusionInvestProduct for restrictions.

Shell Riders as Restrictions for Feature SubTypes

Shell Riders can also serve the purpose of restricting feature subtypes. Below is an example of how this is done.

Since AFFIRM is looking for available funds to match in three places (PPfA within FeatureOptProduct, 21207 Response, PPfA for Complex Allocations), AFFIRM can find restrictions modeled in the PPfA in the FeatureOptConflict.

• In the PPfA, the FeatureTransactionProduct for TransType=102 (fund transfer for this example) can have FeatureCode entries to specify shell riders for restrictions.
  • These will have no ActionTypeAllowed entries; these are shell riders.
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureTransactionProduct/FeatureProductInfo/FeatureCode
  • Example below shows two, “IFIRN” and “IFIRY”.

• These FeatureCodes will appear in the FeatureProduct
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureCode

• For each FeatureCode, the FeatureOptProduct will contain a ProductCode list. One of these ProductCode entries will match the RiderCode from the VI.
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/ProductCo de
  • In our example, “IR08” is found in “IFIRN”:

• Within that ProductCode will be a FeatureOptConflict list. The conflicts that apply will include the FeatureCode of the FeatureProduct, and the ProductCode of the FeatureOptProduct. When these match on a feature and option, that option should be restricted.
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/FeatureOp tConflict/FeatureCode
  • /TXLife/TXLifeRequest/OLifE/PolicyProduct/AnnuityProduct/FeatureProduct/FeatureOptProduct/FeatureOp tConflict/ProductCode
  • In our example, IR08 has conflicts for FeatureCode IFT and FeatureProducts DDFT and PPFT:

• We see that these match the Fund Transfer Options for Percent to Percent (27) and Dollar to Dollar/Percent (29).
• Therefore, the dropdown options for 27 and 29 (both) would be restricted in this case and should not appear in the dropdown.

Scope

The system and party scope includes AFFIRM, DTCC, Carriers, and iPipeline. Below is a high-level summary of business requirements for IFT entry:

1. User should not be required to initiate a specific IFT transaction (ACORD 21207 in the case of Fund Transfer) in order to obtain and view latest contract values provided from the DTCC POV file.
2. To start any in-force transaction, the latest contract details, rules, and values need to be obtained from carriers.
   1. For standard implementation, contract information will be retrieved via DTCC IFT Web service transactions using Values Inquiry (VI) services. This is an ACORD 21207 needed for a Fund Transfer transaction.
3. Retrieved contract information in conjunction with PPfA and DPfA should drive available IFTs and options.
   1. For instance, PPfA, DPfA and VI response will determine if a Fund Transfer via AFFIRM™ is supported for a given client and contract and will specify what type of Fund Transfer options are allowed and can be presented to the end-user.
4. Contract details and PPfA rules should drive IFT entry.
   1. For example, PPfA may specify min/max amounts for funds within models.
5. Started IFT transactions should remain in and be accessible from the user’s “IFT Dashboard”.

Fund Transfer Configuration and Administration

Forms Support – Adding support for Fund Transfer Forms

The DTCC Fund Transfer tx102 transaction does not support attachments. This decision was made years ago by DTCC after carriers expressed no need at the time for attachments with the transaction. AFFIRM started development with the idea that carriers would actually need form support in cases where there isn’t a signature on file for the Distributor; however the only way to support this at the present time would be implementation of the DTCC attachment service. This integration is deferred functionality for now.

However, AFFIRM will still support the inclusion of forms for a Fund Transfer transaction. Such forms will be displayed for the user on the Forms/Submit screen, but they will not be transmitted to the DTCC with the tx102 message for a Fund Transfer.

Fund Transfer Hierarchy Settings

• EnableFundTransfer – Boolean (0,1) – Distributor has IFT Fund Transfer functionality available in AFFIRM or not.

Fund Transfer Subscription Settings

• AffirmFundTransferCanSubmit – Boolean (0,1) – Allows a Distributor user to submit IFT Fund Transfer transactions in NGEN screens. Other data can be modified and entered, but the user can only submit if this subscription is True.
• FundTransferReadOnly – Boolean (0,1) – Allows a read-only view of IFT Fund Transfer transaction data in NGEN screens for a Distributor user.
• IFTPostSubmitEvent – String – This is the name of the event for the Distributor that will run and handle the review status of the transaction. It is typically set to Annuity_Order_FlagForReview.
• FundTransferAlwaysEnabled – Boolean (0,1) – Carrier setting when testing in Pilot regions. Carrier has IFT Fund Transfer functionality available in AFFIRM or not.
• Order.SubmitAction.SkipApproval – Boolean (0,1) – Distributor requires approvals on transactions or not. Applies to IFT.
• NotifySupportOnSubmitFailure – Boolean (0,1) – Distributor setting to send a message to support when a DTCC transmission fails. In addition to the value = 1, the Distributor must have the email template set up for the message to be sent. Applies to all IFT.
• TryResend105107 – Integer – Number of times a retry will happen for a Distributor when a DTCC transmission fails. The name indicates 105 and 107, but it applies to all IFT.
• UpdateOrCancelIFT – Boolean (0,1) – Distributor is permitted to do update or terminate actions on IFT
• VICallEndTime – DateTime (HH:MM:SS) – Time in EST the Get Latest Values button becomes unavailable in CVU screen. Default 19:00:00 based on DTCC availability for VI requests.
• VICallStartTime – DateTime (HH:MM:SS) – Time in EST the Get Latest Values button becomes available in CVU screen. Default 07:00:00 based on DTCC availability for VI requests.
• WithdrawalApplyWetSign – Boolean (0.1) – Distributor requires upload of wet signature documents for IFT. The name indicates Withdrawals, but it applies to all IFT.
  • Note: The Fund Transfer tx102 message does not support attachments, so no forms can be sent to DTCC for a Fund Transfer at this time. Enabling the upload of a wet signed form will NOT allow it to be transmitted to the carrier.
• WithdrawalEditEndTime – DateTime (HH:MM:SS) – Time that edit of existing IFT arrangement becomes unavailable in the IFT dashboard. Default 19:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalEditStartTime – DateTime (HH:MM:SS) – Time in EST edit of existing IFT arrangement becomes available in the IFT dashboard. Default 07:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalEndTime – DateTime (HH:MM:SS) – Time in EST the IFT action to initiate transaction becomes unavailable in the CVU screen. Default 19:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalMaxPendingApprovalHours – Integer – Amount of time after submission and before approval, if necessary. Default 24 hours. If not approved in this amount of time, the job will auto cancel (64) the transaction. The hours are counted against business days only, not weekends or holidays. Job must be configured per distributor and must run every 5-10 minutes. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalPendingCarrierProcessingCancelEndTime – DateTime (HH:MM:SS) – Time that cancel of transmitted order becomes available in the IFT dashboard. Default 07:00:00 based on DTCC availability for accepting cancellation requests. A cancellation can only be sent on the same day that the initial transaction was sent. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalPendingCarrierProcessingCancelStartTime – DateTime (HH:MM:SS) – Time in EST that cancel of transmitted order becomes unavailable in the IFT dashboard. Default of 16:00:00 based on DTCC availability for accepting cancellation requests. A cancellation can only be sent on the same day that the initial transaction was sent. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalStartTime – DateTime (HH:MM:SS) – Time in EST the IFT action to initiate transaction becomes available in the CVU screen. Default 07:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalSubmissionEndTime – DateTime (HH:MM:SS) – Time in EST that user can no longer submit a transaction for approval or transmission (click Submit button). Default 19:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. Also the cutoff time for order to change to “Transaction Expired” (64/1000300092) if not submitted. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalSubmissionStartTime – DateTime (HH:MM:SS) – Time in EST that user can submit a transaction for approval or transmission (click Submit button). Default 07:00:00 based on DTCC availability for accepting VI requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalTransmissionEndTime – DateTime (HH:MM:SS) – Time in EST that job stops picking up transactions for transmission to carrier via DTCC by AFFIRM. Default 16:00:00 based on DTCC availability for accepting 105/107 requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.
• WithdrawalTransmissionStartTime – DateTime (HH:MM:SS) – Time in EST that job starts to pick up transactions for transmission to carrier via DTCC by AFFIRM. Default 07:00:00 based on DTCC availability for accepting 105/107 requests. DTCC business days (non-weekends, non-DTCC-holidays) only. The name indicates Withdrawals, but it applies to all IFT.