# Western Backstop (WEB)

Emissions and Allowance Tracking System (EATS) Analysis

Prepared by: Perrin Quarles Associates, Inc. 675 Peter Jefferson Parkway, Suite 200 Charlottesville, VA 22911
July 31, 2003Table of Contents Page

I. Introduction

........................................................... 1 II. Overview of the System and Analysis

....................................... 1 III. Functional Areas

...................................................... 3 A. Source Inventory

................................................ 3 B. User Management

............................................... 5 C. Account Management

............................................. 6 D. Allowance Allocations (Initial and Ongoing)

............................ 7 E. Allowance Trading

.............................................. 10 F. Annual Compliance Assessment

.................................... 12 G. Emissions Tracking and Emissions Reporting

........................... 15 H. Program Assessment and Analysis

.................................. 18 I. Public Information Needs and Requirements

............................ 19 IV. Types of Users

...................................................... 19 A. State and Tribal Users

........................................... 20 B. Industry Users

................................................. 21 C. General Account Holders

......................................... 22 D. Tracking System Administrator

..................................... 23 E. Public Users

................................................... 24 V. Technical Architecture

................................................. 24 A. Security

...................................................... 25 B. System Performance

............................................. 27 C. Maintainability

................................................. 28 D. System Outputs

................................................ 28 E. Application of Platform Selection Criteria

............................. 29 VI. Design and Development Approach

....................................... 30 A. Recommended Implementation Methodology

.......................... 30 B. Timing/Schedule

................................................ 32 C. Cost Factors

.................................................. 32 VII. TSA Responsibilities and Performance Criteria

.............................. 33 A. TSA Responsibilities

............................................. 33 B. TSA Performance Criteria

........................................ 36List of Figures Page

Figure 1: Overall WEB EATS Model

......................................... 2 Figure 2: Flow Chart of Allowance Allocation Process

............................ 10 Figure 3: Flow Chart of Annual Compliance Assessment Process

.................... 14 Figure 4: Use Case Diagram: State and Tribal Users

............................. 20 Figure 5: Use Case Diagram: Industry Users

................................... 21 Figure 6: Use Case Diagram: General Account Holders

........................... 22 Figure 7: Use Case Diagram: Tracking System Administrator

...................... 23 Figure 8: Use Case Diagram: Public Users

.................................... 24-1- July 31, 2003 

### Western Backstop (WEB) Emissions and Allowance Tracking System (EATS) Analysis
I. Introduction This section of the State Implementation Plan/Tribal Implementation Plan (SIP/TIP) is an analysis of the information management needs of the Western Backstop Emissions and Allowance Tracking System (WEB EATS) which is a requirement for the program under 40 CFR 51.309. Section 309(d)(h)(4)(v) of the Regional Haze rule requires that "the Implementation Plan must provide for submitting data to a centralized system for the tracking of allowances and emissions." The purpose of this document is to describe the architectural and system requirements necessary to support a State/Regional emissions trading program information system. The document summarizes the overall needs and objectives of an emissions trading system to ensure successful implementation of the program. It is intended to serve as a roadmap to help WRAP implement the program once it has been triggered. II. Overview of the System and Analysis Figure 1 contains a graphical depiction of the overall information system, including the basic users, functionality needed for each of these user types, and a high level architecture. Section III

describes each functional area of the application. Section IV describes the primary user groups and how they relate to the functional areas. Section V describes the considerations affecting the choice of technical architecture for the application. Section VI describes recommended design and development approaches, and Section VII addresses the overall responsibilities of the Tracking System Administrator (TSA). The development and deployment of this application, if needed, would most likely occur after 2013, possibly later. It is assumed that currently available technology would not be used, nor is it possible to project what advancements in technology would be available. For this reason, this report does not address specific technologies, except as a reference point for better understanding or describing capability that would be needed. The focus is on general issues related to technology and the functional requirements for designing and implementing the program. The scope of the application and information system needs which are described do not extend to several areas relating to the possible implementation of the Backstop Trading Program envisioned by Section 309. Excluded areas include the baseline emissions inventory for determining whether the program triggers, performing initial allowance allocations, and evaluating and tracking early reduction credits. Also, it has been assumed that it is not necessary to support a significant level of variation in requirements or needs from different States or tribes and that areas in which these requirements may vary, such as enforcement activities beyond the automatic provisions of the program, would be addressed in other systems.WEB EATS AnalysisJuly 31, 2003-2-

Application

Database WEB EATS

Public

EPA Emissions Database Program Emissions Inventory Public Data Industry

General Accounts ü Query Data

ü View Standard Reports ü Manage Application and Users

ü Conduct Compliance Assessment

ü Develop Reports

ü Coordinate Program Implementation ü Complete Registration

ü Transfer Allowances

ü Submit Emissions

ü View Reports

ü Add/Update General Accounts

ü Transfer Allowances

ü View Reports The System Administrator ü Allocate Allowances

ü Approve Sources and Units

ü Approve Monitoring

ü View Reports Tribal Set-aside Allocation System States/Tribes Figure 1

Overall WEB EATS ModelWEB EATS Analysis July 31, 2003

-3- III. Functional Areas The system to support the WEB Trading Program must contain functionality to support implementation of the trading program in the following areas: source inventory, user management, account management, allowance allocations, allowance trading, emissions reporting and collection, compliance, and program assessment. At this time, the system functionality does not include consideration of allowance transfer price data. However, there may be a need to include this functional area in the final system design, and the overall system design needs to allow for this possible expansion of the functional areas. Because the core requirements for allowance transfer price tracking remain uncertain, this section does not discuss this functional area in further detail. Each of the other areas of functionality is described below. In addition, core requirements relating to the areas are defined. A. Source Inventory 1. Description

a. Facilities and Units The central focus of the system is the list or inventory of sources which are affected by the program. This inventory is initially derived from the baseline emissions inventory developed to support the development and approval of the WEB Trading Program as part of the SIP/TIP approval process. To this initial inventory, it is expected that States and Tribes may add sources, either during the period prior to triggering the program or after the Program Trigger Date. Throughout, it is expected that sources will permanently cease operation or "retire." To support the dynamic inventory, the information system must allow the addition of new sources and track the status, including the regulatory status, of all sources identified as potential program participants beginning with the baseline period.To support changes in facility operation and ownership in both the pre-trigger and posttrigger period, it will be necessary to track basic changes in facility identity, including facilities which, due to these types of changes, change "identity" or divide into two facilities. This functionality would include tracking facility name changes. It is assumed that States and Tribes would be responsible for identifying all "new" sources to the database and for making decisions and entering data about the applicability of the program to a new source. Once a source is identified as being subject to the program, the maintenance of these data would be the primary responsibility of the owners and operators of affected sources through the source representative. A single, secure portal for changing these data would be provided to authorized industry representatives.WEB EATS Analysis July 31, 2003

