Introduction

PBGC’s premium e-filing application, My Plan Administration Account (My PAA) supports an XML specification that allows properly formatted filing data from an external source to be submitted to PBGC via My PAA. The information on this page is intended for private-sector software vendors/developers who wish to update their software to support premium e-filing using this XML specification.

Overview

• How Practitioners Submit Software-Prepared E-Filings to PBGC
• How Software Vendors/Developers Submit Draft Premium XML Files to PBGC for Review and Verification

PBGC Premium E-Filing Data Standards

• Premium e-filing XML specification  
• Paper Form field mapping to XML schemas:
  2007 Filings and 2008 Estimated Flat-rate filings  [PDF]
  2008 Comprehensive Filings (form code 325784)  [PDF]

Vendor/Developer Resources

• Sample PBGC Premium Filings in XML Format
• Testing XML files/Submission Validation Service (SVS) (http://validate.pbgc.gov/VendorValidator/)
• Tips for Creating PBGC Premium Filings in XML Format
• Additional Checks PBGC Does on Submitted Filings

Contact us

If you are a software vendor/developer and have questions about how to modify your product to integrate with PBGC’s requirements, please send any comments, suggestions and/or questions to the PBGC e-filing team at: softwareefiling@pbgc.gov

Overview

How Practitioners submit Software-Prepared E-Filings to PBGC 

• My PAA allows pension plan practitioners to submit premium filing information via data files that adhere to an XML specification published by PBGC in one of two ways:
• Import: A filer imports an XML file containing filing information for a plan in their account for plan years 2006 and later. Filers then use My PAA’s features to review, edit, sign, and submit each filing to PBGC. Each user who works on the filing must have an account in My PAA.
  
• Upload: A filer uploads, certifies, and submits an XML file containing complete filing information for up to approximately 100 filings, for plan years 2005 and later. Only the user uploading the file is required to have an account in My PAA; however, filers do not have the opportunity to make changes to the filing information in My PAA using this method.  

For more information about these premium filing options from the user’s perspective, review the Premium E-Filing Options found under the Practitioners Tab, Online Premium Filing section.

^ Top

How Software Vendors/Developers Submit Draft Premium XML Files to PBGC for Review and Verification

PBGC has established a review and verification process (outlined in three steps below) for private-sector software vendors/developers to follow. The purpose of this process is to ensure that the premium XML files produced by this software adhere to the PBGC defined standards and it requires vendors/developers to submit XML files that contain filing information for a variety of filing scenarios.

If the submitted XML files do not meet the standards, PBGC will provide vendors/developers with the resulting error messages and will provide any necessary assistance. If the XML files submitted by a software vendor/developer meet the standards, PBGC will assign a unique vendor identification number that must be included in all XML files created by a vendor’s/developer’s software.

Note: The assignment of this number simply means that the sample XML files submitted met the PBGC-defined standards. It does not mean that all XML files produced by a software product will be valid. For this reason, we strongly recommend that vendors/developers produce a wide variety of premium filing XML files and test them using the Schema Validation Service . See Sample PBGC Premium Filings in XML Format for more information about the types of filings premium filing software should be able to produce.

To receive a vendor identification number that is valid for submission of 2008 Comprehensive filings, the following types of filings must be submitted to PBGC for verification:

1. 2008 comprehensive filing for a single-employer plan that is exempt from the VRP
2. 2008 comprehensive filing for a single-employer medium or large plan that’s not exempt from the VRP
3. 2008 comprehensive filing for a single-employer small employer plan that qualifies for the VRP cap and is only paying the VRP cap (i.e., is not reporting the Unfunded Vested Benefit amount)
4. 2008 single-employer plan that’s eligible for the cap on the VRP and elects to provide the Unfunded Vested Benefit amount so that they can pay the lesser of the VRP based on Unfunded Vested Benefit amount calculation or based on the VRP cap
5. 2008 comprehensive filing for a multiemployer plan
6. 2008 comprehensive filing for which premium proration applies for both a single-employer and multiemployer plans

Below are the three steps for software vendors/developers to follow to send test premium filing XML files to PBGC for review:

Step 1: Once you have tested your XML files yourself using our Vendor Validator Web Service, (see Testing XML files / Submission Validation Service (SVS), you need to submit them to PBGC for review. When you are ready, send an e-mail to softwareefiling@pbgc.gov with the following information:

Step 2: PBGC will acknowledge receipt of submitted XML file(s) and provide verifications such as the following for each submission:

Step 3: PBGC will respond with XML file review results such as:

^ Top

PBGC Premium E-Filing Data Standards Premium e-filing XML Specification

These data standards are applicable to premium filings starting with the 2005 plan year. A premium filing submitted to PBGC via My PAA in XML format must adhere to the premium filing XML schema published by PBGC. A filing is composed of three core schemas:

Submission.xsd: This primary schema defines how a premium filing is considered complete and valid. All premium filing XML files will be validated against this document. Download Submission.xsd [ZIP]

SubmissionTypes.xsd: The data type definitions used throughout the schema definitions. Download SubmissionTypes.xsd[ZIP]

PremiumFiling.xsd: This document explains the element and format definitions for 2005-2008 estimated flat-rate filing data (equivalent to the paper form 1-ES), 2005 – 2007 final premium filing data (equivalent to the paper forms: Form 1-EZ, Form 1, and Form 1/Schedule A), and 2008 comprehensive filing data.  Download PremiumFiling.xsd [ZIP]

The form/filing types are defined by the presence of key elements within the schema:

• At the root level, the document defines PlanData and FilingData.
• Within PlanData, the date provided in PlanYearBeginDate identifies the Plan year of the filing.
• The FilingData element can and must contain one of two elements - EstimatedFilingData or FinalFilingData. The presence of the EstimatedFilingData element indicates an estimated flat-rate filing (Form 1-ES 2004 - 2008) while the presence of the FinalFilingData element represents a final filing (Form1, 1-EZ or Form 1 with Schedule A 2005 -2007) or a comprehensive filing (2008).
• Within the EstimatedFilingData element, the PremiumAmount element must contain either the SingleEmployerPremium element or the MultiemployerPremium; this defines the plan type for an estimated flat-rate filing.
• Within FinalFilingData, the FilingPlanType element must contain either the MultiEmployer element or SingleEmployer element; this defines the plan type for a final or comprehensive filing.
• Additional key elements define the filing further as described below:
   
• • A Comprehensive Filing (starting plan year 2008) is defined by the presence of a Plan Year Commencement date in PlanData. PlanYearBeginDate which includes 2008 as the year, and the presence of the FilingData.FinalFilingData element.
  • A final filing for a single-employer plan that’s exempt from VRP (Form 1-EZ for plan years 2005 - 2007) is defined by the presence of a PlanData.PlanYearBeginDate of 2005 – 2007, the SingleEmployer element in FilingData.FinalFilingData.FilingPlanType, and the presence of the Exempt element in the SingleEmployer.VariableRatePremiumData element.
  • A final filing for a multiemployer plan (Form 1 for plan years 2005 – 2007) is defined by the presence of a PlanData.PlanYearBeginDate of 2005 – 2007 and the presence of the MultiEmployer element in FilingData.FinalFilingData.FilingPlanType.
  • A final filing for a single-employer plan that’s not exempt from VRP Form 1/Schedule A (plan years 2005 – 2007) is defined by the presence of a PlanData.PlanYearBeginDate of 2005 – 2007, the presence of the SingleEmployer element in FilingData.FinalFilingData.FilingPlanType, and the presence of the NonExempt element within SingleEmployer.VariableRatePremiumData.

^ Top

Paper Form field mapping to XML schemas

To review additional details regarding how elements in the schemas map to data elements as identified by PBGC’s forms and instructions, review the following PDF files:
2007 Filings and 2008 Estimated Flat-rate filings [PDF]
2008 Comprehensive Filings [PDF]

 ^ Top

Vendor/Developer Resources

Sample PBGC Premium Filings in XML Format

XML Samples for Comprehensive Filings

The Sample XML files provided cover the filing scenarios for which each vendor/developer must submit test files to PBGC for 2008 Comprehensive Filings. In addition to meeting the minimum requirements for submitting test filings to PBGC, the sample files provided here illustrate use of many of the elements new to the schema beginning in 2008.

To view the XML examples, open this zip file: Comprehensive_Filing_XML_filing_samples.zip.

Reference the PDF file titled 2008ComprehensiveDataMappingforSamples.pdf for information about each filing scenario and the data used in each XML sample.

XML Samples for Estimated and Final Filings

This table below lists 12 filing types PBGC typically receives involving Estimated Flat-rate Filings (1-ES) for plan years 2008 and prior and Final Filings for plan years 2007 and prior. For each filing type, you can view a sample XML file that shows how that data would be represented and a sample 2006 paper form to show how that data would appear on our traditional forms. To view the XML example, open this zip file: XML_filing_samples.zip and find the specific XML file listed in the table.

* Note: The sample paper versions are for illustration only.  If you need PBGC's premium forms, please see page: "Premium Forms and Instructions".

^ Top

Testing XML files / Submission Validation Service (SVS)

PBGC has developed the Submission Validation Service (SVS) which validates XML files against PBGC’s specification. A technical description of the SVS is provided in PDF format. Developers may access this service via a web-based Validation utility to ensure that the XML files generated by their software are properly structured for submission to PBGC. Use this validation service to test XML files that contain test filing data (for plan years starting 2005).

The service will provide an immediate success/failure response for each XML file you test. If an XML file passes, SVS provides a message that lets you know this file has passed. If an XML file fails, SVS will provide detailed error messages, such as the example below.

Example failure notice

Error Message: The 'http://www.pbgc.gov/schema/premiumfiling/Submission:PlanYearBeginDate' element has an invalid value according to its data type. An error occurred at , (8, 38)

Problem: Form 1-ES has an improperly formatted date element

Download technical description of SVS [PDF]
Go to Validation Utility

^ Top

Tips for Creating PBGC Premium Filings in XML Format

Please refer to the schema documents to identify all schema rules and validations (including rules governing field type and length). Following are tips and additional requirements not explicit in the schema documents that vendors/developers must follow when modifying their software to create premium filings in XML format. The information below is provided based on specific questions and issues that have been encountered by developers in generating XML files that meet the PBGC specification:

• Order XML Nodes in the same order as identified in the Premium Filing Schema Documents

  My PAA will reject an XML file that has the nodes in the incorrect order. An XML file must provide the data in the specified order according to the schema. The schema enforces this rule to better enable PBGC to review and verify your sample filings. In addition, a consistent ordering of schema data elements assists with manual filing review.

• Do not include commas in any value in a numeric XML node.

• Do not submit an XML premium filing to the PBGC with empty XML nodes.

My PAA will reject an XML file that has empty nodes, regardless if the nodes are mandatory or optional. The only exception to this is if the node type is "string" with no restriction for minimum length. For example: Submitting an XML file with an empty Amended Filling node would look like this: <AmendedFiling> </AmendedFiling>.- and will generate the following error when validating the XML filing:

1. The 'http://www.pbgc.gov/plan_admin/efiling/2006/Filing:AmendedFiling' element has an invalid value according to its data type. An error occurred at , (1, 1814).

The correct way to show that a filing is not an amended filing is to submit the XML file without the <AmendedFiling> node since this is an optional node.

• Be sure to use the accurate spelling of all XML nodes. In addition, the XML node names are case sensitive.

My PAA will reject an XML file with misspelled XML node names or with node names those that do not match the case as indicated in the schema documents.

• Be sure to include correct namespace (xmlns) references to the submission, submissiontypes, and premiumfiling in your XML premium filing documents. For example, if the following namespace is used:

xmlns:f="http://www.pbgc.gov/plan_admin/efiling/PremiumFiling" xmlns:st="http://www.pbgc.gov/plan_admin/efiling/SubmissionTypes"
The tag names of XML elements should have prefixes in reference to these namespaces. Schema validation will generate an error if any of these prefixes are omitted from the XML document. For example, in the following XML, “st” is the namespace prefix for SubmissionTypes and “f” for PremiumFiling.

<f:SingleEmployerPremium> <st:FlatRatePremium>19000.00</st:FlatRatePremium> <st:VariableRatePremium>90315.00</st:VariableRatePremium> <st:TotalPremium>109315.00</st:TotalPremium>
</f:SingleEmployerPremium>

Submitting these data without the “st:” tag prefix may cause the following validation error:

1. The element 'http://www.pbgc.gov/plan_admin/efiling/2006/Filing:SingleEmployerPremium' has invalid child element 'http://www.pbgc.gov/plan_admin/efiling/Submission:FlatRatePremium'.
Expected 'http://www.pbgc.gov/plan_admin/efiling/SubmissionTypes:FlatRatePremium'. An error occurred at, (1, 2222).

2. The 'http://www.pbgc.gov/plan_admin/efiling/Submission:FlatRatePremium' element is not declared. An error occurred at, (1, 2222).

3. The 'http://www.pbgc.gov/plan_admin/efiling/Submission:VariableRatePremium' element is not declared. An error occurred at , (1, 2265).

4. The 'http://www.pbgc.gov/plan_admin/efiling/Submission:TotalPremium' element is not declared. An error occurred at, (1, 2316). 

• Mapping filing questions to the latest schemas

The latest schema is used for creating XML files that contain filing data for plan years 2005 and later. There are two mapping documents provided that show where each filing question on the paper facsimile is mapped to in the schema:

• http://pbgc.gov/docs/schema_to_form_mapping_for_6_and_7_0.pdf - This document maps the filing questions to the schema for all filings for plan years 2005 through 2007 and for the 2008 Estimated Filing.
• http://pbgc.gov/docs/Map2008CompFormtoSchema.pdf - This document maps the filing questions to the schema for Comprehensive Filings starting with the 2008 plan year.

Note that My PAA’s “import” feature is designed to accept XML files with filing data for plan years 2006 and later, while the “upload” feature will accept XML files with filing data for plan years 2005 and later.

• Including multiple filings in one XML submission

PBGC developed the requirements for XML files so that multiple filings (approximately 100) can be included in one XML file in anticipation of scenarios like the following:

• Third party administrators who create filings for different plans for their customers or for a sponsor who has several plans and would like to put them all in one XML file that can be imported or uploaded to My PAA at one time.
• Plans that may have to submit a filing for two different plan years – e.g., the plan might need to submit an amended filing for the 2006 plan year and a new filing for the 2007 plan year.

There is no restriction on combining different types of filings or different plan years within a single XML submission. The XML structure dictates that each filing be saved in the XML in an “envelope” – each filing would begin with the opening <Envelope> tag and each will end with the closing </Envelope> tag. One XML file may contain multiple envelopes.
It is important to note how My PAA handles an XML file that contains multiple filings for the same plan (identified by EIN/PN), depending on how the user chooses to submit the XML – either by uploading it or importing it. For example:

• If the XML is UPLOADED into My PAA and it includes 1 envelope for Plan X with an Estimated Flat-rate Filing and a second envelope for Plan X with a Comprehensive Filing, My PAA transfers both of these filings to PBGC’s processing system.
  
• If that same XML file is IMPORTED into My PAA, it will be handled differently. My PAA, it can only have one “draft” filing open for a plan for each plan year. Therefore, if an XML file contains more than one filing for the same plan and the same plan year, the last filing (envelope) in the XMLfile for that plan and plan year will overwrite any preceding ones. For example, if there was a 2008 Estimated Flat-rate Filing in the first envelope for Plan X, and a 2008 Comprehensive Filing for Plan X in the second envelope, upon completion of the import, only the 2008 Comprehensive Filing for that plan would be available in My PAA for reviewing, editing, certifying, and submitting.

• Mapping of the FormCode element specified in PremiumFiling.XSD map to the Paper forms

On a paper filing form, the Form Code is shown in the top right corner. The Form Code is unique by form type/year. You should provide the Form Code appropriate to the form type/year of the filing being submitted in the FormCode element within PremiumFiling.XSD. For the purposes of e-filing, an envelope with filing data that represents a Form 1 with Schedule A should use the Schedule A form code.
 
The Form Codes for 2008 are:
1-ES = 324679
Comprehensive Filing = 325784

The Form Codes for 2007 are:
1-ES = 239874
1-EZ = 234695
Form 1= 235749
Schedule A = 237486

The Form Codes for 2006 are:
1-ES = 990406
1-EZ = 993606
Form 1= 991506
Schedule A = 995706

The Form Codes for 2005 are:
1-ES = 987435
1-EZ = 984573
Form 1= 985350
Schedule A = 975384

• Values for "Yes" and "No" nodes

There are numerous elements within the schemas that map to checkbox items on the paper forms. In the XML, these items are represented with a <Yes> sub-element and a <No> sub-element. In some cases, depending on which node is present (Yes or No) an additional element is required, such as with Disaster Relief where a Yes node requires the Disaster Relief Explanation node. When there is not a dependent element in the selected node, a value of 'X' should be provided for the element. For example:

<f:DisasterRelief>
<f:No>X</f:No>
</f:DisasterRelief>

• About Disaster Relief and Disaster Relief Explanation

On the paper forms for all plan years, there is a “Disaster Relief” item:

• • All filings for plan years 2005 through 2007 and for the 2008 Estimated Flat-rate Filing: the instruction booklets tell filers to check the disaster relief checkbox and write or type in the name of the disaster across the top of the form.
    
    Here is an example of how the disaster relief node in the XML file should be formatted for a plan that is covered by a Hurricane Katrina disaster relief notice for this premium filing:

    <f:DisasterRelief>
    <f:Yes>
    <f:DisasterReliefText>Hurricane Katrina</f:DisasterReliefText>
    </f:Yes>
    </f:DisasterRelief>

  • 2008 Comprehensive Filings: filers are instructed to enter the appropriate four digit code provided in the disaster relief announcement posted on PBGC’s web site.
    
    Here is an example of how the disaster relief node in the XML file should be formatted for a plan that is covered by a disaster relief notice for this premium filing:

  <f:DisasterRelief>
  <f:Yes>
  <f:DisasterReliefText>08-09</f:DisasterReliefText>
  </f:Yes>
  </f:DisasterRelief>

• About Credit Explanation

Credit Explanation is not a field on the paper form, but an attachment that would have to be provided by the filers if they are claiming a credit on the estimated filing. On pages 9 - 10 of the instruction booklet for the 2006 Form 1-ES, it tells filers that they need to provide an explanation for any short year proration in their estimated premium filing. In a paper submission, this would be done as an attachment. Within an XML submission, the explanation can go in the optional <CreditExplanation> node.

• About Foreign Countries

Within SubmissionTypes.XSD, there is an element called ForeignAddressType. A mandatory sub-element is Country. This type is defined as a string with a maximum length of 30. This field is used if the plan sponsor, plan admin, or actuary address is not a United States address. While this field is free form in the schema, within the My PAA application, country is handled via an allowable list of country codes. This distinction currently only impacts filings that are imported and opened for editing in My PAA, however it would be preferable to move to the use of country codes vs. free form text for all data passed in the <Country> element.

For uploaded filings the name of any country can be included in this field, up to the maximum length of 30 characters. The value for this field will be passed into PBGC's accounting system as provided in the XML.

For imported filings, My PAA will only recognize the country if it matches one of the allowable country codes. If the value for <Country> does not map to a country code on this list, My PAA will not be able to interpret the country, and will instead map the country to the default value of United States - Any address that included the invalid country code will be updated to reflect United States as the country. This impacts the user in two ways.

1. The wrong country (United States) will be displayed on the filing. The user will need to edit the country by selecting it from the drop down list of countries for the element where the incorrect country code is used - elements affected could be Plan Sponsor, Plan Administrator or Actuary.

2. The edit checks that are enforced for submission within My PAA are more strict for United States than for foreign countries. Until the user updates to the correct country, My PAA will consider the filing incomplete if any element required for a US address is incomplete. For example, a foreign address does not require that zip code be provided, but a US address requires the zip code. If the imported filing included a foreign country and no zip code, when My PAA maps the invalid country code to  the United States, the filing manager page will interpret the filing as incomplete. Once the user edits the country to the correct value from the drop down list, the edit checks will be relaxed to those for a foreign country and the file will be considered complete without entering a zip code.

• About creating test files to match sample data

The sample premium filings contained in the sample XML and PDF files are intended to illustrate the mapping of values from the paper form to the XML schema. It is not a requirement to submit to PBGC XML files that contain precisely the same sample data.

^ Top

Additional Checks PBGC Does on Submitted Premium Filings

When a premium filing is submitted, PBGC checks the accuracy and validity of the information reported. The purpose of the PBGC_Business_Rule_Edits.pdf document is to provide software vendors/developers with some of the business rules that PBGC applies to premium filings once they have been submitted - including those that will not be filtered by the schema validator itself. Software vendors/developers can use these rules to create validations in their software so that their customers will be able to submit more complete and accurate filings to PBGC.  

Note that this document primarily applies to 2008 Estimated Flat-rate Filings and estimated and final filings for plan years 2007 and prior; it has not yet been updated with information for Comprehensive Filings for plan years 2008 and later. However, for data elements that exist across years (e.g., EIN/PN), the validation rules will continue to be applied to Comprehensive Filings for plan years 2008 and later.

Until we have completely updated the business rule document, we have included a few examples below of business rules that apply to Comprehensive filings for plan years 2008 or later, along with the related page numbers from the Instructions. 

• If an item is completed, make sure all information requested in the item is completed, whether or not this is enforced in the schema for example:
  • item 3.c.(3) - if the 5500 EIN/PN is included in a filing, the filer must also provide an explanation as to why the EIN/PN on the filing is different from the EIN/PN provided on the previous year’s Form 5500.  (page 26) (this rule is enforced in the schema)
  • item 14 - if one date is given for a new or newly covered plans, all dates must be completed.  (page 34). (not enforced in the schema)
• Alternative Premium Funding Target Election – Once a plan has made the election to use the alternative premium funding target, this election cannot be revoked for five years. If a plan has already made the election in a previous filing, the plan should not submit a filing where they indicate they are making the election again. (pages 26 and 27) (not enforced in the schema)
• Premium funding target – If a plan is using the standard premium funding target method, the filing should include all three segments for the discount rate. If the plan is using the alternative premium funding target method, they should provide all three segment rates OR indicate that they used the full yield curve to determine the premium funding target. (pages 29 and 30) (the schema enforces that either full yield curve or all three segment rates must be present if the comprehensive VRP node is present, but it does not enforce that full yield curve can only be used with the alternative method)
• Amended Filing - A VRP reconciliation filling (in which the final premium funding target info is provided after having reported an estimated premium funding target) is considered to be an amended filing.  (page 24) (not enforced in the schema)
• Reporting dollar amounts - With the exception of total premium, premium credits, the amount due PBGC, and the amount of any overpayment, money amounts should be in dollar only (no cents).  (page 24) (not enforced in the schema)
• Treatment of Overpayment – If a filing indicates that the plan has an overpayment, the filer must choose whether to have the overpayment refunded (by check or EFT) or credited toward the next year's premium for the plan. If EFT, the filer must provide the banking information requested.  (page 33) (enforced in the schema)

^ Top