Skip to main content

Practitioners

Software Developer E-filing Resources for Integrating with PBGC

Introduction

PBGC's premium e-filing application, My Plan Administration Account (My PAA) supports XML specifications that allow 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 these XML specifications.

Overview

PBGC Premium E-Filing Data Standards

Vendor/Developer Resources

Contact us

If you are a software vendor/developer and have questions or comments about how to modify your product to integrate with PBGC's requirements, please send them 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 and Upload:

  • 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. Note that XML files must typically be submitted to PBGC when there are changes to the schema. If the schema does not change, vendors/developers are still encouraged to validate their own sample files for the new plan year.

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 Comprehensive Filings (for plan years starting 2014), the following types of filings must be submitted to PBGC for verification:

  • Test File 1
    2014 Comprehensive filing for a single-employer plan that is exempt from the VRP due to New or newly covered small plan other than a continuation plan.
    • Continuation plan should be reported in ContinuationPlan\No node.
    • Exempt Type information should be reported in Exempt\NewNewlyCvrdSmallPlanNotContinuation node.
  • Test File 2
    2014 Comprehensive filing for a single-employer, from a Foreign country, with three new participant count nodes (Active, Terminated Vested and Retirees and Beneficiaries).
    • Continuation plan should be reported in ContinuationPlan\No node.
    • Foreign should be reported in Administrator\ForeignAddress\Country node
    • Participant counts should be reported in ParticipantCountFields\ParticipantCountActive, ParticipantCountFields\ParticipantCountTerminatedVested, ParticipantCountFields\ParticipantCountRetireesandBeneficiaries nodes.
  • Test File 3
    2014 Comprehensive filing for a single-employer small plan that is exempt from VRP with more than one exemption.
    • Plan size should be reported in IsSmallPlan\Yes node.
    • Exempt types should be reported in Exempt\NoVestedParticipants, Exempt\NewNewlyCvrdSmallPlanNotContinuation nodes.
  • Test File 4
    2013 Comprehensive filing for a single-employer small employer plan that is not exempt from the VRP, qualifies for the small employer cap, and is only paying the VRP cap (i.e., is not reporting the Unfunded Vested Benefit amount).
    • If the filer chooses to take the maximum VRP calculation without providing other VRP related data, the XML should include UniversalVRPCap (item 7h1), SmallEmpCap (item 7h2), MaximumVRP (item 7h3) but should exclude the fields in the node.
  • Test File 5
    2014 Comprehensive filing for a Multi-employer New or newly covered small plan, continuation plan with three new participant count nodes (Active, Terminated Vested and Retirees and Beneficiaries).
    • Plan size should be reported in IsSmallPlan\Yes node.
    • Continuation plan should be reported in ContinuationPlan\Yes node.
    • Participant counts should be reported in ParticipantCountFields\ParticipantCountActive, ParticipantCountFields\ParticipantCountTerminatedVested, ParticipantCountFields\ParticipantCountRetireesandBeneficiaries nodes.
  • Please note that all 2014 filings (as well as requested test files) should:
    • Reflect the updated flat-rate premium and includes all required nodes.
    • Include sponsor's name (Sponsor/Name) but exclude Address nodes.
    • Include effective date in node AllPlanEffectiveDate.
    • Include Contact Person (2h) detail (name, e-mail address, phone number and ext).
  • After you have validated the above five scenarios, forward the XMLs for all of the filings described (the five specific Test Files) to PBGC for review (via softwareefiling@pbgc.gov) and include the following information so that each test file is clearly identified and we can call or email you if there are questions:
    • Test file names should be descriptive and start with the requested test file number that matches the scenario described.
    • Your name, your company name, and your contact information (telephone number and email address).

If your software will also be used to submit Comprehensive Filings for plan years 2008 through 2013 and PBGC has not previously reviewed your filings, the following types of filings must be submitted to PBGC for verification:

  1. Comprehensive filing for a single-employer plan that is exempt from the VRP
  2. Comprehensive filing for a single-employer medium or large plan that's not exempt from the VRP
  3. 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. 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. Comprehensive filing for a multiemployer plan
  6. Comprehensive filing for which premium proration applies for both a single-employer and multiemployer plan

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

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

  • Company name
  • Product name
  • Product version and/or release number
  • Your first name and last name
  • Business telephone number
  • Business E-mail address
  • A description of the XML file that you are submitting for review that contains the plan year and type of filing (e.g., 2007 Final Filing, 2012 Estimated Flat-rate Filing, 2012 Comprehensive Filing).
  • Attach the XML files that you are asking PBGC to review