-4- b. Source Owners The owners and operators of each source authorize individual(s) to represent them regarding allowance trading, emissions reporting and all other compliance activities. The identity of the owners and operators should be tracked to ensure that legal responsibility for compliance can be accurately determined at any point in time during which compliance is required. The WEB EATS should track changes in owners and operators for a source.

c. Source Representatives The designated representatives appointed by the owners and operators of the source are also tracked so that appropriate communication about program activities involving the source and compliance is facilitated. Under the Duty to Register provisions, representatives of a source initially must register and use consistent source identifiers with the source program data first entered by the State or Tribe. The representative is responsible for the accuracy of submissions and certifying source compliance. Program rules should be structured to ensure that at no time during the operational phase of the program is an affected source unrepresented. d. Source and Unit Detail Additional information about the facility and units, including fuels, controls, and other operational information would be necessary for program implementation, particularly with respect to emissions monitoring, and for program assessment. During the design phase for WEB EATS development an assessment of these needs and the availability of information from other sources (for example, a shared air program database at EPA or in a State/Tribe) should be performed. 2. Core Data Entities and Attributes ! Facilities . Location, source category or type, permit IDs, size, Federal and State/Tribal cross identifiers with other data systems, program status, operational status (including retirement status), initial on-line date (for new sources). ! Units . Relationship to facilities, type, Federal and State/Tribal cross identifiers with other data systems, operational status (including retirement status), initial on-line date (for new units). ! People . Type and duration of relationship of representatives to facilities, type and duration of agent relationship to representatives, address, affiliation, security level, user ID, passwords (or equivalent), phone numbers, email or equivalent. ! Owners/operators . Address, relationship to facilities.WEB EATS Analysis July 31, 2003

-5- ! Program applicability

. Exemptions, opt-in or other program status information, including year affected (or non-affected), identification of Category 1 and 2 sources, etc. Could include permitted production capacity or other permit data. 3. Core Functional Requirements ! Populate initial facilities and units. ! Add and update facilities and units. ! Add and update owner/operator information. ! Change owner/operators for facilities. ! Add and update individual information for any person utilizing or identified in the application. ! Change representatives for facilities. ! For on-line changes, provide to users documentation of changes in owners and representatives to meet recordkeeping requirements. This could be email or other electronic format. ! Track changes in facility names and program identifiers and relationship to prior entities. ! Communicate/verify facility and unit inventory changes, particularly where change impacts regulatory status or responsibilities or triggers deadline. ! Add and update program applicability data. B. User Management 1. Description User security and authentication are key requirements for the WEB EATS. To support these requirements the application must contain functionality to store user identifying information and associate each user with the appropriate security level. A system administrator, or person designated by the system administrator, must use tools provided in the application to review and approve user accounts, and to access and monitor usage. For any on-line access and submission by an industry user, the system should require appropriate compliance certifications and contain a record of certifications. 2. Core Data Entities and Attributes ! People . Relationship to facilities or to representatives and their agents, address, affiliation, type, security level, user ID, passwords (or equivalent), phone numbers, email or equivalent.WEB EATS Analysis July 31, 2003

-6- ! User Access Requests . User identification (per People), information to facilitate approval, status of request (approval, denial). ! Certification Records . Content of certification, date, user identification. 3. Core Functional Requirements ! Receive requests for user registration. ! Approve/deny requests and establish security groups. ! Provide notification of request status and assigned user ID and passwords (or equivalent). ! Develop and apply user privileges for specific functional areas and categories of data. ! Delete or archive users. ! Revoke or modify user access privileges. ! Display appropriate certification statements for review and agreement. C. Account Management 1. Description In the model rule, an Allowance Tracking System account is defined as an account "established for purposes of recording the allocation, and for holding, transferring, or deducting allowances." The WEB EATS should contain at least four types of accounts: general, compliance, retirement and government accounts. It must include a range of functionality to support each type of account.
A compliance accountholds allowances which are used for compliance purposes. There is one compliance account for each source subject to emissions trading requirements and the compliance account is assumed to have the identical owners and representatives as its associated source. A compliance account should be automatically created for each new source when a source has met the appropriate registration requirements. For specified periods, compliance accounts or the allowances in those accounts may be subject to restrictions on trading to facilitate annual compliance assessment.
A general accountallows anyone to hold allowances separate from the compliance and true-up process. A representative for a facility must move allowances from a general account to a compliance account before the true-up deadline in order to use them for current year compliance. A general account is created upon request of any individual or entity, and like a facility's compliance account, must have a defined owner and an individual person named as an account representative. General accounts are populated through trading functions, described below. The system administrator should have the ability to archive or deactivate a general account if specified criteria are met (such as containing no allowances for a specified period of time). For analysis purposes, the type of general account holder should be identified.WEB EATS Analysis July 31, 2003

-7- A retirement account holds allowances which have been used for annual compliance to offset emissions or which have been voluntarily removed from the market by its owners. At least one retirement account will be identified initially; additional accounts may be necessary to meet specific needs, if a detailed analysis of requirements indicates that separating retired allowances would be useful for analysis or other purposes.
A government account holds allowances which are still under the control of a State or Tribe (or, as their agent, the Tracking System Administrator). These accounts will contain serialized allowances to be allocated in the future. The new source set-aside, for example, is a government account. 2. Core Data Entities and Attributes ! Accounts . Identification number, type, restrictions, relationship to source (if any), State/Tribe, or owner/representatives, owner type. ! People . Type and direction of relationship to accounts and representatives and their agents, address, affiliation, security level, user ID, passwords (or equivalent), phone numbers, email or equivalent. ! Owners/operators . Address, relationship to accounts. 3. Core Functional Requirements ! Add/create general accounts. ! Change owner/operators for general accounts. ! Change representatives for general accounts. ! Add/create retirement, government, and compliance accounts (system admin only). ! Implement freeze on account or specific allowances within account. ! Archive or delete accounts. ! Notification of changes to user and other responsible persons. D. Allowance Allocations (Initial and Ongoing) 1. Description The system should support both initial and ongoing allocations of allowances from government accounts into compliance accounts. The initial allocation for the first five year period would be provided by States or Tribes in a format to be defined by the TSA and system designers. It is recommended that the allocation process replicate the transfer of allowances from account to account, thus creating an audit trail of the allowance back to its original issuing State or Tribe. It is recommended that the system design include a standard file format for submission of initial allowance allocations by the State or Tribe.WEB EATS Analysis July 31, 2003

