1 Introduction

The Common Transactive Services (CTS) is an application profile of the OASIS Energy Interoperation 1.0 ([EI]) specification, with most optionality and complexity stripped away. CTS defines the messages for transactive energy, leaving communication details unspecified. Transactive energy names the collaboration techniques to balance energy supply and energy demand at every moment even as power generation becomes decentralized and as the ownership of energy assets becomes more diverse.

The purpose of CTS is to enable broad semantic interoperation between systems in transactive energy-based markets, or in any markets whose products are commodities distinguished chiefly by time of delivery. These time-volatile commodities are termed resources, and the interactions defined in CTS are common to any market used to manage resources over time.

To encourage broad adoption, CTS uses terms from financial markets in preference to the relatively obscure terms used in specialized energy markets. Among these is the use of the term instrument for a tradable asset, or a negotiable item. In CTS, the term instrument encompasses a quantity of a Resource delivered at a particular time for a particular duration. A transaction is created when a buyer and seller agree on the price for an instrument.

Transactive resource markets coordinate resource supply and resource use through markets that trade instruments. The initial research into transactive resource markets used a market to allocate heat from a single furnace within a commercial building. Transactive resource markets balance supply and demand over time using automated voluntary transactions between market participants.

Examples of transactable resources include, but are not limited to, electrical energy, electrical power, natural gas, and thermal energy such as steam, hot water, or chilled water. The capability to transmit such time-dependent resources is also a transactable resource, as instruments can be defined for transmission rights as well as for the services that maintain grid frequency or voltage.

When we apply transactive resource markets to the distribution of power or energy, we refer to it as transactive energy. A significant driver of transactive energy is the desire to smooth supply and demand variability, or alternatively, to match demand to variable supply. We anticipate this variability to increase as additional variable and distributed generation sources are connected to the power grid. The reader can find an extended discussion of Transactive Energy (TE) in the EI specification [EI]

A goal of CTS is to enable systems and devices developed today or in the future to address the challenges of increasing distributed energy resources. CTS enables distributed actors to participate in markets deployed today or in the future.

CTS defines interactions between actors in energy markets. We do not identify whether an actor is a single integrated system, or a distributed collection of systems and devices working together. See Section 1.5 for a discussion of the term Actor in this specification. Autonomous market actors must be able to recognize patterns and make choices to best support their own needs.

CTS assumes the perspective of a trader, that is of a market participant. [EI] was developed with significant input form Economists and energy market regulators, and it relies on language from economics and regulation. The Committee deliberately chose to seek guidance from financial traders and to use their language. Many data elements and message types have been renamed to align with FIX-based markets.

CTS messages are simple and strongly-typed and make no assumptions about the systems or technologies behind the actors. Rather, CTS defines a technology-agnostic minimal set of messages to enable interoperation through markets of participants irrespective of internal technology. In a similar manner, CTS does not specify the internal organization of a market, but rather a common set of messages that can be used to communicate with any transactive energy market.

The Common Transactive Services, strictly speaking, are a definition of the payloads and exchange patterns necessary for a full-service environment for interaction with markets. In other words, CTS describes the message payloads to be exchanged, defining the semantic content and ordering of messages. Any message exchange mechanism may be used, including but not limited to message queues and Service-Oriented mechanisms.

In a Service-Oriented Architecture [SOA] environment, the semantic payloads are those sent and returned by the services described. CTS enables any SOA or other framework to exchange equivalent semantic information without presuming the specific messaging system(s) or architecture used, thus allowing straightforward semantic interoperation.[1] See Section 2.3. Th

1.1 Application of the Common Transactive Services

The purpose of this specification is to codify the common interactions and messages required for energy markets. Any system able to use CTS should be able to interoperate with any CTS-conforming market with minimal or no change to system logic. The full protocol stack and cybersecurity requirements for message exchange between systems using CTS are out of scope.

Systems that can be represented by CTS actors include but are not limited to:

· Smart Buildings/Homes/Industrial Facilities

· Building systems/devices

· Business Enterprises

· Electric Vehicles

· Microgrids

· Collections of IoT (Internet of Things) devices

TE demonstrations and deployments have seldom been interoperable—each uses its own message model and its own market dynamics. Such markets discount local decision making while introducing new barriers to resilience such as network failure. Others rely on a single price-setting supplier. Systems built to participate in these demonstrations and deployments have been unable to interoperate with other implementations. The intent of this specification is to enable systems and markets developed for future deployments to interoperate even as the software continues to evolve.

CTS does not presume a Market with a single seller (e.g., a utility). CTS recognizes two parties to a transaction, and the role of any Party can switch from buyer to seller from one transaction to the next. Each Resource Offer (Tender) has a Side attribute (Buy or Sell). when each transaction is committed (once the product has been purchased) it is owned by the purchaser, and it can be re-sold as desired or needed.

A CTS micromarket may balance power over time in a traditional distribution system attached to a larger power grid or it may bind to and operate a stand-alone autonomous microgrid [SmartGridBusiness].

1.2 Support for Developers

Specific coding, message, and protocol recommendations are beyond the scope of this specification which specifies information content and interactions between systems. The Common Transactive Services payloads are described using the Universal Modelling Language [UML] and defined in XML schemas [XSD]. Many software development tools can accept artifacts in UML or in XSD to enforce proper message formation. To further support message interoperability, two additional common serializations are defined:

(1) This specification provides [JSON] schemas compatible with JSON Abstract Data Notation [JADN] format.

(2) This specification provides [SBE] schemas. The FIX Simple Binary Encoding specification is used in financial markets and for general high-performance messaging—SBE is designed to encode and decode messages using fewer CPU instructions than standard encodings and without forcing memory management delays. SBE-based messaging is used when very high rates of message throughput are required. Naming Conventions

This specification follows some naming conventions for artifacts defined by the specification, as follows:

For the names of elements and the names of attributes within XSD files and UML models, the names follow the lowerCamelCase convention, with all names starting with a lower-case letter. For example,

For the names of types within XSD files, the names follow the UpperCamelCase convention with all names starting with an upper-case letter suffixed by “type-“. For example,

For clarity in UML models the suffix “type” is not always used.

For the names of intents and for attributes in the UML models, names follow the lowerCamelCase convention, with all names starting with a lower-case letter, EXCEPT for cases where the intent represents an established acronym, in which case the entire name is in upper case.

JSON and where possible SBE names follow the same conventions.

1.3 Editing Conventions

For readability, element names in tables appear as separate words. The actual names are lowerCamelCase, as specified above, and as they appear in the UML models, and in the XML and JSON schemas.

All elements in the tables not marked as “optional” are mandatory. This is the opposite of the convention used in the specification of FIX.

Information in the FIX Field column is non-normative, and includes in parentheses zero or more FIX Tags that are related to the field. This provides guidance for those integrating CTS markets to interoperate with markets supporting the FIX Protocol.

Information in the Meaning column of the tables is normative. Information appearing in the Notes column is explanatory and non-normative.[2]

Examples and Appendices are non-normative. In particular, architectural and functional examples are presented only to support narrative description. The specific processes, structures, and algorithms are out of scope.

1.4 FIX and the Language of Trading

As noted above, this specification strives to apply the language of financial trading to resource markets. FIX is the language of trading.

