THIS MATERIAL HAS NOT BEEN REVIEWED, APPROVED, OR AUTHORIZED BY THE TREASURY DEPARTMENT OR THE INTERNAL REVENUE SERVICE AS MEETING THE REQUIREMENTS OF ANY APPLICABLE RULES OR REGULATIONS. THE SPARK INSTITUTE DOES NOT PROVIDE LEGAL ADVICE. USERS OF THIS MATERIAL SHOULD CONSULT WITH THEIR LEGAL COUNSEL BEFORE RELYING ON IT.

TECHNICAL ISSUE 1 - OBSOLETE (January 28, 2010)

TECHNICAL ISSUE 2 - OBSOLETE (January 28, 2010)

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 - OBSOLETE (January 28, 2010)

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 a future release of the Data Elements. 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-case basis. (September 2, 2008; revised January 28, 2010 to reflect that this change will be made in a future release.)

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:  OBSOLETE (January 28, 2010)

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:  OBSOLETE (January 28, 2010)

Question 8:  The "Type of Account" field (Part II, Section A) 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). (September 16, 2008; revised January 28, 2010 by deleting a sentence that limited the scope of when to use the Best Practices.)

Question 9:  OBSOLETE (January 28, 2010)

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).(September 16, 2008; revised January 28, 2010 to remove references to the DTCC.)

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). (September 16, 2008; revised January 28, 2010 to remove references to the DTCC.)

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. Typically most firms will use a CR-LF to start the next row of data. To get a better understanding of the data layout please review the "Best Practices for file sharing". (September 16, 2008; revised January 28, 2010 by adding the last two sentences.)

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, 8-13. 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; revised January 28, 2010 by updating Section references to conform to Version 1.04 of the Best Practices.)

Question 14:  OBSOLETE (January 28, 2010)

Question 15:  OBSOLETE (January 28, 2010)

Question 16:  OBSOLETE (January 28, 2010)

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. 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

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:  OBSOLETE (January 28, 2010)

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:  OBSOLETE (January 28, 2010)

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:  OBSOLETE (January 28, 2010)

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:  OBSOLETE (January 28, 2010)

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: OBSOLETE (January 28, 2010)

NOTE – The following Distribution Types were added after this question was originally answered: 07 – Death, 08 – Disability, 09 – RMD, and 10 – QDRO (January 28, 2010)

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:  The following Distribution Types were added after this question was originally answered: 07 – Death, 08 – Disability, 09 – RMD, and 10 – QDRO (December 19, 2008; revised January 28, 2010)

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)