-8- All allowances would be serialized according to a numbering system to be determined as part of the system design when they are initially populated in the application. This serial number would be a permanent attribute of each allowance and could not be changed. Ongoing allocations, which occur every five years for all allowances, would be supported through a process similar to the initial allocation, depending primarily on a standard file format, containing allocations determined by the State or Tribe for the period. The application should generate a draft and final Regional Allocation Report for each five year allocation period. The application should support periodic allocations of allowances to compliance accounts for new sources from the new source set-aside. Specialized tracking and reporting would be needed to record the date of all requests and the status of the set-aside account. When this account is depleted, the tracking information would be used to prioritize allocation of future allowances to these sources. The application must support allocations of allowances for opt-in sources on an annual basis. It is assumed that the State or Tribe would provide data to support opt-in source allocation (including source identification) either on-line or in an electronic format. The application must support notification of all allocations to registered sources and to the appropriate State or Tribe. If a source representative elects a monitoring option for a unit under 1.(b) of Section I (Monitoring, Recordkeeping and Reporting) of the model rule, the source representative would submit a request to the State or Tribe about this election, and must provide information about the portion of the facility's allowance allocation attributable to these units. Upon approval of the request by the State or Tribe, the TSA (or the State or Tribe directly) would mark the appropriate number of allowances as "non-tradeable" in the allowance account for the source for all years already allocated. A record of the request and approval would be stored, so that future allocations would also be marked as non-tradeable. If the special monitoring status under Section I1.(b) is revoked or no longer applicable, the "non-tradeable" status of the allowances would be changed by the TSA. 2. Core Data Entities and Attributes ! Accounts . Identification number, type, restrictions, relationship to source, State/Tribe, or owner/representatives, owner type. ! Allowances . Serial number, type, origin, year (if not indicated by serial number), nontradeable indicator.WEB EATS Analysis July 31, 2003

-9- ! Transactions . Transaction identifier, date, allowance range, transferor account, transferee account, type of transaction. ! Action Log. Type of submission or request, user, source, status, etc. 3. Core Functional Requirements ! Import of allowance allocations from file provide by State or Tribe. ! Assign serial numbers to new allowances. ! Notification system to automatically inform industry users of allocations and future responsibilities. ! Notification or report system to keep States and Tribes informed re allocation status. ! Tracking capability for new source set-aside requests. ! Allocations to compliance accounts from new-source set aside.WEB EATS Analysis July 31, 2003

-10- WEB EATS automatically notifies industry users of allocations and future responsibilities WEB EATS assigns serial numbers to new allowances

WEB EATS automatically notifies States and Tribes regarding allocation status WEB EATS imports allowance allocations from file provided by State or Tribe Figure 2 Flow Chart of Allowance Allocation Process

E. Allowance Trading 1. Description The ability to trade allowances supports the underlying principle of an emissions trading program and the functionality to support allowance transfers is critical to the WEB EATS. Security of the data and transparency of the transfer record are critical to the overall program and should be carefully evaluated. The WEB EATS must provide the TSA the ability to maintain information on all current account holdings and an audit trail of all allowance transactions, including both market transactions and regulatory transactions. The current standard for emissions trading programs established by EPA is to allow industry users to record allowance transfers on-line in real-time. These applications support both interactive, on-lineWEB EATS Analysis July 31, 2003

-11- transfers and batch transfers using specified file formats to transfer larger numbers of allowances. For batch transfers, industry has developed software to monitor allowance ownership and submit large volumes of allowance transfers with a minimum of user intervention. It is assumed that the technical capability for secure system-to-system interactions will continue to improve and that this approach will be more widely used in the future. Current allowance trading systems also support transfers performed by the TSA based on the receipt of paper forms. It is assumed that the reliance on paper forms will continue to diminish. Whether this functionality should be supported in the WEB EATS should be evaluated. During the true-up period, activity in compliance accounts is frozen to allow the TSA to conduct the necessary compliance evaluation and allowance retirement. Two alternative approaches should be considered. Under one approach, the WEB EATS would allow users to submit allowance transfers for allowances involved in an ongoing compliance process, but these transfers would be held and recorded following the completed process. All affected parties would be informed of the status of these transfers both when submitted and when finally recorded or denied. Under the alternative approach, allowance transfers for allowances involved in on-going compliance would be rejected, and transfers would have to be resubmitted (reflecting deductions carried out for compliance) after the compliance process is completed. For on-line transfers performed interactively by the transferor, the WEB EATS should provide access only to those accounts over which the transferor currently exercises control. Account access would be determined by the WEB EATS based on the user's relationships to specific general or compliance accounts. From these accounts, the user would select the accounts and specific allowances for the transfer. The user would then identify the account into which the allowances should be transferred. It is assumed that eligible recipients include general accounts, compliance accounts or a voluntary retirement account. The user would be asked to review and verify the transfer prior to its taking affect. The process for electronic transfers of batch transfers will be more technology dependent. It would undoubtedly require definition of file transfer formats and security standards to ensure authentication of the submitter and completeness and quality of the data. It is not feasible to predict standards or available technology for this process at this time. The paper-based process used by the TSA would be similar to the interactive process. Depending on the volume of paper transfers, redundancy of data entry or additional verification should be considered to ensure data quality and accuracy. For all transfers (interactive, batch or paper), the WEB EATS must support a process of communication to both the transferor and transferee so that transfers recorded are fully disclosed to all parties and errors or other disputes between parties can be quickly identified and resolved.WEB EATS Analysis July 31, 2003

-12- The WEB EATS must support a process of either transaction reversal or transaction error correction, or both. This functionality would be restricted to the TSA. In addition, the WEB EATS must support a process of review of transfers to ensure that they are valid under the trading program rules (e.g., that they involve allowances actually held in the transferor account) and to reject invalid transfers. The WEB EATS must support a process of communication to the transferor concerning the acceptance or rejection of transfers. Reports would be available to the TSA and designated State/Tribe users to review specific transactions or overall transaction activity at any time. 2. Core Data Entities and Attributes ! Accounts . Identification number, type, relationship to source, State/Tribe, or owner/representatives. ! Allowances . Serial number, type, origin, year (if not indicated by serial number). ! Transactions . Transaction identifier, date, allowance range, transferor account, transferee account, type of transaction, status. 3. Core Functional Requirements ! Interactive transfer. ! Batch transfer. ! Capability to freeze compliance accounts with regard to allowances involved in ongoing compliance assessment. ! Notification to transferor and transferee. ! Reports and summaries. ! Allowance transaction audit trail. F. Annual Compliance Assessment 1. Description Following each control period, the TSA must perform an assessment of annual compliance with the basic program requirement that each affected source hold a number of allowances equal to or exceeding the tons of SO2emissions for the period. The compliance module of the WEB EATS would support receipt of annual compliance notifications and certifications by the source representative. It is expected that most representatives would provide the certifications and designate allowances to be deducted using an on-line access similar to the allowance transfer capability. Following receipt of the annual compliance forms, the WEB EATS would then compare the allowances held in the compliance account and theWEB EATS Analysis July 31, 2003