We thank members of the FIX Trading Community (https://www.fixtrading.org/) for their extensive input and close reading. FIX was formed in 1991 to connect the global ecosystem of venues, asset managers, banks/brokers, vendors and regulators by standardizing the communication among participants. FIX relies on 4 key principles:

· Creating and maintaining robust open standards across the across the trade life-cycle with its pre-trade, trade, and post-trade environments.

· Providing advice and counsel to regulatory bodies in a transparent and unbiased way.

· Seeking ways to improve the trading process front to back for the global financial services industry.

· Providing FIX members with a neutral, collaborative environment to come together through member-driven conferences and other critical forums to promote, support and educate.

This specification relied strongly on their assistance.

1.5 Use of terms Actors and Facets in this specification

This specification defines message content and interaction patterns.

The EI 1.0 specification in 2011 presumed web services for interactions. That specification described a Service-Oriented Architecture (SOA) approach. Service orientation complements loose integration and organizes distributed capabilities that may be in different ownership domains by focusing solely on requested results rather than on mechanisms. [EI] uses the language of web services to describe all interactions.

There is a growing use of the descriptive term “cloud-native computing” for extending the architecture and technologies developed for use in clouds not only in data centers but to edge computing, where IoT devices reside. A discussion of the rapidly-evolving topics of cloud-native computing and edge computing is beyond the scope of this specification.

At the time of this specification, typical architectures decompose applications into smaller, independent building blocks that are easier to develop, deploy and maintain. A single market participant in energy may be embodied as several of these independent blocks (actors).

For the Internet of Things (IoT), the term Actor begins and ends at the interfaces to things. The “actor model” makes no assumptions of the mechanisms or even motives internal to an Actor. An Actor is simply a thing that acts. The Actor implementation may be by a traditional computer, a cloud node, a human behind a user interface, or any device on the Internet of things.

In transactive energy, the actor model supports the diversity of IoT and of markets. An energy seller may be a generator or a solar panel or a virtual power plant or a demand responsive facility or a financial entity. An energy buyer or seller may be a home or commercial facility or an embedded device or a microgrid or an energy district. A Market acts to match Tenders. An Actor may take a market-maker role, buying and/or selling power for itself. An energy storage system may act as a buyer or as a seller at any time.

We use the term “Facet” to name a coherent set of messages that an Actor may use to communicate with other Actors. An Actor submits tenders to buy or to sell. An Actor may operate a Market. If the architecture includes a telemetry Actor, measuring Resource flow (metering), then that Actor MAY represent the Market or the market participant or even a third party. This specification makes no requirement as to how to distribute or make use of these facets.

While this specification discusses messages between Actors, it establishes no requirement or expectation of specific implementation. While this specification uses the language of Actor and Facet, there is no architectural expectation linked to this language. One could apply the terms Actor and Facet throughout the [EI] specification. A traditional [EI] application consisting of a several unitary systems each presenting all facets as web services described by WSDL can be conformant so long as it uses a compatible set of information payloads.

1.6 Security and Privacy

Service requests and responses are generally considered public actions of each interoperating system, with limitations to address privacy and security considerations (see Appendix B). Service actions are independent from private actions behind the interface (i.e., device control actions). A Facet is used without needing to know all the details of its implementation. Consumers of services generally pay for results, not for effort.

1.6.1 Security Considerations

Size of transactions, costs of failure to perform, confidentiality agreements, information stewardship, and even changing regulatory requirements can require that similar transactions be expressed within quite different security contexts. Loose integration using the service-oriented architecture (SOA) style assumes careful definition of security requirements between partners. It is a feature of the SOA approach that security is composed in to meet the specific and evolving needs of different markets and transactions. Security implementation is free to evolve over time and to support different needs. The Common Transactive Services allow for this composition, without prescribing any particular security implementation.

The best practice in cloud-native computing is to use Zero-Trust security [ZeroTrust]. Zero Trust security requires authentication and authorization of every device, person, and application. The best practice is to encrypt all messages, even those between the separate components of an application within the cloud.

This specification makes no attempt to describe methods or technologies to enable Zero Trust interactions between Actors.

1.6.2 Privacy Considerations

Detailed knowledge of offers to buy or sell or knowledge of energy inputs and outputs for an Actor may reveal information on actions and operations. For example, transactions or tenders may indicate whether a production line is starting or stopping, or anticipated energy needs, or who has been buying or selling power. Making such information public may be damaging to actors. Similarly, an adverse party may be able to determine the likelihood that a dwelling is presently occupied.

The essence of any transaction is the agreement of a Party to sell, and of another a Party to buy. The identity of the buyer and the identity of the seller are each part of the transaction. Some transaction notifications may hide the identity of the buyer from the seller. Some transaction notifications may hide the identity of the seller from the buyer. Some transactions, such as a double auction, may be between the market participants as a whole, and not with any particular counterparty. Where this is required, the Market itself may be designated as the counterparty in a notification.

Both security and privacy considerations are addressed in Appendix B.

1.7 Semantic Composition

The semantics and interactions of CTS are selected from and derived from OASIS Energy Interoperation [EI]. EI references two other standards, [EMIX] and [WS-Calendar], and uses an earlier Streams definition. We adapt, update, and simplify the use of the referenced standards, while maintaining conformance.

See Appendix C, Semantic Composition from Energy Interoperation, EMIX, and WS-Calendar.

• EMIX describes price and product for electricity markets.

• WS-Calendar communicates schedules and sequences of operations. CTS uses the [Streams] optimization, which is a standalone specification, rather than part of EI 1.0.

• EI uses the vocabulary and information models defined by those specifications to describe the services that it provides. The payload for each EI service references a product defined using [EMIX]. EMIX schedules and sequences are defined using [WS-Calendar]. Any additional schedule-related information required by [EI] is expressed using [WS-Calendar].

• Since OASIS published [EI], a semantically equivalent but simpler [Streams] specification was developed in the OASIS WS-Calendar Technical Committee. CTS uses that simpler [Streams] specification.

See Appendix C, Semantic Composition from Energy Interoperation, EMIX, and WS-Calendar.

In [EI], the fundamental resource definition was the [EMIX] Item, composed of a resource name, a unit of measure, a scale factor, and a quantity. For example, a specific EMIX Item may define a Market denominated in 25 MWh bids. In CTS, we group and name these elements as a Resource, Product, and Instrument. These terms are defined in Section 2.2.4, “Markets and Venues”

Note that the informational elements in a fully defined tender or transaction are identical to those described in EMIX. The conceptual regrouping enables common behaviors including Market discovery and interoperation between Actors built on different code bases.

1.8 Applicability to Microgrids (Informative)

As an extended example, using the Common Transactive Services terminology, a microgrid is comprised of interacting nodes each represented by an actor (interacting as CTS parties). Those actors interact in a micromarket co-extensive in scope with the microgrid. No actor reveals any internal mechanisms, but only its interest in buying and selling power.

An actor can represent a microgrid within a larger micromarket; the actor would in effect aggregate the resources in the microgrid. As above, such an actor would not reveal any internal mechanisms, but only its interest in buying and selling power. There is no explicit bound on repeating this interoperation pattern.

An actor representing a microgrid may interoperate with markets in a regional grid, which may or may not be using CTS. In addition, infrastructure capacity may limit delivery to the microgrid. The Actor representing a microgrid must translate and enforce constraints and share information with the other nodes in the microgrid solely by means of CTS. Any translations or calculations performed are out of scope.

See informative references [StructuredEnergy] and [SmartGridBusiness] for a discussion. [Fractal Microgrids] is an early reference that describes hierarchies of microgrids. [Transactive Microgrids] describes transactive energy in microgrids.

1.9 Specific scope statements

This specification interprets Energy Interoperation from the perspective of a Trader interacting with a Market. CTS defines Pre-Trade, Trade, and Post-Trade information exchanges. Trading refers to the specific interactions that buy or sell a resource. A Trader uses pre-trade information to discern the operation of the Market and the actions of the other Traders. Post-Trade information informs the participants of the Trade, tracks whether the resource is delivered, and any resulting changes to the Trader’s ability to participate in the Market.

Interaction patterns and facet definitions to support the following are in scope for Common Transactive Services:

· Interaction patterns to support transactive energy, including tenders, transactions, and supporting information.

· Information models for price and Product communication

· Information models for Market and Market Segment characteristics

· Payload definitions for Common Transactive Services

The following are out of scope for Common Transactive Services:

· Requirements specifying the type of agreement, contract, Product definition, or tariff used by a particular market.

· Computations or agreements that describe how power is sold into or sold out of a market.

· Communication protocols, although semantic interaction patterns are in scope.

This specification describes standard messages, the set of which may be extended.

1.10 Naming of Messages and Operations

The naming of messages and operations and message payloads follows the pattern defined in [EI]. Services are named starting with the letters Ei following the Upper Camel Case convention. Operations in each service use one or more of the following patterns. The first listed is a fragment of the name of the initial service operation; the second is a fragment of the name of the response message which acknowledges receipt, describes errors, and may pass information back to the invoker of the first operation.

Create—Created An object is created and sent to the other Party.

Cancel—Canceled A previously created request is canceled.

For example, to construct an operation name for the Tender Facet, "Ei" is concatenated with the name fragment (verb) as listed. An operation to cancel an outstanding Tender is called EiCancelTender.[3]

Facets describe what would be called services in a full Service-Oriented Architecture implementation, as we do not define SOA services, but only imply and follow a service structure from [EI].

2 Overview of Common Transactive Services

CTS provides for the exchange of resources among parties which represent any provider or consumer of energy (e.g., a distributed energy resource). CTS makes no assumptions as to their internal processes or technology.

Systems use the common transactive services to interoperate in transactive resource markets. A transactive resource market balances the supply of a resource over time and the demand for that resource by using a market specifying the time of delivery.

Although the Common Transactive Services are a profile of Energy Interoperation, the CTS focus is markets and trading. The language used in the Energy Interoperation specification was developed with extensive input from economists, regulators, and participants in highly regulated markets. This profile strives instead for the language of markets and traders.

This specification supports agreements and transactional obligations, while offering flexibility of implementation to support specific approaches and goals of the various participants.

2.1 Parties

The Common Transactive Services (CTS) defines interactions in a resource market. This Resource Market is a means to make collaborative decisions that allocate power or other resources over time. We follow [EI] and financial markets by calling market participants “Parties”.

A Party may represent a single actor, or the roles (see Facets, below) of a single Party may be distributed across multiple Actors. When the market recognizes tenders that match each other, however decided, the market generates a transaction that represents a contract (“Trade”) between the buyer and the seller. This transaction includes a party and a counterparty.

2.2 Trading semantics from FIX

The FIX Community divides messages into Pre-Trade, Trade, and Post-Trade Messages.

Pre-Trade messages convey information that traders need to discover how to use the market and to develop a strategy to buy and sell successfully. Pre-trade messages include advertisements and announcements (“Tickers”) of offers and contracts in the market, and negotiations between parties (“Quotes”). Other pre-Trade messages describe how the market itself works and what a Party can expect when interacting with the market.

Trade messages include submitting and cancelling orders (“Tenders”) to the market and executing contracts (“Transactions”) when orders to sell match (however defined) orders to buy.

Post-trade messages include settlement and position management.

For narrative purposes, this specification begins with the Trade facets, Tenders and Contracts. It then discusses the post-trade facets of Delivery and Position. This covers all the functions in some transactive resource markets. This specification then describes Negotiation, an optional pre-Trade facet. It next describes the pre-trade market data reports (“Tickers”) that inform an Actor about the activities of other participants. The pre-trade Market Instrument Report facet provides summary information about Tenders currently held in the market. Finally, the pre-trade Market Structure facet conveys how a Trader may interact with the market, which includes how to find each Facet and which messages this market supports.

An Actor interacting with the market would first discover the market structure, subscribe to Tickers relevant to its interest, and then use the facets and messages that are permitted in this market to Trade. A Party MAY not understand negotiation, or MAY skip subscribing to Tickers, but any party MUST be able to Trade.

2.2.1 Parties and Orders

In Energy Interop as in FIX, a trade is executed between two parties. While Energy Interoperation acknowledges only a Party and a Counterparty, FIX is more semantically rich.

What Energy Interoperation (and this specification) terms Tenders, FIX terms orders. An order that is on the book in the market is a Resting or Passive order. An order that enters the market to match a Resting order is the Initiating or Aggressive order. Passive orders increase market liquidity. Aggressive orders decrease market liquidity. Regulators of financial markets are often interested in liquidity and in the ratios of Aggressive to Passive orders.

When it makes the discussion clearer, this specification uses the terms Resting, Passive, Initiating, and Aggressive as they are used in financial markets.

2.2.2 Instruments

Financial Markets trade financial instruments. CTS borrows this language from FIX. See Section 3, Market Semantics: Resource, Product, Instrument, for a discussion.

2.2.3 Market Crossing

Market Crossing refers to either the opening or to the closing of a market or market segment. A traditional exchange opens in the morning and closes in the afternoon. Tenders are not matched prior to market opening or after the market close.

In many markets, parties wishing to trade pay close attention to prices and volumes in the period around closing. Many traders prefer not to trade close to a crossing because it is a period of high price volatility on a market. Many markets announce a “closing price” and an anticipated “opening price”, even as no transaction may have occurred at either of those prices.

Transactive resource markets may have regulatory time limits on trading. Some electricity markets have banned transactions more than a day prior to delivery. CTS traders must be able to understand the local rules and adjust their trading tactics without human intervention. A Market MAY accept Tenders prior to the opening of the Market Segment or Instrument. Transactive market researchers have used tenders submitted prior to opening to generate opening prices in black-start scenarios. Others have used trade residue, which is the tenders left in the market after closing to seed real-time prices for unplanned energy use.

Consider a utility that provides day-ahead hourly pricing from the local bulk power market to retail customers. The prices for tomorrow may be posted at 9:00 AM each day. These prices may be good until 3:00 PM each day. The market may begin accepting tenders an hour before opening. This describes a market segment with two crosses each day, opening at 9:00 AM and closing at 3:00 PM. After 3:00 PM orders may be processed as a normal forward market using an order book to process tenders into transactions.

As transactive resource markets are in essence markets in time of delivery, individual instruments can be considered to open and close as well. In a continuously open market segment, a rule might prevent trading more than 24 hours in advance. In that same market, an instrument for delivery of a resource between 10:00 AM and 11:00 AM can no longer be traded at noon.

2.2.4 Markets and Venues

A Market MAY be divided up into different venues wherein different products are traded, perhaps with different rules. Following the FIX Protocol, we term these Market Segments, and we use the FIX classification Venue Type to name the market activities of each Segment. A Market may have one or many Market Segments.

2.3 Common Transactive Services Roles

Actors interact through messages submitted to Facets. The specification makes no assertions about the behaviors, processes, or motives within each Actor. A particular Actor may use all Facets, a subset of Facets, or even a single Facet. This specification groups similar messages by Facet messages and interactions.

2.3.1 Parties as Market Participants

The Common Transactive Services (CTS) defines interactions in a Resource Market. This Resource Market is a means to make collaborative decisions that allocate power or other Resource over time. We follow [EI] and financial markets by calling market participants “Parties”.

A Party can take one of two Sides in Transaction:

· Buy, or

· Sell

A Party selling an Instrument takes the Sell Side of the Transaction. A Party buying an Instrument takes the Buy Side of the Transaction. The initiating Party is called the Party in a Transaction; the other Party is called the Counterparty.

From the perspective of the Market, there is no distinction between a Party selling additional power and Party selling from its previously acquired position. An Actor representing a generator would generally take the Sell side of a transaction. An Actor representing a consumer generally takes the Buy side of a transaction. However, a generator may take the Buy Side of a Transaction to reduce its own generation, in response either to changes in physical or market conditions or to reflect other commitments made by the actor. A consumer may choose to sell from its current position if its plans change, or if it receives an attractive price. A power storage system actor may choose to buy or sell from Interval to Interval, consistent with its operating and financial goals.

We do not specify how to manage delivery of the Resource.

2.3.2 Party and Counterparty and Transactions

The party in a tender is offering to buy or sell. The PartyID in a Tender should always reference the Party that is tendering.

When the Market recognizes tenders that match each other (however defined), the market generates a Transaction that represents an agreement between the buyer and the seller. This transaction includes a Party and a Counterparty.

2.3.3 Facets in the CTS Specification

This specification refers to a coherent set of interactions, that is, closely related requests and responses, as Facets. An Actor sends and receives defined messages through its Facet to interact with other Actors that expose a complementary Facet. An Actor in a CTS-based system of systems may expose all Facets, a single Facet, or any collection of Facets. A particular Market may use some or all named Facets. A participant in a Market must include Actors supporting each Facet required in that Market; there is no requirement that each Actor supports all these Facets.

Detailed descriptions of each facet begin in Section 4.

Table 2‑1: Facets Defined in CTS

Facet	Description
Registration	A Party must Register with a Market to participate in the Market Segments in that Market. See Section 4, “Party Registration Facet”.
Tender	Tenders are actionable offers to buy or to sell an Instrument at a given price. Tenders are sent to the Market Segment and are generally private. It is possible to request that a Tender be advertised to all Parties in the Market. See Section 5, “The Tender Facet”.
Transaction	A Transaction records the trade when a Tender to buy and a Tender to sell are matched. Each Party is notified of the creation of the Transaction. Note: a Tender for one side MAY match more than one Tender on the other side, and could generate multiple Transactions, potentially at different prices. See Section 6, “The Transaction Facet”.
Position	At any moment, a Party has a position which represents the cumulative amount of Instruments that the Party has previously transacted for within a bounding time interval across all Segments in the Market. A Position for an Instrument reflects the algebraic sum of all quantities previously bought or sold. See Section 7, “The Position Facet”.
Delivery	It is simplest to think of Delivery as a meter reading, although that meter may be virtual or computed. Some implementations may compare what was purchased or sold with what was delivered. What a system does after this comparison is out of scope. See Section 8, “The Delivery Facet”.
Negotiation	Negotiation covers messages that may lead to a Tender that will be accepted. Negotiation includes Requests for Quotes (RFQs), Indications of Interest (IOI), and Quotes. See Section 9, “The Negotiation Facet”.
Tickers	A Ticker is a continuous live view of market interactions-consider a ticker tape. A Ticker is one form of Market Subscriptions as defined by FIX. See Section 11, “Ticker ”
Market Instrument Summaries	A Market Instrument Summary is a compressed or summarized variant of Market Data as defined by FIX. See Section 12, “Instrument Market Data”.
Market Structure	The Market Facet exchanges information about the Market and its Products and Market Segments. An Actor may query the Market to discover the Resource and Products traded in a Market. While a Market trades a single Resource, it may consist of multiple Market Segments trading multiple Products. See Section 13, Market Structure Subscription

Each of these facets includes multiple messages which are described starting in Section 3.2 below. Sometimes the use of one facet precedes the use of another facet, as Tenders may initiate messages that result in messages for the Transaction Facet.

2.4 Responses

This section re-iterates terms and simplifies models from [EI]. That specification is normative. The form of the Response is common across all Facets.

Table 2‑2: Responses

Attribute	Meaning
Created Date Time	Timestamp for creation of this response
Market Attribute Violation	Market and Segment attributes violated in the referenced request. See Section 13 Market Structure Subscription and Table 13‑2 and Table 13‑3.
In Response To	A reference ID which identifies the artifact or message element to which this is a response. The Request ID uniquely identifies this request and can serve as a messaging correlation ID^{^[4]}.
Response Code	The Response Code indicates success or failure of the operation requested. The Response Description is unconstrained text, perhaps for use in a user interface. The code ranges are those used for HTTP response codes,^{^[5]} specifically: 1xx: Informational - Request received, continuing process. 2xx: Success - The action was successfully received, understood, and accepted 3xx: Pending - Further action must be taken in order to complete the request 4xx: Requester Error - The request contains bad syntax or cannot be fulfilled 5xx: Responder Error - The responder failed to fulfill an apparently valid request
Response Description	A string describing the response, e.g. “Duration doesn’t match Segment configured Duration”

Most messages elicit a response. Information-only messages, as in Tickers, do not.

A screenshot of a computer

Description automatically generated

Figure 2‑1 UML Class Diagram of EiResponseType and MarketAttributeViolationType

2.5 Identities

Table 2‑3 ID UML Class Diagram of ID Types in CTS

3 Market Semantics: Resource, Product, Instrument, and Streams

The messages of CTS use a few common elements. These elements derive from and are compatible with definitions in [WS-Calendar], [EMIX], and in [EI].

Every CTS-based market offers the exchange of a specific resource. Each CTS market segment is a venue for trading a single product, which is a resource packaged for sale. All tenders and transactions are for instruments, which are products scheduled for delivery at a specific time.

3.1 Resource, Product, & Instrument

We define a Resource as a commodity whose value depends on time of delivery. A Party subscribes (see Section 10) to a Market to discover the Resource that is traded in the market, and the Products available in different Market Segments. (See Section 13.2, “Market Definition”) A Party can then trade Instruments, a Product at a specific time, in a Market Segment. This specification leaves Market Definition until the end of the specification, as the meaning and import of the terms used to define each Segment are first described in the trading process.

Figure 3‑1 illustrates the relationship between Resource, Product and Instrument. A close-up of a product

Description automatically generated

Figure 3‑1 showing the relationship between Resource, Product, and Instrument

The Product incorporates the Resource, defining how the Resource is “packaged” for market. Adding a start date-time to a Product defines an Instrument.

A Market Segment trades Instruments, as a financial market trades financial instruments. CTS trades Instruments to deliver Product at a specific time.

The UML in Figure 3‑2 shows the relationship between Resource, Product, and Instrument.

A screenshot of a computer

Description automatically generated

Figure 3‑2 UML Class Diagram for Resource, Product, and Instrument

3.1.1 Defining Resource

We define a Resource as a commodity whose value depends on time of delivery. A developer may extend the Resource enumeration using standard UML techniques (subclassing); however, CTS 1.0 uses only the limited list in the Resource Designator Type (Figure 3‑2).

A Market typically includes some information that further specifies the Resource, for example voltage and frequency for Power.

Table 3‑1: Defining the Resource

Attribute	Type	FIX Field Name	Meaning	Notes
Resource Designator	String	Not in FIX	POWER ENERGY TRANSPORT WATER_PRESSURE WATER_FLOW GAS_PRESSURE GAS_FLOW BANDWIDTH	The Resource Designator serves a purpose similar to that of the FIX AssetSubClass (1939) The list is extensible
Resource Unit	String	Not in FIX	The unit of measure for the Resource	Item Unit in [EMIX]
Resource Attributes	String	Not in FIX	Optional elements that further describe the Resource	e.g. Hertz and Voltage

The Resource is named in the Market. Each Market deals in a single Resource. Segments of a Market restrict trading into profiles of the Resource. Position and Delivery (see Sections 7, 8 below) itemize Resource quantities.

3.1.2 Defining Product

The Product is a Resource packaged for Market. The size and duration of the Product define what is, in effect, the “package size” for the commodity. A Market may offer multiple Products for the same Resource in different Market Segments.

Note that the Product is derived from the[EMIX] ItemBase.

A screenshot of a computer

Description automatically generated

Figure 3‑3 UML Class Diagram for Product showing Inheritance from Resource

Table 3‑2, below, defines each of the fields in the Product.

Table 3‑2: Defining the Product

Attribute	Type	FIX Field Name	Meaning	Notes
Duration	String	Not in FIX	The interval Duration for the specific Product definition.	As defined in [WS-Calendar]
Quantity Scale	Int	Not in FIX	The exponent of the Quantity	For example, a Product denominated in kilowatts has a QuantityScale of 3.
Resource Designator	String	Not in FIX	Reference to the Resource as defined in this Market.	Used to support Tender validation and auditing
Resource Unit	String	Not in FIX	The unit of measure for the Resource	Item Unit in [EMIX]
Warrant Designator (Optional)	Int	Not in FIX	Optional further specificity of Product.	Warrants are itemized in the Market. This specification does not define Warrants.

Products with differing Warrants are different Products and therefore traded in different Market Segments.

As non-normative examples, if an Actor wishes to buy energy with a Green Warrant (however defined) then the Actor, not the Market, is responsible for defining its trading strategies if the warranted Product is not available. Similarly, an Actor that wishes to buy or sell Neighborhood Solar Power is responsible for submitting Tenders that expire in time to make alternate arrangements, or in time to cancel Tenders before fulfillment. This specification establishes no expectation that the Market engine will address these issues automatically.

Warrants are defined in [EMIX], and CTS permits Warrants to support this complexity if desired, but not described in this specification. A Market MAY define a list of Warrants and Warrant Designators. Warrants were defined in [EI].as additional non-essential characteristics of a Resource such as how it was produced, or an attribute of regulatory interest. Warrants are defined in the Market but are offered per Market Segment.

3.1.3 Defining Instrument

A Market Segment trades Instruments for a single Product. In CTS, an Instrument is a Product delivered for a specific duration beginning at a certain time. CTS includes Duration explicitly in both the Tender and the Quote. The Instrument follows the pattern defined in WS-Calendar—a Resource bound to a Duration (“Product”) and the Product bound to a Starting DateTime.

Table 3‑3: Specifying the Instrument

Attribute	Type	FIX Field Name	Meaning	Notes
The fields below as defined in the Product, Table 3‑2
Duration	String	Not in FIX	The interval Duration for the specific Product definition.	As defined in [WS-Calendar]
Quantity Scale	Int	Not in FIX	The exponent of the Quantity	For example, a Product denominated in kilowatts has a QuantityScale of 3.
Resource Designator	String	Not in FIX	Reference to the Resource as defined in this Market.	Used to support Tender validation and auditing
Resource Unit	String	Not in FIX	The unit of measure for the Resource	Item Unit in [EMIX]
Warrant Designator (Optional)	Int	Not in FIX	Optional further specificity of Product.	This specification does not define Warrants.
A start time completes the Product (above) into a tradable Instrument
Start Time	DateTime (UTC)	Not in FIX	Starting Date & Time	A start time completes the specification of Product into a tradable Instrument

Every Tender, Transaction, Quote is to buy or sell a quantity of an Instrument.

Within a market Segment, the Start Date and Time uniquely identifies an Instrument. Because an off-market Segment, sometimes known as over-the-counter (OTC) Segment can transact products of any Duration, Tenders, Quotes, and Transactions all use the Segment identifier, the Start Time, and the Duration to identify the Product.

3.1.4 Summary of Instrument Specification

A UML model for the Instrument showing all inheritance is in Figure 3‑4 below:

A screenshot of a computer

Description automatically generated

Figure 3‑4 UML Class Diagram for Instrument showing Inheritance from Resource & Product

3.2 CTS Streams: Expressing Time Series

Resource Markets are based on time-of-delivery. It is often useful to convey requests and information about consecutive durations. This specification uses the simplified pattern described in WS-Calendar [Streams], that is, common information followed by a repeating set of information for each consecutive Interval. Each Interval uses a common Duration. All Intervals in a Stream are consecutive.

Streams are a response to a request for a Stream. A Request for Quotes may specify Intervals for an entire day. A Request for a Position or for Delivery may also include several Intervals. In either case, the Request includes the common information (as in what is requested, a Duration, and a bounding interval, expressed as a Start DateTime, and an End DateTime).

A screenshot of a computer

Description automatically generated

Figure 3‑5: UML Class Model for CtsStream and the Stream Intervals

The response to a request for a stream is a stream.

The common information in CTS Streams is the Product and the Start DateTime. The Product specifies Resource and Duration. The consecutive intervals in the CtsStream begin with the Start DateTime for the specified Duration. The second Interval has an implied start of the end of the first Interval. The third Interval has an implied start of the end of the second Interval…and so on.

Each interval carries what can be considered a local UID.[6]

Several Facets request a CtsStream in the response. They are:

· Position Facet

· Delivery Facet

Certain payloads may include a CtsStream, including:

· Tender Facet (see “Interval Tenders and Stream Tenders”, Section 5.3.1)

· Quote and Negotiation Facet (see Stream Quote)

Figure 3‑6 shows payloads for the Position and Delivery Facets as an example of the pattern for requesting and responding with streams.

Table 3‑4: Specifying the Stream

Attribute	Type	FIX Field Name	Meaning	Notes
Stream Interval Duration	String	Not in FIX	The interval Duration for each Stream element.	As defined in [WS-Calendar] Optional if inherited from message containing Stream
Stream Start	DateTime	Not in FIX	Starting Date & Time for the first element in the series of Intervals.	After the first Interval, each Interval starts when the proceeding Interval finishes
Stream Interval Price Value	Long	Price (44)	Price per Unit during Interval	Optional depending upon purpose of message including Stream
Stream Interval Quantity Value	Long	OrderQty (38)	The Quantity of the Product during the Interval	Optional depending upon purpose of message including Stream
StreamUID	Int	Not in FIX	Unique identifier for each interval.	Certain serializations for do not guarantee order- the UID enables it to be reconstructed

The CTS pattern includes a Bounding Interval, and the response requests is all CtsStream Intervals that are contained within the Bounding Interval including those which align with the ends of the Bounding Interval.

Created with Enterprise Architect (Build: 1626) 2

Figure 3‑6: UML Examples of Payloads incorporating Streams

The information within each Interval varies per message type. For example, a StreamQuote or a StreamTender will put the Price and Quantity in each interval. A Delivery (metering) payload will put only the Quantity in each Interval.

4 Party Registration Facet

A valid Party ID is required to interact with a Market and is included in most payloads.

Party Registration is described in EI. This facet describes the messages necessary for an actor to register and obtain a Party ID to participate in a Market.

EiCreateParty associates an actor with a Party ID and informs the Market of that ID. CTS makes no representation on whether that ID is an immutable characteristic, such as a MAC address, a stable network address, such as an IP, or assigned during registration,

EiRegisterParty names the exchange of information about an actor that enables full participation in a CTS Market. It may exchange information needed for financial transfers including, perhaps, reference to an existing customer or vendor ID, or proof of financial bond for large participants, or issuance of crypto-tokens, or any other local market requirements. A Registered Party is ready to be a full participant in the local Market.

Cancel Party Registration removes a Party from the Market. It may include final settlement, cancellation of outstanding Tenders, backing out of future contracts, or other activities as defined in a particular CTS Market.

Aside from the business services as described, Party Registration may have additional low-level requirements tied to the protocol itself used in a particular implementation based on CTS.

This specification does not attempt to standardize these interactions and messages beyond naming the Register Party facet. A more complete discussion can be found in the [EI] specification.

Some Markets MAY wish to associate one or more measurement points with a Party. Such measurement points could be used to audit Transaction completion, to assess charges for using uncontracted-for-energy, etc. Measurement points are referenced in Section 8 “The Delivery Facet”, Markets that require this functionality may want to include an enumeration of Measurement Points in Party Registration.

An implementation is not required to use the Party Registration Facet. For example, if uniqueness and universality are satisfied, any assignment of Party IDs should work.

5 The Tender Facet (Trade Messages)

A party wishing to buy or sell submits an order (“Tender”) to the Tender Facet. The Service descriptions and payloads are simplified and updated from those defined in EI. The FIX Protocol classifies Tenders as one of the Trade messages.

5.1 Messages for the Tender Facet

Trade messages are exchanged between parties to find or create a Transaction. The Tender Facet payloads are shown in Table 5‑1.

Tenders and transactions are artifacts based on [EMIX] artifacts, suitably flattened and simplified, and which contain schedules and prices in varying degrees of specificity or concreteness.

Table 5‑1: Tender Facet Payloads

Facet	CTS Initial Message	CTS Response Message	Meaning
EiTender	EiCreateTender	EiCreatedTender	Create sends a message containing one or more Tenders. Created returns errors, and when successful returns the Market-assigned ID for the submitted Tender
EiTender	EiCancelTender	EiCanceledTender	Cancel one or more Tenders

In the FIX specification, a Tender is “completed” when it is satisfied, when it is cancelled, or when it is replaced. CTS does not permit replacing tenders, instead requiring that a Party cancel a tender and submit a new one. If a Tender is already partially filled, cancellation cancels only the unfilled portion.[7]

5.1.1 Illustrative Narrative on Tenders [Non-Normative]

For example, Party A submits a Tender 1 to buy 100 kWh over an hour. A Tender from Party B for 45 kWh matches Party A’s Tender and the Market creates a Transaction (see Section 6, “The Transaction Facet” for a discussion of Transactions). A Tender from Party C for 35 kWh matches Party A’s Tender and the Market creates a Transaction. Party A’s Tender 1 remains on the market with 20 kWh remaining. If Party A wishes to increase the price offered to get the 20 kWh for a critical operation, Party A must cancel Tender 1, with 20 kWh remaining, and submit a Tender 2 offering a new price. Cancelling Tender 1 does not invalidate either of the two completed Transactions.

5.2 Interaction Patterns for the Tender Facet

Figure 5‑1 presents the UML sequence diagram for the EiTender Facet. Note that while [EI] defines a message EIDistributeTender, CTS uses the Negotiation Facet (Section 9, “The Negotiation Facet”) and Ticker Subscriptions (Section 11, “Ticker ”) to accomplish similar purposes.

A diagram of a process

Description automatically generated

Figure 5‑1: UML Sequence Diagram for the Tender Facet

5.3 Information Model for the Tender Facet

The information model for the Tender Facet artifacts follows that of [EMIX] but flattened and with Product definition implied by the implementation. See Section 5.5 Message Payloads for the Tender Facet below.

The EiTender and EiQuote classes share most attributes in common. Accordingly, a superclass TenderBase holds those common attributes as shown in Figure 5‑2. TenderBase is an abstract class, so no object can be of that class.

A screenshot of a computer

Description automatically generated

Figure 5‑2 UML Class Diagram showing common attributes between EiTenderType and EiQuoteType

Attributes used in Tenders, are shown in Table 5‑2

Table 5‑2 Tender Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
All or None	Boolean	In Execution Instructions	All or none of the tendered or quoted amount must be traded.	In Energy Interoperation 1.0 this was called IntegralOnly
Execution Instructions	String	ExecInst (18)	FIX Supports many instructions for how to execute a tender (or Tradable Quote)	See Table 5‑4 below. Modeled as a String in CTS.
Expiration Time	Instant Type	ExpireTime (126)	The Tender or Quote expires at the specific time.	Always expressed in UTC
Interval	Start Time and Duration	Not in FIX	Start Date and Time for Product delivery together with Duration of delivery. Part of Instrument	While a Market Segment only accepts Tenders and Quotes of a single configured duration, the complete description is required to ensure validity and for off-market interactions.
Market ID	UID	MarketID (1301)	Identifies the Market
Market Segment ID	UID	MarketSegmentID (1300)	Identifies the Segment processing the Tender, Transaction, or Quote	This should be a unique combination paired with the Market Order ID
Order ID	UID	CIOrdID (11)	ID assigned by originating Party
Market Order ID	UID	ORDERID (37)	ID assigned by the Segment or Market.	Used in acknowledgment and in all future market messages
Price	Long	Price (44)	The unit price for the Product being Tendered	Amount is the product of Price and Quantity. Note that Price is subject to the Price Decimal Fraction value.
Price Scale	Int	Not Defined in FIX	A multiplier for the Price	A Market Segment may be denominated in, for example dollars or 10ths of a cent.
Quantity	Long	OrderQty (38)	The quantity of the Product being Tendered	Must meet the SCALE and Round Lot requirements of the Segment
Quantity Scale	Int		A scale factor on the Resource unit for this Market	For example, “mega” vs “kilo” vs “femto-”
Referenced Quote ID	UID	QuoteMsgID (1166)	Tradable Quote reference in Tender	Reference to Market Quote ID assigned by Market. See Negotiation Facet (Section 9) for use.
Resource Designator	Resource Designator	Not defined in FIX	Identifier of the Resource being offered (Optional in many markets)	While a Market only accepts Tenders and Quotes for a single Resource, the complete description is required to ensure validity and for off-market interactions.
Tender Detail	Tender Detail	Not defined in FIX	Unit price and quantity for this tender	May be Interval or Stream as permitted
Tender ID	UID		ID as submitted to Market	Identifies Tender until Market Order ID is assigned by Market
Tender Interval	Tender Interval Detail	Not defined in FIX	Interval, price and quantity for this tender	Used in Interval Tender
Tender Stream	Tender Stream Detail	Not defined in FIX	Stream of consecutive Intervals with Prices and Quantities	Sometime referred to as a Load Curve in Power Markets.
Side	Side Type	Side (54)	Whether the Tender is to buy or to sell the Product	Buy or Sell
Warrant Ref	Int	Not in Fix	Reference to Warrants as defined in the Market	If used, see comments Warrants in Tenders, Section 5.3.3.

The following diagram shows EiTenderType showing inherited and included attributes.

A screenshot of a computer

Description automatically generated

Figure 5‑3: UML Class Diagram for EiTenderType showing attributes inherited from Tender Base

Of the attributes in Table 5‑3 Tender ID and Referenced Quote ID (Referenced Quote Id) are unique to EiTender Type; the others are inherited from Tender Base and shared with EiQuote Type. See Section 9, “The Negotiation Facet”, for a discussion of Quotes.

Table 5‑3: EiTender Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Tender ID	UID		An ID for this Tender generated by the submitting Party
Referenced Quote ID	UID	QuoteMsgID (1166)	ID of the Tradable Quote to which this is a response.	Optional. If Quote ID is not known to the Market Segment, or if the referenced Quote has expired, then the Tender is rejected.
The fields below are as defined in the Tender, Table 5‑2
All or None	Boolean	In Execution Instructions	All or none of the tendered or quoted amount must be traded.	In Energy Interoperation 1.0 this was called IntegralOnly
Execution Instructions	String	ExecInst (18)	FIX Supports many instructions for how to execute a tender (or Tradable Quote)	See Table 5‑4 below. Modeled as a String in CTS.
Expiration Time	Instant Type	ExpireTime (126)	The Tender or Quote expires at the specific time.	Always expressed in UTC
Interval	Start Time and Duration	Not in FIX	Start Date and Time for Product delivery together with Duration of delivery. Part of Instrument	While a Market Segment only accepts Tenders and Quotes of a single configured duration, the complete description is required to ensure validity and for off-market interactions.
Market ID	UID	MarketID (1301)	Identifies the Market
Market Segment ID	Int	MarketSegmentID (1300)	Identifies the Segment processing the Tender, Transaction, or Quote	This should be a unique combination paired with the Market Order ID
Order ID	UID	CIOrdID (11)	ID assigned by originating Party
Market Order ID	UID	ORDERID (37)	ID assigned by the Segment or Market.	Used in acknowledgment and in all future market messages
Price	Long	Price (44)	The unit price for the Product being Tendered	Amount is the product of Price and Quantity. Note that Price is subject to the Price Decimal Fraction value.
Price Scale	Int	Not Defined in FIX	A multiplier for the Price	A Market Segment may be denominated in, for example dollars or 10ths of a cent.
Quantity	Long	OrderQty (38)	The quantity of the Product being Tendered	Must meet the SCALE and Round Lot requirements of the Segment
Quantity Scale	Int		A scale factor on the Resource unit for this Market	For example, “mega” vs “kilo” vs “femto-”
Resource Designator	Text	Not defined in FIX	Identifier of the Resource being offered (Optional in many markets)	While a Market only accepts Tenders and Quotes for a single Resource, the complete description is required to ensure validity and for off-market interactions.
Tender Detail	Tender Detail	Not defined in FIX	Unit price and quantity for this tender	May be Interval or Stream as permitted
Tender ID	UID		ID as submitted to Market	Identifies Tender until Market Order ID is assigned by Market
Tender Interval	Tender Interval Detail	Not defined in FIX	Interval, price and quantity for this tender	Used in Interval Tender
Tender Stream	Tender Stream Detail	Not defined in FIX	Stream of consecutive Intervals with Prices and Quantities	Sometime referred to as a Load Curve in Power Markets.
Side	Side Type	Side (54)	Whether the Tender is to buy or to sell the Product	Buy or Sell
Warrant Ref	Int	Not in Fix	Reference to Warrants as defined in the Market	If used, see comments Warrants in Tenders, Section 5.3.3.

5.3.1 Interval Tenders and Stream Tenders

The most common Tender is the simple or Interval Tender, that is, an offer for a Product beginning at a specific date and time.

In financial markets, a multi-leg order submits simultaneous offers to buy or sell as a single order all of which must be accepted or rejected together. This specification describes a specialized type of multi-leg order for use in in some Market Segments which we term a Stream Tender. A Stream Tender defines a consecutive series of Intervals of identical Duration. The price and quantity tendered must be specified for each Interval.

For example, an industrial customer in a power market may intend to buy power to support a long running process. In power markets, such a sequence of power use is sometimes referred to as a load curve.

Such multi-leg orders are expressed using a CtsStream(see 3.2, “CTS Streams: Expressing Time Series”). While the information contained in a Stream Tender can be mapped precisely to a group of Interval Tenders, multi-leg semantics and processing of the related tenders leads to a Stream Tender. For example, All-or-None would refer to the entire set of Intervals in the Stream Tender.

Not all Market Segments permit Stream Tenders; some may require them. A Party submits a Stream Tender, when permitted or required, just as a Party submits an Interval Tender. A Market responds to the submission of a Stream Tender, when permitted or required, just as it responds to an Interval Tender.

The submission of a Stream Tender is restricted to Market Segments that specifically permit or require them and forbidden in all other Segments. See Section 13, “Market Structure Subscription”.

Market Segments that support Stream Tenders SHALL also support Stream Quotes (if they support Quotes) and Stream Transactions. See Section 9, “The Negotiation Facet”, for a discussion of Quotes.

5.3.2 Execution Instructions

FIX supports many Execution Instructions, only a profile of which are addressed in this specification.

Additional Instructions as defined by FIX are conforming but may not be implemented in all Venues. Since more than one may be present (albeit with semantic constraints) these are modeled as a string using single letters for each FIX Execution Instruction Code.

For example, the string HKA indicates the following:

· Cross is forbidden.

· Reinstate on system failure.

· Cancel on trading halt.

Table 5‑4 presents a subset of the FIX Execution Instructions permitted for use in CTS.

Table 5‑4: Trading Instructions

Instruction	FIX Code	Abbreviation	Notes
No cross	A	[NoCross]	Cross is Forbidden
OK to cross	B	[OKToCross]	Cross is Permitted. In Segments that have Successors, this MAY permit conversion.
All or none – AON	G	[AllOrNone]	Ignored in deference to the AllOrNone attribute.
Reinstate on system failure	H	[ReinstateOnSystemFailure]	Mutually exclusive with Q and l (lower case L).
Reinstate on trading halt	J	[ReinstateOnTradingHalt]	Mutually exclusive with K and m.
Cancel on trading halt	K	[CancelOnTradingHalt]	Mutually exclusive with J and m.
Cancel on system failure	Q	[CancelOnSystemFailure]	Mutually exclusive with H and l (lower case L).
Cancel if not best	Z	[CancelIfNotBest]	Cancel if order is not immediately matchable
Ignore price validity checks	c	[IgnorePriceValidityChecks]
Suspend on system failure	l	[SuspendOnSystemFailure]	Mutually exclusive with H and Q.
Suspend on trading halt	m	[SuspendOnTradingHalt]	Mutually exclusive with J and K.

5.3.3 Use of Warrants in Tenders

Warrants increase the specificity of Product (and Instrument). A Buyer who does not specify a Warrant will be satisfied Delivery of a Product whether or not it has a Warrant. A Buyer who requests Product with a Warrant will only be satisfied by Delivery of a Product that has that Warrant.

Consider a buyer who wishes to buy a package of coffee beans and a buyer who wishes to buy a package of organic coffee beans. The word “Organic” on the label serves as a Warrant. The first buyer will buy solely on price, and is indifferent to seeing the word “Organic” on the label. The second buyer will choose only from among those packages with the warrant “Organic” on the label.

When a Tender on the Buy side specifies a Warrant, it must be rejected by any Market Segment that does not include that Warrant. A Tender on the Sell side that specifies a Warrant may be accepted by any Segment where the same Resource and Duration are traded. Conversely, a Tender on the Sell side without a Warrant must be rejected by any Segment that specifies a Warrant.

5.4 Contingent Tenders

Contingent Tenders are multiple Tenders submitted in a single message. The FIX List Order bundles multiple Tenders (Orders) with a common instruction (Contingency Type, 1385) that influences how fulfilling each Tender affects the other Tenders. A Market Segment either forbids or requires the use of Contingent Tenders. Tender Contingency Types are defined in the FIX Order List Contingency codeset (FIX 1385)

5.4.1 Illustrative Narrative on Contingent Tenders [Non-Normative]

The Contingency Type describes how the other Tenders in the List are affected by the acceptance of any one Tender in the Market. A common usage for Contingent Tenders is to submit a List of Tenders or StreamTenders (Load Curves), to support a long-running industrial process. The submitter wishes a contract for only one of the Tenders. In CTS Version 1, the only in Contingency is OCO or “One Cancels the Other” and it is expressed as a Boolean atMostOne in EiCreateTenderPayload and EiCreateStreamTenderPayload.

A Party submitting a List with the atMostOne = True is willing to accept whatever schedule matches the Transaction that returns from the Market.

A Party MAY wish to probe the market to make a more nuanced decision. This may include choosing one of several options. A decision to schedule a long-running process may depend upon being able to acquire a specific load curve over the entire schedule. A party that requires such complex contingent behavior should use the Negotiation Facet (section 9) to obtain Tradable Quotes, and then make its own choices based on those Quotes.

5.4.2 Rejecting a Tender

A Market may reject a Tender that violates market rules or which if transacted would violate the market’s integrity and other constraints (e.g. liquidity goals). Rejection Reasons include but are not limited to:

- Tender exceeds price limits on the potential transaction.

- Tender exceeds total value limits on the potential transaction.

- Tender violates total quantity limits for this Market Segment.

- Party is not in good standing with the Market.

- Tender violates lot size requirements of the Market Segment.

- Tender violates starting time requirements for instruments in the Market Segment.

- Market Segment is not open.

- Instrument is prior to temporal trading limits for this Market Segment.

- Instrument is past to temporal trading limits for this Market Segment.

- Tender is incomplete or corrupt.

- Referenced Quote not found.

- Referenced Quote has expired.

Details for rejection MAY be included in the EiResponse included in the EiCreatedTenderPayload.

5.5 Message Payloads for the Tender Facet

Figure 5‑4 is a [UML] class diagram for the payloads for the Tender Facet operations. Note that each operation supports a Tender Set, and any set may consist of any number of Tenders, Interval or Stream.

A screenshot of a computer program

Description automatically generated

Figure 5‑4 UML Class Diagram for Tender Facet Payloads

The Market Order ID is assigned by the Market on receipt of a Tender. The Market makes no assumption that the Tender ID (Order ID) submitted as part of the Tender is unique across all Parties in the Market. The Market responds with a Market Order ID for each Tender ID submitted. The submitting Party should record this Market Order ID, as it will be used in any Transactions awarded by the Market, and is required to cancel any Tender.

Specific Market Segments may limit all Tender submissions to either Interval Tenders or to Stream Tenders or may accept both. Specific Market Segments may restrict each Tender Set to all Interval Tenders or all Stream Tenders. Specific Market Segments may limit the cardinality of a Tender Set to any count. In the absence of such Segment specification, to support minimal interoperability, Interval Tenders are permitted, Stream Tenders, and the cardinality of each Tender Set is limited to one.

See Section 13.3 “Segment Definition” for details.

The following tables describe the attributes for the Tender Facet Payloads.

Table 5‑5 EiCreateTenderPayload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
At Most One	Boolean	See ExecInst (18)	Used to express alternatives, only one of which is to be effective	See Trading Instructions in Table 5‑4. First match cancels other Tenders.
Counter Party ID	Actor ID		The Actor ID for the Counterparty for which the Tender is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counterparty is used.
Execution Instructions	String	ExecInst (18)	Execution Instruction.	Used only for multi-leg, and appliesto for all tenders in multi-leg. Execution instructions apply to each Tender in the List.
Market ID	UID	MarketID (1301)	Identifies the Market
Market Segment ID	Int	MarketSegmentID (1300)	Identifies the Segment processing the Tender, Transaction, or Quote	This should be a unique combination paired with the Market Order ID
Party ID	Actor ID		The Actor ID for the Party on whose behalf this Tender is made.	Indicates which Actor proposes the buy or sell side EiCreateTender.
Tender	Ei Tender Type	OrderID (37)	Tenders requested to be created	One or more Tenders per Table 5‑3: EiTender Attributes.
Request ID	Ref ID		An identifier for this Create Tender Payload

Table 5‑6 EICreatedTenderPayload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID		The Actor ID for the CounterParty for which the Tender is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counterparty is used.
In Response To	Ref ID		An identifier for Create Tender Payload to which this is a response
Response	EiResponse Type		Specific error responses	See Section 2.4
The fields below are as defined in the Tender, Table 5‑2
Market Order ID	UID	ORDERID (37)	ID assigned by the Segment or Market.	Used in acknowledgment and in all future market messages
Party ID	Actor ID		The Actor ID for the Party on whose behalf this Tender is made.	Indicates which Actor proposes the buy or sell side EiCreateTender.
Market Order ID	Market Order ID Type	OrderID (37)	The market-assigned identifier for the order in the Create Tender Payload to which this is a response
Tender ID	Tender ID Type		Identifies the tenders in the Create Tender Payload to which this is a response

Table 5‑7 EiCancelTender Payload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID		The Actor ID for the CounterParty for which the Tender is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counterparty is used.
Party ID	Actor ID		Actor ID for the Party that created the Tender
Request ID	Ref ID		An identifier for this Cancel Tender Payload
The fields below are as defined in the Tender, Table 5‑2
Market Order ID	UID	ORDERID (37)	ID assigned by the Segment or Market.	Used in acknowledgment and in all future market messages

Table 5‑8 EiCanceledTenderPayload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID		The Actor ID for the CounterParty for which the Tender is created.	In CTS, generally the PartyID for the Market
Party ID	Actor ID		The Actor ID for the Party on whose behalf this Tender was made.	Indicates which Actor proposes the buy or sell side EiCreateTender.
In Response To	Ref ID		An identifier for the Cancel Tender Payload to which this is a response
Ei Canceled Response	Canceled Response Type		Detailed response for each tender that was included in the EiCancelTender Payload
EiResponse	EiResponse Type		Specific error responses	See Section 2.4

6 The Transaction Facet

This section presents the Transaction Facet, used by the Market to notify of the creation of Transactions. FIX terms the matching of a Buyer and a Seller as a “Trade”. CTS follows EI (and the term transactive energy) in naming it a Transaction.

In the general case, the Market notifies each Party of the creation of a Transaction when two Tenders match as discovered by the Market’s internal execution engine. To protect participant privacy, the market MAY use the MarketID as the counterparty to each Party receiving the Notification.

Unlike in financial markets, the market operator must still enforce limits imposed by physical infrastructure limits. For example, a substation or distribution cable will have physical limits for Power transferred during a given Interval. The reasons and mechanisms for such an enforcement are out of scope for CTS.

See Section 9, “The Negotiation Facet” for a discussion of Transactions based upon a Tradable Quote.

All Transactions are committed, that is, they cannot be cancelled or modified under normal market operations. Transactions in aggregate make up the Position. (See Section 7, The Position Facet for a discussion of Position.) A Party may thereafter choose to sell any portion or all of its Position in any instrument.

6.1 Messages for the Transaction Facet

A Transaction is created by a Market or Segment (See Section 13) based on some mechanism internal to the Market.[8] When a Market recognizes a potential Transaction, it creates a Transaction ID, and notifies the participating Parties.

Table 6‑1: Transaction Management Service

Facet	CTS Initial Message	CTS Response Message	Meaning
EiTransaction	EiCreateTransaction	EiCreatedTransaction	Create and acknowledge creation of a Transaction; typically initiated by the Market Segment engine
EiTransaction	EiCreateStreamTransaction	EiCreatedStreamTransaction	Create and acknowledge creation of a Stream Transaction; typically initiated by the Market Segment engine

6.2 Interaction Pattern for the Transaction Facet

In Off-Market venues (see Section 13.1.1,”Venue Types”), the Parties match Tenders themselves, and inform the Market of their agreement. Even in Off-Market venues, the market operator must still enforce limits that affect physical integrity.

Figure 6‑1 shows the UML sequence diagram or the EiTransaction Facet:

Figure 6‑1: UML Sequence Diagram for the EiTransaction Facet

Most Transactions are mediated by a market. The Market matches Tenders, creates a Transaction, and notifies the submitting Parties.

In Off-Market venues (see Table 13‑1, “Venue Types in CTS”), the Parties match Quote and Tender, and inform the Market. Even in Off-Market venues, the market operator must still enforce physical or other limitations.

6.3 Information Model for the Transaction Facet

The EiTransaction object includes the information in the original EiTender, possibly updated to reflect the actual price and quantity rather than the requested price and quantity.

A screenshot of a computer program

Description automatically generated

Figure 6‑2: UML Class Diagram of EiTransactionType

The attributes of EiTransactionType are shown in Table 6‑2.

Table 6‑2: EiTransaction Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Market Transaction ID	Market Transaction ID Type	TradeID (1003)	ID Assigned this Transaction (Trade) by the Market (Segment)	Note that Energy Interoperation defines Transaction ID differently than does FIX. This is assigned by the actor that performed the match, typically a market segment.
All other fields are as defined in the Tender, Table 5‑2

6.4 Payloads for the Transaction Facet

The [UML] class diagram in Figure 6‑3 describes the payloads for the EiTransaction facet operations.

A screenshot of a computer

Description automatically generated

Figure 6‑3: UML Class Diagram of EiTransaction Facet Payloads

The following tables list the attributes of the Transaction Facet Payloads.

Transactions are produced by a market or actor that performs matches; the resulting Transaction information is sent to the Parties whose Tender(s) are matched. Note that there is not a one-to-one relationship of Tender to Tender, or Tender to Contract. A Tender to buy one- hundred might match multiple Tenders to sell ten; this results in one Tender resulting in multiple Transactions. Each Transaction is created by an interaction between a Tender to buy and a Tender to Sell. The Transaction payloads “echo” to each Tender to the Party that submitted it to become part of the Transaction.

The Tender included as part of a Transaction payload indicates a buy side or a sell side. When the Transaction indicates “buy”, then the PartyID is that of the Buyer. When the Transaction indicates “sell”, then the PartyID is that of the Seller. The CounterpartyID is the other participant in the Transaction.

As in financial markets often designate a “clearing” or “central” counterparty. Privacy concerns, particularly for transactions involving homes, are one reason for using the PartyID of the central counterparty. Under some rules, certain Parties must be revealed. For example, the PartyID of a dominant participant such as a distribution serving operator MAY be deemed public information; transactions involving such a designated participant would use the participant’s PartyID in the payload.

When use of a PartyID clearing counterparty is required, CTS uses the PartyID of the Market.

Table 6‑3 EiCreateTransactionPayload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID	PartyID (448)	PartyID of the Party on the other “side” from the Tender in the payload.	May be the PartyID of the clearing counterparty.
Market Order ID	UID	ORDERID (37)	ID assigned by the Market when processing Tender
Party ID	Actor ID	PartyID (448)	Party ID of the Party on the same “side” of the Tender in the Payload.	Side of the included transaction determines the Party.
Trade ID	String	TrdId (1003)	ID assigned to the trade entity once it is received or matched	Assigned by the Market
Reference ID	String	ExecId (17)	An identifier for this message
Tender	TenderBase		Price and Quantity for Interval[s] in Transaction

Table 6‑4 EiCreatedTransactionPayload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID	PartyID (448)	PartyID of the Party on the other “side” from the Tender in the payload.	May be the PartyID of the clearing counterparty.
Party ID	Actor ID	PartyID (448)	Party ID of the Party on the same “side” of the Tender in the Payload.	Side of the included transaction determines the Party.
Trade ID	String	TrdId (1003)	Identifier for the Market’s ID for the received Transaction
Recipient Transaction ID	Recipient Transaction ID Type	XID	The ID assigned to the received Transaction by the recipient of the associated EiCreateTransaction
Reference ID	String	ExecId (17)	The Ref ID for the message payload indicating the cleared Transaction
Response	EiResponse Type		Specific error responses	See Section 2.4

6.5 Comparison of Transactive Payloads

In this section we show the payloads for the Tender and Transactive Facets

A screenshot of a computer program

Description automatically generated

Figure 6‑4: UML Diagram comparing Tender and Transaction Facet Payloads

6.6 Off-Market Transactions

While most transactions originate as Tenders submitted to the Market, are then matched by the Market, and result in a Transaction created by the Market, there are use cases for bilateral actions that generate a Transaction that did not come through the market.

For example, two parties within a market may choose to transact directly. A party may opt to buy directly from his neighbor’s solar power. Another market may permit charity, that is, a donation to the Position of a neighbor. In either case, the Transaction is sent to the Market so that each Party’s Position is maintained and so that the Buyer does not get double billed. These transactions may also be referred to as over-the-counter (OTC) agreements.

Off-Market agreements require both parties to report to the Market. The originating Party sends a Tradable Quote to the Market, including the ID of the counterparty. The simplest means is for one Party to publish a targeted Quote (see Section 9, “The Negotiation Facet”, below) naming the CounterParty in the Quote. The Counterparty then submits a Tender referencing that QuoteID and the terms on the Quote.

Some Markets will have specific Market Segments for Off-Market Transactions with specific message patterns. An OTC Market is notable for permitting violations of the Lot Size constraint and of the start time and duration constraints of other market segments. For example, in a Market with a Market Segment with a product of Lot Size 20 kWh and a Duration of one hour, an Off-Market execution could register a transaction of 23 kWh delivered over 27 minutes beginning at 2:48.

See Sections 13.2, “Market Definition” and 13.3 “Segment Definition”.

7 The Position Facet

The Position Facet provides the sum of a Resource transacted for by a Party, positive and negative, for each interval and for each Segment, within a possibly larger bounding Interval. For example, a Position sum all transactions over the course of a day. It is typically requested by an auditor or settlement agent (See Section 8 The Delivery Facet) or by a Party to get information about its own position.

For example, a Party may buy and sell from several Market Segments, perhaps with different Durations. A Party may also transact with specific counterparties in an Over-The-Counter (OTC) market. All of these are part of the Party’s position. In most Resource markets, a Party may also take delivery (see Section 8, The Delivery Facet) which is measured by a meter. But what is the Quantity for this “self-executed” Transaction? This amount can be calculated by the difference between Position and Delivery and thereby creates Transactions for the used-but-never-bought Resource.

There may be other reasons to track Position. A market rule may require a Party designated as a Market Maker to maintain a Position of a certain quantity. A Party representing a Storage System may have specific rules for Position before a weather event. This specification does not catalog all the uses for Position that a Market or Party may require.

7.1 Introduction

The purpose of the Position Facet is to allow access to the accumulated position for actors supporting specific Roles. A Party’s Position for a time period is the algebraic sum of committed supply or sales for instruments overlapping that time period. A Party’s position for an Instrument is evolved from an accumulation of trades for that Instrument.

An Actor may, with appropriate authorization, request positions for other parties. This permits the specification and implementation of an auditor Actor. Roles using the Position Facet include:

· The Actor whose position is being requested—the position Party.

· An Actor who is authorized to request position information for other actors—including but not limited to an auditor—the requestor.

Position Interactions follow the Streams pattern. A request for position includes a bounding interval The response reports, at least, the Position for each Interval included within the bounded Interval of the Request.

Table 7‑1: Position Facet

Facet	Request Payload	Response Payload	Notes
Position	EiRequestPosition	EiReplyPosition	Request an Actor’s Position(s) for a specific time interval, and reply with those Position(s) if access is authorized.

This is the UML sequence diagram for the Position Facet:

Created with Enterprise Architect (Build: 1555) 2

Figure 7‑1: UML Sequence Diagram for the Position Facet

7.2 Information Model for the Position Facet

For Position, a bounding interval is specified and the position in each interval contained in the closed bounding interval is returned. A Request for Position specifies either a Product or a Resource.

When the Position Request is for a Resource, then the Position is assembled from all Transactions for that Resource. For example, a Transaction for Green Power, however defined, may only exist between 1:00 PM and 4:00 PM. The Position for Power for the rest of the day may be assembled from several sources, perhaps with different Warrants.

A Position is concerned with the total amount under contract, not the prices. If an Actor has positions in more than one Product, say, in a one-hour Product and in a one-minute Product, then the returned Position SHALL use the shorter Duration.

The attributes are shown in the following section.

7.3 Payloads for the Position Facet

The Position payload is in the format of a CTS Stream, with only a Quantity in the Interval Payload. Position stated against the sum of Transactions in all Segments.

The [UML] class diagram describes the payloads for the Position facet.

Figure 7‑2: UML Class Diagram of Payloads for the Position Facet

Table 7‑2: Attributes of Position Facet Payloads

Attribute	Meaning	Notes
Bounding Interval	The [closed] time interval for which position information is requested. The first Positions Stream element starts at or after the start of the Bounding Interval. The last Stream element ends at or before the start of the Bounding Interval.
Position Party	The Party whose position is being requested.	Allows a request for another Party’s position, with appropriate privacy and security constraints
Resource Designator	The Resource for which Position is being requested	Should match the identified Market’s Resource Designator
Market ID	Identifier of the market of interest	A Party MAY be able to participate in more than one Market See Section 13.
Request ID	A reference to this payload	May be used as a correlation ID
Requestor	The Party requesting the position.	A failure indication will be returned if the Requestor is not authorized to access position information for Position Party.
Positions	CTS Streams containing the positions for Position Party for each Resource. Positions are signed and may be zero.	Each CtsStream interval that is contained within the Bounding Interval will have a value associated (signed integer). Note that a CtsStream contains a Resource Designator
Response	An EiResponse will indicate failure if Requestor is not authorized to access position information for Position Party for any of the requested intervals.

The following system-specific requirements are out of scope:

· Different systems may support Position requests for different purposes. An Actor MAY request its own position(s) to recover from failure.

· A supplier of last resort MAY compare Positions to Delivery to impute transactions for unpurchased power delivered. (See 8 The Delivery Facet)

8 The Delivery Facet

The CTS Delivery Facet can be considered as the meter telemetry facet. We name it “Delivery” to align with the market focus of this specification, that is, a building takes delivery of power, or a distributed energy Resource (DER) delivers power. A CTS Delivery payload contains a CtsStream that conveys the measured or computed flow of a specific Resource through a particular point on the Resource’s delivery network during a specific Interval.

CTS Delivery is typically derived from reading one or more meters, but it may be computed, implied or derived from some other method. Every Transaction is between a Party that promises to buy and a Party that promises to sell. Consider an actor that performs temporal arbitrage, i.e., buys one-hour Products and sells one-minute Products during the same hour. The Actor MAY report that it took delivery in each minute of that Interval, and the sales to other Actors MAY be visible only as reductions as recorded in Delivery.

In most cases, a node that takes delivery of more power or other Resource during an Interval than contracted for must eventually pay for that delivery. For example, An auditor (however defined) could sum all positions (See section 7, The Position Facet) and compare the result to total Delivery. The Auditor can then impute a transaction for the over-delivery. This may not be a simple “spot price”; if multiple Actors are taking over-delivery, then the last transaction is likely underpriced. Systems that track “actor reputation” may lower the reputation score. These examples explain the potential use of the information delivered by this facet and are not meant to suggest or dictate any particular business process or system model.

A CTS Delivery payload reports on the flow of a Resource and the duration of that report stream may not match the temporal granularity of any particular Product. The payload may (e.g.) include the sum of a one-hour market and of a one-minute market for the same Resource.

A CTS Market MAY have assess penalties for Delivery outside certain bounds from the Position—as do many of today’s tariffed markets. Such bounds and penalties are out of scope for CTS. Computation and notification of Penalties is outside of scope.

A request for delivery specifies a Resource, unit of measure, and a temporal granularity [Duration]. While the unit of measure and temporal granularity need to be within the capabilities of the telemetry node, they need not match any particular Product.

8.1 Interaction Pattern for the Delivery Facet

Table 8‑1: Delivery Facet

Facet	Request Payload	Response Payload	Notes
Delivery	EiRequestDelivery	EiReplyDelivery	Request Delivery through a specific Measurement Point

Figure 8‑1 is the UML sequence diagram for the Delivery Facet.

Created with Enterprise Architect (Build: 1526) 2

Figure 8‑1: UML Sequence Diagram for the Delivery Facet

8.2 Information Model for the Delivery Facet

A Delivery response returns a single CtsStream of intervals of the requested Duration, with a quantity in each.

As with the Position Facet a bounding interval is specified and the delivery in each interval contained in the closed bounding interval is returned. The temporal granularity as requested MAY not be available, or the Delivery Actor may convert and combine—for example a request for one hour delivery intervals could be responded to using information from 1 minute or 5-minute measurement cycles.

The attributes are shown in the following section.

8.3 Payloads for the Delivery Facet

The [UML] class diagram describes the payloads for the Delivery facet.

A screenshot of a computer

Description automatically generated

Figure 8‑2: UML Class Diagram of Payloads for the Delivery Facet

Table 8‑2: Attributes of Delivery Facet Payloads

Attribute	Type	Meaning	Notes
Bounding Interval	Interval	The [closed] time interval for which position information is requested.	The first Positions Stream element starts at or after the start of the Bounding Interval. The last Stream element ends at or before the start of the Bounding Interval
Measurement Point	ID	An identification of the Point where measurements are made of the flow of the resource.	Information should be secured in conformance with appropriate privacy and security constraints
Request ID		A reference to this payload	May be used as a correlation ID
Requestor	PartyID	The Party requesting the position.	A failure indication will be returned if the Requestor is not authorized to access position information for Position Party. Addresses the auditor use case.
Delivered	CtsStream	A CtsStream containing the Quantity delivered in each Interval.
Response		An EiResponse. Will indicate failure if Requestor is not authorized to access position information for	If the Requested Delivery Granularity cannot be used, MAY indicate what granularity can be used.

9 The Negotiation Facet

Negotiations are part of what FIX terms Pre-Trade Information. So far, this specification has discussed interactions between a Party and a Market in which some internal process decides how a Transaction is created. This section describes instead how Parties come to an agreement to create a Transaction through direct communication. This conversation is conducted using various types of quotations. The Market facilitates the quote process but does not intervene—it acts as a neutral party.

Any Segment may support Negotiation as indicated in the Market Structure (see Section 13, “Market Structure Subscriptions”).

9.1 The Negotiation Process (non-normative)

The Negotiation process is inherently flexible. A Transaction may come after many rounds of negotiation, or directly from a response to the first tradable quote. This section describes some potential interactions to clarify the concepts before we define the message types in the following sections.

A Party that wishes to transact some amount of a resource, to find a potential counterparty, or to arrive at an agreement with a specific known counterparty begins a Negotiation by sending a Request for Quotation (RFQ), an Indication of Interest (IOI), or perhaps a unsolicited Quote. In CTS, the distinction between an IOI and Quote is Boolean variable “tradable” which is false for an IOI and True for a Quote.

The initial message may be general, advertised to all participants in a Segment, or targeted, sent to one or more chosen Parties. The IOI is non-tradable and sent to elicit a counteroffer which could be a tradable Quote, another IOI, or an RFQ. A tradable Quote, whether solicited or unsolicited, invites a Tender which will result in a Transaction.

Financial markets assume that the same party, called the Issuer, initiates all quotes in a specific negotiation. The recipient of a quote can accept the quote, if it is tradable and the terms are agreeable, or reject the quote. When a Party accepts (“hits” or “lifts”) a tradable quote, the Market executes the Transaction—the issuer of the quote cannot back out. The market facilitates the quote process but does not intervene—it acts as a neutral party.

CTS negotiations differ from financial practice in that in financial negotiation, the instrument never changes. Over the course of a CTS negotiation, the time of delivery may change, which is a change of Instrument.

And RFQ uses a Bounded Interval to indicate what an acceptable IOI or Quote would be.

· Consider Party A that wishes to buy 15 kW of power over a two-hour period, sometime within an 8-hour window. This would take the form of an RFQ with an eight hour bounding interval with a specific start time, but with a Stream of two Intervals with a Duration of 1 hour but with no starting time specified.

· Consider instead that Party A further wishes to buy 10 kW of energy over an hour at $0.05/kWh sometime during the work day. Party A create an RFQ, with a bounding duration of the workday, containing a single unscheduled Interval of one hour containing the Price and the Quantity.

Party A and B can send these RFQs directly to one or more potential counterparties or advertise it to the entire market. Because it is not tradable, the Market does not need to know about or register the RFQ. The response is a quote, either indicative (IOI) or tradable (Quote).

Party A may receive one or more offers in response. These become more specific, perhaps two Quotes issued by the same counterparty with different prices at different times. A quote issuer may make a counteroffer by sending a quote proposing different quantities and/or prices. Perhaps the responding Party considers that it will turn on a generator, but only if it can operate the generator at an economic rate for an economic duration. A quote MAY be for only one of the two hours indicated in the original RFQ, leaving the requesting Party to find an acceptable match from among all the offers (quotes) it receives. The prices may be higher or lower than requested in the original RFQ. Until one party issues a tradable Quote, than all responses are RFQs or IOIs, issued to continue the negotiation.

When the respondent thinks that there is an essential meeting of requirements, that Party submits a tradable Quote, that is a quote that a matching Tender will turn into a Transaction. For a CTS quote to be tradable, the Party informs the Segment, even if it is a private quote and not generally advertised.

To accept a tradable Quote, a Party submits a Tender to the Segment, referencing the Quote ID, and matching the details of the quote. The Segment compares the Tender to the quote, and, if they match, it awards the Transaction without going through the Segment’s matching engine. All tradable quotes are treated as if they are marked All-or-None (AON).

The issuer MUST accept a Tender received in response to a tradable Quote.

Negotiations may include Interval Quotes or Stream Quotes, a pattern that matches that of Tenders (See Section 5.3.1, “Interval Tenders and Stream Tenders.”) A Stream Quote must be matched to a Stream Tender to create a Transaction. A requester that wishes to get a Stream Quote back indicates it in the RFQ or IOI. The stream in an RFQ need not fill the Bounding Interval; an overnight bounding interval of fifteen hours may be seeking any proposal three-hour stream during that interval.

There are three scenarios for negotiation below to illustrate the flexibility of Negotiation: (1) Single-provider, (2) over-the-counter, and (3) system recovery.

1) In certain Market Segments, a single Provider may operate entirely by general advertisement, available to the entire Market. Consider a local distribution electric utility that provides hourly prices for the next day. The providing Party announces day-ahead prices at 9:00 AM each day through 24 indications of interest (IOI) (or a single Stream Indication) to the Segment. Each indication expires at 11:30 AM. Each IOI includes the maximum Power that the Party is willing to sell during each hour of the next day. Each Consumer that wishes to buy on these terms submits RFQs to the issuer for the power they want. The Issuer prepares an actionable quote for each Consumer; each Consumer accepts that Quote by means of a Tender. The Issuer MAY repeat the process, perhaps at different prices, until Transactions for all the power that the Issuer intends to sell are executed.

