Privacy Impact Assessment-Modernized e-File Application in support of Excise Tax E-file & Compliance (MeF-ETEC)

System overview:

MeF is the IRS’s Modernized e-filing system. MeF currently accepts electronically filed 1120, 1120S, 7004, 990, 990-EZ, 990-PF, 1120-POL, 1065, 1065B and 8868 (Extension to file 990) tax returns and documents. In support of Excise Tax E-file & Compliance (ETEC) MeF will be adding forms 2290 (Heavy Highway Vehicle Use Tax Return), 720(Quarterly Excise Tax Return) and 8849 (Claim for Refund of Excise Taxes).  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, exempt organizations, and partnerships.

System of Record Notice(s)

Treasury-IRS 22.062 Electronic Filing Records
IRS 50.001 – Employee Plans and Exempt Organizations Correspondence Control Records
Treasury-IRS 34.037 IRS Audit Trail and Security Records
IRS 24.046-CADE Business Master File (BMF) (Formerly: Business Master File (BMF).

Data in the System 

1. Generally describe the information to be used in the system in each of the following categories: Taxpayer, Employee, and Other.

Taxpayer: MeF validates, collects, prepares for downstream processing, and retains taxpayer data contained on the Return Forms Series 1120, 1120S, 1120-POL,  1065, 1065B, 7004, 990, 990-EZ, 990-PF, 2290, 720, 8849 and 8868, including all schedules, forms, statements, and attachments required by law which were electronically filed via the IRS portals.  MeF also will collect State tax returns, whether filed with a Federal return or not, for transmission to the appropriate state agency; that is, MeF will make State returns available to states.  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts federal and state returns filed by organizations, specifically corporations, exempt organizations, and partnerships.  MeF shall virus check the request message and check that the state participates in either the Fed/State or State Stand-Alone program.  If a state return fails this validation, it will be rejected in accordance with business rules.  In a joint Fed/State filing, if the federal return is rejected, the state return will also be rejected.  Notice of acceptance or rejection is contained in the acknowledgement which is retrieved using a separate Service Request.  If the federal return is submitted on or near the filing date and the return is rejected, the taxpayer has 20 days from the date-time stamp in the acknowledgement to refile rejected returns and 5 days to refile rejected extensions.  However, there is no such implied or expressed re-file period for a rejected state return.  Originators and State Agencies must come to agreements between themselves as to what, if any, re-filing period exists.  This data is retained on the MeF system for the current tax year only.

Transmission Files: MeF retains the transmission files as originally transmitted by Registered users for three years.  These files contain the original return data transmitted electronically.  The data is retained to keep a record of the return data as originally transmitted. 

Acknowledgement Files: Since acknowledgement files contain validation results for all returns contained in transmission files, each acknowledgement file is retained along with its originating transmission file for three years.

Database: MeF retains taxpayer data in the MeF database for the entire processing cycle (one tax year).  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, exempt organizations, and partnerships.  In addition to taxpayer data, MeF retains statistical and summary data derived from tax returns.  Some of the data, like taxpayer entity information, is retained in the database to support return validation.  For example, each return must contain a valid Employer Identification Number (EIN) and name control.  Entity data is also used to prevent duplicate filings for the same tax period.  E-Help Desk personnel, Error Resolution Tax Examiners, auditors, classifiers, customer service representatives, and managers all require access to this data to perform their duties. 

MeF collects the following types of statistical and summary data:
.
(1) Number of accepted and rejected returns sorted by District Office,
      Service Center, EFIN (ERO),

(2) Rejected transmissions by ETIN (Transmitter),

(3) Number of accepted returns by ETIN,

(4) Number of rejects by error category,

(5) ERO return volumes by District Office,

(6) Volumes of each form and schedule by return type,

(7) Rejects by type of Software Package,

(8) Daily Totals of filed returns,

(9) Duplicate filing rates,

(10) Returns filed by BOD.

Employee: MeF does not house, collect, or store employee data.  The employees gain access to the MeF application through the Employee User Portal (EUP).  The EUP validates each employee’s login and password against the logins and passwords housed in the e-Trust, which resides on a separate infrastructure server in the EUP.  It is this server that writes all login attempts to Security Audit Analysis System (SAAS).  Upon successful login, the employee selects a MeF application from a list of applications the employee is authorized to access.  Once the employee selects the application, the employee is connected to the MeF presentation logic (resides on the web application server), which is separate and distinct from the MeF application that resides on the MeF server.
Once connected to the MeF presentation logic, all user transactions are audited and written to SAAS.  The SAAS record includes the user ID, role, and session ID, but MeF does not process or retain this data. 

Other: Registered and confirmed Transmitters, On-Line Providers, and Large Taxpayers (hereafter all three are referred to as Transmitters), transmit e-filed tax returns to MeF via the RUP (Transmitters also transmit through the EMS.  These transmissions are then transferred to the MeF system).  In A2A, for instance, the system ID and password of the Transmitter application are used for authentication; whereas, for IFA, the user ID and password of the authorized Transmitter user are processed.  Each Transmitter is validated upon successful login.  Then the Transmitter is connected to MeF.  All registered users log in and select a personality.  The user then uploads the return file to this MeF application component.  Once connected to the MeF process, all user transactions are audited and written to SAAS.

Other Organization Taxpayer / Transmitter related data includes (refer to the Attributes of the Data section, item 4 of this PIA document for the following data element descriptions):
Employer Identification Number (EIN)
Document Locator Number (DLN)
Electronic Transmitter Identification Number (ETIN)
Electronic Filer Identification Number (EFIN)
Global Transaction Key (GTX Key)
Submission ID
Message ID

A2A provides the ability for Transmitters to submit returns and documents unattended.  The techniques involved will cause remote applications, especially those belonging to Transmitters or state governments, to authenticate themselves to the Registered User Portal and transmit Web Services requests to the Portal where they will be processed by WebSphere on the MeF SOAP Web Application Server.  A major use of this feature is in the transmission of returns unattended.  Fed/State provides the ability for Transmitters and EROs to file State returns through the MeF system where they will be routed to the respective states.  Starting in Release 4, Transmitters will be able to transmit state returns through the original Internet Filing Application (IFA).  These will be attended transmissions as opposed to A2A which is unattended.  States can only retrieve the returns and receipts through A2A.  The states must be participating states. Transmitters who wish to participate in A2A will be required, during registration, to abide by the rules outlined in the registration process and Publication 4164 which is publicly available information.  The states are required to abide by the rules of the Memorandum of Understanding that they must sign.  The MOU will include reference to IRS Publication 4164.  The states must comply with IRS Publication 4164.

The IRS assigns each authorized Transmitter an Electronic Transmitter Identification Number (ETIN) and each authorized ERO an Electronic Filer Identification Number (EFIN).  The Transmitter inserts their ETIN into each transmission file, and the ERO inserts their EFIN into each e-filed return.  Upon receiving the transmission file, the MeF application verifies the Transmitter and ERO by matching the inserted ETIN and EFINs against the IRS official list of ETINs and EFINs, which it receives from the TPDS (See below).  If the Transmitter uses an invalid ETIN, the entire transmission file is rejected, including all returns contained within the file.  If the ERO inserts an invalid EFIN into a return, that return is rejected.

Also, MeF retains statistical and summary data derived from tax returns in the MeF database.  For example, information about the number of returns by ERO, validation results, and types of forms attached to returns are tracked and contained in the MeF system.  Preparer Tax Identification Numbers (PTINs) are included in the tax return where required, but MeF does nothing with these PTINs.  See Appendix E for more detailed information.

2. What are the sources of the information in the system?

2.a.  What IRS files and databases are used?

National Account Profile (NAP)

Taxpayer entity information such as EINs, name controls, and filing requirements are provided to MeF by the National Account Profile (NAP) system.  This data is housed in the MeF database and is used to validate entity information on the e-filed tax returns.  This data does not contain taxpayer financial data.  NAP transmits updates to MeF once each week using the EFNS/EFTU FTP Server Utility.  This data includes the following taxpayer Identification data:

Employer Identification Number (EIN): Name Control,Filing Fiscal Month,Filing Requirement

General Mainframe Framework (GMF): MeF checks all e-filed returns for duplicate filings.  If the return is a duplicate, it is rejected.  The rejected returns remain on the MeF system.  They are used by the E-Help Desk to help EROs understand and fix the errors.  They are removed from the system at the end of the tax year with the rest of the tax data.  Since taxpayers can file electronically and by paper, MeF requires Identification information (EIN, return type, tax period) for all paper filed returns.  GMF provides this information to MeF daily using the EFNS/EFTU FTP Server Utility.   This data includes the following taxpayer Identification data:

Employer Identification Number (EIN): MeF will send International returns to the Philadelphia GMF Area Locator Number (ALN).  The Philadelphia GMF ALN resides on the same Unisys in MCC as does the GMF ALN.  GMF sites were consolidated but not the ALNs.  A separate GMF runs for each ALN. Thus, MeF sends files to two GMFs.  MeF will batch international returns separately and transmit those batches to the Philadelphia (International) GMF ALN using the same EFNS/EFTU utility.  MeF will continue to send non-international corporate and TE/GE returns to the GMF ALN. 

Modernized Tax Return Database (M-TRDB): M-TRDB is the authoritative source of all accepted tax returns electronically filed through MeF.  When an authorized internal IRS user uses MeF to request an e-filed return, MeF retrieves that return from M-TRDB.  These tax returns contain the following taxpayer Identification data: 
Employer Identification Number (EIN),
Taxpayer Name and Address,
Document Locator Number (DLN),
EINs, Names, and addresses of Subsidiary Corporations,
Tax Return Information.

For Forms 1065 and 1065B, the following taxpayer identification data for partnerships is included in Schedule K-1:

Partner TIN, which may include the partner’s EIN or SSN as part of a Partnership tax return.

The M-TRDB will provide extracts on a weekly basis of redacted Exempt Organization form 990, 990-EZ, and 990-PF information to a server operated by the Statistics of Income Organization (SOI).  The XML formatted returns are converted into the PDF file format and included on a publicly available CD-ROM.   The IRS is required by law to provide the redacted form 990 and 990-EZ information to the public and currently accomplishes this through the use of various paper and electronic media.  Redacted information consists of the following: Return ID; Time Stamp; ISP Number; Software ID; Software Version; Multiple Software Packages Used; Originator; EFIN; Originator Type; Practitioner PIN, EFIN; PIN; PIN Entered By; Signature Option; Name Control; Phone; Taxpayer PIN; Authorized Third-Party; Preparer phone.

M-TRDB also provides extracts to the IRS Return Inventory Control System (RICS), ETA's marketing database, and SPLAT.  M-TRDB processes and privacy considerations fall within the boundaries of the M-TRDB PIA.  Refer to the M-TRDB PIA for more details concerning M-TRDB privacy posture.

Third Party Data Store (TPDS):
 
TPDS is the authoritative source of all Transmitter, Electronic Return Originator, and Software ID information.  MeF uses this data to validate authorized Transmitters and EROs.  MeF uses the Software IDs to verify that the tax returns were prepared using IRS authorized software.  This identification information is not taxpayer information and is not contained in tax returns. 

TPDS transmits this information to MeF daily, using the EFNS/EFTU FTP Server Utility.  The identification numbers for EROs and Transmitters are not Taxpayer Identification Numbers.  They are numbers assigned by the IRS to Transmitters and EROs only for the purpose of identifying them as Transmitters and EROs. 

Only registered Transmitters can transmit e-filed returns to MeF, and only returns prepared by registered EROs are accepted.

MeF: As MeF validates and converts tax return data and generates statistical and summary data, it collects and stores it in the MeF database.  Converted tax data is also transmitted to downstream systems to be perfected (i.e., makes changes to inaccurate return data).  Downstream systems “perfect” the tax data, not MeF.
The MeF database houses taxpayer entity data, tax return data, summary data, statistical data, transmission files, and acknowledgement files (validation results).  A complete list of MeF database tables and data elements can be found in the MeF Data Model View (DMV); that is, the Data Model Modernized e-File Project, Release 4, MS 4B,Version 1.6, September 1, 2006, as well as the associated Data Model Supplement entitled, Data Model: Enumerated Data Supplement, Modernized e-File Project, Release 4, MS 4B, Version 1.6, September 19, 2006.  The DMV contains the MeF data dictionary.  The following taxpayer Identification data is housed in the MeF database:
Taxpayer Identification Number (TIN)
Uniquely identifies taxpayer
For partnerships (Form 1065/1065B, Schedule K-1), returns can include partner EIN or SSN
Subsidiary EINs
Uniquely identifies subsidiaries
Document Locator Numbers (DLN)
Uniquely identifies tax return to the organization taxpayer
Name Control
Identifies taxpayer
Return ID
Uniquely identifies tax return
Header.xml
Contains EIN and taxpayer name and address

2.b. What Federal Agencies are providing data for use in the system?
Financial Management Service:
Only the Financial Management Service (FMS) supplies MeF with data.  FMS supplies MeF with the official list of Routing Transit Numbers (RTNs).  This list is updated as RTNs are added and deleted.  There is no update schedule; as financial institutions are added and deleted by the FMS, updates are distributed.

2.c. What State and Local Agencies are providing data for use in the system?
Transmitters and EROs submit state tax returns to be forwarded to the appropriate participating states.  The states send receipts and state acknowledgements to MeF after they pick up the state returns designated for them.  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, exempt organizations, and partnerships.  

2.d. From what other third party sources will data be collected?
External Trading Partners
The Third Party or Trading Partner community is made up of Transmitters, Electronic Return Originators (EROs), Software Developers, On-Line Providers, Large Taxpayers and Intermediate Service Providers.
Trusted users (Transmitters and Electronic Return Originators (ERO)) prepare and transmit tax return data to the MeF system either through the EMS or RUP portals.  EMS and the RUP forward the transmission files to the MeF application server.  All external trading partners are registered via E-Services, and authorized by, the IRS to e-file.  These transmission files contain tax return data, which include the following taxpayer Identification data:

Employer Identification Number (EIN),
Name and Address. 
Some returns will contain EINs and names and addresses of subsidiary corporations, exempt organizations, and partnerships.
For partnerships (Form 1065/1065B, Schedule K-1), returns can include partner EIN or SSN.

Software Developers develop the tax preparation software used by taxpayers or their preparers to prepare their returns.  Only e-filed returns prepared by IRS (MeF) authorized tax preparation software are accepted by the MeF system.
EROs prepare and convert e-filed returns into IRS format (XML) using the approved tax preparation software.  MeF only accepts returns prepared and converted by authorized EROs.
Transmitters batch returns prepared and converted by EROs into transmission files.  They then transmit the files to MeF.  In addition to having to be authorized by the IRS to transmit e-file returns, all Transmitters must have a valid login and password to transmit.  A2A (which was implemented previously in Release 3.2) enables remote applications, especially those belonging to Transmitters or state governments, to authenticate themselves to the Registered User Portal and transmit Web Services requests to the Portal where they will be processed by WebSphere on the MeF SOAP Web Application Server.  A major use of this feature is in the transmission of returns.  In Release 4, Fed/State functionality will be added to the IFA processing channel; whereby, a user can log in through a secure https web site and file returns to MeF.  State returns would be made available to States for retrieval.

2.e.  What information will be collected from the taxpayer/employee?
Taxpayer:
The MeF system collects the following taxpayer tax return and return related information.  It only accepts returns filed by organizations, specifically corporations, exempt organizations, and partnerships:

• Returns 1120 and 1120S, Corporate income tax returns, including schedules, forms, and attachments required by law or regulation.
• Information documents 990, 990-EZ, 990-PF and 1120-POL, including schedules, forms, and attachments required by law or regulation.
• Returns 1065 and 1065B, Partnership income tax returns, including schedules, forms, and attachments required by law or regulation.
• Other attachments are generic statements.  They are listed in IRS filing instructions and tax booklets. 
• Form 8868, Application for Extension of Time to File an Exempt Organization Return.
• Form 7004, Application for Automatic Extension of Time to File Corporation Income Tax Return  
• Form 8736, Application for Automatic Extension of Time to File U.S. Return for a Partnership, REMIC, or for Certain Trusts
• 2290, Heavy Highway Vehicle Use Tax Return
• 720, Quarterly Excise Tax Return
• 8849, Claim for Refund of Excise Taxes
• State corporate income tax returns for participating states whether or not the Federal corporate return is filed with it.

As part of the registration process so that an organization (i.e., exempt organization, corporation, or partnership) can file a tax return via e-file (e.g., via IFA processing), an organization assigns a Responsible Official (up to 5 individuals in the organization) or Designated Representative as the primary point of contact.  Those individuals would have to supply the following identifying information as part of the registration process in order to secure a user ID, password, and 5-digit PIN (refer to IRS e-file for Large Taxpayers Filing Their Own Corporate Income Tax Return, dated February 2006 and located on the www.irs.gov web site for more information):
Name, Address,Phone,SSN,Date of Birth, Adjusted Gross Income (from current or one previous tax year).

Employee:
The login process along with all login related auditable events are conducted outside MeF by the Infrastructure Employee User Portal.  MeF does audit all employee transactions as they request data from the MeF Return, Request, and Display and Reports Applications.  For each audited transaction, the employees’ user ID (SEID), TIN, IP address of message originator, event ID, date/timestamp, and payload is written to SAAS.

3.a. How will the data collected from sources other than IRS records and the taxpayers be verified for accuracy?
The list of RTNs provided by the FMS is the only data supplied to MeF from other than IRS records or taxpayers.  FMS is an agency of the Department of Treasury and considered a trusted user, and therefore their data is assumed accurate.  MeF relies on FMS to ensure the integrity of their own data accuracy.
EROs are required by law and regulation to supply accurate tax return data to the IRS.  (See the list of regulations later in this document.)  MeF retains the original transmission file (see retention rates) so that a record of returns as submitted is maintained.

3.b. How will data be checked for completeness?
MeF validates all tax returns against the XML schemas and business rules which can be found on the following two pages, XML General 1120/1120-F/1120S Technical Information & Archives and Exempt Organization Modernized e-File XML Schemas and Associated Information.
XML schemas are developed and maintained by the IRS to ensure data integrity and completeness of all tax return data submitted to MeF.  Each return prepared and submitted to MeF for e-filing must adhere to the schemas.  If a single data element fails the schema integrity check, the tax return is rejected.
XML schemas enforce structure and integrity upon the data.  One or more schemas exist for each form, schedule, and attachment.  All MeF e-file tax returns must be created using the schemas as a blueprint.  If the tax return does not meet the structure and data integrity rules as defined by the schemas, the MeF system rejects the return. 
The customer, Electronic Tax Administration (ETA), supplies the business rules for each return type.  MeF enforces the rules against the tax returns using a business rules engine.  Business rules enforce relationships between data and forms.  For example, a business rule might state, “If the taxpayer declares capital gains, then a schedule D must be attached to the return.”  When MeF validates returns against the business rules, if it encounters a return that declares a capital gain without an attached Schedule D, the tax return is rejected.  The rejected returns remain on the MeF system.  They are used by the e-Help Desk while helping preparers and EROs understand and fix the errors.  They are removed from the system at the end of the tax year with the rest of the tax data.
State returns received through MeF are validated against the NAP as a service to the states.  MeF acts as a pass through to the participating States.

3.c. Is the data current?  How do you know?
Schemas enforce format and content restrictions on all data elements, on all forms and schedules.  New schemas are issued each year to reflect the current year’s tax returns.  If a single data element fails the schema check, the return is rejected.
Business rules enforce relationships between data and between forms and schedules.  A new set of business rules are issued along with each new set of schemas.  If a tax return fails to validate against a business rule, the return is rejected. 
FMS supplies MeF with the official list of Routing Transit Numbers (RTNs).  This list is updated as RTNs are added and deleted.  There is no update schedule; as financial institutions are added and deleted by the FMS, updates are distributed.
Taxpayer entity information such as EINs, name controls, and filing requirements are provided to MeF by the National Account Profile (NAP) system.  This data is housed in the MeF database and is used to validate entity information on the e-filed tax returns.  This data does not contain taxpayer financial data.  NAP transmits updates to MeF once each week using the EFNS/EFTU FTP Server Utility. 
Taxpayer entity information such as EINs, name controls, and filing requirements are provided to MeF by the National Account Profile (NAP) system.  This data is housed in the MeF database and is used to validate entity information on the e-filed tax returns.  This data does not contain taxpayer financial data.  NAP transmits updates to MeF once each week using the EFNS/EFTU FTP Server Utility. 
Finally, each tax return must include the correct tax period and tax year.  If the tax period and year fail to validate against the business rule, it is rejected. 

4.  Are the data elements described in detail and documented?  If yes, what is the name of the document?
Yes.  All MeF data elements are documented in the MeF Release 4 Data Model View. 
 
Access to the Data

1.  Who will have access to the data in the system (Users, Managers, System Administrators, Developers, Others)?
To access the MeF system, all employees must submit a Form 5081.  The employee's manager must approve the Form 5081.  The Form 5081 describes the employee's responsibilities accessing, handling, and disclosing data retrieved from the system.  The Form 5081 procedures describe circumstances under which employees may share data with other individuals (management approval), including requests from other employees and Auditors from TIGTA.  The employee signs the Form 5081 indicating s/he has read the security rules and agrees to abide by them.  A Manager approves the employee’s Form 5081 request before access to the system is granted.  There are no contractors working the e-Help Desk.

IRS e-Help Desk Personnel:
e-Help Desk personnel provide support to Transmitters and EROs.  Usually, this help is in the form of explaining errors that resulted in rejected returns and transmissions.  e-Help Desk personnel can view transmission, ERO, tax return, and validation results (acknowledgements).  e-Help Desk Personnel cannot change data.

IRS Error Resolution Tax Examiners:
ERS Tax Examiners correct errors identified by downstream processing systems like GMF.  As an aid to correcting the problem, the tax examiner accesses the MeF system to look at the tax return.  The tax examiner cannot modify the MeF return.  All corrections must be entered into the Error Resolution System.  These tax examiners can view accepted returns and perfected data only.  No consolidated, summary, acknowledgement, Transmitter, or ERO data is accessible by them.

IRS Auditors:
Tax Return Auditors can view returns they are auditing (if they were e-filed through MeF).  However, the auditor cannot make changes to the return through MeF.  IRS auditors can view accepted returns and perfected data.  All rules concerning access are observed and enforced by the employee’s immediate supervisor not software or applications.

IRS Classifiers:
IRS Classifiers use MeF to view accepted tax returns and perfected data only.  They cannot modify the tax return through MeF.  A classifier decides whether or not a return should go to audit.  No specific returns are assigned to the classifier; they look at a broad range of returns which is part of their duties.  All rules concerning access are observed and enforced by the employee’s immediate supervisor, not software or applications.

IRS Customer Service Representatives (CSR):
Customer Service Representatives can view accepted tax returns and validation results.  CSRs handle taxpayer inquiries that come in by phone over the 800 numbers.  Sometimes those inquiries require the CSR to look at the validation results of taxpayer’s tax return.  MeF is just one tool among many that the CSR uses to respond to taxpayer questions. 

IRS Managers:
Managers of the above types of employees have the same level of access to data as their employees.  Managers can also access MeF report data.  As previously stated, there is no employee information on MeF.  However, sometimes these managers have to look at the data their employees are looking at.  Like all employees, managers must prepare and submit Form 5081 to access this data.  Like all other employees, the Form 5081 must be approved by their supervisors and the security officer.

Transmitters:
Transmitters (external users) are registered with the IRS and authorized to transmit return files to MeF and retrieve acknowledgement files from MeF.  They log in and retrieve (pick up) the acknowledgements; acknowledgements are never systematically forwarded to them.  (See section 5a for a detailed explanation of how these users log in, how they transmit, and what system they retrieve acknowledgements from.)
Transmitters can also use A2A. The techniques involved will cause remote applications belonging to Transmitters to authenticate themselves to the Registered User Portal and transmit Web Services requests to the Portal where they will be processed by WebSphere on the MeF SOAP Web Application Server.  A major use of this feature is in the transmission of returns and retrieval of acknowledgements. 

System Administrators:
System Administrators will have access to MeF to perform scheduled maintenance and other regular administrator duties.  System administrators have root access to the MeF system.  Accesses to the MeF system, along with each system command executed by the administrator are auditable events.  These events are stored in audit files and reviewed by the security officer for any unauthorized activities.  Unique logins for each system administrator ensures that all audited events can be traced back to their source. These administrators could be contractors.  All contractors are required to have a full background investigation.  Once they have passed their background investigation, they will follow the same security procedures as an IRS employee system administrator.  These procedures are contained in IRM 25.10.5., and 25.10.9.

Database Administrators:
Database Administrators will have access to MeF to perform regular database maintenance duties.  Database administrators have access to the data that resides in the MeF database.  No tax return related data, including summary and statistical data derived from the tax return data, is allowed to be modified.  Access to MeF data by the database administrator, and all other users, are auditable events.  These events are stored in audit files and reviewed weekly by the security officer for unauthorized access to data.  Each database administrator has a unique login and password so that all audited events can be traced back to the source.  These administrators could be contractors.  All contractors are required to have a full background investigation.  Once they have passed their background investigation, they will follow the same security procedures as an IRS employee system administrator.  These procedures are contained in IRM 25.10.5., and 25.10.9.

End Users (i.e., within exempt organizations, corporations, and partnerships):
As part of the registration process so that an organization (i.e., exempt organization, corporation, or partnership) can file a tax return via e-file (e.g., via IFA processing), an organization assigns a Responsible Official (up to 5 individuals in the organization) or Designated Representative as the primary point of contact.  The following descriptions provide a background for those types of users.  Refer to IRS e-file for Large Taxpayers Filing Their Own Corporate Income Tax Return, dated February 2006 and located on the www.irs.gov web site for more information.

Responsible Official:  An individual with responsibility for and authority over the e-file operation of an organization (exempt organization, corporation, partnership).  An individual who is the first point of contact with the IRS and has the authority to create, revise and sign your e-file Application.  An individual who is responsible for ensuring that your corporation adheres to the provisions of all publications and notices governing IRS e-file.  (If one individual cannot fulfill these responsibilities, up to four additional Responsible Officials may be identified [for a total of five]).  An individual who is a U.S. citizen or legal resident alien (lawful permanent resident), and have attained the age of 21 as of the date of the application Note: The Responsible Official is not required to be a Corporate Officer or a Principal of the Firm.  The following information is needed for each Responsible Official who is to be added to the organization’s e-file Application as part of registration: Name, Social Security Number, Title, Date of Birth, Position Title, and e-mail Address.

Delegated User:  An individual within your firm/organization, other than a Responsible Official, who is an employee, partner, or other member of the firm/organization (exempt organization, corporation, partnership) or who has a business relationship with the firm/organization.  The information needed for each Delegated Users added to an organization’s e-file Application includes: Name, Social Security Number, Title, and e-mail Address. 
The organization will determine what “authorities” the Responsible Official(s) and Delegated User(s) can have.  The Responsible Official that creates the organization’s e-file Application can authorize any or all of the following permissions for either Responsible Officials or Delegated Users: View the organization’s e-file Application Information, Update the corporation’s e-file Application Information, Sign and Submit the organization’s revised e-file Application, Add, delete or change Responsible Officials, and Be designated as the organization’s Internet Transmitter.

2.  How is access to the data by a user determined? 
Access is controlled using Role Based Access Control (RBAC) process.  Electronic Tax Administration (ETA) has defined the end users’ roles with the Business Operating Divisions (BODs), Large & Mid-Size Business (LMSB), Small Business/Self Employed (SB/SE) and Tax Exempt & Government Entities (TE/GE).  BODs are responsible for determining which employees are assigned to which role(s).  Infrastructure system administrators set up user access controls.  This includes setting up the relationships between users and roles.  Security Administrators will audit all users’ activities within the infrastructure and MeF.  The System Administrators’ managers, the Security Officers, and the MeF Project Officer monitor the administrators’ access and activities.  The level of access granted is based on job functions, level of responsibility, “need-to-know” and separation of duties.
In addition to the above access procedures, all employees must submit a Form 5081 to access the MeF system.  The employee's manager must approve the Form 5081.  The Form 5081 describes the employee's responsibilities accessing, handling, and disclosing data retrieved from the system.  The Form 5081 provides procedures and consequences for unauthorized disclosure of tax returns or return information.  The employee signs the Form 5081 indicating s/he has read the security rules and agrees to abide by them.
Outside contractors can be hired to perform system administrator duties for MeF and the underlying Infrastructure components.  All contractors are required to have a full background investigation / high risk level.  Once they have passed their background investigation, they will follow the same security procedures as an IRS employee system administrator.  These procedures are contained in IRM 25.10.5., and 25.10.9.
Only authorized registered external trading partners can transmit return files to MeF and, along with participating States, retrieve their acknowledgements (validation results).  External trading partners access the MeF application via the Internet (RUP) or EMS.  All Transmitters and participating states will be required to complete the new e-Services IRS e-file Application and pass suitability checks.  By law and regulation, all e-filers and states must abide by the same disclosure rules (See Section 5b for the list of regulations and procedures that apply).  To register, all Responsible Official(s) and Delegated User(s) within an organization (i.e., exempt organization, corporation, partnership) who will be responsible for e-filing corporate returns and/or creating or maintaining corporate e-file Applications will need to individually register with e-Services. To register, s/he would need to select the “Not yet registered?” link at http://www.irs.gov/taxpros/article/0,,id=109646,00.html
The following identifying information is needed to register: Name, Address, Phone, SSN, Date of Birth, and Adjusted Gross Income (from current or one previous tax year).  Directions are then provided on how a user should construct a robust Username, Password, and five-digit Personal Identification Number (PIN) which will represent his/her electronic signature.  The PIN is used by the Responsible Official(s) and Delegated User(s) of a Transmitter to sign the organization’s e-file Application.  After successful registration online, the IRS will mail a confirmation number to the official address of record.  That user will have 28 days from the initial registration to access e-Services and input the confirmation number to successfully complete your registration.  E-Services passwords expire every six (6) months as a security precaution. Users receive screen notices within 15 days of expiration and an e-mail within 10 days of expiration.

2. a. Are criteria, procedures, controls, and responsibilities regarding access documented?
Yes.  Access procedures are documented with the On-Line Form 5081 process.  Roles and procedures for assigning roles are defined in the MeF roles document.  Publication 4164, Modernized e-File Guide for Software Developers and Transmitters, contains system access procedures for external trading partners.  This document can be found at http://www.irs.gov/taxpros/providers/article/0,,id=97626,00.html
. All employees must submit an OL (Online) Form 5081, Information Systems User Registration/Change Request to access the MeF system.  The employee's manager must approve the Form 5081.  The Form 5081 describes the employee's responsibilities accessing, handling, and disclosing data retrieved from the system.  The Form 5081 procedures describe circumstances under which employees may share data with other individuals (management approval), including requests from other employees and auditors from TIGTA.  The employee signs the Form 5081 indicating s/he has read the security rules and agrees to abide by them.
All entities who wish to play the role of Transmitters must complete an IRS e-file Application.  Most applicants must undergo a suitability check.  Applicants who pass suitability are assigned ETINs, and then are allowed to transmit.  All Transmitters agree to abide by all rules and regulations governing Transmitters when they sign the IRS e-file Application.  (See section 5b for a list of regulations and procedures that apply).  Participating states must follow the same the IRS e-file Application procedures.

3.  Will users have access to all data on the system or will the user's access be restricted?  Explain.
User access will be restricted.  All user access is role based.  For example, Transmitters will only be able to transmit return files to MeF and pick up the validation results contained in the acknowledgement files.  Error Resolution Tax Examiners will only have access to accepted returns.  E-Help Desk personnel can access accepted and rejected tax returns along with their validation results.  System Administrators have access to the underlying system resources.  Their access to these resources are restricted based on their duties.  End users (i.e., Responsible Officials and Designated Users of an organization/transmitter) will have the ability to access the IRS account of their respective organization through, for example, A2A (direct application data processing of an organization’s tax returns) or IFA (individual submission of an organization’s tax returns as authorized).

4.  What controls are in place to prevent the misuse (e.g. browsing) of data by those having access?
All user transactions within the EUP and RUP are audited and written to SAAS.  The employee’s user ID (SEID), TIN, IP address of message originator, event ID, date/timestamp, and payload data are written to the SAAS log.  Requirements are being developed to create reports that will be issued to managers weekly and quarterly that identify employees who have potentially accessed taxpayer data inappropriately.

5.a   Do other systems share data or have access to data in this system?  If yes, explain.
Yes.
(1) Electronic Management System (EMS)
Transmitters can also transmit return files and retrieve acknowledgements through EMS.  EMS is the existing IRS portal for electronic filing.  EMS handles all non-Internet access from the outside (T-1s, ISDN, dial-up).  EMS also authenticates and authorizes Transmitters prior to allowing them access.  EMS forwards the transmission file to the MeF server if it passes validation. 

(2) TPDS (e-Services)
The e-Services TPDS provides MeF with daily extracts of ETIN, EFIN, and Software ID information.  No SSNs or EINs are included in this data.  MeF uses this information to validate Transmitters, EROs, and approved software tax preparation packages.  A PTIN is a preparer Identification number; and that data is not included in this information.

(3) General Mainframe Framework (GMF)
GMF is the entry system to pipeline processing.  Both electronic and paper returns are input to GMF.  MeF converts all accepted returns into GMF format then forwards them to GMF.
MeF receives paper filer EINs from GMF of all returns accepted on MeF.  This data is used to detect duplicate filings.  All duplicate returns are rejected.  Duplicate returns are rejected the same way returns that fail any other business rule are rejected.  Rejected returns are not processed through the system.  They remain on the MeF system with the other transmissions, returns, and database.  See Maintenance of Administrative Controls for retention periods.
MeF will send International returns to the Philadelphia GMF ALN.  The Philadelphia GMF application resides on the same Unisys in MCC as the GMF application MeF currently (release 1) sends returns to.  MeF will batch international returns separately and transmit those batches to the Philadelphia (International) GMF ALN using the same EFNS/EFTU utility.  MeF will continue to send all other type returns to the GMF ALN it uses in release 1.

(4) IDRS – End-of-Day (EOD)
MeF sends all subsidiary corporations and tax-exempt organizations subsidiaries’ EINs included on consolidated returns to EOD.  EOD uses the EINs to satisfy subsidiaries’ filing requirements and transfer any credits to parent corporation.
End-of-Day records for form 8873 (990 TEGE) will be created batched and forwarded to IDRS.  No change to the existing interface to IDRS and EOD record layouts are required

(5) Electronic Federal Tax Processing System (EFTPS)
MeF sends debit payment information to EFTPS.  EFTPS is an IRS system that processes payment vouchers and credits taxpayer accounts for payments made.  Taxpayers can choose to have the IRS perform an electronic transfer of funds to satisfy outstanding balances.  If a taxpayer chooses this option, MeF forwards entity and account information to EFTPS.
The debit payment information consists of the following:
 (1) EIN,
 (2) Name Control,
 (3) Name and Address,
 (4) Bank Account Number,
 (5) Routing Transit Number,
 (6) Transaction Amount (debit),
 (7) Payment Date,
 (8) Tax Period
 (9) Type of Account
 (10) Tax Type
 (11) Taxpayer's Daytime Phone Number

(6) Electronic Tax Administration Report Administration System (ETARAS)
ETARAS reports summary and detailed information on electronic filing to IRS management.  MeF forwards summary and detailed tax information to ETARAS.
(ETARAS is provided the same summary and statistical information described above in the Data-in-the-System Section.)

(7) M-TRDB
MeF inserts each accepted return (passes MeF validation) into M-TRDB, the authoritative source of MeF e-filed tax return data. 

(8) National Account Profile (NAP)
The NAP contains entity information and filing requirements for taxpayers.  (The NAP data contains the taxpayer’s EIN, name control, and tax return filing requirements).  NAP provides MeF with a weekly update of entity information for all returns accepted in MeF.  This information is used to validate taxpayer entity information on each tax return transmitted to MeF.

(9)  Participating State Agencies
The MeF System provides a single point of transmission and retrieval (i.e., pass-through) for all state submissions and acknowledgements.  The MeF system shall accept stand-alone organization (i.e., exempt organization, corporation, partnership) state returns, as well as organiztaion state returns linked to a Federal tax return.  The MeF System shall reject a state submission if it cannot identify the state, or the state is not a participant, or the federal return is rejected and the state return is attached to this federal return.  In a joint Fed/State filing, if federal return is rejected, state return will be rejected.  MeF application services will send files to external systems as part of a response to an authorized request from that system.
The State Submission Manager component is responsible for processing all state submissions. It determines if a state submission should be made available to the targeted state and, if so, makes the submission available to the state for pick up. It is responsible for making copies of an IRS EO submission for the state(s), and is responsible for retrieving state submissions for a specified state. The State Submission Manager invokes services provided by other components to fulfill its responsibilities. It invokes the State Submission Validation component to determine if the submission should be made available to the state, and the State Copy Processing component to make copies of an IRS EO submission
The Submission Storage component is responsible for saving a submission in a database. It takes a submission as input, creates a TOC (Table of Contents) and a document index for documents in the submission, and saves the submission, the TOC, and the document index in the database. It provides two interfaces for saving a submission: one to save a Federal submission in M-TRDB and another to save a submission in the MeF database. The Submission Storage component is invoked by the IRS Submission Manager component to save a submission.  See Appendix G for more information.
High level information regarding the agreement between the IRS and participating states can be located in Memorandum of Understanding (MOU) for the 1120 Federal/State Electronic Filing Program.  For more specific details defining the IRS and participating states operational requirements, refer to the Modernized eFile Interconnection Security Agreement (ISA) with Third Party Transmitters and Participating States (TPT-PS), version 3.1, August 18, 2006.

• All IRS systems that share data with MeF have the following PIA and C&A status:
• NAP – PIA approved on 5/3/2006, expiring 5/3/2009.  A C&A date was not available in the Mission Assurance Master Inventory.
• TPDS – PIA currently in development.  C&A currently in development.
• M-TRDB – PIA approved on 9/2/2003, expiring 9/2/2006 (PIA may be currently in the development phase as part of Release 4).  C&A approved on 7/1/2004, expiring 7/1/2007.
• RICS – PIA approved on 5/1/2006, expiring 5/1/2006.  C&A approved on 7/15/2006, expiring on 7/15/2009
• ETA (ETA-RAS) ETARAS – PIA approved on 5/23/2006, expiring 5/23/2009.  An approved C&A is included in the GSS
• GMF – PIA approved on 8/31/2004, expiring 8/31/2007.  A C&A date was not available in the Mission Assurance Master Inventory.
• EMS – PIA approved on 12/5/2005, expiring 12/5/2008.  C&A approved on 12/16/2004, expiring 12/16/2007.
• IDRS – PIA approved on 3/23/2006, expiring 3/23/2009.  C&A  approved on 7/1/2004, expiring on 7/1/2007.
• EFTPS – PIA approved on 4/26/06, expiring 4/26/2009.  C&A approved on 12/23/2004, expiring 12/23/2007 (FYI: EFTPS is currently undergoing a streamlined C&A.).
• BFM SPLAT ODS – Not available in the Office of Privacy PIA Inventory nor the Mission Assurance Master Inventory.

(9)  ETEC Vehicle Identification Number (VIN) Data Store
MeF sends VIN information extracted from Form 2290 to this repository to be used by the ExFirs system.

5.b.  Who will be responsible for protecting the privacy rights of the taxpayers and employees affected by the interface?
Transmitters are required by law to protect the privacy rights of taxpayers.    Revenue Procedure 2000-31 covers the responsibilities and requirements for all e-file providers.  Transmitters who wish to participate in A2A will be required, during registration, to a abide by the rules outlined in the registration process and Publication 4164

•   A tax return preparer is subject to a criminal penalty for unauthorized disclosure or use of tax return information.  See Section 7216 of the Internal Revenue Code and section 301.7216-1(b) of the regulations.

•   Section 6713 of the Internal Revenue Code establishes civil penalties for unauthorized disclosure or use of tax return information.

•   Section 301.7701-15 and Revenue Ruling 85-189 establish penalties for EROs, Intermediate Service Providers, Transmitters, and products of a software developer that alters the return information.

•   In addition to the above specified provisions, the Service reserves the right to assert all appropriate preparer, non-preparer, and disclosure penalties against an Authorized IRS e-file Provider.

•   The states are required to abide by the rules of the Memorandum of Understanding that they will sign.  The MOU will include reference to IRS Publication 4164.  The states must comply with IRS Publication 4164, Modernized e-File Guide for Software Developers and Transmitters and the Infrastructure Shared Services Interconnection Security Agreement with Modernized e-File (MeF) (Document No. PRIME-ISS-DOC-ISA-MEF) to help ensure security and privacy of taxpayer data.

Employee data is not collected and stored on the MeF system directly and therefore there is no potential for disclosure of employee information. 

6.a.  Will other agencies share data or have access to data in this system (International, Federal, State, Local, & Other)?
FMS provides data to MeF.  MeF does not share data with FMS or allow FMS to access MeF data.  As stated previously, the MeF System shall provide a single point of transmission and retrieval for all participating State submissions and acknowledgements. 

6.b.  How will the data be used by the agency?
The state returns submitted through MeF will be used to meet the filing requirements of the participating states.

6.c. Who is responsible for assuring proper use of the data?
The participating states will be responsible.  MeF does not store or act on the state returns in any manner.   MeF acts only as a pass through of the state returns from the transmitter to the state.

6.d. How will the system ensure that agencies only get the information they are entitled to under IRC 6103?
A Memorandum of Understanding (MOU) between registered states and the IRS to allow the retrieval of state returns has been prepared and must be signed by the states.  An Interconnection Security Agreement (ISA) is also provided and offers more in-depth details defining operational requirements and security measures.  These documents along with the related Publication 4164 govern the data to be submitted and the following of the Disclosure rules.  Further, the IRS is only acting as a pass through for the state returns.  This is the same information they would have received if the transmitter sent the returns directly to the states.  No other additional information is sent to the states.

Attributes of the Data

1.  Is the use of the data both relevant and necessary to the purpose for which the system is being designed?
Yes.  The data elements in the system are directly related to the IRS tax administration of the tax forms required for each tax year for exempt organizations, corporations, and partnerships.

2.a. Will the system derive new data or create previously unavailable data about an individual through aggregation from the information collected?
Taxpayer:  Statistical information is derived from the aggregation of the data received.  No individual information is currently processed for aggregation by MeF.  It is important to note that MeF, through Release 4, does not accept any individual returns. 
Employee: No.  MeF does not capture employee data.

2.b. Will the new data be placed in the individual’s record (taxpayer or employee)?
Taxpayer:  No.  Statistical and summary data are derived and aggregated from taxpayer data and cannot be traced back to the originating taxpayers.  It only accepts returns filed by organizations, specifically corporations, partnerships and exempt organizations.
Employee:  No.  MeF does not collect or store employee data, and MeF does not update any employee records.

2.c. Can the system make determinations about taxpayers or employees that would not be possible without the new data?
Taxpayer:  No.  Statistical and summary data are derived and aggregated from taxpayer data cannot be traced back to the originating taxpayers.  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, partnerships and exempt organizations.
Employee:  No.  No employee data is captured on the MeF system.

2.d. How will the data be verified for relevance and accuracy?
All consolidated data (statistical and summary) is aggregated from received taxpayer data, which has undergone validation against tax year schemas and business rules.

3.a If the data is being consolidated, what controls are in place to protect the data and prevent unauthorized access?  Explain.
Role Based Access controls user access to data.  Role Based Access is described previously in this document.  Only those users assigned roles that allow access to consolidated data can access it.  There is no special set of users that access consolidated data (statistical and summary).  If a manager authorizes a user to access this data, and the user has an approved Form 5081, the appropriate roles are assigned to the user so s/he can access this data.  End users of an organization (e.g., Responsible Officials and Delegated Users) may only access the organization’s account as assigned by their organization and as approved by the IRS.

3.b If processes are being consolidated, are the proper controls remaining in place to protect the data and prevent unauthorized access?  Explain.
No existing processes are being consolidated.  State returns are received in an encrypted format which is unopened by MeF and forwarded to the states in the same condition as received.  MeF just needs to read the State that the return applies to and the originator of the return.  Since MeF does not open or store these returns in any way, there is no capability in the MeF system to access this information.  Upon receipt, the states are responsible for preventing unauthorized access.

4. How will the data be retrieved? Can it be retrieved by personal identifier? If yes, explain.
Yes, authorized employees can retrieve and view tax return data using the MeF system’s Return, Request, and Display feature.  Role Based Access determines level of access to data.  E-Help Desk personnel, Error Resolution Tax Examiners, auditors, and customer service representatives must all be able to retrieve individual returns.  All requests for data, and responses, are audited and written to SAAS. 
The following personal identifiers are used to retrieve data:

• Employer Identification Number (EIN):  The EIN is a unique taxpayer Identification number for businesses that can be used to retrieve tax returns of specific taxpayers.

• Document Locator Number (DLN):  A DLN is assigned to each tax return accepted by the MeF system.  Each DLN uniquely identifies each tax return of an organization taxpayer.  The DLN is used to retrieve a specific tax return for specific taxpayers.

• Electronic Transmitter Identification Number (ETIN):  An ETIN uniquely identifies each Transmitter.  Taxpayer data transmitted by a particular Transmitter can be accessed indirectly by querying on that Transmitter’s ETIN.

• Electronic Filer Identification Number (EFIN):  An EFIN is a number that uniquely identifies each ERO.  Taxpayer data prepared by a particular ERO can be accessed indirectly by querying on that ERO’s EFIN.

• Global Transaction Key (GTX Key):  A GTX Key is a number generated that uniquely identifies each transmission and its acknowledgement.  User can view validation results and tax data contained in an acknowledgement file and transmission file by querying on GTX key.  (e-Help Desk personnel and customer service representatives can view acknowledgements.  e-Help Desk personnel can view transmission files.  Once again this is role based.)
 
• Submission ID:  Submission ID is a number generated by ERO that uniquely identifies tax return.  e-Help Desk personnel will be able to query using the Submission ID.,

• Message ID:  A Message ID is a number generated by a Transmitter that uniquely identifies a transmission file.  e-Help Desk personnel can access tax return data contained in a transmission file by querying on Message ID.

5. What are the potential effects on the due process rights of taxpayers and employees of:
a. Consolidation and linkage of files and systems;
Taxpayer:  Each return submitted is validated against the schemas and business rules for that return type.  If a return fails validation, it is rejected and the taxpayer must make the necessary changes and resubmit the return.  If the return passes validation, it is accepted and processed through the Pipeline.  Tax data is then, converted and shared with other IRS tax processing systems.  The data is converted into IRS proprietary formats and is then forwarded to the appropriate downstream systems.  It only accepts returns filed by organizations, specifically corporations, partnerships and exempt organizations.  Individual tax returns are not filed through MeF.  Any individual information derived from IRS Forms (e.g., Form 1065, Schedule K-1) or through the e-File registration process (i.e., for an organization’s Responsible Officials or Delegated Users) is not consolidated or used for any intention beyond the stated business purpose of the MeF system.
Employee: Although MeF does not store employee data, it depends on the Infrastructure e-Trust and integrity of the login process for accurately identifying users who access the system.

b. Derivation of data;
Taxpayer:  None.   
Employee:  MeF does not derive any consolidated employee data.

c. Accelerated information processing and decision making;
Taxpayer:  None.
Employee:  None.

d. Use of new technologies;
Transmitters and EROs will be able to use the Internet to file their corporate taxpayer, exempt organization, and partnership clients’ tax returns through the IFA channel. 

How are the effects to be mitigated?
Transmission files containing the original tax return data as transmitted to MeF (IRS) is retained on the MeF system for the retention periods stated in Maintenance of Administrative Controls, item 2a of this PIA document.  Retaining this data gives the taxpayer an opportunity to challenge and to correct taxpayer data collected by MeF and converted with downstream systems.

Maintenance of Administrative Controls

1.a.  Explain how the system and its use will ensure equitable treatment of taxpayers and employees.
No taxpayer or group of taxpayers is treated differently from any other taxpayer of group of taxpayers.  All tax returns must adhere to the same standardized and published XML schemas and business rules for the same return type.  Schemas validate data element formats and ranges on all forms and schedules.  Business rules enforce relationships between data, forms, and schedules.  All returns must adhere to the same rules.  There are no exceptions.
No employee or group of employees is treated differently by the system than any other employee or group of employee.  All employees must have a user ID (SEID), a password, and an assigned role.  All employee transactions are audited and written to the SAAS.  There are no exceptions.

1.b. If the system is operated in more than one site, how will consistent use of the system be maintained at all sites?
The MeF system operates at only one site.  The MeF Application Server resides at the Enterprise Computing Center-Martinsburg (ECC-MTB).

1.c. Explain any possibility of disparate treatment of individuals or groups.
Because of the processes described above in item 1a, there is no disparate treatment of individuals or groups.  The MeF system is used for the collection of the tax returns regardless of whose return it is.  The system does not have the ability to discern differences between taxpayers.

2.a. What are the retention periods of data in this system?
Retentions periods for the following data apply: (Review IRM)

Transmission Files: 
Retention Period: 3 years.
Authorizing Source: IRM 1.15.3, General Records Schedule 20
MeF System Requirements Report
Acknowledgement Files:
Retention Period: 3 years.
Authorizing Source: IRM 1.15.3, General Records Schedule 20
MeF System Requirements Report
Database:
Retention Period: 3 years.
Authorizing Source: IRM 1.15.3, General Records Schedule 20
MeF System Requirements Report

2.b. What are the procedures for eliminating the data at the end of the retention period?  Where are the procedures documented?
At the end of the retention period, data will be purged from the MeF system according to standard IRS procedures – IRM 25.10.1.6.4.6 (01-01-2002).
Purge requirements are documented in the MeF Use Cases.   Purge procedures are included in the System Administrator manual, Trusted Facility Manual, and Technical Contingency Planning Document. 
Two RISs have been issued to define the report requirements and there is a group working the issue.  (The RIS numbers are RIS BSM-3-0005A00 and BSM-3-000600.  This issue impacts MeF, but it is a modernization-wide issue and is being worked at that level.  These reports must be developed for all modernization applications, not just for MeF.  These are not MeF reports.  High-level requirements have been defined; however, Modernization has not yet determined when these reports will be developed and made available to management. 

2.c. While the data is retained in the system, what are the requirements for determining if the data is still sufficiently accurate, relevant, timely, and complete to ensure fairness in making determinations?
New schemas and business rules are issued for each new tax period.  Each transmitted tax return must conform to the schemas and business rules or the system will reject it.  Each tax return must contain the tax year and tax period in the data.  If the tax year and tax period declared in the data does not match the tax year and tax period in the business rules the return is also rejected.   No user or system can modify tax return information that resides on the MeF system.  ERS does not modify MeF data.  ERS personnel modify tax returns that come from MeF, but those changes are fed into M-TRDB, not MeF.  (The ERS relationship with M-TRDB would be addressed in the M-TRDB PIA.)
All data received from other IRS systems for the purposes of validating tax returns is updated on a daily or weekly basis, depending on the type of data. 

3.a Is the system using technologies in ways that the IRS has not previously employed (e.g. Caller-ID)?
Yes.  IRS will allow corporations, partnerships, and Exempt Organizations to e-file their tax returns and information documents through Transmitters over the Internet.  The infrastructure Registered User Portal RUP is used for this.  As part of Release 4, the IFA channel will be available to support these submissions for Federal and State Organization/Transmitter tax returns.

3.b How does the use of this technology affect taxpayer/employee privacy?
Risks for potential disclosure exist.  However, IRS infrastructure and application architects have implemented safeguards: firewalls defends against network attacks, encryption protects data from unauthorized viewing, https for the IFA channel provides a secure web site for e-filed tax return submissions, virus software scans data for potential virus and worm attacks, logins and passwords enforce user authorization, role-based access restricts access to data to authentic users, and audit trails record all user transactions.  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, partnerships and exempt organizations.

4.a Will this system provide the capability to identify, locate, and monitor individuals?  If yes, explain.
No.  MeF is not designed to identify, track, locate, or monitor individuals and will not be used for any identification purposes.  MeF is designed to process e-filed tax returns for organizations.  It is important to note that MeF, through Release 4, does not accept any individual returns.  It only accepts returns filed by organizations, specifically corporations, partnerships and exempt organizations.

4.b. Will this system provide the capability to identify, locate, and monitor groups of people?  If yes, explain.
No.  MeF is not designed to identify, locate, and monitor groups of people.  However, since the Infrastructure assigns roles to users, any concerns or background information from the Infrastructure level would fall within the scope of the M-TRDB system (see the M-TRDB PIA for more information regarding infrastructure level controls).

4.c.  What controls will be used to prevent unauthorized monitoring?
MeF does not monitor individuals or groups of individuals; however, audit trail data is collected in SAAS.  Managers cannot request to monitor individuals or groups of individuals without probable cause.  Procedures are being developed for this process.  The IRS has issued two RIS’s to define reports and procedures and work is ongoing.  The RIS numbers noted in the Maintenance of Administrative Controls section, item 2b of this PIA document provide a reference to that background information.  This requirement is being satisfied at the program level.  Also, see Appendix H for more details.
 
5.a  Under which Systems of Record Notice (SORN) does the system operate?  Provide number and name.
MeF operates under the following System of Records Notices:

• Treasury-IRS 22.062 Electronic Filing Records
• IRS 50.001 – Employee Plans and Exempt Organizations Correspondence Control Records
• Treasury-IRS 34.037 IRS Audit Trail and Security Records
• IRS 24.046-CADE Business Master File (BMF) (Formerly: Business Master File (BMF)).

5.b. If the system is being modified, will the SORN require amendment or revision?Explain
This is the Privacy Impact Assessment for Release 4.  Per discussion with the Disclosure Analyst, the SORN does not need to be modified.  With each future release, the MeF Project Office will coordinate with the Privacy Advocate’s office to update the Privacy Impact Assessment and System of Records Notice. 

APPENDIX A – Data Model View (DMV)

The Data Model View can be found at: http://bsm.web.irs.gov/mef/review.htm

Name From Web Site Date Official Document Name
Data Model
9/1/06 Data Model Modernized e-File Project, Release 4, MS 4B,Version 1.6, September 1, 2006

Data Model Supplement
9/19/06 Data Model: Enumerated Data Supplement, Modernized e-File Project, Release 4, MS 4B, Version 1.6, September 19, 2006
 
APPENDIX B – Business Objects Reports in MeF 4.0

The Reports information and screen shots provided below offer a review which, in part, indicates the data contained with such reports.  For a comprehensive review, refer to the MeF Reports Manager Guide for Release 4. 
All of the reports can be found at: http://bsm.web.irs.gov/mef/review.htm

Name From Web Site Official Document Name
Reports Manager Guide Updates
MeF Reports Manager Guide for Release 4

Since the MeF Reports Manager Guide for Release 4 was not available as of this writing, I have included an excerpt form the Release 4 Use Case regarding Reports at the end of this Appendix.
Of particular interest for Privacy is the 6 reports listed below as being emailed of which 4 contain SBU data and included in the Reports Manager Guide.

REPORTS

This section describes the reports to be produced by the e-File system. All reports are to be made available to the Test (ATS) and Operational system. 
As described in the “Run Management Reports” Use Case, reports can be scheduled to be generated nightly, and/or they can be generated in real-time.
Two Scheduled reports, a “Daily Report’ and an ‘YTD Report”, are generated nightly for each report category.  The user can specify values for the two report options“ Tax Type” and “Business” for Scheduled reports.  The value for the third report option, “Report Period”, is fixed for these reports.  It is set to “day” for the Daily reports, and “YTD” for YTD reports.
Reports generated in real-time are also referred to as “Dynamic” reports.  The user can specify values for all three report options- “Tax Type”, “Business”, and “Report Period” for Dynamic reports.
The structure of the Scheduled reports is the same as that of the Dynamic reports. 
There are several categories of reports:
• Management
• EFTPS
• Accounting
• Operations
• Audit
• State
All reports will have a:
• Title
• Report number
• Report date
Each table in the following sections describes one or more reports that can be generated by selecting the report and the associated options. The columns in these table are as follows:
• Group Report By - This is the first column in the report.  Counts are displayed for each value in this column.
• Report Period - The date range options for the report.
• Tax Type - The tax type options for the report, such as 1120, 1120S, etc.
• Business - The business type options for the report, such as SB/SE, LMSB, etc.
• Breakdown - The rest of the columns in the report.
• Order Report By - The default for each report is to be sorted by the first column.  If the report is available sorted by a different column, it is listed here.
• State Submission Category – Submission category for the report e.g., Corporate, EO, etc.
• Additional Prompt – Transmitter ETIN, or state, as appropriate for a state report.
o Corporate and Partnership Income Management Reports
The breakdown between LMSB and SB/SE for the purpose of these reports will be as follows:
LMSB – Businesses with assets of $10 million or more
SB/SE – Businesses with assets of less than $10 million. 
Assets for the 1120 are found in Field D, Seq. 0150 and for 1120S in Field E, Seq. 0150.
Assets for the 1065 and 1065-B are found in Schedule L, Line 14(b).

The Business Type of Form 7004 (Application for Automatic Extension of Time To file Corporation Income Tax Return) is determined by the type of return for which the form is filed.
If the type of return to be filed is 990-C, then Business Type is LMSB.
If the type of return to be filed is 1120-POL, then Business Type is TEGE.
If the type of return to be filed is other than 990-C and 1120-POL, then Business Type is SB/SE.
Report: BMF-M001: Track Total Transmitted Returns
Description: Track volume of daily and YTD total returns transmitted, accepted, rejected, % rejected, total EFT (Direct Deposits), total EFW (Electronic Funds Withdrawal) payments, total checks (returns with a refund but no Form 8050), and total balance due by EFIN, District Office (first 2 digits of EFIN), Service Center and LMSB vs. SB/SE. Provide a count of Participating EROs.   Provide a total sum for each element of the breakdown. When requested, show the breakdown by Asset Range (Under $10 Million, $10-25 Million, $25-50 Million, $50-100 Million, $100 Million Plus) for an EFIN.

APPENDIX C – Application to Application (A2A)

• One of the principal new features of Release 3.2 is the enablement of Application-to-Application (A2A) interfaces using the Internet standard Web Services interface (FYI:  A2A functionality will remain consistent across Release 4.).  The techniques involved will cause remote applications, especially those belonging to Transmitters or state governments, to authenticate themselves to the Registered User Portal and transmit Web Services requests to the Portal where they will be processed by WebSphere on the MeF SOAP Web Application Server.  A major use of this feature is in the transmission of returns. The Transmitter's application prepares a set of submissions within a Web Services envelope as a "Send Submissions" Request.
• The MeF system shall allow third party application programs to securely transmit tax returns to IRS via the Internet without human intervention.  These external user systems for A2A will register to gain access to IRS processing.  This process will include authentication services to enable authentication of external systems attempting to access IRS processing.  MeF shall provide the capability to authorize requests from properly authenticated external systems for specific IRS application processing services.  Validation services will be provided for the standard Infrastructure and security portions of requests from external systems to access IRS application services.  ISS shall provide the capability to invoke specific application services for validated requests coming from authenticated and authorized external systems.  ISS shall provide a list of personalities corresponding to a user ID in response to a request from an authorized user or system.  ISS shall ensure that a response from an application service is returned to the external system originating the request.  ISS shall provide the capability to log all external system transactions with MeF.  The process is as follows: 
o The Transmitter's application transmits this Web Services envelope, containing the set of submissions and credentials through the RUP to the MeF Soap Web Application Server.
o The MeF SOAP Web Application Server passes the “Send Submissions” Request Message to the MeF Application Server for processing.
o The MeF Application Server saves this request message for archiving within a table in its Oracle database.
o The MeF Application Server validates the Submissions in the Request Message, using the procedures detailed in section 5.6.  The ETIN stored as the originating ETIN of each submission is the one derived from the credentials in the header of the Request Message.
o The MeF Application Server validates that the number of Submissions matches the submission count in the Request Message.
o The MeF Application Server sets the status of each Submission to received.
o The MeF Application Server creates a Status Record for each Submission that indicates that the Submission has been received.
o The MeF Application Server creates a Receipt for each Submission.
o The MeF Application Server saves the Submissions, the Status Records, and the Receipts within tables in its Oracle database.
o The MeF Application Server creates a Response Message containing a Receipt for each Submission.
o The MeF Application Server saves the Response Message within a table in its Oracle database.
o The MeF Application Server sends the Response Message to the MeF SOAP Web Application Server.
o The MeF SOAP Web Application Server sends the Response Message to the Transmitter's application.
o The MeF Application Server records that the Status Records have been delivered to the Transmitter and are no longer considered new by updating the record within a table in its Oracle database.
o The MeF Application Server validates each received IRS Submission.
o After validation, the MeF Application Server changes the status of the IRS Submission to accepted and creates and saves a Status Record that indicates that the Submission is accepted.
o At this point, the MeF Application Server submits the return to the Modernized TRDB.
o The MeF Application Server sets the Submission Status of the IRS Submission to indicate that an Acknowledgement has been created.
o The MeF Application Server records that the Acknowledgement is new i.e., it has not yet been retrieved by the Transmitter.
o The MeF Application Server creates and saves a Status Record that indicates that an Acknowledgement has been created for the Submission.
o The MeF Application Server records that the Status Record is new – that is, it has not yet been picked up by the Transmitter.
o For each received State Submission whose corresponding IRS Submission has been accepted, the MeF Application Server validates that the state for which the State Submission is targeted is participating in the Fed/State program.
o For each standalone State Submission, the MeF Application Server validates that the state allows standalone Submissions.
o For each received State Submission which has passed state participation, the MeF Application Server validates the FEIN and Name Control combination and saves the result with the State Submission.
o The MeF Application Server changes the status of each State Submission which has passed Name Control validation to indicate it is ready for its state to pick it up, and then it creates and saves a Status Record that indicates that the submission has been queued for the state within a table in its Oracle database. The Status Record is recorded as being new – that is, it has not yet been picked up by the Transmitter.
o For each received IRS EO Submission containing a list of states to which copies should be sent, the MeF Application Server performs the following process for each state in the list:
? The MeF Application Server creates and saves a State Copy of the IRS EO Submission using data extracted from the IRS EO Submission following the rules for the state and submission type.
? The MeF Application Server sets the status of the State Copy of the IRS EO Submission to indicate it is ready for the state to pick up.
? The MeF Application Server creates and saves a Status Record for the State Copy of the IRS EO Submission that indicates that it is ready for its state to pick it up within a table in its Oracle database.
 
Appendix D – PAS Data Redaction

M-TRDB provides the PAS with complete 990, 990-EZ, and 990-PAS returns with an exception of the following elements and attributes that will be removed. PAS is fully responsible for determining the redaction criteria and initiating a change request if the redaction criteria should be updated. 

a. If organization is not a 527 Political organization (“Organization527”),
/Return/ReturnData/IRS990/Organization527
remove the entire section IRSScheduleB990.xsd, if present, from the Tax Return Document XML.
/Return/ReturnData/IRSScheduleB990

b. If present, remove each of the following fields from the Tax Return Header:
A. ReturnID
/Return/ReturnHeader/ReturnID
B. TimeStamp
/Return/ReturnHeader/TimeStamp
C. ISPNumber
/Return/ReturnHeader/ISPNumber
D. SoftwareID
/Return/ReturnHeader/SoftwareID
E. SoftwareVersion
/Return/ReturnHeader/SoftwareVersion
F. MultipleSoftwarePackagesUsed
/Return/ReturnHeader/MultipleSoftwarePackagesUsed
G. Originator - remove the entire  Originator (complex type)
/Return/ReturnHeader/Originator
H. PINEnteredBy
/Return/ReturnHeader/PINEnteredBy
I. SignatureOption
/Return/ReturnHeader/Originator
J. Filer (complex type) – only the following elements:
1. NameControl
/Return/ReturnHeader/Filer/NameControl
K. Officer (complex type) – only the following elements:
1. Phone
/Return/ReturnHeader/Officer/Phone
2. EmailAddress
/Return/ReturnHeader/Officer/EmailAddress
3. TaxpayerPIN
/Return/ReturnHeader/Officer/TaxpayerPIN
4. AuthorizeThirdParty
/Return/ReturnHeader/Officer/AuthorizeThirdParty
L. Preparer (complex type) – only the following elements:
1. Phone
/Return/ReturnHeader/Preparer/Phone
2. EmailAddress
/Return/ReturnHeader/Preparer/EmailAddress
N.  binaryAttachmentCount attribute
/Return/ReturnHeader/binaryAttachmentCount

Appendix E – Employee User Portal (EUP) Business Objects (BO) functionality

The new functionality is identified as additional reporting capabilities (for example, drill down, edit report, dynamic sorting of columns, hierarchical categories, and ad hoc reports) for the already existing BO reports.  Also, provides new reports that indicate statistics related to this new A2A functionality and the capability to e-mail selected and approved reports to authorized IRS employees. No ad hoc reports will be allowed to be e-mailed.  The Business Objects Web Intelligence application provides an interface to the Business Object Reports Server. Business Objects is a reporting and analysis tool that queries the database server to generate, publish, access, and distribute documents. Reports are canned reports with no ad-hoc queries allowed. Specific reports are accessible to the user according to application specific profiles set in Business Objects, and synchronized with user role information maintained in the eTrust (EDAS) database. Details regarding the content of these reports are included in

Appendix B.

Business Objects Reports Server
The Business Objects Server provides the e-File reports for MeF. User credentials for accessing the reports are synchronized with the EDAS repository through a script. The Business Objects Server is dependent on the WebSphere application server. The Business Objects server generates the reports and stores them in the reports repository in the MeF Database Server.

Business Objects Auditor/Scheduler Server
All reports generated by Business Objects run nightly. These generated reports are stored in the repository in the MeF application server’s database. The scheduler is installed on a server that also hosts the auditor function, which helps to determine how reports are used and also audits access to reports.

Emailing of Pre-approved Statistical Reports
The business requires certain reports to be e-mailed to IRS personnel. These employees must use the reports to resolve issues. For example, accounting reports are e-mailed to the accounting managers. The managers forward the reports to their employees, distributing the work amongst them. These selected reports are intended for distribution via the internal IRS e-mail.  See Appendix B.  The IRS Security Office will approve each report intended for internal IRS e-mailing. The report list and the addressee lists will be maintained by authorized IRS personnel.  Only pre-existing reports are under consideration to be e-mailed internally; no ad-hoc reports are allowed to be e mailed

MeF produces these statistical reports that can be generated and displayed to the EUP user via a Web page or in PDF format.  BO Publisher’s automated e-mail Function sends a designated pre-approved report upon its generation to the email accounts listed in the distribution list based upon the employee’s role in eTrust and Business Objects. BO Publisher, allows authorized users to configure BO to e-mail selected reports to users in the irs.gov mail domain. The BO e-mail capability requires administrator actions to manually enter e-mail addresses in the BO database for selection when sending reports. 

The data elements involved in this email capability for administrative reports will be determined by the Office of Privacy and the Office of Disclosure as e-mail report types are developed.  Again, no ad hoc reports are involved with email capability. Additionally, there is a Business Objects Reports Administrator to manage roles and provide assistance to employees using these reports.

The BO e-mail capability has no technical mechanism to mitigate the entry of incorrect e-mail addresses. The BO also has a dynamic e-mail address capability that allows a manager to forward reports by manually entering an e-mail address.  Unprotected e-mail capabilities and transmissions can result in deliberate or inadvertent disclosure of SBU information to an unauthorized individual both within the IRS and outside of the IRS.

The only additional training that is planned for infrastructure in support of MeF is the training need for the BO administrator to perform his job appropriately. This will be performed on the job

Ad Hoc Reports
Ad Hoc reports are being implemented in a limited way.  For Release 4, a Security Deviation Request is being drafted in the short term to address reports being e-mailed in clear text which may contain SBU data.  Currently, SMIME solutions are being evaluated for secure e-mailing of reports.

Administrative Functions
The infrastructure provides the following administrative functions to a designated “e-mail BO reports” user/administrator:
• Give a privilege to a BO user to mark (categorize) reports as “Not for e-mail” or “For e-mail”
• Give a privilege to an authorized BO user to delegate the “Not for e-mail”/ “For e-mail” assignment
• Give a privilege to a BO user to assign “For e-mail” reports to a valid IRS e-mail address
• Give a privilege to a BO user to maintain a list of valid IRS e-mail addresses (add, delete, update) to be assigned to the BO reports
• The system does not allow the administrator to assign the “Not for e-mail” reports to an e-mail address
• Give a privilege to an authorized BO user to delegate the e-mail assignment to a “For e mail” report.
It is assumed that the “e-mail BO reports” user/administrator role is assigned via the existing role assignment capability. These functions are performed off-line in order to set-up or manage e-mail BO report distribution. On the diagram, these functions are depicted on the left (lemon background).

Automated E-mail Functions

• The system (BO/publisher) automatically sends a designated “For e-mail” report upon its generation to the e-mail accounts listed in the distribution list
• Depending on BO 5 and 6, BO Publisher must be purchased for the corresponding version, or coded using Visual Basic for Applications (VBA)
The above functions are depicted on the right portion of the diagram (dark-yellow background)
All off-line administrative activities and on-line automated e-mail transactions are logged for later auditing.
A manual process to be reviewed by the security administrator must be established for all the categorization and re-categorization activities from “Not for e-mail” to “For e-mail” reports and vice versa.

Starting with Release 3.2, emails containing reports containing SBU data  must contain on the subject line the following prior to the name of the report:  SBU DO NOT FWD.

Beginning with Release 3.2, all recipients of emailed SBU containing reports must take the online Privacy Awareness Training.

Beginning with Release 4,  all emailed SBU reports must contain a banner, either in the body of the email or in the report itself, stating that the report contains SBU data and should not be forwarded nor stored in an unprotected directory. 

Business Objects Roles

There are three classes of users which will be supported in BO:
• View users, who can only view reports which have already been generated
• Refresh users, who can rerun reports with pre-specified input fields
• Edit users, who can create their own reports given the columns in the database and can save these report layouts as personal customized reports, although they can't save them into the enterprise-wide list
    Furthermore, any BO user can send a report to another BO user locally - independently of the e-mail facility, which is handled by Infrastructure.
A2A Statistics Gathering
The infrastructure provides a new API to help gather information for later statistical reporting. This information contains the data as depicted in Figure 4-8, Information for Statistics Gathering.
 
This information is stored in an A2A statistics gathering table. The statistical reports can be subsequently generated by the Business Objects and displayed to the EUP user on a Web page or in Portal Document Format (PDF).
The following information is gathered by the infrastructure:
• Total daily submissions (number and size)
• Daily submission by size range and possibly other differentiators such as transmitter or ETIN
• Total daily errors by third party trading partners and by states
• Total daily viruses by third party trading partners and by state
• Other error gathering statistics as deemed necessary
The above statistics are retrievable by help desk personnel/administrators via new Web page access.

Appendix F – ESM Monitoring

ESM Monitoring

ESM’s coverage of the MeF environment includes application-specific monitors and increased synthetic Web transactions. The MeF event console uses the Tivoli Event Console (TEC).
COTS products are used to monitor the MeF infrastructure, including availability monitoring of MeF-specific processes and file systems, WebSphere, MQSeries, and Web servers. Web transaction monitoring of Return Request and Display (RRD) requests, MeF Internet Filing Application (IFA) transmission upload, and the Business Objects view provides coarse availability and performance measurements from a user’s perspective
Since synthetic transactions are read-only, some synthetic transactions terminate prior to the point that an actual user’s transaction would end. For example, the IFA submission upload transaction executes up to point of transmission to the MeF application
Log files provide information that is used to determine volumetrics and to detect errors. Standard monitoring of internal infrastructure processes includes monitoring of:
FTP Pull Receiver
DB2 Connect
WebSphere JVM garbage collection
Oracle Database tablespace
Domain A,B,C, and E CPU utilization
File system usage
EMS node reachability
Monitoring of the portals includes Internet Information Server (IIS), SiteMinder
Internal processes of infrastructure components are not visible to standard Tivoli monitoring solutions. To expose internal processes to ESM, these components are modified to send events to the event console in one of two ways:
Modify the processes to write messages to a log file. Then, deploy a Tivoli log file adapter to read and parse new messages and send them to the event console. The advantage of this method is simplicity for the developer, but at the cost of more complex and fragile ESM processes
Incorporate the Tivoli Event Integration Facility (EIF) API in the processes. The processes is then able to send events directly to the event console. The advantage of this method is more robust and simpler ESM processes at the cost of incorporating a simple API
Captured failure events often reflect infrastructure problems outside the scope of the process. Events whose completion codes are captured include:
ETIN retrieval
GTX generation
Store files (uploaded submission files)
SAAS log generation
Virus check
File rename
File deletion
File transfer to MeF application servers
To assist the rules engine, processes send the completion codes of recovery actions to help the rules engine close open events.
The Tivoli Event Console (TEC) uses a Web interface to manage MeF’s infrastructure processes. The events are significant system operational events that require system administrator, operator, or automated responses. TEC rules do not have any business rules.
MeF application uses Tivoli Event Integration Facility (EIF) to send application events to the TEC, which evaluates the events and determines a course of action. Rules can execute tasks (scripts or programs) on any MeF system to manage MeF processes.

ESM Tivoli Health Monitoring
ESM data elements specific to the MeF application are in the log file into which the MeF application logs all the system exception error messages in ASCII-text format. A Tivoli Logfile Adapter polls the log file at short intervals, typically 30 seconds, parses the message into a Tivoli event and forwards the event to Tivoli Enterprise Console (TEC). MeF also shares a common ESM infrastructure whose data elements are described in the ESM Data Model View.

Appendix G – State Activities

State Activities
Beginning in January 2006, State Agencies can retrieve their state submissions from, and forward their state-generated acknowledgements to, MeF.  To do this, each state agency must register with the IRS and complete a Form 8633 to obtain an ETIN.  The state indicates in the application DBA (Doing Business As) field which returns they will accept – Fed/State (linked) and/or State Stand-Alone (unlinked).   The state must also register the system(s) that will be used to conduct business with MeF to obtain a system ID.  If a state agency and system(s) are not registered, the agency cannot access MeF.  MeF only validates that portion of the state submission manifest that it needs to perform MeF validations, such as FEIN/Name Control check.

The following services can be requested by the states:

Get New Submissions: This service allows a state to retrieve new state submissions (not picked up previously using this service) targeted for the state from the MeF system.
Get Submission: This service allows a state to retrieve a specified state submission from the MeF system.
Get Submissions: This service allows a state to retrieve specified state submissions from the MeF system.
Send Submission Receipts: This service allows a state to send receipts for state submissions (it has successfully retrieved) to the MeF system.
Send Acknowledgements: This service allows a state to send acknowledgements for state submissions to the MeF system.
Get New Acknowledgement Notifications: This service allows a state to retrieve new notifications indicating that acknowledgements have been retrieved by transmitters.
Get Acknowledgement Notification: This service allows a state to retrieve for a given submission the notification indicating that the acknowledgement has been retrieved by a transmitter.
Get Acknowledgement Notifications: This service allows a state to retrieve specific notifications indicating that acknowledgements have been retrieved by transmitters.

State Submission Controller
The State Submission Controller component is responsible for processing all state submissions. It determines if a state submission should be made available to the targeted state and, if so, makes the submission available to the state for pick up. It is responsible for making copies of an IRS EO submission for the state(s), and is responsible for retrieving state submissions for a specified state. The State Submission Controller invokes other components to fulfill its responsibilities. It invokes the State Submission Validation component to determine if the submission should be made available to the state, and the State Copy Processing component to make copies of an IRS EO submission.

State Submission Validation
The State Submission Validation component is responsible for determining whether a state submission should be made available to the state targeted by the submission. It takes a state submission as input and produces validation results that indicate whether the submission passed validation checks. The State Submission Validation component validates that the state targeted by the submission participates in the Fed/State program, and if the state submission is part of a combined Fed/State submission, that the IRS submission has been accepted.

State Copy Processing
The State Copy Processing component is responsible for creating a copy of an accepted IRS EO submission for a specific state and making it ready for the state to pick up. It takes an accepted IRS EO submission and the state code as input, and creates a redacted copy of the IRS submission for the state. The submission (copy) for a state, called State Copy IRS EO Submission, contains data extracted from the accepted IRS EO submission per business rules specified for the submission type and the state.

State Filing options
State agencies during registration can select Fed State (linked) or State Stand Alone (unlinked) state returns.  If a state selects Fed/State, then the state is indicating that MeF must have already received and accepted the federal Return for this taxpayer.  If the state agency selects State Stand Alone then the state is indicating that linkage is optional.  See below.  

How linking and unlinking works:
Each time MeF receives a state return, it checks for a submission Id for the federal return in the state return manifest.  If the federal submission ID is present then that federal return for that taxpayer must have been received and accepted by MeF.  If MeF has not accepted the federal return then the state return is rejected.  This is true whether the state agency has selected Fed/State (linked) or unlinked State Stand Alone (unlinked). 
If the federal submission ID is not present in the state return manifest, then MeF checks the linked/unlinked status for that state.  If the state agency selected Fed/State MeF rejects the state return.  If the state agency selected State Stand Alone, then processing continues.   State Stand Alone offers the states and taxpayers an option.  By including the submission ID for the federal return linkage is enforced.  By omitting the submission ID for the federal return linkage is not enforced.
Fed/State filing requires that the federal submission be received and accepted by MeF before any state submissions for that taxpayer will be forwarded to state agencies.  The state submissions may be included in any message as long as the state submission manifest contains the submission ID linking it to the federal return.  This offers the advantage of e-filing state submissions at a different time than the federal submission.  However, EROs must be able to associate the federal return submission ID with the state submission.  If the state has selected Fed/State but submission ID of the federal return is not present in the state submission manifest the state return will be rejected.

Stand-Alone State Filing:
This option is for states that do not require MeF to receive and accept the federal return as a condition to processing and forwarding the state return to the state agency.   
For Exempt Organization filing, this is also an option for states that do not require the federal return to be received and accepted by MeF prior to making state submission available to state agency.  (This option does not include 990s, 990EZs, or 990-PFs, but does include other Exempt Organization state submissions like the URS.)

• If submission ID of federal return is present in the state return manifest, then MeF enforces linkage.  Else submission ID of federal return is not present in state return manifest then
o MeF identifies state.
o MeF validates state participation and that state authorizes State Stand Alone filing.

State Submission Processing:

• For 990, 990EZ, and 990-PF submissions
o MeF will make copy of federal return for each state identified in federal return.
o Redact payment information is in each copy.
o Redact Schedule B is included for those states that require redaction of schedule.
o MeF will make copies available to states identified in federal return.  States will retrieve copies by using Get New Submissions Service Request
o MeF will generate an acknowledgement notifying transmitter that redacted copies of federal return have been made available to the states to retrieve.
o Update Status.

MeF processing for state submissions
o MeF checks FEIN and name control in the state submission manifest against National Account Profile (NAP).
o MeF stores results of check in MeF database.
o MeF associates results of check with state submission.
o MeF associates submission receipt with state submission.
o MeF stages state submission and IRS provided data (results of FEIN/name control check, date received, ETIN and Electronic Postmark (when present)) for retrieval by state agency using Get New Submissions Service Request).
o MeF updates state submission status.
o MeF generates acknowledgement notifying transmitter that state submission has been made available for retrieval by the state.
NOTE:  It is the responsibility of each state agency/system to validate the state submission file structure.  MeF does not do this.  MeF only validates that portion of the state submission manifest that it needs to perform MeF validations, such as FEIN/Name Control check.
o 

State processing of state submission
o State retrieves state submission (or redacted copy).
o MeF generates Acknowledgement Notification to notify transmitter that state retrieved state submission.
o MeF makes Acknowledgement Notification available to transmitter.  .
o Transmitter retrieves acknowledgement notification using Get Acknowledgement Notifications Service Request.

Appendix H – SAAS Information

SAAS info

Audit Trail Responsibilities
Audit log records of all MeF application transactions will be transmitted by the Modernized System Infrastructure messaging service (AMDAS) for collection, storage, and reporting by the security audit service (SAAS). AMDAS will format, for acceptance by SAAS, standard auditable information taken from the MQSeries headers and the security context of the AMDAS message header. The security context of the AMDAS message header will be populated by the MeF application. The MeF-provided auditable information that will be populated will be the User ID, the Target ETIN, and the message originator IP address and application system ID and security credentials.  For all MeF transactions, the user ID will be the one under which the user logged in. Additional auditable information will be added to the security context after consultation with Modernization Security and the Treasury Inspector General for Tax Administration (TIGTA). The Modernized System Infrastructure will also log all activities from a platform perspective.
Audit trails for third parties and states will be the responsibility of the MeF Application.

Security Parameters
The AMDAS API facilitates the exchange of messaging data between the Modernized System Infrastructure and MeF. AMDAS protects against unauthorized access to the queue and only accepts well-formed messages from authorized sources.
Access to queue resources is controlled through an authorization service component of MQSeries, the Object Authority Manager (OAM). When the MeF application program attempts to access an object, AMDAS checks with the OAM that the account under which the application is running has the authorization for the operation requested. The OAM restricts access to objects based upon the ACLs that it manages. This means that queues, and the messages on queues, can be protected from unauthorized access (UNAX).
A message type tells AMDAS which queue to put a message on. A message type is a value passed from the application program that AMDAS uses for authorization and to select a queue. The queue manager places this value in the message descriptor of messages when it puts them on queues, so that the application program that gets the messages can verify that they originated from an authorized program.

Audit Trail Work Flow and Overall Description
The infrastructure provides an audit trail of the application-to-application communication for subsequent auditing, troubleshooting, and trend analysis.
Audit records about the following are sent directly to SAAS:
• All requests from the third party trading partners that contain SBU data
• All requests from the states that contain SBU data (for example, acknowledgements)
• All responses to the third party trading partners that contain SBU data
• All responses to the states that contain SBU data