-13- level of emissions for the source (taking into account the year of allowances, flow control limitations and prior exceedances) and deduct the appropriate allowances from compliance accounts into retirement accounts. Emissions reported at the unit level would be "rolled" up to the facility level. The process would result in a compliance report or compliance assessment notification to source representatives, States and Tribes. In addition, the WEB EATS would assess the need to apply flow control in the subsequent year and determine the appropriate flow control factor. Finally, the WEB EATS would identify any failure to meet allowance limitations. Based on the level of excess emissions the WEB EATS would compute the appropriate penalties, both monetary penalties and deduction of subsequent year allowances. 2. Core Data Entities and Attributes ! Annual compliance certifications . Facilities, submitter name/ID, year, compliance certification statements. ! Tracking . List of facilities for whom an annual compliance certification is required, received, etc. ! Compliance Results . Penalties, deductions, status, year. 3. Core Functional Requirements ! Receive and store annual compliance certifications. ! Perform compliance assessment. ! Calculate exceedances. ! Calculate flow control applicability and ratios. ! Communicate compliance results.WEB EATS Analysis July 31, 2003

-14- WEB EATS compares allowances held in compliance accounts and the total level of emissions Source Representatives place appropriate amount of allowances to be deducted in compli ance accounts

WEB EATS deducts appropriate allowances in compliance accounts WEB EATS calculates total emissions per Source including rollup to Facility level

WEB EATS provides compliance assessment notification to Source Representatives, States, and Tribes

WEB EATS assesses need to apply flow control in subsequent years and compute appropriate flow control factor

WEB EATS computes penalties based on exceedances Figure 3 Flow Chart of Annual Compliance Assessment ProcessWEB EATS Analysis July 31, 2003

-15- G. Emissions Tracking and Emissions Reporting 1. Description Emissions tracking and reporting for compliance purposes following the program trigger will require a wide range of functionality and data tables. There will be a need to evaluate carefully how and whether the functionality of the Emissions Tracking Database used for milestone tracking inventory purposes can be utilized to support the post-trigger emissions reporting. Also, it will be very useful to identify any potential overlap with existing emissions reporting systems used for other national or regional trading programs. For example, EPA plans to put into place the Emissions Collection System (ECS) and Monitoring Plan System (MPS) sometime after 2004. Although the software itself may not be adaptable for use as the emissions reporting module of WEB EATS, the system requirements and design should be consulted as an additional, more detailed, roadmap in the initial stage of system design. The following general areas of functionality would be required: Reporting Requirements and Tracking Information. To facilitate program implementation, the WEB EATS would identify monitoring and reporting obligations of each source participating in the program and track the receipt of required information. At least three types of reporters are envisioned: ! Part 75 reporters (submitting SO 2emissions reports directly to EPA); ! Hourly non-Part 75 reporters; and ! Annual reporters (not participating in trading because of monitoring limitations). For each of these type of reporting there are distinctly different reporting obligations and functionality to support submissions and reported information. Monitoring and Emissions Information for Part 75 Units. For Part 75 affected sources who are reporting SO 2monitoring and emissions data directly to EPA, the assumption is that redundant submission of these data would not be required. Instead, the WEB EATS would access or receive information from the EPA system about submissions and reported values under Part 75. Although EPA does not share these data directly with other data systems currently, it is anticipated that technological advances and the demand for shared data by other emissions trading programs would make this not only viable, but routine, by the time the program trigger occurs. Monitoring Information for Non-Part 75 Units. For non-Part 75 units monitoring under Section I of the model rule, the submission requirements are not spelled out in the model rule. We recommend and assume that the program require and support the electronicWEB EATS Analysis July 31, 2003

-16- submission of monitoring plans that are needed to establish an identification base for monitoring methodologies, monitoring locations and monitoring systems. These data are needed to support periodic reporting of hourly emissions data and to ensure that the data from monitoring systems are certified and quality assured. Tracking capability would be needed to assist in identifying whether required submissions (electronic and hardcopy) have been received, reviews conducted and approvals issued. This capability would assist States and Tribes, the TSA, and source representatives in the implementation phase of the monitoring program. Because monitoring plans contain important components which are either graphics or documentation and are not easily stored as data elements, system designers should consider including document management capability to complement the tracking of information and sharing of data between all parties. A robust document manager could provide a submission process and eliminate or greatly reduce submission of hard copy material. This is an area in which technical options and standard practices may improve significantly prior to the program trigger year. Emissions Data for Non-Part 75 Units. For non-Part 75 sources required to monitor SO 2emissions, the WEB EATS would support submission, processing and storage of hourly emissions data. By current standards, the volume of and processing capability for hourly data could be large. However, it is expected that processing power and data storage capability will continue to expand and costs will decline. It is also expected that the submission process would utilize the next generation of broadband access and communication, in whatever direction technology dictates. Standardization of data reporting protocols would probably facilitate design and implementation of data submission requirements. The shape of the WEB EATS would be dictated to a large degree by available technology, supporting basic functionality of receipt, tracking, checking, analysis, and communication between the regulated sources and program management. Quality Assurance of Emissions Data. Underlying successful cap and trade programs is the assumption that the emissions recorded and traded are comparable from State to State, Tribe to Tribe and industry to industry. Clear monitoring protocols and quality emissions data are needed to maintain the viability of the program. The monitoring and emissions data collection process should include the appropriate level of checking, analysis to ensure accurate and complete monitoring and reporting. Part 75 is a useful model of standards and checking which has provided the appropriate level of market assurances about the quality of emissions. The designers and developers of the WEB EATS should provide comparable capability, including calculation checks, assessment of monitoring system quality assurance compliance, and the accuracy of missing data routines. Emissions data should be evaluated to check routinely and periodically for anomalies and inconsistencies. Petition Tracking . To meet SIP approval requirements, petitions for alternative monitoring would require joint approval of the State/Tribe and the U.S. EPA. The WEB EATS should provide a mechanism to track petitions and their approval and disapproval in a centrallyWEB EATS Analysis July 31, 2003

-17- accessible location for all State, Tribal and EPA program administrators. The WEB EATS should highlight and define electronically any aspect of the petition which results in allowable changes to reporting of monitoring or emissions data. Annual Emission Statements for Reduced Monitoring Units. For units with reduced monitoring requirements under Model Rule Section I1.(b), the owner or operator would submit an annual emissions statement. The WEB EATS would track receipt of these submissions and record the emissions value reported. Annual production data or other information may also be required on a case-by-case basis as a condition of State or Tribe acceptance of the request under Paragraph b. These data should also be recorded in the data system. Consideration should be given as to whether more frequent emissions reporting than annual reporting (e.g., quarterly) should be required in order to facilitate data quality assurance, and the overall system design should allow for this possibility. 2. Core Data Entities and Attributes ! Tracking . Including projected monitoring and reporting deadlines, submissions, and approvals or other status. ! Emissions Methodology/Reporter Type . Compliance period, Facility/Unit. ! Monitoring Locations . Units, stacks and pipes and attributes. ! Monitoring Systems Detail . Monitoring systems, formulas. ! Certification and Ongoing Quality Assurance Test Data. Test dates, overall results, test detail data. ! Cumulative Quarterly and Annual Emissions