2) Parties may choose to use an over-the-counter (OTC) trade because they wish to bypass certain market restrictions. A Segment with an Off-market Venue Type would permit, for example, a Party to buy 87 kWh of Power for a period over 1 hour and 5 minutes beginning 15 minutes after the hour. Parties negotiate as above, come to terms, as above, and the Segment records the Transaction.
Order Book Segments impose restrictions on Round Lots and Intervals to improve Market Liquidity, that is, the likelihood of a match between a Tender to Buy and a Tender to Sell. If OTC Parties already have made an agreement, then there is no need to improve liquidity. This makes the Durations and Round-Lots in Off-market venues indicative rather than prescriptive. 87 kWh is a rough match for Off-Market Segment with a 20 kWh round lot—a gWh is not. In a comparable way, the quote’s Duration is a rough match for Segment with an Hour Duration while 3 minutes is not.

3) Markets commonly project opening prices for Instruments before they open. If a system recovery requires a market re-start, there may be no good information to set opening prices. Prior to a re-start, a Segment may advertise RFQs to buy and to sell. The Operator may use a Segment to probe the potential market in this way several times, perhaps with different prices and quantities, to discover an opening price in which the Resource will be in rough balance. When the market has enough information, then the market opens a Segment for trading, announcing the opening prices.

