Technical Questions and Answers Regarding
The SPARK Institute’s 403(b) Plans Information Sharing –
Minimum and Comprehensive Data Elements

(Version 1.03, dated December 5, 2008)

(Q&A Last Updated - March 24, 2009)

Following the release of Version 1.01 of The SPARK Institute’s Information Sharing – Minimum and Comprehensive Data Elements (the “Data Elements”), The SPARK Institute received a number of technical questions. The SPARK Institute has formed a standing panel, made up of representatives from various member companies that played a significant role in developing the Data Elements. The SPARK Institute and the panel reviewed the questions and developed answers which are posted below. This information is being made widely available in order to assist all others that are adhering to the Data Elements Best Practices.

Please note: the most current version of the Best Practices is Version 1.03 (dated December 5, 2008) and is available here.

The SPARK Institute will maintain this site and update it periodically with answers to questions it receives. We encourage 403(b) plan providers and employers who have questions about the Data Elements to submit their questions to us at data-elements.questions@sparkinstitute.org. Please include information for us to be able to contact you if necessary when you submit your questions. Questions submitted to us will be reviewed by the panel, and answered through this Q&A site to the extent possible. Please note that we are unable to answer legal questions or provide guidance with respect to company or plan specific issues and situations.

The SPARK Institute received a significant number of questions regarding the Best Practices from companies that are actively developing systems to follow them. As with most technology initiatives, during the development and implementation process certain issues have been raised that The SPARK Institute, based on the advice of the working team, has decided warrant technical corrections. Certain technical corrections are noted immediately below and others are identified in specific questions that raised the issues that warranted the corrections. For example, see Question 15 and 20.

IMPORTANT TECHINCAL CORRECTIONS

TECHNICAL ISSUE 1 - Part II, Section A and Part IV, Section A both include a field for an “Employee Account Number.” However, the maximum field length for each of the two fields is not the same.

TECHNICAL CORRECTION 1 - The maximum field length for the Employee Account Number under Part IV, Section A  has been changed to 25 to conform to the same maximum field length identified under Part II, Section A. This change is effective immediately and has been included in the Technical Correction Version 1.02 of the Best Practices document available from The SPARK Institute at: http://www.sparkinstitute.org/comments-and-materials.php. Service providers and employers are encouraged to inform their business partners of this Technical Correction. (October 29, 2008).

TECHNICAL ISSUE 2 - How does the Depository Trust & Clearing Corporation’s (DTCC) decision to place their 403(b) plan project on hold through the end of 2008 impact The SPARK Institute Information Sharing Best Practices?

TECHNICAL CORRECTION 2 - The SPARK Institute has revised the Best Practices by eliminating all of the provisions that were added specifically for the DTCC project. The work that was done will be preserved for later use as needed. Questions related to the DTCC specific provisions that were submitted to The SPARK Institute will not be addressed at this time. A copy of the Best Practices document reflecting this Technical Correction is available from The SPARK Institute at: http://www.sparkinstitute.org/comments-and-materials.php. Service providers and employers are encouraged to inform their business partners of this Technical Correction. (October 29, 2008).

TECHNICAL ISSUE 3 - The SPARK Institute had previously responded to a question regarding the indicator that should be used in the “Type of Account” field (Part II, Section A) for a 403(b)(9) retirement income account. In light of the need to make other technical corrections to the Best Practices, we have taken the opportunity to resolve this issue now.

TECHNICAL CORRECTION 3 - The value “009” has been added to the “Type of Account” data element in the release of the Best Practices to identify retirement income accounts established by churches. A copy of the Best Practices document reflecting this Technical Correction is available from The SPARK Institute at: http://www.sparkinstitute.org/comments-and-materials.php. Service providers and employers are encouraged to inform their business partners of this Technical Correction. (October 29, 2008).

TECHNICAL ISSUE 4 - What other general technical changes or corrections have been made to the Best Practices?

TECHNICAL CORRECTION 4 - The Best Practices now include a Version Control Log in Appendix A. In addition to changes described within these Q&As, the following changes have been made in Version 1.02:

• Reporting of 403(b)(7) Cash Value is only required for Account Type “008” (combination of 403(b)(1) and 403(b)(7) accounts.
• Clarification of Hardship Reporting.
• Clarification of Loan Reporting, including a requirement to always provide loan component data if there have been any outstanding (active/defaulted) or paid off loans during the last 12 months. Addition of the ability for a vendor to report a “Summary” set of loan component records for all outstanding or paid off loans during the prior 12 months.
• Correction of the Section Name and Data Type for Part III data.
• Addition of the “Vendor Source ID” to the data elements reportable for “Distributions Made” data.

Question 1:  The Deferral Limit Monitoring/415 Limit Monitoring Data Elements (Part II, Section B) does not appear to include a field for year-to-date post-tax contributions. Can this field be added to help facilitate compliance testing for plans that allow post-tax contributions?

Answer 1:  The Deferral Limit Monitoring/415 Limit Monitoring Data Elements do seek year-to-date employee and year-to-date employer contributions. However, the comments to the year-to-date employee contributions data field describe only those contributions that are subject to the 402(g) limit (i.e. employee pre-tax and Roth contributions). Based on the experience of the members of the working team that developed the Data Elements, we understand that non-Roth post-tax contributions are not very common. We note that Basic Data Elements (Section II, Part A) includes a field for post-tax cash value. The SPARK Institute will add a new year-to-date, non-Roth post tax contribution field in Section II, Part B in the next release of the Data Elements. However, as we indicated on July 12, 2008, in conjunction with the release of the Best Practices and Data Elements, no additional changes will be made to the Data Elements (version 1.01) prior to January 1, 2009. Accordingly, anyone that offers or provides services to a plan that allows post tax contributions should take note of this issue and take whatever steps they deem necessary to address this issue on a case-by-base basis. (September 2, 2008)

Question 2:  What indicator should be used in the “Type of Account” field (Part II, Section A) for a 403(b)(9) retirement income account?

Answer 2:  Please see Technical Issue and Correction 3. (October 29, 2008).

Question 3:  What indicator should be used in the “Type of Account” field (Part II, Section A) for the various forms of 457 plans?

Answer 3:  All 457 plan types, including 457(b) and 457(f) plans, can be coded as “457” account types. (September 2, 2008)

Question 4:  What is the purpose of the data in Part III entitled Census Data Format with Remittance Data?

Answer 4:  Part III sets forth data standards for existing census and remittance processing. It is intended to identify data that vendors may need to allocate remittances and provide a method in which vendors could receive census data from employers. While developing the Data Elements, at the request of certain members, The SPARK Institute working team took the opportunity to also document the data fields commonly used to allocate remittances and process census data. Please note that the census and remittance data are not new data types and their inclusion in the Best Practices document is not intended to imply that such information must be shared in order to comply with the 403(b) plan regulations. Additionally, the inclusion of these additional best practices is not intended to create an expectation that 403(b) information sharing processes or services will adhere to these practices on January 1, 2009. (September 2, 2008)

Question 5:  How are after-tax contributions (without earnings) and Roth contributions (without earnings) identified or handled in the Data Elements in order to help with the calculation of basis and the remaining amount available for hardship from a Roth contribution account, as may be necessary.

Answer 5:  The members of the working team considered these points of information and evaluated them in the context of the core functionality that is necessary by January 1, 2009 and likelihood that vendors would support Roth hardship functionality. The team also considered the importance of Roth after-tax hardship functionality relative to more common issues that needed to be addressed in order to develop the Best Practices in a timely manner and in order to facilitate the timely development of core functionality by vendors. Ultimately, these Roth after-tax hardship issues were not specifically addressed in the Best Practices. We also note that the IRS' model plan language avoided the issue altogether by leaving out Roth features.

Additionally, based on information from members of the working team it is our understanding that if a participant has multiple Roth accounts within the same Plan (i.e., accounts with more than one Roth account with more than one vendor), the vast majority of vendors will not be willing or able to take responsibility for aggregating amounts across vendors for purposes of determining earnings and basis. Accordingly, this issue may be handled by most employers with Roth features in their plans by simply providing that Roth amounts are not available for hardship distributions. (September 2, 2008)

Question 6:  What amount should be provided in any of the “Cash Value” data fields?

Answer 6:  “Cash Value” is referred to in multiple places throughout the Best Practices document. The amount that should be provided in the fields that refer to Cash Value is the total value without any reduction for surrender charges or other fees. Examples of such fields include, but are not limited to the following: Employer Cash Value, EE Cash Deferral Value, Rollover EE Pre-Tax Cash Value, Rollover EE Post Tax Cash Value, Rollover Roth Cash Value, EE Post Tax Cash Value and Roth 403(b) Cash Value. (September 2, 2008)

Question 7:  Is the current version of the DTCC’s 403(b) Information Sharing Client Users’ Guide (Draft Version 1.1 – Last Update August 12, 2008) correct in stating that the Latest Hardship Distribution Date is required when the Latest Distribution Type is "NO" meaning no hardship has been taken in the last 12 months? See DTCC 403(b) Information Sharing Client User Guide, Section D at page 36.

Answer 7:  See Technical Issue and Correction 2 (October 29, 2008) 

Question 8:  The "Type of Account" field (Part II, Section A, see page 11) of the Best Practices includes indicators for 401(a), 401(k) and 457 plans. When would the information regarding such non-403(b) plans be shared?

Answer 8:  Information regarding any non-403(b) plans accommodated in the “Type of Account” field would be provided only in instances where such other plan is related to a 403(b) plan of a common employer (e.g. Hospital XYZ has both a 403(b) and 401(k) plan). The Best Practices are only intended to address circumstances where a 403(b) plan is obligated to share information under the applicable regulations. (September 16, 2008)

Question 9:  What value should be reported for the "Roth 403(b) Cash Value" under Section A of Part II of the Best Practices when reporting for a 401(a), 401(k) or 457 “Type of Accounts”?

Answer 9:  Report "0.00" for non-403(b) plans. (September 16, 2008)

Question 10:  Why is certain hardship related information reported under Part II, Section D (see page 14), and under Part IV, Section A of the Best Practices?

Answer 10:  There is no intended interface between the Hardship data recorded in these two separate sections as each field serves a different purpose. Within the Best Practices, the fields in Part II, Section D are either required or conditional to administer Hardships whereas the fields in Part IV, Section A are optional to merely notify others that a Distribution (of some type) has been made. While the Best Practices separated the data required to Administer Hardships (Part II, Section D) from the optional “Distributions Made” data (Part IV, Section A), the DTCC User Guide placed the “Distributions Made” data fields (their Section H) immediately following their other data elements required to administer Hardships, which has led to some confusion. We have informed the DTCC about this. (September 16, 2008)

Question 11:  Why is certain loan related information reported in Part II, Section G and under Part IV, Section A of the Best Practices?

Answer 11:  There is no intended interface between the Loan data recorded in these two separate sections as each field serves a different purpose. Within the Best Practices, the fields in Part II, Section G are either required or conditional to administer Loans whereas the fields in Part IV, Section A are optional to merely notify others that a Distribution (of some type) has been made. While the Best Practices separated the data required to administer Loans (Part II, Section G) from the optional “Distributions Made” data (Part IV, Section A), the DTCC User Guide placed the “Distributions Made” data fields (their Section H) immediately following their other data elements required to administer Loans, which has led to some confusion. We have informed the DTCC about this. (September 16, 2008)

Question 12:  Are the data records in the Data Elements file layout terminated by a CR-LF or LF? If not, does each record have a specific byte size?

Answer 12:  The file is not a fixed length and there is no end of record marker. The record length is variable and the last field can be identified by counting the number of delimiters. (September 16, 2008)

Question 13:  How should certain information that is not available on the reporting company’s system be reported in the applicable fields?

Answer 13:  Please see the information provided in Part I of the Best Practices, particularly Items A, 7-10 on pages 1 and 2. In addition to the foregoing, the Best Practices state how to report the information for each specific field. We note that a required field cannot be reported as “Null.” When an optional field has a value of NULL, it is reported with two delimiters with no embedded space, as “||” (September 16, 2008)

Question 14:  What will be the FILE NAMING standard for files coming from DTCC to plan sponsors, TPAs, and other interested parties?

Answer 14:  See Technical Issue and Correction 2 (October 29, 2008)

Question 15:
Part A - What amount should be reported in the "Maximum Loan Amount Available" field under Part II, Section G of the Best Practices?

Answer 15, Part A: The Maximum Loan Amount Available has been clarified and re-named in The SPARK Institute’s Technical Correction to the Best Practices (released and dated October 29, 2008) as “Maximum Loan Amount Eligible-Vendor” to be the maximum loan amount available after the vendor has applied all IRS, plan, product or fund rules, with these exceptions:

1. Any remaining loan balances should not be subtracted from the calculated MLAE-Vendor amount
2. If the plan or product limits the total number of outstanding and/or defaulted loans, and that maximum has been reached, the vendor should NOT replace with $0.00, the calculated MLAE-Vendor amount. The calculated amount should be reported.
3. Likewise, if the plan or product limits the frequency in which loans can be taken (e.g. no new loan can be taken within 6 months of an earlier loan being issued) and the loan request is within that period, the vendor should NOT replace with $0.00, the calculated MLAE-Vendor amount. The calculated amount should be reported.

Please refer to the following document for examples regarding reporting loan amount available data. Click Here (October 29, 2008)

Answer 15, Part B - No, see above exceptions. (October 29, 2008).

Question 16:  If the "Method of Reporting Loan Data" under Part II, Section G of the Best Practices is coded as “M” (i.e., meaning that the “Maximum Loan Amount Eligible-Vendor” is reported as a summary), what amount should be reported in the "Highest Outstanding Loan Balance-12 Months" field?

Answer 16:  The Best Practices have been revised such that Loan Component data is always required (Method = “C”) if there have been any loans (active, defaulted or paid off) during the prior 12 months. The Best Practices now accommodate, if necessary, the reporting of summarized loan data in a single set of loan component data elements. Detailed loan data for each loan is preferred but vendors can report a summary for all loans (active, defaulted or paid off) if they are unable to provide the detailed data, loan by loan. The “Highest Outstanding Loan Balance-12 months” is one of the loan components required. It is either the value for a specific loan if each loan is being reported, or if summary loan data is being reported, the aggregated sum of the highest outstanding loan balance for all loans outstanding (active/defaulted) or paid off during the prior 12 months. (October 29, 2008).

Question 17:  How should certain fields that are indentified as “required” information be reported when the information is not available on the reporting company’s system?

Answer 17:  Every “required” field must be reported with a valid value as indicated in the “Comments” column of the Best Practices document. For example, the default value for "required" currency fields is "0.00". The SPARK Institute team concluded that using “0.00” as the default for required currency fields would result in the most conservative decision regarding a loan request and, if necessary, the reporting company and receiving company would communicate directly (not electronically) and as needed to address any issues or inaccuracies such an assumption might create. Please see Question and Answer 13 from September 16, 2008 regarding the protocol for reporting unavailable “optional” fields. (October 29, 2008).

Question 18:  As a vendor, we want to send one file for each plan and identify the plan in the file name or “Header Record.” Is this acceptable? Also, can you confirm the contents by record type of a typical file?

Answer 18A:  No, aggregators and other vendors will not be able to recognize a plan’s identity from the file name or the file Header Record. The Best Practices anticipate vendors sending data on a single file that pertains to many plans. The standards identified a file naming convention to identify the Vendor (or Employer or Aggregator) and the date/time the file was created (see Part I, Section A4). Within the detail records on the file, the plan identity must be specified as either the Aggregator Plan ID or the Employer Plan ID if no aggregator has been selected (see Part II, Section A. Basic Account Data fields). Additionally, Part I, Section B of the Best Practices discusses the records. (October 29, 2008).

Answer 18B:  Part I, Section B of the Best Practices discusses the anticipated contents of a file. (Note that DTCC records will no longer be needed). In a simple case where data from a single vendor is being reported, the record types would be:

• SPARK Institute Header for Data Type “01” (Account Data)
• SPARK Institute format Account detail records (Section A, B, C….through G as needed)
• SPARK Institute Trailer for Data Type “01” data
• SPARK Institute header for Data type “02” (Distributions Made data)
• SPARK Institute format Distributions Made detail records
• SPARK Institute Trailer for Data Type “02” data (October 29, 2008)

Question 19:  Have you addressed fees at all in light of the Schedule C and H requirements? There may be fees withheld on certain distributions and there was no ‘place holder’ to identify those. This will be important too in completing information for Schedules C and H for the new 5500 filing requirement.

Answer 19:  The Information Sharing Data Standards have been established for administering Hardships and Loans across vendors.  Preparation of Schedule C and H is not within the scope of this initiative. (October 29, 2008).

Question 20:  Please clarify the definition of “Gross” and “Net” in the “Cash Value Type” field in Part II, Section A of the Best Practices.

Question 21:  Please provide clarification as to when header and trailer records should be sent. Should one header and one trailer be sent per file or one each per ‘Data Type’?

Answer 21:  Header and Trailer records should surround each Part (record type) of the Industry Best Practices data type shared. To clarify, the Parts include:
Part II (Data Type = 01) – Data Sharing Elements for Vendor File Account Point-in-Time Detail Records
and
Part IV (Data Type = 02) - Data Sharing Elements for Employer or Employer Representative (Aggregator) Distributions Made by Vendors. (October 29, 2008).

Question 22:  X Fund Company will only provide account data (data type 01) and distributions data (data type 02). We do not have any census (data type 03) or remittance data (data type 04) to provide. Should we only send records with data types 01 and 02 or must the other data types be sent with null values?

Answer 22:  Yes, send only data types 01 and 02; some vendors will only be required by their Employers to supply Account data (type 01) as this is the minimum data needed to administer Hardships and Loans; some vendors will also be required to share Distributions Made data (Type 02) if a specific Employer requires this. (October 29, 2008).

Question 23:  What is the intended or recommended frequency for transmitting this data?

Answer 23:  This question is addressed in The SPARK Institute’s Information Sharing Technology Best Practices document (Version 1.0) dated September 4, 2008. See Section G, which states that the preferred current best practices standard specifically with respect to sharing point in time data is that it would be shared with and among those who are expressly authorized by the employer to receive the information, at least monthly, except as otherwise directed by the employer. Whether the point in time information that is shared is for all or some of the participants will be determined on a case by case basis depending on who the information is going to and employer directions. (October 29, 2008).

Question 24:  How should the “Employer EIN” be reported when the service provider does not capture the information? Should this field be null or left blank?

Answer 24:  This field is necessary to “tie together” related plans of the same Employer but is not otherwise required. NULL or blank are acceptable. (October 29, 2008).

Question 25:  Please explain how to format “Pipe Delimited” data?

Answer 25:  Please refer to the following document regarding Coding "Pipe Delimited" Data.  Click Here (October 29, 2008).

Question 26:  The Header File specified in Part I, Section C of the Best Practices does not include a file description literal along with a Data Type value but both are referenced in Part III, Sections A and B in regards to Census Data (e.g. "04-Remittance"). Is this a misprint, or does the Data Type also refer to the "Data Source" field?

Answer 26:  The Header Record layout described in Part I, Section C requires that the Data Type (for any section of data being reported) be identified solely as a two digit code (e.g., 04). It does not also require a literal description as was unintentionally implied in Part III, Sections A and B. Data Source is a completely distinct field that identifies the entity sending the data regardless of the data type. (December 1, 2008).

Question 27:  Has the rolling 12 months rule been changed in Part II, Section D relating to Hardship Amount Available Data?

Answer 27:  No, the rule was not changed. Hardship information reported in Part II, Section D should be limited to hardships which have been taken within the last rolling 12 months. The foregoing text was omitted inadvertently in the last release of the Best Practices and will be reinserted in the next release. (December 1, 2008).

Question 28:  In Part II, Section G (Loan Amount Available Data) of Version 1.02 of the Best Practices field "Filler1" replaced the field called "Date of Last Loan Distributed." The Best Practices now state that this field “is no longer needed here as this data [i.e., loan issue data] is now required within the loan component data.” How do you identify or locate the date of last loan distributed information under this methodology?

Answer 28:  The "Date of Last Loan Distributed" is no longer required under the Best Practices and the field was redefined as "Filler1". The “Date of Last Loan Distributed” can be derived from the "Loan Initiation Date” component data, i.e., the latest loan initiation date among all the loan components reported is the Date of Last Loan Distributed”. (December 1, 2008).

Question 29:  Should the “Cash Value Date” be the position date of the extracted data?

Answer 29:  The "Cash Value Date" represents the Trade Date or Valuation Date used to calculate the Cash Value fields reflected in the data file. (December 1, 2008).

Question 30:  One of the hardship distribution types is “U = Unknown”. When this code is used does it mean that a hardship distribution has been taken; however, the reason for the distribution is unknown?

Answer 30:  Yes. (December 1, 2008).

Question 31:  How should the following field be populated if we do not have the necessary data available?

Part II, Section E - Employer Contribution Restriction Grandfathering Data (for 403(b)(1) Annuity Contracts Only) Answer 31-1: NULL values must be reported.

Answer 31-1:  NULL values must be reports.

Part II, Section F - Non-Emergency Withdrawal Data (for 403(b)(1) Annuity Contracts Only)

Answer 31-2:  NULL values must be reports.

Part III, Section A - Census Data Format with Remittance Data

Answer 31-3:  Do not report any Type = 04 data records.

Part III, B. Census Data Format Without Remittance Data

Answer 31-4:  Do not report any Type = 03 data records.

(December 1, 2008).

Question 32:  What are the high level qualifiers and/or data fields that will be used amongst providers and aggregators to match and aggregate plan level data?

Answer 32:  For plans where an aggregator is identified: The Aggregator Plan ID.

Question 33:  Basic Account Data record – Field “Employee Deferral Cash Value” (Part II, Section A): The instructions in the Best Practices refer to “Pre-Tax or Salary Deferral Contributions.” Does that mean Roth amounts should also be included and reported in this field?

Answer 33:  The Employee Deferral Cash Value field should reflect only the current value of Employee Pre-Tax monies (excluding rollover money and Roth assets). (December 2, 2008).

Question 34:  Basic Account Data record – Field “Rollover Employee Pre-Tax Cash Value” (Part II, Section A): The instructions in the Best Practices say “This does not include Roth 403(b) rollovers that can be tracked with Rollover Roth Cash Value.” Does that mean for a non-403b plan (i.e., 401k) the field should include Roth rollover values?

Answer 34:  All rollover cash values should be reported regardless of the type of account (i.e., 403(b) as well as non-403(b) accounts). The “Rollover Employee Pre-Tax Cash Value” field only includes pre-tax balances; therefore any Roth Rollover sources should be reported in the “Roth Rollover Cash Value” field. (December 2, 2008).

Question 35:  Should the "403(b)(7) Cash Value" field in Part II, Section A be reported as the total cash value of a 403(b)(7) custodial account (Type of Account = "007") and/or the cash value of the monies from 403(b)(7) custodial account(s) previously exchanged into a 403(b)(1) annuity contract for accounts as Type of Account = "008"? If the field is intended to refer to Type of Account "008", how should the cash values be reported (i.e., Employee and Employer or Employer only)?

Answer 35:  Note that the previously named “403(b)(7) Cash Value" field in Part II, Section A has been renamed to “403(b)(7) Employer Cash Value” to clarify its use. This should be populated if the Type of Account = "008". For this type of account, the “403(b)(7) Employer Cash Value” is a subset of the “Employer Cash Value” (reported separately) consisting of the 403(b)(7) Employer amounts if your recordkeeping system combines (b)(1) and (b)(7) information in the Employer Cash Value field or if any (b)(7) Employer dollars have been exchanged into a 403(b)(1) account. Any account that has combined (b)(1) and (b)(7) monies should be reported as Type of Account = 008. This “403(b)(7) Employer Cash Value” amount should be excluded when summing cash value fields to arrive at a total cash value for the account. The loan examples that were posted on our website on November 10, 2008 have been revised accordingly. For any Type of Account other than "008" this cash value field should reflect a default value of "0.00". (December 5, 2008)

Question 36:  Basic Account Data record – Fields “Rollover Roth Cash Value” and “Roth 403(b) Cash Value” (Part II, Section A): How should these fields be populated in connection with a 403(b) plan and any other plan that allows Roth Rollovers?

Answer 36:  "Rollover Roth Cash Value" should reflect the current value of the account's Rollover Roth source(s) regardless of the Type of Account (i.e., 403(b) as well as non-403(b) accounts). However, for the field that is currently labeled "Roth 403(b) Cash Value", it should only reflect the value of Roth contributions (i.e., employee Roth contributions) and should NOT include Roth Rollover amounts since such amounts are intended to be reported in a separate cash value field. Equally important is that the field currently labeled "Roth 403(b) Cash Value” applies to any Type of Account (i.e., 403(b) as well as non-403(b)). In order to minimize potential confusion due to the label assigned to this field, The SPARK Institute is releasing Version 1.03 of the Best Practices in which the field previously called Roth 403(b) Cash Value has been renamed as “Roth Cash Value” and its definition clarified. The loan examples that were posted on our website on November 10, 2008 have been revised accordingly. The file structure for Part II of the guidelines remains unchanged. The Best Practices document is available on The SPARK Institute website at: http://www.sparkinstitute.org/comments-and-materials.php. (December 5, 2008)

Question 37:  Basic Account Data record – “403(b)(7) Cash Value” field (Part II, Section A): If the plan is a 403(b)(7) type should this field and the “Employee Deferral Cash Value” field (Part II, Section A) be populated? Also, if there are Roth monies in the 403(b)(7) account, should they be included in the “403(b)(7) Cash Value” field? Your instructions just say to include “employee and employer.”

Answer 37:  Note that the previously named “403(b)(7) Cash Value" field in Part II, Section A has been renamed to “403(b)(7) Employer Cash Value” to clarify its use. The “Employee Deferral Cash Value” field should be reported regardless of the Type of Account. The “403(b)(7) Employer Cash Value” field should be reported if the Type of Account = "008" (combination 403(b)(1) and 403(b)(7) account). The “403(b)(7) Employer Cash Value” field itself represents the 403(b)(7) subset of the Employer Cash Value for a combination account or the Employer dollars that were part of a prior exchange from a 403(b(7) to a 403(b)(1) account. For any Type of Account other than "008" the “403(b)(7) Employer Cash Value” field should reflect a default value of "0.00". Since this “403(b)(7) Employer Cash Value” field applies strictly to 403(b)(7) Employer cash value, Roth monies would not be included in this field. (December 5, 2008)

Question 38:  Should the “403(b)(7) Cash Value” field (Part II, Section A) include Roth accounts as well as traditional 403(b) accounts?

Answer 38:  Note that the previously named “403(b)(7) Cash Value" field in Part II, Section A has been renamed to “403(b)(7) Employer Cash Value” to clarify its use. The “403(b)(7) Employer Cash Value” field should be reported if the Type of Account = "008" (combination 403(b)(1) and 403(b)(7) account). The “403(b)(7) Employer Cash Value” field itself represents the 403(b)(7) portion of Employer cash value for a combination account or the Employer dollars that were part of a prior exchange from a 403(b(7) to a 403(b)(1) account. For any Type of Account other than "008" the “403(b)(7) Employer Cash Value” should reflect a default value of "0.00". Since this “403(b)(7) Employer Cash Value” field applies strictly to 403(b)(7) Employer cash value, Roth monies would not be included in this value. (December 5, 2008)

Question 39:  The comments section for the “Distribution Type” field in Part IV, Section A of the Best Practices states the following:

Type of Distribution Made,
• 01 - (Contract) Exchange
• 02 - Hardship Withdrawal
• 03 - In Service Withdrawal
• 04 - Loan
• 05 - Rollover
• 06 - Separation from Service

Answer 39, Part A:  Any rollover distribution as defined by the IRS should be coded as an “05 – Rollover” distribution.

Part B: We have several other types of distributions that are not specifically covered in your definitions. Does this mean that we should not report these types of distributions? Some examples are dividend payments, return of excess contributions, death, and QDROs.

Answer 39, Part B: The Best Practices are intended to cover only those distributions that must be reported to comply with the new regulations. For example, QDROs would not be reported. (December 5, 2008)

Question 40:  In Part II, Section A of the Best Practices, when the Cash Value Type is “N”, (implying that the Aggregator, or Employer if there is no Aggregator, will add outstanding and/or defaulted loan balances to the Cash Value amount to derive the Gross Total Account Cash Value), should the loan balance amount added be equal to the amount provided in the “Remaining Loan Balance Component” which includes principal and unpaid interest, or should the loan balance added to the Cash Value just represent the outstanding loan balance principal only?

Answer 40: Principal and all interest outstanding (when applicable and reflected in the “Remaining Loan Balance Component”) should be added to the Net Cash Values to arrive at the Gross Cash Value for the account. (December 5, 2008)

Question 41:  The comments section for the “Distribution Type” field in Part IV; Section A of the Best Practices includes a code “01 - (Contract) Exchange.” Is that code intended to apply to an exchange between providers of the same employer?

Answer 41: Yes. This applies to intra-plan contract exchanges between providers of the same employer. (December 18, 2008)

Question 42:  Part I, Section A of the Best Practices, and Q&A 25 on The SPARK Institute website describes and provides examples for formatting pipe delimited numeric fields. None of the examples show leading zeros in the format (e.g., "|98765.42| versus |00098765.42|. Are leading zeros acceptable?

Answer 42: Reported amounts or values that are less than the maximum length of a field do not require leading zeros. The intent is for numeric fields to be variable lengths and thus leading zeros are unnecessary. Accordingly, none of the examples show leading zeros. We note however that certain numeric fields should be fixed length (e.g., dates and social security number). Whether or not leading zeros will be accepted by a particular vendor will depend on the vendor. Please refer to Part I, Section A of the Best Practices, and Q&A 25 on The SPARK Institute website describes and provides examples for formatting pipe delimited numeric fields. (December 18, 2008)

Question 43:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. If this distribution data is provided daily then based on the data components in the Best Practices there appears to be no provision to report more than one distribution event per day per participant account. If more than one reportable distribution event occurred on the same day what distribution event should we report?

Answer 43: Each “Distributions Made” event is reported separately and only once. When two distributions are made on the same date, they should be reported using two “Distributions Made” records, even if they are for the same “Distribution Type”. (December 18, 2008)

Question 44:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. Is there an expectation that if this distribution data is to be provided on a frequency other than daily (e.g. monthly) that the data reported has to be cumulative for the period? If so, is it acceptable to create a full set of distribution data for each occurrence of a distribution if a participant had more than one in that period of time? The guidelines should be clearer on that point.

Answer 44: Each “Distributions Made” event should be reported separately and only once. When two distributions are made on the same date, they should be reported using two Distributions Made records, even if they are for the same “Distribution Type”. For example, if two loan distributions are made on November 1st and November 15th and the vendor reports data monthly as of November 30th, then two separate “Distributions Made” records, both with “Distribution Type” = 04 (Loan) should be reported. These would not be reported again. (December 18, 2008)

Question 45:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. The current definition of Distribution Date is "Effective date of the distribution". Could you elaborate more on what "effective date" means? Is it Trade Date or Process Date, for example?

Answer 45: The date that should be reported for the “Distribution Date” is the Trade Date of the distribution. However, we note that the distribution’s “process date” should be considered when determining whether a distribution itself should be reported for a particular timeframe. If Trade Date alone is used for this reporting consideration any distributions that were back dated would never be reported. (December 18, 2008)

Question 46:  Part I, Section A. 10 of the Best Practices it states "The "Distributions Made" data now allows for a negative amount to be reported, indicating that a Distribution has been reversed". However, there was no specific explanation on how the negative sign should be reflected in the field (i.e. should a negative amount appear like this |-12345.67| or |12345.67-|? Further, it would appear that a negative sign would appear to take up a position in the field. If that's the case, then the actual maximum amount that could be reported based on current field length would be "9999999.99" and not "99999999.99" as is the case for any other amount or cash value field. If a negative sign is intended to reflect a reversal of a distribution and accounted for in the field length then should a normal distribution also have to reflect a sign (i.e., positive)? Regardless, there is a question of whether a reversal of a distribution should reflect a positive sign rather than a negative since distributions inherently a deduction of monies from an account (i.e., negative money out) and a reversal is a restoration of monies from a prior distribution (i.e., positive money in).

Answer 46: A distribution that has been reversed would be reported with a leading negative sign (e.g. |-12345.67|. The negative sign will take up a reportable position so the maximum amount of a distribution reversal would be |-9999999.99|. It is not necessary to utilize a positive sign (+) to denote a normal distribution. (December 18, 2008)

Question 47:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. For the Distribution Amount field should this be considered the Gross Amount before any deduction of fees and charges?

Answer 47: The Distribution Amount that should be reported is the Gross Amount. (December 18, 2008)

Question 48:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. If a distribution was reversed and both events occurred in the same reporting period (e.g., over a month), is it necessary to report both events or could nothing be reported since the event is a wash?

Answer 48: There are two ways this situation can be reported. One alternative is that both the original distribution and its reversal that occurred in the same reporting period are reported. The other alternative is that neither the original distribution nor the reversal is reported since the net effect is that the distribution did not occur in the reporting period. The alternative used can be determined by the investment provider or aggregator based on their preferences and capabilities. (December 18, 2008)

Question 49:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. Starting in January 2009 if distribution data to be reported covered a period more than daily is there an expectation that distributions prior to 2009 must be reported?

Answer 49: This will be based on the needs of the Employer and/or Aggregator and the availability of the data. (December 18, 2008)

Question 50:  Part IV of the Best Practices deals with Distributions Made by Vendors Data. Why aren't triggering events like Attainment of age 59 1/2, Death and Disability also considered as valid Distribution Types? What about a plan termination?

Answer 50: These types of distributions are not specifically identified because it is our understanding that they do not impact compliance with the new 403(b) regulations. (December 18, 2008)

Question 51:  Date of Birth is considered a required field. If a participant account does not have a valid Date of Birth (i.e. none on record) what default value should be reflected in this field (i.e. a NULL value or a dummy Date of Birth)?

Answer 51: The unavailability or absence of a valid Date of Birth will require the use of a default value. Some suggested default values are “19000101” or “19010101”. Recipients of this data will need to be apprised of the use of the default value in order to ensure that the default value is recognized as such by the recipient and not confused for a valid date. (December 18, 2008)

Question 52:  How should the details in Part II, Section A to G of the Best Practices be reported?

Answer 52: All Part II data elements (Sections A to G) should be reported on a single line (variable length record) for each account reported. (December 18, 2008)

Question 53: The "File Layout" section of Version 1.03 of the Best Practices (Part 1, Section A, 1) states that "[t]he extract file should be an ASCII file that is pipe "|" delimited, with no spaces between the data element and pipe at either end." Should the first data field be enclosed with the PIPE character or not?

Answer 53: Please refer to the discussion of "Coding PIPE Delimited Data" on the SPARK Institute's website located here. Examples are shown for when the first data field has a value to be reported and when the first data field is NULL because no data is being reported. (February 3, 2009)

Question 54: Are the "Header" and "Trailer" supposed to use a pipe delimited format as is the case for other fields under the Best Practices?

Answer 54: Yes. Pipe delimited should be used for the Header and Trailer records. (February 3, 2009)

Question 55: How should loan component data be reported under Part II, Section G of the Best Practices if a participant has more than 99 loans?

Answer 55: Loans 1-98 should be reported using the set of loan component data for each loan in accordance with the guidelines in the Best Practices. For Loans 99 and above, the 99th set of loan component data should be used to summarize the loan information of the remaining loans. Please refer to Part II Section G of the Best Practices for additional details. (February 3, 2009)

Question 56: Method of Reporting Loan Data - Under Version 1.03 of the Best Practices and according to Technical Question and Answer 16 on The SPARK Institute website, it appears that "M" is only a valid selection for the "Method of Reporting Loan Data" when there are no loans, otherwise, "C" and the associated components are required. Is that a correct understanding of the Best Practices?

Answer 56: Yes. (February 3, 2009)

Question 57: Part II, Section D in Version 1.03 of the Best Practices relating to "Reporting Hardship Amount Available Data" allows for two reporting methods, i.e., "M" or "C". Another vendor has advised us that they will only accept reporting method "C" and the associated Hardship Components. Is the option for reporting the maximum hardship available (i.e., method "M") still valid or are changes pending to the Best Practices to parallel the ones for loans which will require the components reporting method?

Answer 57: The Best Practices state that hardship data may be reported using either the "M" method (Maximum Hardship Amount Available") or the "C" method (Hardship Amounts are reported in component fields and the Aggregator would perform the calculation to arrive at the Maximum Hardship Amount Available through simple addition and subtraction). Certain vendors may elect to take a more restrictive view regarding how they will report or accept information. (February 3, 2009)

Question 58: How should the contributions reported in the "Account Inception-to-Date EE Contributions" and "Account Inception-to-Date 15 Year Catch-Up Contributions" in Part II, Section B be reported, gross or net (of any related charges, fees or subsequent withdrawal amounts)?

Answer 58: The "Account Inception-to-Date EE Contributions" and "Account Inception-to-Date 15 Year Catch-Up Contributions" in Part II, Section B should be reported as gross amounts (i.e., not reduced by any related charges, fees or subsequent withdrawal amounts). (February 3, 2009)

Question 59: If the "Highest Outstanding Loan Balance 12-Months" data (Part II, Section G) is not available for each loan but is available at a summary level, can an additional record be added at the end of these fields with the summary loan information?

Answer 59: No. The Best Practices already provide a mechanism for reporting loan data in summary form within the component loan fields. Although the Best Practices state that the recommended reporting method is to report individual loans, the flexibility for summary reporting has already been built in. If a vendor is unable to report data on individual loans, the vendor can leverage the summary loan reporting methodology that is already provided for. (February 3, 2009)

Question 60: Please clarify what is intended to be included in certain employee cash value fields in Part II, Section A of the Best Practices.

Part A: “EE Deferral Cash Value” - Should the amount reported in this field be the total of all deferral amounts made only or should it also include earnings?

Answer 60, Part A: The “EE Deferral Cash Value” field represents the current value of Employee Pre-Tax investment source(s). The amount reported in this field should include the cumulative amount of money into and out of the specific investment source(s) and the associated earnings. Please see Question and Answer 6 for additional information. (March 6, 2009)

Part B: “Rollover EE Pre-Tax Cash Value” - Should the amount reported in this field include all rollover/transfer values?

Answer 60, Part B: The “Rollover EE Pre-Tax Cash Value” field represents the current value of Employee Pre-Tax Rollover investment source(s). The amount reported in this field should include the cumulative amount of money into and out of the specific investment source(s) and any associated earnings. Please see Question and Answer 6 for additional information. (March 6, 2009)

Question 61: Is the distribution data defined in Part IV of the Best Practices limited strictly to 403(b) plans or would it also include this data from any accounts of associated non-403(b) plans (i.e., 401(a), 401(k), 457)?

Answer 61: The distribution data defined in Part IV of the Best Practices applies to 403(b) plans as well as any associated plans of the type defined in the Best Practices (i.e., 401(a), 401(k), 457). (March 6, 2009)

Question 62: Should Distribution Amounts that are reported under the Best Practices appear as negative or positive numbers?

Answer 62: Even though a Distribution Amount may be represented as a negative number in the vendor’s administrative system (because it is a withdrawal), positive numbers should be used when reporting the Distribution Amount in the Best Practices format unless a reversal of a Distribution is being reported. If the information reported represents a reversed Distribution, then the Distribution Amount should be reported as a negative number (i.e., with a minus character in the first position). Please refer to the document, "How to Code PIPE Delimited Data" available here if you have any questions concerning the following examples. (March 6, 2009)

The following "Distributions Made" record reports a $50 distribution made by TPA1234

1. Aggregator Plan ID = NULL
   NOTE: : when the first data element is NULL, and the second data element has a value, the record begins with a single PIPE as the PIPE signals the end of a data element and the beginning of the next data element. Also note that no PIPE appears at the end of a record because no data element follows.
2. Employer Plan ID = 70847
3. Vendor Plan ID = 70847
4. Employee SSN = 459-70-4749
5. Employee Account Number = NULL
6. Vendor Transaction Number = NULL
7. Distribution Type = 03 (In-Service Withdrawal)
8. Distribution Date = 01/21/09
9. Distribution Amount = $50.00
10. Distribution Reason = HP (Home Purchase)
11. Vendor Source ID = TPA1234

The following record reports that a $50 Distribution was reversed

1. Aggregator Plan ID = NULL
2. Employer Plan ID = 70847
3. Vendor Plan ID = 70847
4. Employee SSN = 459-70-4749
5. Employee Account Number = NULL
6. Vendor Transaction Number = NULL
7. Distribution Type = 03 (In-Service Withdrawal)
8. Distribution Date = 1/23/09
9. Distribution Amount is a minus $50 indicating a reversal
10. Distribution Reason = HP (Home Purchase)
11. Vendor Source ID = TPA1234

Question 63: There appears to be a discrepancy between the “Vendor Source ID” field which is identified as an optional field under Part II, A of the Best Practices and the same data field which is identified as a required field under Part IV, A of the Best Practices? Please clarify whether the “Vendor Source ID” field is optional or required.

Answer 63: The “Vendor Source ID” field is intended to be an optional field in Part II and IV. This oversight will be corrected in a future version but should be treated as optional now. (March 24, 2009)

Question 64: Are the seven “Cash Value Amount” fields in Part II, Section A supposed to add up to the total cash value of the account (either Gross or Net, as specified)?

Answer 64: The seven cash value fields (i.e., Employer Cash Value, EE Deferral Cash Value, Rollover EE Pre-Tax Cash Value, Rollover EE Post-Tax Cash Value, Rollover Roth Cash Value, EE Post-Tax Cash Value, Roth Cash Value) in Part II, Section A of the current version of the Best Practices (Version 1.03) should add up to the total cash value of the participant’s account (either Gross or Net, as specified). Please note that the “403(b)(7) Employer Cash Value” would not be included in the calculation above because a different calculation applies under 403(b)(7) rules. Please click here for examples regarding reporting loan amount available data. (March 24, 2009)

Question 65: The examples provided on The SPARK Institute website for reporting the “Maximum Loan Amount Eligible” utilize 50% of the total cash value to arrive at this amount. Why doesn’t the calculation also consider the $50,000 limit so that the maximum amount is either 50% of the total cash value or $50,000, whichever is less?

Answer 65: The examples do not mention the $50,000 limit because the total cash value amount was less than $100,000 so it had no impact. The $50,000 limit should otherwise be taken into account as appropriate. Click here for examples regarding reporting loan amount available data. (March 24, 2009)