. ! Hourly Emissions Data

. 3. Core Functional Requirements ! Track deadlines, requirements and submissions. ! Communicate with users about upcoming deadlines or deficiencies. ! Receive emissions report, quarterly and annual. ! Receive original and revised monitoring plans. ! Receive monitoring system certification and quality assurance data. ! Receive quality assurance test data and perform quality assurance checks. ! Address data quality problems. ! Provide final emissions data for annual compliance.WEB EATS Analysis July 31, 2003

-18- H. Program Assessment and Analysis 1. Description Ongoing program assessment and evaluation is an explicit responsibility of the TSA and the system design and requirements should reflect the needs for various types of assessment including: environmental benefits, geographic impacts, market function, implementation successes and failures, co-benefits, and SO 2control strategies. In each of these areas, the proposed database design should be evaluated to determine whether anticipated needs will be met. The analytical utility of the data in WEB EATS will be enhanced in some cases by ensuring that accurate and complete links to other databases are supported and maintained. Similarly, geographic analyses will be enhanced by having high quality and complete locational information. These data will facilitate the availability and use of deposition and other modeling data. It is important to consider the needs of users who want access to basic and repeatable analyses and the needs of users who want access to the data to perform complex analysis or one-time analysis. The basic user may best be served by providing standard reports designed to provide a program overview, summary statistics or status reports on specific types of activity. Combined with basic filtering and sorting options, a well designed report will meet many of the ongoing needs. More flexibility in data analysis could be provided by developing a more robust query tool, perhaps with control over report formats and output file types. For the high end user with more complex analytical needs or requiring use of data volumes beyond the capability of the user interface platform, the ability to request and deliver data in standard formats should be considered. If it is determined that the basic user needs include access to large volumes of data in predictable summary formats or quick access to complex data, the design and development of a data warehouse to facilitate this access should be considered. 2. Core Data Entities and Attributes ! Data warehouse . To provide easier access to aggregated data for analysis purposes. 3. Core Functional Requirements ! Generate standard reports. ! Provide data query tool. ! Provide capability for data export and delivery. ! Provide links to other information systems.WEB EATS Analysis July 31, 2003

-19- I. Public Information Needs and Requirements 1. Description To support market trading, information about market activity must be available to market participants and the general public. This includes, in particular, information about allowance trades and the identity of market participants, including representatives. The specific data content would be evaluated in detail at the time of design and development. It is expected that public access to some data, for example the tribal allocations for set-aside, would be limited. It should be noted that the timeliness of the data is a critical aspect; but it may be appropriate to provide access to different types of information at different intervals. For example, a daily update cycle for allowance trading and representative changes has been adequate for the Federal trading programs; access to reported emissions data may be provided quarterly or even annually. The ease of access for the public is also important. The current standard is to publish data though the Web, either in a readable format such as .pdf, in a standard spreadsheet format or through a query tool which retrieves and displays data in .html format through a browser. Although the technology available for public access to information in the next decade is not easily predicted, it would be expected that similar methods of providing access would be selected. The technical architecture and data formats should be selected based on security, speed or performance, overall accessibility to the technology, and flexibility offered in terms of both output and format. 2. Core Data Entities and Attributes ! Data warehouse . To provide easier access to aggregated data for analysis purposes. 3. Core Functional Requirements ! Timely public access to source inventory, account, allowance and representative information. ! Public access to periodic emissions data. ! Data downloading or extraction. IV. Types of Users As depicted in Figure 1, there are five basic categories of users for the application: State and Tribal users; industry users; general account holders; the Tracking System Administrator; and public users.WEB EATS Analysis July 31, 2003

-20- States and Tribes

View Reports

Allocate Allowances to New Sources

Allocate Allowances to Compliance Accounts Approve Paragraph b Monitoring Add New Sources/Units Approve Petitions Develop Enforceable Procedures for Recording Data A. State and Tribal Users Staff members of a State or Tribe participating in the Backstop Emissions Trading Program would be key stakeholders and users of the application. These users would have read-only access to almost all data in the application and a variety of reports. They would provide key data to the system using a combination of data upload or on-line capability. These would include facility and unit and program applicability data, general allowance allocations, allocations from new source set asides, and approvals of monitoring submissions. These users would have no day-to-day responsibilities for the operation, management or maintenance of the application or data. Figure 4

Use Case Diagram: State and Tribal UsersWEB EATS Analysis July 31, 2003

-21- Industry

Update Compliance Accounts Transfer Allowances Change Source Representatives

Change Source Owners

View Reports Update Source/Unit Characteristics

Certify Compliance Submit Emission Reports Submit Monitoring

Petitions and Monitoring Plans B. Industry Users Representatives of the regulated community would also be key users of the application. These users would have access to data relating to sources under their control, as defined by their roles and responsibilities as source representatives. In this capacity, they would be able to maintain source and unit information, transfer allowances in compliance or general (that they set up) accounts to and from other accounts, and submit required emissions data and compliance certifications. Figure 5 Use Case Diagram: Industry UsersWEB EATS Analysis July 31, 2003

-22- General Account Holders

Add/Update General Accounts Transfer Allowances View Reports Change General Account Representative

Change General Account Owner C. General Account Holders A representative for a general account would also have access to the application to update general account information, create new accounts, transfer allowances out of their general accounts to other accounts and to view reports. The general account holder would have limited (or no) access to source information, unless the holder is also a compliance account holder or until such information is determined to be public information. Figure 6 Use Case Diagram: General Account HoldersWEB EATS Analysis July 31, 2003

-23- Tracking System Administrator

Add/Update/ Delete Facilities and Units Add/Update/ Delete/Archive Owners/ Operators Add/Update/ Delete Representatives Add/Update/

Delete Users

Perform Annual Compliance Assessment Freeze/

Unfreeze Account Trading Populate

Compliance Accounts Generate Reports

Quality Assure Data Track Activities D. Tracking System Administrator The Tracking System Administrator (TSA) would utilize virtually all functionality contained within the application. In appropriate circumstances the TSA would act on behalf of State/Tribal, industry and general account users. In addition, the TSA would perform all types of system management and maintenance activities to ensure effective operation of the application. The TSA would approve access for all users of the application. Figure 7 Use Case Diagram: Tracking System AdministratorWEB EATS Analysis July 31, 2003

-24- Public

Query Data View Standard Reports Extract Data E. Public Users Public users have read-only access to selected data within the system. This access would be consistent with the security requirements of the application and data. Figure 8 Use Case Diagram: Public Users

V. Technical Architecture A key component of system design is the selection of a common architecture. One of the major components of system architecture is the number of levels or layers in a system. An application installed on a user's machine that does not communicate with any other applications or systems is a 1-tier system. A client-server system, where one application sits on a user's computer (client) and another, related application sits on the server is a 2-tier system. Most Web applications are 3-tier systems, where there is a browser and Web server (client), a business logic server and a database server. The system should be built with at least three layers to separate the display (client), business logic, and database, so that each layer could be modified without having to change other parts. The exact architecture would be determined at the time of system design. The final decisions about system architecture should consider many factors, including security, performance, and maintainability.WEB EATS Analysis July 31, 2003