This specification does not require that a Market include any of the scenarios described above. We include them to illustrate how the essential components of Negotiation might fit together in a specific system.

9.2 Negotiation Vocabulary

The Messages use advertisement and negotiation are essentially identical to Tenders. Note that the lowercase quote includes both the IOI and the actionable Quote.

Table 9‑1: Negotiation Message Types

Term	Purpose	Comment
Request for Quote (RFQ)	A Party submits a Request for Quote to try to find a market in an Instrument or Instruments. A Request for a Quote may be for a time range of Instruments	May be used pre-opening to elicit tenders, both buy and sell, to determine market opening prices.
Quote	Indicates the price and quantity at which an instrument can be bought or sold. A quote may be issued in response to an RFQ or to a prior quote, or it may start a negotiation.	The CTS Quote may be either a Bid Quote or an Ask Quote. Any Quote or IOI may be either advertised. Note CTS does not support two-sided quotes
Interval Quote	A Quote provided for only a Specific Interval.	Some Segments MAY limit negotiations to Intervals only.
Stream Quote	Prices and Quantities for a Product in a series of consecutive Instruments submitted as a single Quote	In energy markets, a stream curve may be referred to as a “Load Curve.”
Tradable Quote	An offer to buy or sell up to a specific quantity of an Instrument for a specific price.	A Tradable Quote is registered by the Segment and can be referenced (“lifted”) to initiate a Trade as if it were a Tender.
Indication of Interest (IOI)	A type of quote that does not create a commitment to accept a Transaction.	As part of a Negotiation, an IOI may encourage further Negotiation. May be issued in response to an RFQ.
Private Quote Private RFQ	A quote sent only to potential Counterparties during a Negotiation	An implementation may use the Segment to distribute Quotes to Counterparties or it may expect Parties to message Counterparties directly.
Advertised Quote Advertised RFQ	Setting the Boolean requestPublication when creating a quote requests that the quote be advertised to all Segment participants.	A Segment advertises quotes on the Indication Ticker.(See 11.3) It is undefined what a private Party (other than the Segment) does after receiving a requestPublication
Issuer	The Issuer is the Party that originates a Quote, whether in response to an RFQ or unsolicited.	The Issuer must accept a matching Tender sent in response to a Tradable Quote.