Step 2: PBGC will acknowledge receipt of submitted XML file(s) and will verify each submission, for example, that:

  • The XML is properly formatted
  • Each sample file meets the approved XML schema
  • Each file has all the required data based on the type of filing information included in that file. For example, the XML file that contains filing information equivalent to the Form 1-ES must contain an Estimated Premium Due and the appropriate form number.

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

  • If your submissions contained errors, the response will identify the files that caused the error and provide detailed error messages.
  • If your sample files were approved, PBGC will provide you with a unique vendor identification number to insert into your final XML documents using the Provider Approval Number field. This would be a static data element and should be present in every premium filing XML submission. Note that a new vendor identification number is typically assigned when new sample files are submitted/approved as the result of a schema change.

^ Top

PBGC Premium E-Filing Data Standards

Premium e-filing XML Specifications

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.

Effective December 18, 2013, the XML schema has been updated to include the following changes for all filings for all plan years:

  • The country code for foreign addresses must be a 2 letter code based upon the ISO Standard 3166-1 alpha-2 for two-letter country codes as shown on the ISO Country Codes List
  • The zip code for US addresses must be 10 or 9 or 5 characters
    • For US address zip codes, when entering 10 characters, the first 5 characters must be Numeric, 6th character must be a space or a hyphen, and last 4 characters must be Numeric
    • For US address zip codes, when entering 9 or 5 characters, all characters must be Numeric
    • The zip code can be left blank for foreign addresses
  • The Employer Identification Number (EIN) must be a 9 digit number; while the Plan Number (PN) must be a 3 digit number

A filing is composed of three core schema files (Effective 12/18/2013):

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: This documents the data type definitions used throughout the schema definitions. Download SubmissionTypes.xsd [ZIP]

PremiumFiling.xsd: This schema document explains the element and format definitions for 2005 - 2007 final premium filing data (equivalent to the paper forms: Form 1-EZ, Form 1, and Form 1/Schedule A), for 2009 and later estimated flat-rate filing data and 2008 and later 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 commencement date
  • 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 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 or later).
  • Within the EstimatedFilingData element, the PremiumAmount element must contain either the SingleEmployerPremium element or the MultiemployerPremium element; 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 or later as the year, and the presence of the FilingData\FinalFilingData element.

      Please note the following information related to the new data fields starting plan year 2014:
      • Use IsSmall Plan (YES or NO) for 2014 and later only. The existing element Plan Size (SmallPlanSize or MidSizePlanSize or LargePlanSize or PlanSizeNAFirstYearsFiling) is used for 2008 to 2013 years only.
      • Use ParticipantCountFields node for 2014 and later only. If you include the node you must have all three elements ParticipantCountActive, ParticipantCountTerminatedVested, and ParticipantCountRetireesandBeneficiaries under the node. You cannot have an empty ParticipantCountFields node.
    • 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:

2014 Comprehensive Filings [PDF]

2013 Comprehensive and Estimated Filings [PDF]

2008 – 2012 Comprehensive Filings[PDF]

2007 and Prior Filings and 2008/2009 Estimated Flat-rate Filings [PDF]

^ Top

Vendor/Developer Resources

Sample PBGC Premium Filings in XML Format

XML Samples for 2014 Comprehensive Filings

To view the XML examples, open this zip file: 2014-XML-Samples.zip

Reference the PDF file titled 2014-Samples-Description-Mapping.pdf for information about each filing scenario and the data used in each XML sample for Comprehensive Filings starting 2014. Please note that the 2014 XML Samples zip file also includes a 2013 single-employer test file that reflects a small cap, not exempt from VRP, no UVB scenario. The new data fields starting plan year 2014 (i.e., IsSmallPlan, ParticipantCountFields node that includes ParticipantCountActive, ParticipantCountTerminatedVested, and ParticipantCountRetireesandBeneficiaries) DO NOT apply to any 2013 or earlier filings. You should notice that the 2013 sample does not use any new 2014 elements.

XML Samples for 2013 Comprehensive and Estimated Filings

To view the XML examples, open this zip file: 2013_ XML_Samples.zip

Reference the PDF file titled 2013_Samples_Description_Mapping.pdf for information about each filing scenario and the data used in each XML sample for Comprehensive and Estimated Filings starting 2013.

XML Samples for 2008 – 2012 Comprehensive Filings