-25- A. Security Due to the importance of data integrity and accuracy in the WEB EATS, security will be extremely important. The security measures should be based on current best practices and standards. The system's security can be divided into two areas: application and server level security. 1. Application Level Security The system's application level security consists of the protective measures designed into the application's code. These include the logical measures to determine which users may access which areas of the system, the manner in which session management is handled and the protection of sensitive information, like passwords, at the application level. ! Password Encryption. The system must include a process to authenticate all authorized users to the system. Today's system utilizes encryption to protect the vulnerable data elements, such as user passwords. Implementation of an extremely robust encryption, routine or its equivalent should be incorporated into the system. ! Separate Logins . Each user should maintain a unique username and password, with the password encrypted and stored in a secure database. Each user should be assigned a unique ID. The technology available for security in the next decade is not easily predicted; available alternative technology to the use of passwords should be considered. ! Separate User Types . The access rights and restrictions should be controlled at the user group level. Each user group would have a unique set of rights and restrictions within the WEB EATS. Upon user login to the system, the user's specific user group security should be verified and rights and restrictions set for the session. If the user belongs to multiple user groups, they should be assigned the highest rights for a given section or action among their user groups. ! Audit Trail . The system design should include specific requirements to maintain an audit trail of data adds, updates, and deletes for critical data elements. This audit trail should be designed to detect and resolve challenges to the data (for example, allowance ownerships), and as an additional means of restoring data should there be a breach of data integrity. ! Session Management . Strict session management control, in which session tokens are properly protected and validated, is essential. When two applications are run remotely from each other (like a browser and a server), they require session tokens to be able to communicate about the application state. To prevent attackers from hijacking activeWEB EATS Analysis July 31, 2003

-26-sessions and assuming the identity of a user, session tokens need to be regularly revalidated. 2. Server Security The system's server level security consists of the protective measures designed to protect the server itself from inappropriate access. These include proper server maintenance and the modifying of default system passwords. ! Server-Side Data Validation and Business Logic . To the extent possible, all business logic and data validation should be checked and handled at the server level and not be coded at the client or browser level. Server-side validation improves performance and reduces the risk of a user bypassing business logic designed to prevent them from submitting invalid data. Server-side validation includes business logic as well as basic data type validation (i.e., length, range, data type, characters sets). ! Server Maintenance . The servers or host platform should be maintained according to security standards. For example, many of today's current servers are patched on a regular basis with the latest security releases as soon as they are available. Because flaws in server software are usually well known in the hacker community, it is important to protect the server from attackers. ! System Passwords . The system passwords to the servers or host platform should be modified from their defaults and changed on regular intervals. Because the default passwords for commercial servers are commonly known, they pose a security threat and should be changed. Also, standard security practices should be followed regarding the regular changing of passwords. 3. Physical Data Security Physical data security should be provided by the measures to protect the data center, a specialized facility that hosts an application, from dangers. These dangers include theft, natural disasters, manmade catastrophes, and accidental damage (e.g., from electrical surges, extreme temperatures, spilled coffee, etc.). The data center that hosts the WEB EATS should maintain strong security practices and undergo periodic audits. 4. Backup and Recovery The database should be backed up at least daily and the application files should be backed up regularly. It may be advisable to back-up the allowance transaction data at a more frequent interval, based on the frequency of use and level of recoverability deemed necessary. A copy of the backup files should be stored off-site from the data center to ensure minimum downtime should a catastrophe occur.WEB EATS Analysis July 31, 2003

-27- A Catastrophe Recovery Plan (CRP) should be created to enable the application to return to service as soon as possible following a catastrophe. Most CRPs contain the following: ! Threat analysis, ! Risk assessment, ! Mitigation steps, ! Response and recovery plans, ! Damage assessment process, ! Salvage procedures, and ! Rehabilitation plans. B. System Performance The system's performance can be greatly improved with the intelligent application of best practices and procedures for performance tuning and system design. These include the following: 1. Database Design and Query Optimization The database should be designed with performance in mind. All database queries should be optimized to maximize performance. Use of views and indices or similar database functionality should be considered to maximize database performance. By limiting the results to only those that will be utilized immediately, the system will minimize the server and network resource load. 2. Session Variables System design or programming technologies that overuse session variables can degrade the performance of the system. Therefore, only information that absolutely must be maintained to keep the session active should be stored in session variables. Following a user logout or the expiration of a short time limit, session variables should be explicitly purged from memory. 3. Archiving Data Data should be archived regularly to conserve database space and enhance performance. A mechanism should be provided for retrieving the archived data for reporting purposes. 4. Data Volume The data volume of the WEB EATS will be largely determined by the number of sources and the frequency of data collection. With a planned number of sources of less than a thousand, which may include the periodic submittal of hourly data collection, the database isWEB EATS Analysis July 31, 2003

-28- projected to grow approximately 4GB per year. To ensure maximum performance, the database should be regularly re-indexed and monitored for performance. It is recommended that the emissions data collection component sit on a separate server from the business logic server for performance gains. 5. Frequency of Use The system design should take into account the number of users, the level of access, and the volume of data provided by users for specific processes. The WEB EATS usage is expected to be well within the normal expectation of capability for a small to moderate size application. For emissions data submission, the volume of data may be relatively high (by current standards) and require special design consideration. C. Maintainability To achieve a flexible system that evolves with program needs, the system should be developed for maximum maintainability. If the application is based on vendor software, it should be built upon well-known technology and platforms. If it is custom developed, it should be well documented and based upon best programming practices and standards and developed in a common development language. These measures will minimize time and cost to maintain the application following implementation. In addition, the programming team should be required to adhere to programming standards, including code organization and documentation, to facilitate support and enhancements after deployment. Post-deployment modifications should be developed by a set protocol including input from users. D. System Outputs The system should support various types of outputs, including data transfers, electronic communications, like email, and connections to external systems. During the system design, the needs of the proposed users and the archiving of data should determine exactly which system outputs should be available. 1. Data Transfers The periodic transfer of emissions and related data should be communicated to the application via a standard information exchange protocol. The exact protocol and procedure will need to be determined based on best practices and volume of data at the time of implementation. Each data record should be error checked to verify its integrity during the submission process.WEB EATS Analysis July 31, 2003