9.3 Messages for the Negotiation Facet

A Request For Quotes (RFQ) is a message describing what is to be quoted, and may be sent to the Segment or to one or more intended counterparties.

A Quote is either spontaneous or in response to an RFQ or prior IOI. Quotes may be Tradable, in which case a Counterparty may respond with a Tender acknowledged by a Transaction, avoiding the market clearing process.

Facet	Request Payload	Response Payload	Notes
Negotiation	EiCreateRfq	EiCreatedRfq	Create and send an RFQ. If the RFQ is to be advertised, the Counterparty is the ID of the Market. Otherwise, it goes to the intended Counterparty. The sender of EiCreateRfq may request publication, but has no guarantee that publication is performed.
Negotiation	EiCreateQuote	EiCreatedQuote	Create and send a Quote. If the RFQ is to be advertised, the Counterparty is the ID of the Market. Otherwise, it goes to the intended Counterparty. The sender of EiCreateQuote may request publication, but has no guarantee that publication is performed.
Negotiation	EiCancelQuote	EiCancelledQuote	Cancel RFQ or Quote or Quote

NOTE TO REVIEWERS: Quotes and RFQs could be merged into a single Create an Indication of Interest. Is that an improvement? This Draft goes part way there by including a RequestPublication flag in the respectivce Create message payloads. This would be subsumed by the implied IOI convergence, and may lead to elimination of the undefined EiDistributeIOI interactions. We request specific comments on this issue.

9.4 Interaction Pattern for the Negotiation Facet

This is the UML sequence diagram for the Negotiation Facet:

Figure 9‑1 UML Sequence Diagram for the Negotiation Facet

9.5 Information Model for RFQ and Quote

The UML Class Diagram for the EiRfqType are shown in Figure 9‑2.

Created with Enterprise Architect (Build: 1626) 2

Figure 9‑2 UML Class Diagram for EiRfqType

The UML Class Diagram for the RFQ payloads is shown below. Attributes are in Table 9‑2.

Created with Enterprise Architect (Build: 1626) 2

Figure 9‑3 UML Class Diagram Showing Negotiation Facet RFQ Payloads

Table 9‑2: EiCreateRFQ Payload Attributes

Attribute	Type	Fix Field Name	Meaning	Notes
Counter Party IDs	Actor ID		The Party IDs for the CounterParties for which the RFQ is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counter-party is used.
Party ID	Actor ID		The Actor ID for the Party requesting the Quote.	Indicates which Actor proposes the buy or sell side EiCreateTender.
Request ID	RefIDType		Reference to this message payload
RFQ	EiRfqType		The RFQ transmitted.	Unlike EiCreateTender, only one RFQ is created per message payload.
Request Publication	Boolean			The sender of EiCreateRfq may request publication by setting Request Publication to true, but has no guarantee that publication is performed.
The fields below are as defined in EiRfqType
RFQ Id	QuoteIdType		Assigned by the sender of EiCreateRfqPayload	Creator’s ID for the RFQ
Bounding Interval	Interval Type		A closed interval which encloses all Quotes requested.	See Sections 78 (Position and Delivery Facets). Alignment of instruments is a characteristic of the Segment.
Duration	Duration Type		Resource and Duration determine product.	An explicit duration rather than a database lookup simplifies consumption and generation planning.
All Other fields are as defined in the Tender, Table 5‑2

Table 9‑3 EiCreatedRfq Payload Attributes

Attribute	Type	Fix Field Name	Meaning	Notes
Market Request for Quote ID	RfqIdType	RFQId	ID for this Request for Quote	Market Assigned as it in for Tenders. Used for Cancel request.
Response	EiResponseType		Standard response object
In Response To	RefIdType		ID for the corresponding EiCreateRfq Payload

Table 9‑4 EiCancelRfq and EiCanceledRfq Payload Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID		The Actor ID for the CounterParty for which the Tender is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counterparty is used.
Party ID	Actor ID		The Actor ID for the Party on whose behalf this Tender is made.	Indicates which Actor proposes the buy or sell side EiCreateTender.
Request ID	Ref ID		An identifier for this Cancel RFQ Payload
Market Request for Quote ID	RfqIdType	OrderID (37)	Market-assigned ID for the subject Request for Quote	Market Assigned in parallel with Tenders.
Quote Id	Quote ID Type		The Quote ID included in the CreateQuoteTender Payload or the Tenders within an CreateQuotePayload
Canceled Response	EiCanceled Response Type		Optional Detailed response for each RFQ for which cancelation was requested
In Response To	RefIdType		The EiCancelRfqPayload that is responded to in the Canceled Payload

9.6 Information Model for Negotiation Facet

As described in Section 5.3 Information Model for the Tender Facet, EiQuote and EiTender are subclasses of abstract class TenderBase. In the following table, only the first three attributes are part of EiQuoteType; the rest are inherited.

See Table 5‑3: EiTender Attributes” for details. See Figure 5‑2 for the inheritance and relationship between EiTenderType and EiQuoteType.

A screenshot of a computer

Description automatically generated

Figure 9‑4 UML Diagram of EiQuoteType showing inherited attributes.

Table 9‑5: Attributes of EiQuoteType

Attribute	Type	FIX Field Name	Meaning	Notes
Market Quote ID	Market Order Type		ID assigned by the Segment or Market	Used in acknowledgment of tradable quote in future market messages.
Private Quote	Bool	PrivateQuote (1171)	Specifies Quote is available to a specified counterparty or only.
Quote ID	Quote Id Type	QuoteID (117)	ID as submitted by Quote originator	Used in off-market negotiation Also used in Tender to reference a Tradable Quote
RFQ ID	RFQ Id Type	QuoteReqID (131)	ID as submitted by RFQ originator	Referenced by Quote responding to RFQ
Quote Type	Boolean	QuoteType (537)	IOI or Tradable	Tradable is a Boolean; if true, the quote is tradable. If false the quote is not tradable, or an Indication of Interest (IOI) consistent with FIX terminology.
All Other fields are as defined in the Tender, Table 5‑2

9.7 Negotiation Facet Payloads

Figure 9‑5 shows UML Class Diagrams for the Negotiation Facet Payloads.

Created with Enterprise Architect (Build: 1626) 2

Figure 9‑5 UML Class Diagram for Negotiation Facet Payloads

The following tables show attributes for the Quote Payloads.

Table 9‑6 EiCreateQuotePayload

Attribute	Type	FIX Field Name	Meaning	Notes
Counter Party ID	Actor ID		The Actor ID for the CounterParty for which the Quote is created.	In CTS, generally the PartyID for the Market. To indicate a bilateral exchange, i.e., a Tender between two specific parties, the PartyID of a specific counter-party is used.
EiQuote			As above
Party ID	Actor ID		The Actor ID for the Party requesting the Quote.	Indicates which Actor proposes the buy or sell side
Tradable	Boolean	(part of Codeset in FIX)	If false, this is an indicative quote.	Contains Boolean for whether the quote is Tradable.
Request Publication	Boolean			The sender of EiCreateQuote may request publication by setting Request Publication to true, but has no guarantee that publication is performed.

9.8 Information Model for Stream Quotes

Some Market Segments may permit Stream Quotes, that is, a single Quote for multiple consecutive Instruments. When responding to a Request for Quote, the range of quoted Intervals must be within the bounding Interval of the Request.

Stream quotes and quotes are the same class.

