Technical Questions and Answers

Regarding

The SPARK Institute’s 403(b) Plans Information Sharing –
Minimum and Comprehensive Data Elements
(Version 1.02, dated October 29, 2008)

(Q&A Last Updated - October 29, 2008)

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.

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?

Part B - Should the amount that is reported in the "Maximum Loan Amount Available" field under Part II, Section G of the Best Practices be “0.00” if the maximum number of loans permitted has already been reached?

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)

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

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)