-29- 2. Electronic Communications The application should contain functionality that notifies parties via electronic communication upon the execution of certain actions. These actions would include, for example, allowance transfers, freezing/unfreezing accounts, and system maintenance notices. The exact list of actions, subsequent message media, recipients, and structures should be determined as part of system design. 3. External System Connections The application would be expected to provide data to external data systems such as the Emissions Inventory System that the WRAP will be using to perform the program trigger evaluations tracking. The system should also support connectivity with the National Environmental Information Exchange Network and Tribal Emissions Implementation Software Solution (TEISS). The exact methods used to connect other systems will be determined at the time of system design. The application should also be able to communicate and transfer data files to and from other EPA data and allowance tracking systems, such as the system supporting the federal SO2 emissions trading programs. E. Application of Platform Selection Criteria During the preliminary phases of the system design, a significant decision will be the selection of the technology platforms or architecture for the system. These platforms include the Web server, business logic server, database server, and client interface. For each of these platforms, consider these issues with the following questions in mind: ! Data volume . Will the volume of data which must be maintained, transferred and analyzed be supported by the database and/or the application? Be sure to calculate the data volumes over the estimated life cycle of the project keeping in mind any applicable program specific or overarching regulatory requirements relating to government recordkeeping. ! Performance . What are the minimum performance requirements for basic application tasks, such as accessing the system, updating source information, transferring allowances? What are the minimum performance requirements for infrequent tasks, such as annual compliance assessments, data quality analyses, or submitting hourly emissions data? What are the performance requirements for reports? ! Relative Costs . What are the overall cost constraints? What is the acceptable ratio of design costs to development costs and initial deployment costs versus maintenance costs? Research these issues for comparable systems and platforms.WEB EATS Analysis July 31, 2003

-30- ! Maintainability

. What specific standards and assumptions should be imposed for maintainability? ! Connectivity

. Which connectivity standards should the system support? ! Efficiency

. Are there specific design choices which will impact the efficiency of program implementation? Examine design options and platform options to maximize efficiency benefits of the information system for the overall operation of the program. To what extent should the efficiency benefits to regulated industry, general account holders and the public be taken into account? ! Availability

. What level of system availability is acceptable for each type of user? VI. Design and Development Approach The second objective of this document is to serve as a roadmap to help the States and Tribes implement the program once it has been triggered. Outlined below is an implementation methodology that the States and Tribes can follow to design, develop and deploy the system. In addition, this section provides an analysis of cost and scheduling factors that should be considered. A. Recommended Implementation Methodology Upon the trigger of the WEB Trading Program, detailed system requirements will need to be assessed. The following section recommends, steps to design, develop and implement an information system for the program. It is recommended that a workgroup be created and assigned responsibility for this task. The workgroup should be comprised of user group representation, program analyst(s), and technical specialist(s). 1. Requirements Verification The first step following the need to implement the program will be to verify the requirements of the information system. Since many of the procedural elements of the SIP/TIP will be decided in the future, the exact functionality may have changed since the creation of this document. Therefore, detailed requirements should be verified and incorporated into a system analysis document. It is expected that this stage of the process will require significant participation of all stakeholders, particularly the States and Tribes participating in the program. 2. Assessment of Current Standards and Technology Following the verification of requirements, the workgroup should research and assess the current standards and technologies applicable to this type of information system. Since this application would probably not be designed until many years after this document, it wasWEB EATS Analysis July 31, 2003

-31- determined that the current standards would have little value and these have not been evaluated or referenced. 3. Technical Architecture Option Evaluation Just as the standards and technology should be evaluated, so should the possible technical architectures, as discussed above. Most systems at the time of the creation of this document are 3-tier, but that should certainly not limit the architecture of the WEB EATS. Also, the suggested measures for security and maintainability may no longer be applicable, and should thus be re-evaluated. 4. Closeness of Fit Based upon the system analysis requirements, standards, and architecture assessments, the workgroup should perform a Closeness of Fit study to analyze the available products, technologies, and platforms available. By analyzing the field of products, technologies, and platforms available, the Closeness of Fit study should conclude with a recommended product or set of development technologies and standards. 5. Decision Based upon the Closeness of Fit study, the workgroup should select a product from a vendor(s), develop a custom system, or a combination of the two. 6. Design/Customization/Development Strategy Following the decision to either select a Commercial Off-the-Shelf (COS) product, develop a custom application, or customize an existing application, the workgroup should select a developer and/or TSA to design, develop and implement the system. The development plan should include a careful review of the schedule of program implementation and requirements to ensure that the necessary elements of the application are in place at the appropriate time. A staged process, with design, development, and deployment of specific system modules, is recommended. For example, the initial phase of development would probably focus on the source registration capability and initial allowance allocations. Later development could include allowance transfers capability, annual compliance assessment or overall program assessments. 7. Development Following agreement upon the system design, the developer or TSA should develop the system utilizing modern development best practices and procedures. It is recommended that theWEB EATS Analysis July 31, 2003

-32-developer and/or TSA work with the members of the requirements gathering workgroup to reaffirm and adjust requirements as needed. 8. Quality Assurance/Testing Following the successful development of the system, the developer/TSA should submit the system for rigorous testing. A test environment should be set up and a test database should be populated with data that closely match the quantity and type of data that will be utilized during live transactions. All phases of the system should be rigorously tested by the developer/TSA, States and Tribes, and a select group of end-users. 9. Deployment Following successful quality assurance of the system, the workgroup and the developer/TSA should agree that the system is ready to be deployed or implemented in a production environment. Prior to production, the database will need to be populated with the necessary baseline information including source inventory data, emissions data, users, etc. The developer/TSA should provide training/instructions to users of the system along with appropriate documentation. It is assumed that participating States and Tribes will work closely with the TSA to define and implement a communication strategy to ensure compliance with all program requirements and full use of the information management system developed to ensure its success. B. Timing/Schedule If there is no significant delay after program trigger in the initiation of the information system design and development process and if a staged approach to deployment is adopted, then an implementation schedule in which the necessary system elements are in place is achievable. This objective should be stated at the outset of the project. It should be noted that the use of COS or the customization of an existing system might reduce the initial development time for the system. To fully design, develop and deploy a custom application by today's standards might extend one to two years. Additional time might be necessary if there were significant issues relating to functionality or process about which State and Tribal participants could not agree. Technology trends indicate that forthcoming design and development methodologies will likely reduce this estimate. C. Cost Factors Factors driving the cost of the information system include technical platform, design complexity, data volume, security level, and the level of and approach to integration with other data systems. The availability of and use of COS or another application as the basis for the application would also affect costs.WEB EATS Analysis July 31, 2003