9.9 Rejecting a Quote

Quotes may be rejected if ill formed, violate granularity rules, or other requirements of the Segment or Market.

9.10 Creating Transactions from Quotes

A Party receiving a Tradable Quote MAY respond by submitting a Tender that references that Quote.

The Market registers a Tradable Quote it receives AS IF it were a Tender, that is, places them in a book until it expires. A Quote that is marked as Advertised by using an EiDistributeQuotePayload is included in the Indications Ticker (see Section 11.3).

The Market does not Advertise a Quote that is directed to a specific Party or Parties, though it MAY follow its anonymization and advertising practices.

To accept a Tradable Quote, whether on first notice or after negotiation, a Party submits a Tender matching the Price and Quantity of the Quote and referencing the QuoteID. The Market will then validate the match and create a Transaction if it fits. The Tender must match price, be within the acceptable quantity of the Quote, and so on. An All-or-None Execution Instruction on either Quote or Tender MUST be honored. If the Quote accepts partial fulfillment, the remaining balance on the Quote is decremented as it is for a Tender.

Notwithstanding any negotiation, the Market may reject the Tender if accepting it would interfere with resource operations or violate financial requirements on participants.

If a Tradable Quote is open when the Instrument closes, it is the responsibility of the Party that submitted the Quote to cancel it. If the Negotiator still wishes to accept an instrument scheduled for 11:00 at 11:30, that is up to the Parties; how that is accomplished is out of scope.

9.11 Negotiation Messages

The negotiation messages are variations on a common theme, but are distinguished by message type.

The Quote Service does not wait for or expect acknowledgements of advertised Quotes.

If permitted in the venue (Segment), a Party may submit quotes for several consecutive Intervals, a set of Instruments for an identical Product, as a single Quote. In Power, this is called a “Load Curve”. Stream Quotes are constructed and interpreted in the same manner as are Stream Tenders.

All elements of the stream share the duration and the stream has the explicitly stated start time.

9.12 Discussion of Negotiation (Non-Normative)

Any Market Segment may support Negotiation as indicated in the Market Structure information.

A Quote-Driven Market is one of the venue types (see Table 13‑1: Venue Types in CTS) for a CTS Market Segment. In financial markets, a quote-driven market is a secondary market trading structure wherein buyers and sellers interact with dealers. It is not as transparent as an order-driven market in that the market orders and prices that traders are willing to buy or sell at are not available to the counterparty.

A Quote-Driven Market MAY be chosen to negotiate with a dominant supplier that represents many third parties, i.e., a Distribution System Operator acting as an intermediary to a bulk power market. Such a Quote-Driven Market can permit large buyers to plan significant resource use over time, for example, scheduling a long running industrial process which also requires labor planning. Such a buyer could submit multiple Requests for Quotes with different schedules, and then select from among the Quotes received in response.

The overarching Market tracks all Transactions and monitors all Delivery.

10 Subscriptions

A Party wishing to trade in a market naturally wants to be kept apprised of changing information about the market. This can be roughly divided into granular information about what other Parties are doing in the Market, and information about the Market as a whole. The FIX Protocol specification terms these as Market Data, that is, granular or aggregate information about activities in a Market, and Market Structure Reports, that is, information about how each Market Segment is operating.

In the FIX Protocol, a Party gets this information by means of Subscriptions. A Party subscribes to the information it needs and thereafter receives periodic updates relating to that subscription. The FIX interaction model defines a subscription as how an Actor requests one or more market reports.

A Market consists of multiple Market Segments, each trading a single Product based on the Resource traded in that market. Multiple Market Segments in a Market MAY trade the same Product, perhaps with different trading rules, or different schedules of operation. The Market Segments in a Market may support different Market Data Reports. Information about a Market and its Market Segments is conveyed in the Market Structure Subscription.

Subscriptions are how a Party requests specific Pre-Trade information. Not all Markets and Segments will support all Subscription types. The Subscriptions supported by each Segment are described in Section 13, “Market Structure Subscriptions”.

Some markets will not support granular subscriptions. The Market Structure will instead indicate a multi-cast point or other source that a Party can choose to listen to.

10.1 Subscriptions

Several varieties of market and trade-related information are described in this specification. To request and acknowledge subscription changes objects of the EiSubscriptionRequest and Response Types are included in the appropriate subscription management messages.

10.1.1 Information Model for Subscription Requests and Responses

The UML Class Diagram for the Subscription Request and Response is shown in Figure 10‑1. Specific requests, for example for tickers or market information, are defined in Section 11.

Created with Enterprise Architect (Build: 1626) 2

Figure 10‑1 UML Class Diagram for Subscription Request and Response Types

Attributes for EiSubscriptionRequest are shown in Table 10‑1.

Table 10‑1 EiSubscriptionRequest Attributes

Attribute	Attribute Type	FIX Field Name	Meaning
Market Id	Market ID Type	MarketID (1301)	A UID referencing a Market
Segment ID	Natural Number	MarketSegmentID (1300)	If Segment ID is non-zero, the request is limited to reporting on the indicated single Segment. If zero, the subscription requests reporting on all Segments of the indicated Market
Subscription Action Requested	Enumeration	SubscriptionRequestType (263)	The type of subscription being requested. CTS uses an enumeration carrying the same information as the FIX numeric codes: 0 – Snapshot 1 – Snapshot + Updates (update frequency is determined by the supplier) 2 – End the indicated Subscription
Subscription ID	Subscription ID Type		A UID indicating the created subscription, so that it may be canceled or modified. Should be null for initial request.
Subscription Request ID	Id Type	MDReqID (262)	Used to identify this request for managing a subscription. See ALSO FIX MarketDataRequest (35=DR).

Attributes for EiSubscriptionResponse are shown in Table 10‑2.

Table 10‑2 EiSubscriptionResponse Attributes

Attribute	Attribute Type	FIX Field Name	Meaning
Response	EiResponse Type
Subscription Action Taken	Enumeration	SubscriptionRequestType (263)	The action taken on the referenced Subscription ID.
Subscription ID	Subscription ID Type		A UID indicating the newly created, modified, or canceled subscription.

11 Ticker Facet

A Party wishing to trade in a market naturally wants to be kept apprised of changing information about the market. FIX divides this information into two categories: Market Data and Market Structure. Market Data reports activity in the Market, Market Structure describes how the Market (or Segment in CTS) is organized.

This section describes mechanisms to access continuous Market Data on the activities of market participants. CTS calls these Tickers. Tickers update continuously, on a schedule determined by the provider, as Parties interact with a Segment.

There are four types of Tickers, represented as an enumeration. See Table 11‑1 and Figure 11‑1 below.

Table 11‑1: Types of Tickers in CTS Facet

Ticker Type	Request Payload
Bids	Anonymized Tenders to Buy
Indications	Advertised Indications of Interest (IOI) and RFQs
Offers	Anonymized Tenders to Sell
Transactions	Anonymized Completed Transactions, whether from market matches or from Negotiation

Figure 11‑1 TickerType Enumeration

Not all Markets or Market Segments support Ticker subscriptions or all Ticker types. Actors can discover what Tickers a Segment supports and how to interact with them through the Market Structure reports. Market Structure is discussed in Section 13, “Market Structure Subscription”.

Private Quotes do not appear in Tickers.

In many markets, it is required for most participants to be anonymized, that is, the identity of the submitter kept private. In such markets, the Market Id is used as the Party ID in the Ticker. In Resource markets as in financial markets, Partys in specific and influential roles are not anonymized. For example, a Market may opt not to anonymize the Party Id of the distribution system operator (DSO). CTS makes no statement about what anonymization rules a resource market must use. This specification offers the general guidance that most participants be anonymized to preserve privacy, but that Ticker messages for significant participants can be submitted under their own identity.

11.1 Ticker Facet Subscriptions

A Party subscribes to a Ticker common FIX market subscription model (Section 10.1, “Subscriptions”). A Party can subscribe to a single Market Segment or all Market Segments. Each Ticker Type, if available, requires a separate Subscription.

Table ‎21‑2: Ticker Facet

Facet	Request Payload	Response Payload	Notes
Ticker	EiManage Ticker Subscription. Payload	EiManaged Ticker Subscription. Payload	As multiple Markets may use same Ticker service, must allow multiple subscriptions.
~~Ticker~~	~~EiDistributeTicker~~	~~None~~	~~Publish Indication to the Ticker~~

Created with Enterprise Architect (Build: 1626) 2

Figure 11‑2: UML Sequence Diagram for the Ticker Facet

11.1.1 Information Model for Ticker Facet Subscriptions

The messages for adding, changing, or deleting a Ticker subscription contain only the ticker type and a subscription request or response. The UML Class Diagrams for the payloads are shown in Figure 11‑3.

Created with Enterprise Architect (Build: 1626) 2

Figure 11‑3 Ticker Manage Subscription Payloads

11.1.2 Exceptions to Subscription Interactions

A given Segment may support the same Ticker for any or all of the Ticker types. In that case, an Actor that subscribes one of these Tickers subscribes to all the Types included in that Ticker.

In larger markets, there may be a common broadcast channel for a Ticker. In such markets, there is no subscription; the Actor simply listed to that broadcast channel.

11.2 Ticker Patterns

The various types of tickers share a common approach:

· A subscription is created using EiManageTickerSubscription, passing the requested change and which ticker is being managed.

· The ticker payloads contain the subscription ID and the relevant object for the ticker type:

o TenderTickerType is EiTenderType for Bid and Offer tickers.

o TransactionTickerType is EiTransactionType

o IndicationTickerType is either an EiQuoteType (not tradable) or EiRfqType.

· The ticker delivery is defined by the provider.

o Large or complex markets might use a multicast for delivery, with the relevant ticker payloads.

o Small or less complex markets might use a market-defined delivery mechanism (out of scope)

The UML Class Diagram for ticker types is shown in Figure 11‑4.

Created with Enterprise Architect (Build: 1626) 2

Figure 11‑4 Ticker Facet Payloads

The attributes for the Ticker Types are shown in Table 11‑2.

Table 11‑2 Attributes for the Ticker Type

Attribute	Attribute Type	FIX Field Name	Meaning
Subscription ID	Subscription ID Type		A UID indicating the related subscription.
Ticker Type	TickerType		Enumeration consisting of literals BIDS, INDICATIONS, OFFERS, or TRANSACTIONS.
Tender	EiTenderType		For TenderTickerType
Transaction	EiTransactionType		For TransactionTickerType
Quote	EiQuoteType		Alternate for IndicationTickerType; either all Quotes or all RFQs.
RFQ	EiRfqType		Alternate for IndicationTickerType; either all Quotes or all RFQs.

11.3 The Bids and Offers Tickers

Bids and Offers are simply Buy or Sell side Tenders. When a Tender is submitted, the Segment announces the Tender on the Ticker. A Segment may use a single Ticker for both Bids and Offers as described in its Market Structure reports. Tenders are submitted to the entire market; There is no guarantee that an Offer or a Bid will still be there when a Party submits a matching Tender. [9]

Tradeable Quotes MAY be published in a ticker only. if it is delivered by means of an EiDistributeQuote payload. See Section 9 Negotiation Facet.

The payload for Bids and Offers Tickers includes one or more EiTenderType objects with attributes anonymized following market or segment rules. Attributes are shown in Table 5‑3: EiTender Attributes.

A Party that wishes to receive Bids or Offers from a Segment must subscribe to the Bid or to the Offer Ticker for that Segment. If a single Ticker only is provided Bids and Offers, then subscribing to either one subscribes to both.

11.4 The Indications Ticker

If a Segment supports Negotiations, then it supports an Indication Ticker. While the messages in Bids and Offers are essentially identical, except for BUY or SELL side, there is more diversity in the messages for Indications.

The payload of the Indications Ticker is just as defined for the IOI in Negotiations. Because the purpose of a public Offer is to initiate a Negotiation between Partys, the Indications Ticker is not anonymized.

The objects in the Indication Ticker payload are either all Quotes or all RFQs.

11.5 The Transactions Ticker

The Transactions Ticker is the continuous publication of information about Transactions executed in a Market Segment. Both Parties are listed on a Transaction, although either or both may be anonymized as specified in market rules.

In Negotiation-based Markets, the Transaction announcement is the first public appearance of the Negotiation.

Figure 11‑4 Ticker Facet Payloads includes the payload for the TransactionTicker—an EiTransactionType object with the ticker type and subscription ID.

Table 11‑3: EiCompletedTransaction Attributes

Attribute	Type	FIX Field Name	Meaning	Notes
BuyerId	Uid		ID of the Buyer in this Transaction	May be ExchangeID if anonymized
SellerId	Uid		ID of the Seller in this Transaction	May be ExchangeID if anonymized
The remaining fields are as defined in the Tender, Table 5‑2

12 Instrument Market Data

Instrument Summaries are Subscriptions (described in Section 10) that provide market data about the specific Instruments traded in the Segment. Like other Subscriptions, Instrument Summary Subscriptions provide part of what FIX terms Pre-Trade Data.

12.1 Instrument Summary Subscription

An Instrument Summary Subscription requests periodic data on a bounded range of Instruments. Within a Market Segment, trading is for a single Product, and Instruments are distinguished by Start Time and Date. The Subscription returns market data for all Instruments whose Start Time falls within the Bounding Interval of the Subscription.

Created with Enterprise Architect (Build: 1526) 2

Figure 12‑1 ‎: Need new UML for the Instrument Summary Subscription Request

The Instrument Summary Subscription Request specifies the type of summary and the instruments requested.

Table 12‑1: Information Model for Instrument Summary Subscriptions

Attribute	Attribute Type	FIX Field Name	Meaning	Notes
Market Data Request ID	String	MDReqId (262)	ID of this Market Data Request	Use the ID of previous Market Data Request to modify or cancel a previous request
Request Type	Char	Subscription Request Type (263)	Indicates to the other party what type of response is expected. .	0 = A snapshot request only asks for current information. 1 = A snapshot and updates. 2 = Unsubscribe, will cancel any future update messages from the counter party
Update Type	Char	MDUpdateType (265)	0 = Full Refresh 1 = Incremental Refresh
Market Segment ID	String	MarketSegmentId (1300)	Unique Identifier for Segment	Market Data Reports are for a single Segment
Bounding Interval	Start Date End Date	Bounding Interval	Bounding Interval?	Subscription covers all Instruments within Bounding Interval
Instrument Summary Type	Int		Type of Instrument Summary to subscribe to: 0 = Session Summary 1 = Top-Of-Book
Market Depth	Int	MktDepth (264)	Depth of market for Book Snapshot / Incremental updates 0 = full book depth 1 = top of book 2 or greater = book depth (number of levels)

12.2 The Instrument Summary Report

Instrument Summary Reports provide summary information about one or more instruments. Common information about the report is presented in a Market Data Instrument Header. Information about each instrument is presented in the Market Data Instrument Summary.

12.2.1 The Instrument Summary Header

Table 12‑2: Information Model for the Market Instrument Summary Report

Attribute	Attribute Type	FIX Field Name	Meaning	Notes
Market Data Request ID	String	MDReqId (262)	ID of this Market Data Request	Use the ID of previous Market Data Request to modify or cancel a previous request
Request Type	Char	Subscription Request Type (263)	Indicates to the other party what type of response is expected.	0 = A snapshot request only asks for current information. 1 = A snapshot and updates. 2 = Unsubscribe, will cancel any future update messages from the counter party
Market Segment ID	String	Segment (1300)	Unique Identifier for Segment
Market Segment Status	Int	MarketSegStat (2542)	1 = Active: Market segment is active, i.e. trading is possible. 2 = Inactive: Market segment has previously been active and is now inactive. 3 = Published: Market segment information is provided prior to its first activation.
Instrument Summary		Series	Repeating series for each Instrument in the Report. The information varies by the Summary Type requested.

12.2.2 The Instrument Summary

The Instrument Summary is the information in an Instrument Summary Report that is repeated for each Instrument in the range,

The Instrument Summary are a repeating group of summaries, one for each instrument in the Market Data Instrument Summary Subscription.

The information conveyed varies with the Instrument Subscription Type.

12.3 The Instrument Summary Types

12.3.1 The Instrument Session Summary

A common change reported in an Instrument Session Summary is market crossing, announcing when a Segment opens and when a Segment closes. In transactive resources, each Instrument crosses as well A Segment may not permit trading in an Instrument more than forty-eight hours in the future. An Instrument in the past can no longer be traded. We term the union of Segment crossing and Instrument crossing the Instrument Session.

Session reports include opening prices and closing prices.

Table 12‑3: Instrument Session Summary Detail

Attribute	FIX Field Name	Attribute Type	Meaning
Begin DateTime	BeginDateTime	DateTime	StartTime that identifies this Instrument, and thereby this Instrument Session Summary Detail
High Price	HighPx (332)	Price	The high end of the price range prior to the open or reopen
Low Price	LowPx (333)	Price	The low end of the price range prior to the open or reopen
First Price	FirstPx (1025)	Price	Indicates the first price of a trading session; can be a bid, ask, or trade price.
Last Price	LastPx (31)	Price	Indicates the last price of a trading session; can be a bid, ask, or trade price.

12.3.2 The Instrument Book Summary

The Book is the set of all Tenders, including Tradable Quotes, in the Market Segment. In an active market, unless there are restrictions on matching, all Tenders to sell are priced higher than all Tenders to buy; if there were an overlap, they would already be matched, Transactions generated, and the Tenders already removed from the book.

All Tenders are sorted by price. Tenders to sell are sorted by ascending price—the top of the book is the tender offering the cheapest price. Tenders to buy are sorted by descending price—the top of the book is the tender offering the highest price.

The depth of the Book is the number of Tenders in each list. A Top of the Book request, subscription depth of 1 provides just the top entry in each list. anonymized. A subscription depth of 0 provides both entire sorted lists, anonymized. Any other subscription level (n) provides the first (n) entries in each level.

Table 12‑4: Instrument Book Subscription