The Sample XML files provided cover the filing scenarios for which each vendor/developer must submit test files to PBGC for 2008 – 2012 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 2007 and prior Final Filings

To view the XML examples for Estimated Flat-rate Filings (1-ES) for plan years 2008 and prior and Final Filings for plan years 2007 and prior, open this zip file: XML_filing_samples.zip

Reference the PDF file titled MapXMLtoForm2007priorFinal2009Est.pdf for information about each filing scenario.

^ Top

Testing XML files / Submission Validation Service (SVS)

PBGC has developed the Submission Validation Service (SVS) which validates XML files against PBGC's specifications. 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 SVS was last updated Dec. 2013 with the new schema validation requirements for existing country, zip code and EIN/PN nodes. These validations apply to all filings submitted on or after 12/18/2013.

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

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

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 Code for 2014 is:
Comprehensive Premium Filing = 921857

The Form Codes for 2013 are:
Estimated Flat-rate Premium Filing = 852437
Comprehensive Premium Filing = 863215

The Form Codes for 2012 are:
Estimated Flat-rate Premium Filing = 734296
Comprehensive Premium Filing = 742639

The Form Codes for 2011 are:
Estimated Flat-rate Premium Filing = 624378
Comprehensive Premium Filing = 634295

The Form Codes for 2010 are:
Estimated Flat-rate Premium Filing = 543289
Comprehensive Premium Filing = 564718

The Form Codes for 2009 are:
Estimated Flat-rate Premium Filing = 476320
Comprehensive Premium Filing = 432571

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

^ 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 - and will generate the following error when validating the XML filing:

    The 'http://www.pbgc.gov/plan_admin/efiling/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 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:FlateRatePremium>330</st:FlateRatePremium>
    <st:TotalPremium>830</st:TotalPremium>
    </f:SingleEmployerPremium>

    Submitting these data without the "st:" tag prefix may cause the following validation errors:
    1. The element 'http://www.pbgc.gov/plan_admin/efiling/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:TotalPremium' element is not declared. An error occurred at, (1, 2316).
  • Mapping filing questions to the latest schema

    The latest schema is used for creating XML files that contain filing data for plan years 2005 and later. The following mapping documents show where each filing question on the paper facsimile is mapped to in the schema: 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 2013 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 tag and each will end with the closing 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. The receipt for each envelope will be displayed within My PAA.
    • If that same XML file is IMPORTED into My PAA, it will be handled differently. My PAA, 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 commencement date, the last filing (envelope) in the XML file for that plan and plan year will overwrite any preceding ones. For example, if there was a 2013 Estimated Flat-rate Filing in the first envelope for Plan X, and a 2013 Comprehensive Filing for Plan X in the second envelope, upon completion of the import, only the 2013 Comprehensive Filing for that plan would be available in My PAA for reviewing, editing, certifying, and submitting
  • 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 within a parent 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 or 2009 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: Hurricane Katrina

      • For Comprehensive Filings starting 2008 and Estimated Flat-rate Filings starting 2010: 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: 08-09

  • Country Codes List (Effective 12/18/2013)

    Effective December 18, 2013, all filings with a foreign address must use the ISO Standard 3166-1 alpha-2 country code in the "Country" node. The acceptable country codes are shown on the ISO Country Codes List.

  • Small Employer Cap

    For 2008 and later, if the plan has indicated that they qualify for the cap, this element may be included but is not required. If included, it should be equal to the value of Unfunded Vested Benefits (item 7f) * VRPCap. For 2013+: this element should be included when claiming the small employer cap and reporting Unfunded Vested Benefits.

^ Top

Additional Checks PBGC Does on Submitted Premium Filings

When a premium filing passes the schema and is submitted, PBGC checks the accuracy and validity of the information reported. If any filing data does not pass the business rules validations, the filer will be contacted and may need to submit an amended filing with corrected information. To help improve filing accuracy, we suggest the following:

  • Review each year's premium payment instructions for information about changes that may impact the accuracy of filings. For example, the premium instructions starting 2013 state that only dollars should be reported for the Premium Funding Target data elements which include active participants, terminated vested participants, retirees and beneficiaries receiving payment, and the total premium funding target.
  • Review the My PAA FAQs on our website, particularly "How can I help ensure that my premium filing is accurate and complete?" The FAQ provides filing reminders such as reporting the name and contact information of the plan administrator and actuary who have certified or will certify the filing in the certification section of each uploaded filing (within the XML filing data).

^ Top