-33- 1. Technical Platform The technical platform includes the server software and business logic systems that are required. There are a wide range of options for the level of solution required and cost. A middle-ground solution is most likely the most suitable for the WEB EATS, one that maximizes flexibility and maintainability. 2. Design Complexity The level of complexity incorporated into the system design will be a large cost factor. Generally, the more complex systems are, the more they cost. Based on the current system analysis, the system design appears to be moderately complex. As with any application, the requirements phase of the project may result in relatively more or less complex requirements, directly affecting costs. 3. Data Volume The amount or volume of data will be a key cost driver in selecting the database server. If only one database is utilized for both the allowance and emissions data in WEB EATS , the database will grow quickly and will require a high-end solution to maintain performance levels. It is expected that the relatively high data volume will require database optimization and regular tuning, which will add to the maintenance costs. 4. Security Level The level of security built into the system will certainly affect the cost. The more robust the security model is, the more time consuming and costly to implement. The security level detailed in Section III(A)(I) dictates a moderate level of security. VII. TSA Responsibilities and Performance Criteria A. TSA Responsibilities The Tracking System Administrator (TSA) will have responsibility for the deployment of the site, ongoing maintenance and the day-to-day program implementation tasks associated with the program. It seems likely that the TSA would also design and develop the information system, but it is not necessary that both development and support should be provided by the same organization. Regardless, the ongoing responsibilities of the TSA would include two types of support: information system and program implementation.WEB EATS Analysis July 31, 2003

-34- 1. Information System This category of support is to ensure that the information system is properly administered, supported and performs all required functionality. ! Data security. The TSA would assume responsibility for ensuring that the security of the site and the data is monitored and protected on an ongoing basis. This would include monitoring access to the site and attempted but failed access (particularly if occurring in significant volume). ! Data integrity

. The TSA would assume responsibility for ensuring that the integrity of the data is monitored and protected on an ongoing basis. This would include ensuring that the referential integrity of the data is maintained, a data backup plan is implemented, and any opportunities for data corruption are identified and addressed. ! Data quality assessment and corrective maintenance . The TSA would develop within the application and be responsible for performing data checks to identify duplicative information, data omissions or other data of poor quality that are not easily prevented by error checks or data standards. The TSA would make corrections to the data, as necessary, and maintain documentation of changes. ! WEB EATS enhancements . The TSA would document and evaluate any proposed enhancements, modifications or additions to the application. Working with the State/Tribe participants in the trading program and within established budget constraints, the TSA would perform, test and deploy the modifications (in coordination with the assigned programming team). ! WEB EATS documentation . The TSA would have responsibility for maintaining all technical documentation for the WEB EATS (including enhancements and for maintaining records relating to its ongoing operation). ! User technical support. The TSA would provide technical support to all users of the application. This would include telephone support and responses to requests or inquiries through other means of communications. The TSA would maintain records of all technical support and the TSA response. Technical support needs could also be addressed through the use of other support tools, comparable to the FAQs or online support systems currently in use. ! Performance monitoring . The TSA would be responsible for monitoring the overall performance and availability of the application for all types of users. This would include identifying the causes of any disruption of service or availability and identifying any persistent problems experienced by the user community.WEB EATS Analysis July 31, 2003

-35- ! Database administration . The TSA would monitor data performance and perform all maintenance and optimization tasks affecting the performance of the database. The TSA would maintain records of all database administration activities. 2. Program Implementation The TSA is also expected to implement the program for the consortium of States and Tribes participating in the program. This is necessary to ensure that the program will be implemented consistently and cost effectively. ! User access administration . This support would include evaluating and responding to user access requests, password changes, and related usage issues. ! Coordination with States and Tribes . The TSA will coordinate, as necessary, with each State or Tribe participating in the program to ensure that the State or Tribe fulfills their responsibilities and is aware of the need for their participation in decisions or issues. This includes aiding the States and Tribes in developing enforceable procedures for recording the necessary data. For example, the TSA would obtain allocation lists, petitions, retirement approvals, information about new sources, and reduced emissions monitoring under Section I1.(6) of the model rule from the State or Tribe. ! Perform allowance allocations . Using the information provided by the State or Tribe, the TSA would perform allowance transfers from government accounts to compliance accounts. The TSA would provide a report (or electronic file) to the State or Tribe of these actions. ! Perform allowance transfers . Using the information provided by the representative of the account in which the allowances are held, the TSA would perform valid allowance transfers from the account to another account. The TSA would provide notice to the representative of these actions or of rejections or invalid transfers. ! Periodic status reports on system activity and program implementation issues . On a regular basis (monthly, quarterly and annually), the TSA would provide to the participating State and Tribes a summary of program activity. This report would include, for example, a summary of allowance transfer activities, a status report on emissions reports, or the level of public access to the database. ! Annual compliance assessment . The TSA would perform the annual compliance assessment or true-up and would coordinate with industry, States and Tribes regarding the results of this process. Following review or approval by the participating States and Tribes, the TSA would finalize the compliance assessment by retiring the appropriate number of allowances from compliance accounts. An end-of-year compliance report would be made available.WEB EATS Analysis July 31, 2003

-36- ! Communication strategy development/implementation/support. Throughout the life of the program, the TSA would work with the participating States and Tribes to maintain and implement a communication strategy and plan. The purpose of the plan would be to ensure full participation of affected sources in the emissions trading program and to maximize understanding of and knowledge about the program among all interestedparties. The content of the plan would include a strategy for general guidance, day-today communications to sources about their actions (transfer confirmations, data receipts, etc.), State/Tribal reports, communications between States and Tribes about ongoing program issues such as monitoring approvals or petitions, participant or public meetings and publications containing program results or environmental assessments. ! Overall program assessment . The TSA would assist the States and Tribes in designing and conducting an assessment of the overall program operation, costs, and environmental benefits on a periodic basis. ! Error correction, followup and documentation . The TSA would be responsible for correcting any data entry errors reported by users that are not within the security limits for the user. B. TSA Performance Criteria To ensure adequate support for the program, it will be necessary to establish performance criteria for the TSA. 1. Technology Standards For the WEB EATS and technology support, the key criteria should be based on technology standards prevalent at the time of deployment and they should be tailored to the technical architecture selected for the WEB EATS. The following criteria would fall into this category and should be defined at the appropriate time. The importance of each of these factors should also be considered during the WEB EATS system design phase and in the selection of a technical architecture. ! System performance (response time, number of concurrent users supported, frequency of WEB EATS or database errors, etc). ! System availability (average downtime). ! Timeliness of public access to data.WEB EATS Analysis July 31, 2003

-37- 2. Contract Performance Standards Other important criteria relating to TSA performance would be the traditional criteria relating to overall performance with respect to basic contract terms. These would include: ! Responsiveness to customer concerns, ! Timeliness and quality of status reports, ! Overall cost, and ! Budget accuracy.WEB EATS Analysis July 31, 2003

-38- References 1. Jenkins, George Henry. Information Systems Policies & Procedures Manual. Paramus, NJ: Prentice Hall, 1997. 2. "The Ten Most Critical Web Security Vulnerabilities." The Open Web Security Project

. 13 Jan. 2003. <http://www.owasp.org/>. 3. United States Environmental Protection Agency. Clean Air Market Programs. Emissions & Allowance Tracking System

. 4. United States Environmental Protection Agency. State/EPA Information Management Workgroup. Blueprint for a National Environmental Information Exchange Network

. June 2001.