Attribute	Attribute Type	FIX Field Name	Meaning
Begin DateTime	DateTime	BeginDateTime	StartTime that identifies this Instrument, and thereby this Instrument Session Summary Detail
Book Entry	Compound		Repeating element for each side and level of the Book

The Book Entry is the repeating information for each Side in the Book. The Book Entry is the same message format as a Quote, anonymized as required by market rules.

The Book entry is always summarized. That is, if there are five Tenders at the top of the offer side with the same price, the quantity returned in the Book Entry is the sum of the Quantities in each of those Tenders. The same rule applies to bid side of the Book.

13 Market Structure Subscriptions

For any Market, there are standing terms and expectations about Product offerings. If these standing terms and expectations are not known, many exchanges may need to occur before finding what Products and Tenders meet those expectations. The Market Structure Report tells the Party how to trade. Following the classification used by FIX, Market Structure is just one part of Pre-Trade Information.

Market Structure changes are limited to Opening, Closing, Settlement and to the currently Active Segments.

Segment Structure includes Opening, Closing, as well as Crossing information for specific Instruments. It also includes detailed information to guide Training, detailed rules and negotiations and trading.

13.1.1 Venue Types

One of the most important distinctions between Market Segments is the Venue Type.

FIX defines the Venue Type to describe the general mechanism of trading. A Party participating in trading may change its behavior based on the Venue Type. The optimum trading strategy for a Party will change between an order book and an auction. If there is only a single seller, the Buyer will want to attend closely to the quotes from that buyer.

The Venue Type categorizes how a Transaction is generated by the Venue. A Party wishing to buy or to sell will change strategies based on the rules of the Venue. FIX defines many Venue Types (FIX tag 1430), only some of which are supported by CTS-conforming Markets. Table 13‑1 lists the Venue Types supported by CTS.

Table 13‑1: Venue Types in CTS

FIX Code	Name	Meaning
B	OrderBook	Participants submit their buy and sell orders, which are matched based on specific rules and executed accordingly. Order Books provide transparency, liquidity, and support for different types of orders, but they also have limitations and rely on the integrity and fairness of the exchange. Also referred to as a Centralized Limit Order Book. CTS specifies a “hard” order book, which executes orders immediately and automatically
O	OffMarket	Trades are conducted outside the market, but registered in the automated exchange. Sometimes referred to as an Over-the-counter (OTC) or Bilateral market. Off-Market trades may be for odd lots, for custom durations, and span the temporal boundaries of Products. The exchange may reject a trade that would cause violation of the physical limits of the Resource distribution.
Q	QuoteDrivenMarket	Quote Driven Markets are used for Markets with a single dominant supplier. Parties are notified of the Quoted price for each Instrument and submit Tenders to match those Quotes. Example: A System Operator provides 24 quotes for the next day’s hourly pricing.
N	QuoteNegotiation	A Quote Negotiation Market is used for bilateral negotiations around price. Sellers may advertise round lots that they would like to buy or sell, and indicate an interest in buying or selling.
A	AuctionDrivenMarket	An Auction Driven Market matches Tenders only in scheduled auctions wherein all participants clear at the same price. In Resource Markets, also referred to as a “Double Auction”.
S	SpotMarket (not in FIX)	A Spot Market indicates the “instant” price in the Market Segment that will be used for purchases or sales.
X	Settlement (not in Fix)	A Settlement venue self-executes Transactions for Resource consumed without previously being bought.

13.1.2 Interaction Pattern for Market Structure

The Market Definition Facet enables a Party to request the details of a Market and its Market Segments. The initial request returns the Market and all Segments. Subsequent reports occur when there is a change to a Market Segment and include only the changed Market Segment(s). A request to refresh a subscription returns the entire Market Structure. A request to cancel the subscription suspends all further updates.

Created with Enterprise Architect (Build: 1526) 2

Figure 13‑1: UML Sequence Diagram for the Market Definition Facet

A Party may watch changes to a single Market by naming that Segment in the subscription request. This will return only that Segment and updates to that Segment.

13.2 Market Definition

Table 13‑2 Information Model for the Market Definition

Attribute	Attribute Type	FIX Field Name	Meaning
Market Name	String	NAME	Text providing a descriptive name for a Market. While the Name MAY be displayed in a user interface; it is not meaningful to the Actors.
Currency	String	Currency (537)	String indicating how value is denominated in a market.
Currency Code Source	String	Currency Code Source (2897)	ISO – Fiat Currency per ISO 4217 DTI – Digital Token Identifier LOC – Locally defined Currency
Time Offset	Duration	T_OFFSET	A Duration that some Markets MAY use to describe trading where a first interval is not on an hourly boundary.^{^[10]}
Tick Size	Price	Tick Increment (1208)	Specifies the valid price increments at which a Party may quote or trade an Instrument.^{^[11]}. Use if a common Tick Increment required for all Market Segments. Tick Increments can increase market liquidity.
Resource Designator		Resource	The Resource traded in this Market and Segment
Party Id		Party Id	The PartyID used in Tenders to the Market and in Transactions with the Market.
Market Segments		Market Segment	A list of Market Segment descriptions for each Market Segment contained in the Market. See Section 13.3.
Maximum		MAX	Maximum Transaction size the Market will accept.

13.3 Segment Definition

A Party must interact with a specific Market Segment to trade a specific Product. A Market MAY contain two or more Market Segment trading the same Product; such segments may differ in venue type, or in trading window. For example, a regulated provider may offer a day-ahead hourly market based on an Auction between 9:00 AM and 3:00 PM. Thereafter, a forward Market in the same Product may move to another Market Segment using an Order Book. The Auction and the Order Book are different venues, matching buyer, and seller by different mechanisms.

A Party chooses the Market Segment that it anticipates will be to its greatest advantage. The Party will make this choice based on anticipated price, or on block size, or even on Warrant. Because Transactions are committed when created, a Party may buy on one Market Segment, and thereafter sell part of it on another.

A Party discovers Market Structure, including changes over time, by subscribing to that Market. Even without market activity, the information in a Subscription may change. For example, a Segment may open or close and the biddable Instruments change regularly.

Table 13‑3 Market Segment Description

Attribute	Attribute Type	FIX Field Name	Meaning	Comments
Market Segment ID	String	SEGMENT (1300)	Unique Identifier for Segment
Market Segment Name	String	SEG_NAME (1396)	Optional text providing a descriptive name for a Market Segment.	While the Name MAY be displayed in a user interface; it is not meaningful to the Actors.
Product	Compound		Product transactable this Segment. See Defining Product (Section 3.1.2) for details.	Each Product shares a Resource with the Market
End Point	String	EndPoint	End point to access the Market Segment.	May be a transport end point, mailbox address or other.
Segment Status		MktSegStat	Current trading status of the Market Segment.	1 = Active: Market segment is active, i.e. trading is possible. 2 = Inactive: Market segment has previously been active and is not currently Open. 3 = Published: Market segment information is provided prior to its first activation.
Tradable Interval	Interval		Instruments whose start is within the bounding of the Interval can be traded
Session Start Time	DateTime	TradSes StartTime	Date and Time when Tenders may first be submitted for the current or next Session
Session Open Time	DateTime	TradSes OpenTime	Date and Time Market Segment next opens (or when current or last session Opened)
Session Close Time	DateTime	TradSes CloseTime	Date and Time current Market Segment next Closes (or when last session Closed)
Venue Type	String	VenuTyp	Description of Venue used to match and execute trades.	See Table 13‑1, below.
Residue Disposition	String	RESIDUE (Optional)	How is Residue processed. Allowable values are CANCEL / CONVERT / TRANSFER	Residue is the unfulfilled Tenders on the books when the Segment or Instrument closes. While Resource markets are typically continuously open, Individual Instruments close. i.e., 11:00 AM power closes at 11:00 AM.
Successor Segment	String	SUCCESSOR (Optional)	The Successor is the Segment ID of the Market Successor that is the follow-on after the closing of this Segment.	If Residue is “TRANSFERred” then this is the segment it is transferred to.
Maximum	Integer	MaxTradeVol	The maximum order quantity (as round lots) that can be submitted.
Execution Instructions	String		A list of FIX Execution Instructions that are accepted in this Segment (see Table 5‑4),
Stream Trading	Integer	MLegOK[12] (Optional)	Applies to both Tenders and Quotes	0 – Prohibited (default if missing) 1 – Permitted 2 - Required
Negotiations Permitted		(Optional except Mandatory for Venue Type “Q”)	Segment supports Negotiation	0 – Prohibited (default if missing) 1 – Permitted 2 – Private Quotes Only 3 – Advertised Quotes Only
Private Negotiations through Market	Integer	(Optional. Prohibited if missing)	Private Quotes are sent to the Segment which then forwards them to Counterparties	0 – Prohibited – Private Quotes not forwarded by Segment 1 – Permitted – Segment forwards Private Quotes to listed CounterParties
Market Segment ID	Int	MarketSegmentID (1300)	Identifies the Segment processing the Tender, Transaction, or Quote	This should be a unique combination paired with the Market Order ID
Market Instrument Summary	String	(Optional)	If blank or absent, no Market Instrument Summary is available
Max Summary Instruments	Int		0 – U Unlimited Instruments 1-N – Maximum Instruments in a Subscription
Top of Book Depth	Int		0 – Unlimited 1-N – Up to N levels of Book can be requested
Ticker Advertisement	Int		Advertisement is publication of Tenders and Advertised Quotes as they are entered into the Book	0 – Unavailable 1 – Available for this segment
Ticker Announcement	Int		Announcement of Transactions, that is, Matched Tenders and completed Negotiations in this Segment.	0 – Unavailable 1 – Available for this segment
The fields below are as defined in the Tender, Table 5‑2
Duration	Duration	Not in FIX	Duration of delivery.	Part of all Instruments
Price Scale	Int	Not Defined in FIX	A multiplier for the Price	A Market Segment may be denominated in, for example dollars or 10ths of a cent.
Quantity Scale	Int		A scale factor on the Resource unit for this Market	For example, “mega” vs “kilo” vs “femto-”
Resource Designator	Resource Designator Enumeration	FIX Instrument component	Identifier of the Resource being offered (Optional in many markets)	While a Market only accepts Tenders and Quotes for a single Resource, the complete description is required to ensure validity and for off-market interactions.
Warrant Ref	Int	Not in Fix	Reference to Warrants as defined in the Market	If used, see comments Warrants in Tenders, Section 5.3.3.

Bindings

Payloads and interaction patterns are described in [UML] in Sections 6 through 12 above. This section contains bindings for the payloads in three encoding schemes:

· JSON [JSON]

· XML Schema [XSD]

· FIX Simple Binary Encoding [SBE]

13.4 JSON

PENDING—JSON Schema awaiting stable payload definitions

13.5 XML Schema

PENDING—XML Schema awaiting stable payload definitions

13.5.1 XML Namespaces

PENDING—XML Namespaces awaiting XML Schema

13.6 Simple Binary Encoding

TODO—SBE Schema awaiting stable payload definitions.

14 Conformance

14.1 Introduction to Conformance

By design, CTS is a simplified and restricted subset profile of TeMIX. See Appendix

Portions of CTS conform to, and use updated and simplified versions of the specifications consumed by EI, specifically:

· OASIS WS-Calendar [WS-Calendar]

· A definition of Streams contained in [EI]

We normatively reference and apply the evolution of these specifications, in particular:

· OASIS WS-Calendar Schedule Streams and signals [Streams], simplified as CTS Streams.

· The WS-Calendar [CAL-MIN] Interval is used directly (as IntervalType).

This specification simplifies WS-Calendar Schedule Streams and Signals [Streams] as CTS Streams (see Section 3.2) and refactors the TEMIX profile of [EI].

Conformance of the CTS evolved specification can be shown with the techniques of [IEC62746-10-3] is described in informative Appendix D.

14.2 Claiming Conformance to Common Transactive Services

Implementations claim conformance to Common Transactive Services 1.0 by asserting conformance statements on the numbered items below.

1. The conformance statement MUST list all Facets which it supports in full or and in part.

2. The conformance statement MUST describe all extensions to payloads described in this specification.

3. The conformance statement MUST describe the Binding(s) which it supports along with any extensions. If the implementation does not use a standard binding as defined in Section 13, the conformance statement MUST define the binding used, at a similar level to detail to Section 13.

4. The conformance statement MUST describe how each payload definition conforms to the UML and/or profiled definitions for each payload unless it uses only standard Bindings in Section 13.

5. The conformance statement MUST indicate cardinality for message payload attributes where there is flexibility in this specification.

6. The conformance statement MUST describe any facets it defines to extend this specification.

14.3 Annex: Conformance statements from Spec not yet incorporated into this section

14.3.1 Conforming with Use of Warrants in Tenders

Appendix A. References

This appendix contains the normative and informative references that are used in this document. Normative references are specific (identified by date of publication and/or edition number or Version number) and Informative references may be either specific or non-specific.

While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.

A.1 Normative References

The following documents are referenced in such a way that some or all of their content constitutes requirements of this document.

NOTE: INSERT AS FORMATTED REFERENCES. Consider [EI]

[CAL-MIN]
WS-Calendar Minimal PIM-Conformant Schema Version 1.0. Edited by William Cox and Toby Considine. 26 August 2016. OASIS Committee Specification. http://docs.oasis-open.org/ws-calendar/ws-calendar-min/v1.0/ws-calendar-min-v1.0.html

[CAL-PIM]
OASIS WS-Calendar Platform-Independent Model version 1.0, Committee Specification 02 Edited by William T. Cox and Toby Considine, 21 August 2015. http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/cs02/ws-calendar-pim-v1.0-cs02.html Latest version: http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/ws-calendar-pim-v1.0.html

[EI]
Energy Interoperation Version 1.0. Edited by Toby Considine, 11 June 2014. OASIS Standard. http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html Latest version: http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html. and its TeMIX Profile

[EMIX] OASIS Energy Market Information Exchange (EMIX) Version 1.0 Committee Specification 02 Edited by Toby Considine, 11 January 2012. http://docs.oasis-open.org/emix/emix/v1.0/cs02/emix-v1.0-cs02.html Latest version: http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.html

[JSON]

JavaScript Object Notation and JSON Schema. https://cswr.github.io/JsonSchema/

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2246]
T. Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0, http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999.

[SBE]
Simple Binary Encoding Technical Specification 1.0. FIX Trading Community, June 16, 2016. https://www.fixtrading.org/standards/sbe/

[Streams]
Schedule Signals and Streams Version 1.0. Edited by Toby Considine and William T. Cox. 18 September 2016. OASIS Committee Specification. http://docs.oasis-open.org/ws-calendar/streams/v1.0/streams-v1.0.html.

A.2 Informative References

The following referenced documents are not required for the application of this document but may assist the reader with regard to a particular subject area.

[Actor Model]
C. Hewitt, "Actor Model of Computation: Scalable Robust Information Systems," arxiv.org, 2010.

[Fractal Microgrids]
Art Villanueva et al, Camp Pendleton Fractal Microgrid Demonstration, California Energy Commission Report CEC-500-2016-013,j available at http://400.sydneyplus.com/CaliforniaEnergy_SydneyEnterprise/Download.aspx?template=Books&field=PublicURL&record=57483797-a40e-49e7-b675-2858a3ad0d91&showSave=False&repeat=d4e63b56-27d1-4476-9300-7ede86a533ca

[Framework]
National Institute of Standards and Technology, NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, January 2010, http://nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf

[CTS2016]
W.T. Cox, E. Cazalet, E., A Krstulovic, W Miller, & W.Wijbrandi Common Transactive Services. TESC 2016. Available at http://coxsoftwarearchitects.com/Resources/TransactiveSystemsConf2016/Common%20Transactive%20Services%20Paper%2020160516.pdf

[EML-CTS]
Energy Mashup Lab Common Transactive Services (open-source software) https://github.com/EnergyMashupLab/eml-cts)

[FSGIM]
Facility smart grid information model. ISO 17800. https://www.iso.org/standard/71547.html 2017

[iCalendar]
B. Desruisseaux, Internet Calendaring and Scheduling Core Object Specification (iCalendar), https://tools.ietf.org/html/rfc5545. 2009,
See also
C. Daboo & M. Douglas. Calendar Availability, https://tools.ietf.org/html/rfc7953, 2016

[GridFaultResilience]
W.T. Cox & T. Considine. Grid Fault Recovery and Resilience: Applying Structured Energy and Microgrids. IEEE Innovative Smart Grid Technologies 2014. Available at http://coxsoftwarearchitects.com/Resources/ISGT_2014/ISGT2014_GridFaultRecoveryResilienceStructuredMicrogrids_Paper.pdf

[IEC62746-10-3] International Standard. Systems interface between customer energy management system and the power management system - Part 10-3: Open automated demand response - Adapting smart grid user interfaces to the IEC common information model, https://webstore.iec.ch/publication/59771 2018.

[Micromarkets]
W.T. Cox & T. Considine, Energy, Micromarkets, and Microgrids.
GridInterop 2011, https://www.gridwiseac.org/pdfs/forum_papers11/cox_considine_paper_gi11.pdf

[RFC3552]
E Rescorla & B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[SmartGridBusiness]
T. Considine & W.T. Cox, Smart Loads and Smart Grids—Creating the Smart Grid Business Case. Grid-Interop 2009. Available at http://coxsoftwarearchitects.com/Resources/Grid-Interop2009/Smart%20Loads%20and%20Smart%20Grids.pdf

[StructuredEnergy]
Structured Energy: Microgrids and Autonomous Transactive Operation, http://coxsoftwarearchitects.com/Resources/ISGT_2013/ISGT-Cox_StructuredEnergyPaper518.pdf. Innovative Smart Grid Technologies 2013 (IEEE).

[TPB-EI] Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0. 01 October 2012. OASIS Committee Specification 01.
.

[TeMIX] TeMIX Transactive Energy Market Information Exchange [TeMIX] an approved Note of the EMIX TC. Ed Cazalet et al., 23 May 2010. http://www.oasis-open.org/committees/download.php/37954/TeMIX-20100523.pdf

