6804-3 ETRM Software SOW_Technical Specifications-FinalEnergy Trading Risk Management Solution
RFP 6804
EXHIBIT 3
TECHNICAL AND FUNCTIONAL REQUIREMENTS SPECIFICATION
Table of Contents:
1. INTRODUCTION 3
1.1 About DME’s Risk, Energy Management, and the QSE Function 3
1.2 Scope of Requested Software and Data Integration Services 5
1.3 Respondent’s General Responsibilities 6
1.4 DME’s General Responsibilities 6
1.5 Project Timeline 7
1.6 Confidentiality 7
2. TECHNICAL REQUIREMENTS 8
2.1 General System Functionality 8
2.2 Respondent’s Background Narrative 9
2.3 Front Office Functionality 10
2.4 Front Office Reporting 10
2.5 Middle Office Functionality 11
2.6 Back Office Functionality (Counter-Party Checkout, Invoicing, and Accounting) 11
2.7 System Helps, Guides, and Documentation 12
2.8 Standardized Training 12
2.9 Proposed System General Questions 12
APPENDIX C: 13
APPENDICES 14
Appendix A Proposed System Architecture 14
Appendix B Recommended desktop and server requirements for the proposed solution 14
Appendix C – DME Envisioned System Connectivity 15
1. INTRODUCTION 3
1.1 About DME’s Risk, Energy Management, and the QSE Function 3
1.2 Scope of Requested Software and Data Integration Services 5
1.3 Respondent’s General Responsibilities 6
1.4 DME’s General Responsibilities 6
1.5 Project Timeline 7
1.6 Confidentiality 7
2. TECHNICAL REQUIREMENTS 8
2.1 General System Functionality 8
2.2 Respondent’s Background Narrative 9
2.3 Front Office Functionality 10
2.4 Front Office Reporting 10
2.5 Middle Office Functionality 11
2.6 Back Office Functionality (Counter-Party Checkout, Invoicing, and Accounting) 11
2.7 System Helps, Guides, and Documentation 12
2.8 Standardized Training 12
2.9 Proposed System General Questions 12
APPENDIX C: 13
APPENDICES 14
Appendix A Proposed System Architecture 14
Appendix B Recommended desktop and server requirements for the proposed solution 14
Appendix C – DME Envisioned System Connectivity 15
INTRODUCTION
This Technical and Functional Requirements Specification document describes the desired functionality for an Energy Trading Risk Management (ETRM) software/system to be purchased by
The City of Denton for Denton Municipal Electric (DME). The new system shall be utilized in the existing DME Administration Building located at 1659 Spencer Road, Denton, Texas 76205.
The installation, implementation and commissioning of the new system must be carefully coordinated with DME support staff.
DME has developed this Technical and Functional Requirements Specification document to give prospective bidders sufficient information to construct high-quality proposals for solutions,
software and data integration services, which in their experience with similar organizations, will best meet DME’s needs. These requirements are not intended to be all-inclusive, but
are meant to provide a reasonable indication of the combination of DME’s front, middle, and back office system needs, how these systems must interact with DME’s real-time operations
infrastructure, executive management reporting needs, middle office risk monitoring and compliance requirements, back office/accounting operations and desired Information Technology
(I/T) related characteristics of the new system.
DME is seeking to replace its current ETRM System with a commercial-grade solution that can at a minimum, meet current and future functional requirements.
The primary business drivers for purchasing an ETRM System include, but are not limited to, DME’s need for:
Accurate capture, storage, audit, control, valuation, and reporting commodity operations exposure, P&L attributes and risk controls/metrics,
Provision of greater efficiency and effectiveness in running DME’s Front, Middle and Back office processes,
Additional functionality and flexibility to expand to meet new business requirements and capabilities in all functional areas,
Technical support must have superior “bench depth and breadth”,
Adherence to Electric Reliability Council of Texas (ERCOT) market rules, regulations and requirements, current and future, including Public Utility Commission (PUC) Texas and Texas Reliability
Entity (TRE) oversight, and
Industry best practices.
1.1 About DME’s Risk, Energy Management, and the QSE Function
Background for DME’s Risk and Energy Management is as follows:
DME is an ERCOT Non-Opt-in Entity ‘NOIE’. DME is not a competitive area but operates within the deregulated footprint of ERCOT. DME ‘Energy Management’ includes the functions of an
ERCOT Qualified Scheduling Entity (QSE).
DME utilizes the following products both physical and financial:
Power
Ancillary Services
Natural Gas
Emissions & Environmental commodities (including, but not limited to RECs)
Congestion Revenue Rights (CRRs)
Options and other underlying transactions.
DME is part owner of Texas Municipal Power Agency (TMPA), a coal plant.
DME has a nearly completed project to build and operate a quick start gas-fired generation facility. DME purchases natural gas to supply its generation.
DME has a growing renewable portfolio, incorporating wind and solar assets. DME serves as the QSE for Independent System Operator (ISO) scheduling purposes. DME may provide QSE services
for ISO-scheduling of these assets and/or that of other market participants.
Pricing, valuation, reporting, and volumetric capture of contracted to estimated (scheduled) to actual quantities of DME’s hourly and 15 minute positions, or shape, is important to DME.
DME has modest trade volume for a utility of its size per and is not a power marketer or a proprietary trader, in that regard.
DME has a limited “in-house” resources for operation with ETRM systems, including from an implementation and operation standpoint.
DME is not staffed to have a team of dedicated ETRM personnel. At most, DME will have one dedicated ETRM administrator/operator, with some access to multi-duty back-up personnel. DME
Information Technology is part of City of Denton I/T and while dedicated to DME, its time is split between several different departments within DME. As such, it is not dedicated solely
to support the commodity portfolio management and optimization operations efforts. It is intended that the ‘business’ will be the owner/operator of the ETRM. Many of DME’s operational
and commercial personnel have prior experience from competitive companies ranging from small to large organizations, which typically have dedicated resources to support implementation
efforts, which is not feasible at DME.
Functions of an ETRM system are only part of Risk and Energy Management personnel responsibilities, therefore the proposed system must “support” and “lighten the workload” of personnel
and not become an additional workload.
Typically, DME users will extract data from the ETRM system to perform their own analysis and are proficient Excel users and not SAS based users.
There will be in the order of 10 unique users; comprised of:
2 risk,
1 settlements,
5 power, gas & congestion
1 System Administrator
1 managers, and
DME anticipates 2-4 growth users in future years
1.2 Scope of Requested Software and Data Integration Services
DME seeks proposals for an Energy Trading, Risk Management ‘ETRM’ system to support its Risk and Energy Management operations. DME envisions a software application or suite of applications
that provides the Operations, Analysis, Valuation, Controls and Reporting tools necessary to support DME’s Energy Management Functions listed below:
DME Energy Management Functions
Front Office
Middle Office
Back Office
Trade Capture
Curve capture and validation
Counterparty Checkout
Position Management
Valuation, P&L, M-t-M
Invoicing
Scheduling
Risk Analytics
Accounting
Volume and price actualization
System set-up
Reporting
Reporting
Change management
Credit & Collateral Management
Confirmations
Risk Controls
Audit Reporting
The desired ETRM solution should be intuitive, flexible, adaptable, and scalable while at the same time minimizing burdensome complexity that would degrade performance, inhibit user
interaction, or require undue user training or, specialization or excessive time and resources, including support.
The desired ETRM provides solutions that integrate two way data communication with a variety of data sources that is automated, where practicable, to avoid repetitive user interactions
and minimize risk of data integrity error. Automation should be updateable, and enable updates to the automation to address changes to data sources, content, format or other change
requirements in a timely manner, with minimal vendor support, minimal error risks, and that minimizes any negative impact to DME business operations and performance.
Significant features of the proposed system that DME desires potential proposers to address are described below. DME is seeking proven vendors that have commercially available, currently
deployed, ETRM software that fulfills the functionality as listed in this RFP. DME is not interested in software that is either “in-development”, commercially unproven, or currently
not deployed in a tested commercial installation. Vendor staff should be adequately knowledgeable of and capable of the deployment of their system to the ERCOT market, including all
underlying commodity market products and applications to be held within the ETRM system. Existing deployment within ERCOT is desirable.
1.3 Respondent’s General Responsibilities
The Respondents shall assume responsibility for the design, fabrication and startup of the new system. The Vendor's obligations shall include, but not be limited to, the responsibilities
in the following list, and those required performing the system functions described in the Specification:
Delivery of application software, client ready set up and required licenses.
Integration of all Vendor-supplied hardware and software.
Data migration of existing data into new platform.
Training of DME personnel.
User’s guides, electronic “help” services/assistance, and other documentation.
The vendor shall be responsible to provide adequate support and warranty services for a minimum of 1 year after the Production Go-Live Date. Support services must include day-time support
(Monday through Friday during normal business hours), help desk, problem resolution, subscription for vendor software patches, software upgrades and provision for support of a 24x7
electric energy business and its operations.
1.4 DME’s General Responsibilities
DME shall supply the following items and services as part of the new system:
Windows based desktop computers, database and OS software licenses, and required Windows/Linux server platforms, for on premise installations.
ERCOT Digital Certificates.
Physical LAN and Internet connections, firewall configurations, VPN tunnels for data connectivity.
Meeting room facilities.
1.5 Project Timeline
The project timeline and schedule of events is stated in the RFP, but additional information is given in the table below.
For guideline purposes only, dates may shift per circumstances.
Item/Task
Start
End
COD Initial review of proposals, defines presenter short list
2/14/19
2/20/19
Vendor “short list” proposal prep week
2/25/19
3/1/19
Vendor proposal week for short list group
3/4/19
3/8/19
COD FINAL review of proposals (after Vendor presentations)
3/11/19
3/18/19
DME/Successful Vendor, contract and T&C negotiations period
3/20/19
4/1/19
Presentation to PUB/Presentation to Council
4/15/19
4/16/19
1.6 Confidentiality
DME has the expectation that detailed mutual exchanges of information that may be confidential, commercially sensitive, or are protected intellectual property may need to occur between
Respondent(s) and DME at a future point during product exploration, or negotiation. For any such confidential information disclosed as part of a response to this RFP, the City of Denton
will keep such information confidential and will not disclose to third parties to the extent that it is legally permitted. All respondents should be aware that Denton is required to
comply with the Texas Public Information Act (Chapter 552 of the Texas Government Code) (“TPIA”) when responding to records requests made under the Act.
The City of Denton has the expectation that it will select a group of semi-finalist from the RFP respondents and will engage in a deeper examination of the product or service in this
phase. In this deeper examination detailed mutual exchanges of information that is confidential, of a competitive nature that may reveal cyber system architecture/security features,
or may be protected intellectual property may be required between Respondent and the City Denton.
In anticipation of this, the City of Denton has provided a proposed Confidentiality Agreement as part of this RFP that Respondent may execute and include with its response. Respondent
my also propose its own Confidentiality Agreement or Non-Disclosure Agreement for review by the City of Denton’s Legal Department, who will review and advise the City of its acceptability.
If not acceptable, additional negotiations and changes will occur prior to execution.
TECHNICAL REQUIREMENTS
This section describes the technical and functional requirements of the Energy Trading and Risk Management ‘ETRM’ software. It shall be noted that the proposal shall be judged by its
conformance to the functional requirements of this section.
The proposed software must provide industry leading processing speed and minimum turn-around time for all functionality; have audit controls commensurate with industry best practice;
be capable of being integrated and operating efficiently with other related systems; and must store data and transaction information so that it is easily accessible within the database
architecture and can be imported or exported through user-defined queries or other convenient means that can be automated. The proposed software must be robust, flexible, upgradeable
and expandable to accommodate changes in energy trading activities and regulations for a period of at least 10 years.
Appendix A: Should be drafted and included by the Respondent and contains the system architecture for the proposed system and interfaces/connectivity to existing DME servers and databases.
DME anticipates either a locally installed client server solution or a hosted SaaS solution, or both, and is open to other configurations by Respondents. The proposer should attach
the necessary documentation in Appendix A. The proposer shall include pricing for both options in the Excel pricing exhibit (Exhibit 1).
Appendix B: Should be drafted and included by the Respondent and contains the recommended desktop and server system requirements. A detailed description of the workstation(s), physical
servers, application and database server(s), middleware, network, telecommunication and Internet connectivity requirements and specifications. A written description and applicable
structural diagrams of the information technology and architecture, system design, data flow and data interfaces. Hardware, software, and support costs for which DME is responsible
will be included in the total cost of ownership Evaluation Criteria.
2.1 General System Functionality
2.1.1 The proposed software must facilitate increased collaboration and integration across functions and departments, while maintaining a separation of duties across the previously-described
front office, middle office, and back office functions.
2.1.2 The proposed software must leverage existing platforms and eliminate redundant data entry through the use of integration.
2.1.3 The proposed software must satisfy client requirements relating to security, transparency, data-integrity, record keeping, data backup, data input/output and other system and
control requirements.
2.1.4 The proposed software must incorporate a strong systematic workflow process to schedule tasks and to automate functions and routine procedures. More specifically, the ETRM must
have certain specified capabilities for each of the following functional areas:
a) System setup of account, counterparty, market, product, books, etc.
b) Trade or Deal Capture/Entry, Price/Curve Repository & Integration with Price/Curve Feeds
d) Trade/Deal valuation and Data Repository
e) Integrated Risk Reporting and Repository
f) Credit & Collateral Management
g) Contract Management and Confirmations Tracking
h) Scheduling (Volume actualization) and Logistics
i) Centralized Position, Valuation and M-t-M/Profit & Loss (P&L) Reporting
j) Full audit capabilities and controls
k) Settlements (check out, invoicing and operational accounting roll off)
2.1.5 The software must have the capability to integrate with existing client network security systems and firewalls, and also allow for effective user access controls.
2.1.6 Comprehensive Audit and Internal Controls: The proposed software needs to support effective risk controls including data entry, amendment and valuations tracking controls and reporting,
including internal controls and documentation in accordance with leading industry practices. The system should respond to requests and valuations quickly and effectively, including
standardized and ad-hoc tasks/queries. There should be minimal performance degradation for small or large tasks. Please describe the proposed software’s ability to create an electronic
process/trace ticket for the entire life cycle of a transaction. This should include: who, what, when, why, where, and how a transaction is created and or modified, and the storage
location of ticket when deposited into a repository. The repository should allow for search, sorting and tagging by trader, price, counterparty, date, commodity, and all other variables,
unique or otherwise, efficiently and effectively displaying, reporting and providing output to show transactions in their entirety throughout the transaction life cycle in ‘day of’
and ‘as of’ reporting.
2.1.7 Security: The solution must provide user-level security and control.
2.2 Respondent’s Background Narrative
2.2.1 An account of Respondent’s track record of how previous production releases are supported; this should include a description of significant limitations, such as the number of previous
releases that will be supported.
2.2.2 A description of Respondent’s approach to adapting and providing support for significant changes in the industry; the Respondent should also include a realized example of such
an event and how it was addressed.
2.2.3 A description of Respondent’s experience (including examples) in supporting automation of applicable work process flow in coordination with the Respondent’s ETRM software solution,
addressing to the extent applicable pre-defined, user-defined and user-modified automated workflows.
2.2.4 A description of Respondent’s experience (including examples) in planning and executing implementations and full operation of systems for clients. Attention should be noted to
experience and qualifications of personnel and resources available and to be used.
2.2.5 Given the proposed award date in the table in the Main RFP, Section 4 – Schedule of Events, and section 1.5 above, can the system be functional for capturing and evaluating trades
and be interfaced to other DME systems on or prior to September 1, 2019? If not, when could the system be installed and functional?
2.3 Front Office Functionality
The proposed software must have the ability to support energy deal record, processing and valuation capabilities for both physical and financial electric power transactions-energy and
ancillary services or associated products (specifically, but not limited to ERCOT); and physical and financial natural gas transactions (commodity, transport, storage, basis etc.);
all power industry fuel types (e.g., coal, fuel oil, alternative fuels, etc.); Congestion Revenue Rights; Emissions and Renewable Energy Credits/Environmental Attribute Products; options
on all of the above; the capture of physical asset attributes (e.g. power plants, renewable energy facilities, energy storage); fees and charges related to a transaction (such as from
Brokers, Exchanges or Clearing Houses, consumables, etc.); and capacity for future consideration, if desired.
The system must be able to capture contracted, scheduled, and actualized volumes and must be tracked and auditable. Operational integration with ISO, pipeline, storage operator communication/data
flow tools are desirable.
The trade/transaction functionality of the solution must be able to capture deal terms for multiple commodities, various nodal locations and delivery times, with granularity to at least
15 minute time interval where needed, and permit risk controls (e.g. track approvals and validations). Cross commodity and cross counterparty/entity (e.g. book) transactions should
be possible.
A key proposed software system objective is ease of use for data capture and data extraction. The process should be intuitive, efficient and user-friendly.
The proposed software functionality also must support position management.
2.4 Front Office Reporting
The proposed software must provide effective position management capabilities, including reporting in both detailed and summarized form, capable of standard and user-defined reporting
parameters. Reporting and data export must be possible in detail and aggregation by multiple
filtering methods, including but not limited to; gross and net position & valuation reporting, by product type, risk type, time, locations, counterparty, asset, strike, expiry etc.
2.5 Middle Office Functionality
Market data gathering is critical to the accuracy and timeliness of pricing and trade valuation within any energy trading environment. Process efficiency, accuracy, internal controls,
validation and change, and regulatory requirements are primary considerations.
DME expects that the selected solution will provide robust features to help manage transaction-related risks. This software product will need to support internal controls such as limit
structures for traders, counterparty credit limits, confirmation processing, exception reporting, validation, and verification.
Financial and Commodity Risk Management functions and reports including Position, P&L, MtM, and risk metrics, including but not limited to VaR, CFaR, GMaR, etc. reports are key tools
for management to analyze, monitor, understand, and make decisions regarding market, credit and operational opportunities and risks. It is important to DME that this software will
display day to day changes in real time and show the causes of P&L shifts and position movements.
The software will need to be able to house and support the processing of multiple forward price curves, including forward curves for Ancillary Services, interest rates, correlations
and volatilities. The capability to manage forward price curves within the system are important to DME such as tools for data cleansing (filling in missing data, correcting errors),
formatting (to standardize granularity or time of use periods) and validation (detecting and removing inconsistencies).
A robust set of credit management tools is also an important feature DME is seeking from this software product, such as the ability to store collateral thresholds, independent amounts,
percentage of exposure and credit matrices from contract provisions, automation of the margin call process; the ability to generate a hierarchical view of counterparty/subsidiary legal
structures and commitments; model complex limit structures, counterparties, commodities and hierarchies; view credit risk concentrations by commodity, deal type and credit rating; generate
real-time alerts of ratings and financial filing changes; create robust scoring models; identify and monitor key risks through dynamic modeling and reporting capabilities; generate
suggest credit limits based on score; integrate with external feeds such as S&P, Moody’s, Fitch, D&B.
2.6 Back Office Functionality (Counter-Party Checkout, Invoicing, and Accounting)
Please provide a detailed description of the functionality and features of the proposed software package that support back office operations.
Credit/Collateral risk management is an integral component of any trading/hedging organization. A robust, scalable platform is required. A software solution which will eliminate manual
processes that can be automated is a priority. The primary business objectives are to improve information availability and data reporting, and to streamline the business processes.
Back office functions including check-outs, reconciliations, settlement, invoicing and receivables-tracking must be fully integrated. This functionality must process complex deal types
using deal and price data maintained within or through interfaces with general ledger or other systems. The settlement functionality may potentially include invoicing, bilateral and
ISO/Exchange settlements, or alternatively interfacing with existing systems that perform those functions, as well as cash application and accruals.
2.7 System Helps, Guides, and Documentation
The proposed software should have well-defined support, training and documentation for both users and administration of the software.
2.8 Standardized Training
DME desires to receive adequate and effective training for all functions of the software as it relates to the Front, Middle, and Back Office functions.
2.9 Proposed System General Questions
Each respondent must answer all of the questions below.
2.9.1 Can the solution store or generate invoice numbers (system or user initiated)?
2.9.2 Can the solution track payments to/from counterparties?
2.9.3 Does the solution import, store, or link information (PDF, .wav, word, csv, etc.) in support of transaction modification?
2.9.4 Is the solution capable of invoicing for third parties and keeping track of separate ‘books’ with distinct functions (e.g. Power Marketing agreements vs. PPA's)?
2.9.5 Does the solution allow for customizable invoice templates with UTILITIES' design and other corporate designs?
2.9.6 Is the solution capable of adding additional charges that are not part of the commodity component but are transaction related and/or making retroactive adjustments e.g. a demand
charge or a power plant consumable?
2.9.7 Does the solution support the analysis between internal and external charges?
2.9.8 Does the solution attribute costs for items that flow through multiple services (e.g. gas to electric, shared storage facilities, inter-book transfers)?
2.9.10 Can the solution track cash collateral transactions and balances to/from Counterparties?
2.9.11 Can the solution track transactions and balances to/from Clearing Broker accounts?
2.9.12 Is the system a cloud based (Web as a Service), hosted environment, local server, or PC based system?
2.9.13 Is the proposed software capable of direct copying and pasting data to/from Excel, Access, e.g. hourly deal capture, etc.? If not, does it have other import/export capability?
2.9.14 Can the proposed system capture multi-period products (e.g. Nat Gas Futures Strip) without repetitive data entry. For example does a calendar strip trade have to be broken
down into unique monthly trades?
2.9.15 What are the configurable time periods over which positions can be analyzed and netted?
2.9.16 Does the proposed system offer API functionality? If so, are there limitations to specific functional areas (for example there is an API to import trades but that is all)?
2.9.17 Are there pricing impacts to the perceived size requirements to the proposed system? For example if DME had twice the number of trades that the Respondent expects, would this
impact system cost? Alternatively, if DME had half of the perceived trades, would this impact the proposed system cost?
Appendix C:
A simplified system interface and connectivity diagram is given in Appendix C. Because of the sensitive nature of DME’s operating environment, the envisioned detailed connectivity between
existing DME systems and the prospective ETRM software system will only be shared with Respondents after completion of a Confidentiality or Non-Disclosure Agreement (a proposed Confidentiality
Agreement is provided – see section 1.6). Once such an agreement is in place, this detailed information will be provided to Respondents allowing a better understanding of DME’s integration
plans.
C.1 Integration: Solution must integrate with other systems and applications within DME’s infrastructure. The selected Respondent must collaborate with DME to accomplish successful
integration. The Solution may be interfaced with subsequent new solutions, databases that may be developed in parallel, existing Microsoft Access databases, Excel-based systems, and
other systems that are not being replaced.
Appendices
Appendix A Proposed System Architecture
(to be completed by Respondents)
Appendix B Recommended desktop and server requirements for the proposed solution
(to be completed by Respondents)
Appendix C – DME Envisioned System Connectivity
/