[TransactiveMicrogrids]
Jennifer M. Worrall, Edward G. Cazalet, PhD, William T. Cox, PhD, Narayanan Rajagopal, Thomas
R. Nudell, PhD, and Paul D. Heitman, Energy Management in Microgrid Systems,TESC 2016. Available at http://coxsoftwarearchitects.com/Resources/TransactiveSystemsConf2016/tes2016_microgrids_paper_Final.pdf

[TRM] (Transactive Resource Management)
B. Huberman and S. H. Clearwater, Thermal markets for controlling building environments, Energy Engineering, vol. 91, no. 3, pp. 26- 56, January 1994.

[UML]
Object Management Group, Unified Modeling Language (UML), V2.4.1, August 2011. http://www.omg.org/spec/UML/2.4.1/

[XSD]
W3C XML Schema Definition Language (XSD) 1.1. Part 1: Structures, S Gao, C. M. Sperberg-McQueen, H Thompson, N Mendelsohn, D Beech, M Maloney http://www.w3.org/TR/xmlschema11-1/, April 2012, Part 2: Datatypes, D Peterson, S Gao, A Malhotra, C. M. Sperberg-McQueen, H Thompson, P Biron, http://www.w3.org/TR/xmlschema11-2/ April 2012

[ZeroTrust]
Zero Trust Architecture, S Rose, O Borcher, S Mitchell, S Connelly. NIST Special Publication 800-207, https://doi.org/10.6028/NIST.SP.800-20 August 2020

Appendix B. Security and Privacy Considerations

This specification defines message payloads only. Security must be composed in. Privacy considerations must be decided when implementing specific systems for specific purposes.

B.1 CTS and Security Considerations

Procuring energy for local use and selling energy for remote use are each at the cusp of finance and operations.

· A price that is falsely low may cause the buyer to operate a system when there is inadequate power, potentially harming systems within a facility, or harming other facilities on the same circuit.

· A price that is falsely low may cause the seller to leave the market.

· A price that is falsely high may cause the buyer to shut down operation of systems or equipment.

· A price that is falsely high may cause the seller to increase operations when there is neither a ready consumer nor perhaps even grid capacity to take delivery.

For these reasons, it is important that each system guard the integrity of each message, assure the identities of the sender and of the receiver, and prove whether a message was received or not.

Messages should be encrypted to prevent eavesdropping. Any node should be able to detect replay, message insertion, deletion, and modification. A system must guard against and detect man-in-the-middle” attacks wherein an intermediary node passes of messages as originating from a known and trusted source.

The Technical Committee generally recommends that production implementations use Zero-Trust security [ZeroTrust], especially because of the wide distribution and potentially diverse ownership of TRM Actors. Zero Trust security requires authentication and authorization of every device, person, and application. The best practice is to encrypt all messages, even those between the separate components of an application within the cloud.

This specification makes no attempt to describe methods or technologies to enable Zero Trust interactions between Actors.

B.2 CTS and Privacy Considerations

The United Nations has defined privacy as “the presumption that individuals should have an area of autonomous development, interaction and liberty, a ‘private sphere’ with or without interaction with others, free from state intervention and excessive unsolicited intervention by other uninvited individuals. The right to privacy is also the ability of individuals to determine who holds information about them and how that information is used” (UN General Assembly 2013:15).

Electrical usage data inherently creates a privacy risk. Published work has demonstrated that simple usage data can be used to reveal the inner operations and decisions in a home. Other research has demonstrated that anonymous electrical usage data can be “de-anonymized” to identify an individual electricity user. The more fine-grained the data, the more intimate the details that can be garnered from meter telemetry.

In an amicus brief in a case on smart metering, the Electronic Freedom Foundation testified that that aggregate smart meter data collected from someone’s home in 15-minute intervals could be used to infer, for example, whether they tend to cook meals in the microwave or on the stove; whether they make breakfast; whether and how often they use exercise equipment, such as a treadmill; whether they have an in-home alarm system; when they typically take a shower; if they have a washer and dryer, and how often they use them; and whether they switch on the lights at odd hours, such as in the middle of the night. And these inferences, in turn, can permit intimate deductions about a person's lifestyle, including their occupation, health, religion, sexuality, and financial circumstances. These privacy concerns are linked to increased security risks criminals may be able to access the data and use the information to enable inferences about what people are doing in their home or if they are away from home.

This specification describes how to share communications beyond mere electrical usage telemetry. Communications reveal what the user would like to buy, how much they would be willing to spend, and future intents and plans.

System developers using this specification should consider legal requirements under the Fair Practice Principles and the European Union's General Data Protection Regulation. These include:

1) The Collection Limitation Principle. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

2) The Data Quality Principle. Personal data should be relevant to the purposes for which they are to be used and, to the extent necessary for those purposes, should be accurate, complete and kept up to date.

3) The Purpose Specification Principle. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

4) The Use Limitation Principle. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified, except a) with the consent of the data subject, or b) by the authority of law.

5) The Security Safeguards Principle. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.

6) The Openness Principle. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data and the main purposes of their use, as well as the identity and usual residence of the data controller.

7) The Individual Participation Principle. An individual should have the right:

to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him.

to have data relating to him communicated to him, within a reasonable time, at a charge, if any, that is not excessive; in a reasonable manner, and in a form that is readily intelligible to him.

to be given reasons if a request made under subparagraphs (a) and (b) is denied and to be able to challenge such denial; and

to challenge data relating to him and, if the challenge is successful, to have the data erased, rectified, completed or amended.

8) The Accountability Principle. A data controller should be accountable for complying with measures which give effect to the principles stated above.

In developing this specification, the Technical Committee has kept in mind the need to support a developer wishing to support privacy. Actors representing an up-stream electrical serving entity, say a distribution system operator or traditional utility, use the tame messages as anyone else—no actor is inherently privileged. Messages to provide market information or “tickertape” functions do not include Party IDs. General advertising of Tenders, while necessary to draw matching Tenders quickly to market, may be anonymous.

In some messages and some markets, it is necessary to use a proxy ID to protect privacy or to simply conveyance of a transaction from a complex matching mechanism. To protect privacy, a market may transmit such a proxy ID in place of a Party Id in Quotes, Tenders, Transactions, and Tickers. Markets that use cumulative matching algorithms such as double auction cannot identify a specific Counter Party to a transaction.

The system developer should keep the privacy principals in mind when making specific technology choices. For example, messages between an actor and the market MAY be encrypted to protect the privacy of people represented by individual actors. While the transactive energy market must know both buyers and sellers to support transactions and settlements, the developer should take steps to guard that information. A developer may opt that each notice of contract sent to an actor always has a counterparty of the market, so as to protect the sources and uses of electricity.

It is beyond the scope of this specification to specify security practices and privacy design for markets built using this specification.

Appendix C. Semantic Composition from Energy Interoperation, EMIX, and WS-Calendar

The semantics and interactions of CTS are selected from and derived from [EI].

EI references two other standards, [EMIX] and [WS-Calendar], and uses an earlier Streams definition. We adapt, update, and simplify the use of the referenced standards, while maintaining conformance.

• EMIX describes price and product for electricity markets.

• WS-Calendar communicates schedules and sequences of operations. CTS uses the [Streams] optimization, which is a standalone specification, rather than part of EI 1.0.

• EI uses the vocabulary and information models defined by those specifications to describe the services that it provides. The payload for each EI service references a product defined using [EMIX]. EMIX schedules and sequences are defined using [WS-Calendar]. Any additional schedule-related information required by [EI] is expressed using [WS-Calendar].

• Since [EI] was published, a semantically equivalent but simpler [Streams] specification was developed in the OASIS WS-Calendar Technical Committee. CTS uses that simpler [Streams] specification.

All terms used in this specification are as defined in their respective specifications.

In [EI], the fundamental resource definition was the [EMIX] Item, composed of: a resource name, a unit of measure, a scale factor, and a quantity. For example, a specific EMIX Item may define a Market denominated in 25 MWh bids. [EI] defined how to buy and sell items during specific intervals defined by a duration and a start time. The Quotes, Tenders, and Transactions that are the subject of [EI] added specific prices and quantities to the item and interval. EMIX optionally included a location, i.e., a point of delivery for each [EI] service.

In CTS, we group and name these elements as a Resource, Product, and Instrument. These terms are defined in Section 2.2.4, “Markets and Venues”

14.3.2 Conformance with Energy Interoperation

EI defines an end-to-end interaction model for transactive services and for demand response. CTS uses the EI transactive services and draws definitions of parties and transactive interactions primarily from the [EI] TEMIX profile.

This specification can be viewed as a minimal transactive profile of [EI].

14.3.3 Conformance with EMIX

This specification uses a simplified profile of the models and artifacts defined in OASIS Energy Market Information Exchange [EMIX] to communicate Product definitions, quantities, and prices. EMIX provides a succinct way to indicate how prices, quantities, or both vary over time.

The EMIX Product definition is the Transactive Resource in CTS 1.0.

EMIX defines Market Context, a URI used as the identifier of the Market. EMIX further defines Standard Terms as retrievable information about the Market that an actor can use to configure itself for interoperation with a given Market. We extend and clarify those terms, provide an extension mechanism, and discuss the relationship of markets, market segments, and products.

14.3.4 Conformance with WS-Calendar Streams

WS-Calendar expresses events and sequences to support machine-to-machine (M2M) negotiation of schedules while being semantically compatible with human schedules as standardized in [iCalendar]. Schemas in [WS-Calendar] support messages that are nearly identical to those used in human schedules. We use a conformant but simpler and more abstract Platform Independent Model [CAL-PIM] and the [Streams] compact expression[13], to support telemetry (Delivery Facet) and series of Tenders while not extending the semantics of [Streams].[14]

WS-Calendar conveys domain specific information in a per-event payload within a schedule-centric message; in CTS, the domain is the price, product, and quantity. An essential concept of WS-Calendar is inheritance, by which a starting time can be applied to an existing message, or by which all events in a sequence share common information such as duration. Inheritance is used to “complete” a partial message during negotiation. CTS makes use of this to apply a common product across a sequence, or to convey a specific starting time to a market product.

14.3.5 CTS and WS-Calendar Streams

The [Streams] specification describes how to handle repeating time series of similar data, applying repeating information to a series of schedulable intervals, expressing common information once for the series, overriding the common information only if needed within a specific interval, and potentially scheduling (“binding”) the entire series by adding a starting date and time to one of the Intervals.

For CTS, this means that a Product is fully described in the header, and only the elements that vary, such as the Price or the Quantity, are expressed in the intervals.

CTS Streams use this same format even when the Intervals contain only a single Interval.

In addition, CTS Streams include energy-market elements that are outside the Streams standard but follow the pattern of referrals as defined in [Steams] conformance.

CTS Streams have neither interaction patterns nor payloads, as they are a common abstract information model used to define the messages used in Facet messages.

The CtsStream follows this pattern. The elements from [Streams] have been flattened into the CTS Stream, and the Stream Interval and payload flattened into a streamPayloadValue and the internal local UID for the stream element.

Created with Enterprise Architect (Build: 1526) 2

Figure C‑14‑1: CtsStreamDefinition

As with [Streams], CtsStreamIntervals are ordered, that is the sequence of intervals is essential. Some serialization specifications, notably XML, do not require that order be preserved when deserializing a list. The UID enables proper ordering of the Stream Intervals if order is not preserved. Since conformant CTS implementations need not be owned by the same implementer, and may pass through multiple translations, the UID property is required.

Appendix D. Conformance to the TEMIX Profile of Energy Interoperation

TBD

Appendix E. Glossary of Terms and Abbreviations Used in this document

Throughout this document, abbreviations are used to improve clarity and brevity, especially to reference specifications with long titles.

Table C‑‑14‑1 Abbreviations and Terms used throughout this document

Attribute	Meaning
CTS	Common Transactive Services
EI	Energy Interoperation, an OASIS specification as per the normative references, CTS is a conforming profile of EI.
EMIX	Energy Market Information Exchange, an OASIS specification used to describe Products and markets for resources, particularly those traded in power grids.

Appendix F. Acknowledgments

This work is derived from the specification Common Transactive Services 1.0 , contributed by The Energy Mashup Lab, written by William T. Cox and Toby Considine.

Portions of models and text is derived from The Energy Mashup Lab open-source project, EML-CTS and is used under terms of the Apache 2.0 License for that project.[15]

F.1 Participants

The following individuals were members of this Technical Committee during the creation of this document and their contributions are gratefully acknowledged:

Rolf Bienert, OpenADR Alliance
Toby Considine, University of North Carolina at Chapel Hill
William T. Cox, Individual Member
Pim van der Eijk, Sonnenglanz Consulting
David Holmberg, National Institute for Standards & Technology (NIST)
Elysa Jones, Individual
Chuck Thomas, Electric Power Research Institute (EPRI)

Appendix G. Revision History

Revision	Date	Editor	Changes Made
WD01	2/15/2021	Toby Considine	Initial reformatting and conversion of the specification contributed by The Energy Mashup Lab to create a document for committee work.
WD02	3/3/2021	Toby Considine	Added prose definitions of Resource, Product, and Instrument
WD03	4/5/2021	Toby Considine	Simplified introductory material, raised message type to earlier in document. Removed some repetitive material. Revised UML required.
WD04	5/7/2021	Toby Considine David Holmberg William T Cox	Reordered intro material to reduce repetition, Reference Actor Model more consistently, Revise and re-factor Resource/Product/Instrument Add Section 3 to elevate common semantic elements
WD05	5/25/2021	Toby Considine David Holmberg William T Cox	Continues clean-up and condensation of sections 1, 2
WD06	6/7/2021	Toby Considine	Refines Item language into Resource and Products. Explains Message Groups as a conforming descendant of EI Services.
WD07	6/21/2021	Toby Considine William T Cox	Clarified terminology and relationship to implied Service-Oriented Architecture. Structured CTS facets for clearer explanation
WD08	8/5/2021	Toby Considine William T Cox David Holmberg	Clarify and simplify actor facets descriptions, including Tender, Transaction, and Configuration. Reduce redundant and less relevant content.
WD09	9/14/2021	William T Cox Toby Considine David Holmberg	Added Facet descriptions for Position, Market Characteristics, CTS Streams, and drafts of Privacy Consideration, Delivery and Party Registration Facets. Numerous edits for clarity and conciseness.
WD10	10/4/2021	Toby Considine William T Cox David Holmberg	Extended Market Facets. Defined Position and Delivery facets. Made references more consistent. Updated UML model and diagrams.
WD11	10/22/2021	David Holmberg William T Cox Toby Considine	Corrections for clarity. Improved UML diagrams. Flagged requests for comments in Public Review
CSD01	10/29/2021	OASIS TC Administration	Content as in WD11, formatted to include OASIS metadata and references to the published specification
WD12	1/10/2022	William T Cox Toby Considine	Simpler edits in response to comments from PR
WD13		William T Cox Toby Considine	Clarification of Resource/Product/Instrument Removal of references to “Architecture” Responses to “Clarity” tagged issues
WD14	2/22/2022	William T Cox Toby Considine	Clarification of front material Section 1/-2 compared to eliminate duplicative definitions Numerous issues resolutions applied as per Jira
WD15	3/20/2020	William T Cox Toby Considine	Clarity, responses to issues from Review
WD16	4/12/2022	William T Cox Toby Considine	Marketplace and Market characteristics responses to issues Expanded Quotes and Tickers Focus on capitalization
WD17	4/25/2022	William T Cox Toby Considine	Updated UML Market Information added OTC Transactions Edits for Clarity
WD18	9/19/2023	Toby Considine	First response to FIX meetings Changed to Market/Market Segment language Reference FIX Tags when known Closings and Crossings added First pass at FIX-conformant Market Data Reports

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website: [https://www.oasis-open.org/policies-guidelines/ipr/].

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS AND ITS MEMBERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT OR ANY PART THEREOF.

As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specifications, OASIS Standards, or Approved Errata).

[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]

[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

The name "OASIS" is a trademark of OASIS, the owner and developer of this document, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, documents, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.

[1] SOA is occasionally mis-described as a client-server approach. In distinction, services are requested by an Actor, and fulfilled by another Actor. In SOA the services offered are key, and the actors take different roles in different interactions.

[2] In ISO and IEC standards, portions that are not normative are informative. OASIS uses the term non-normative.

[3] This pattern was developed and is used by IEC Technical Committee 57 (Power Systems).

[4] As an example of the Correlation Pattern for messages

[6] Certain serializations for payloads do not guarantee order, so a small integer serves as a unique identifier for each interval.

[7] This avoids a potential race condition in variable latency distributed systems.

[8] Some aspects of the market’s mechanism(s) are visible to actors who are trading, generally where the mechanism affects rational bidding strategies. For example, bidding very low in a double auction market is reasonable (as you get the clearing price), but bidding very low in an order book market is not (as you get something similar to what you offered). See Section 13.1.1, “Venue Types”.

[9] One edge case is that of a Tradable Quote—in some sense a tradable quote might be considered a Tender, and in another sense considered an Indication. CTS adopts the second approach, but a

[10] A power distribution entity may experience disruption if there is a big price change on the hour. For example, a distribution system operator (DSO) that operates multiple CTS Markets could opt to set a different offset on each Market Segment operated out of a given substation. In this model, a Market could use an offset duration of 3 minutes to indicate that all tenders are based on three minutes after the hour.

[11] Integer operations are typically much more efficient than fixed or floating point, so it is likely to be much faster to apply decimal shift on input and output rather than for more frequent comparison operations in the Execution Engine implementation.

[12] Fix refers to a trade of multiple instruments together as a Multi-Legged Trade

[13] Simplified as CTS Streams in this specification.

[14] Some specifications (e.g. [FSGIM]) have extended the basic [Streams] capabilities, but this brings additional complexity which does not benefit our use cases.

[15] https://github.com/EnergyMashupLab/eml-cts