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.
See Section 2.3. Th
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].
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,
<element name="componentType"
type="ei:ComponentType"/>
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,
<complexType name="ComponentServiceType">
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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].
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.
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.
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.
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.
Financial Markets trade financial instruments. CTS borrows
this language from FIX. See Section 3, Market Semantics: Resource, Product,
Instrument, for a discussion.
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.
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.
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.
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.
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.
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.
Figure 2‑1 UML Class Diagram of EiResponseType
and MarketAttributeViolationType
Table 2‑3 ID UML Class Diagram of ID Types in CTS
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.
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. 
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.
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.
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.
A UML model for the Instrument showing all inheritance is in
Figure 3‑4 below:
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).
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.
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
|
|
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.
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.
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.
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.
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.
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.
Figure
5‑1: UML Sequence Diagram 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.
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.
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.
|
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.
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.
|
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.
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)
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.
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.
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.
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
|
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.
A Transaction is created by a Market or Segment (See Section
13) based on some mechanism internal to the Market.
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
|
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.
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.
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
|
The [UML] class diagram in Figure 6‑3 describes
the payloads for the EiTransaction facet operations.
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
Figure 6‑4:
UML Diagram comparing Tender and Transaction Facet Payloads
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”.
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.
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:
Figure
7‑1: UML Sequence Diagram 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)
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.
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.
Figure 8‑1: UML Sequence Diagram 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.
The [UML] class diagram describes the payloads for
the Delivery facet.
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.
|
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”).
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.
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.
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.
|
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.
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.
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.
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
|
|
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.
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
|
Figure 9‑5 shows UML
Class Diagrams for the Negotiation Facet Payloads.
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.
|
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.
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.
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.
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.
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.
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.
|
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.
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
|
Figure 11‑2:
UML Sequence Diagram for the Ticker Facet
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.
Figure 11‑3 Ticker Manage Subscription Payloads
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.
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.
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.
|
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.
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.
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.
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
|
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.
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.
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)
|
|
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.
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.
|
|
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.
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.
|
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.
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.
|
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.
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.
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.
|
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
(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.
|
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]
PENDING—JSON Schema awaiting stable payload definitions
PENDING—XML Schema awaiting stable payload definitions
PENDING—XML Namespaces awaiting XML Schema
TODO—SBE Schema awaiting stable payload definitions.
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.
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.
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.
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
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.
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”
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.
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].
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.
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,
to support telemetry (Delivery Facet) and series of Tenders while not extending
the semantics of [Streams].
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.
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.
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.
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.
|
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.
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)
|
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
|
Copyright © OASIS Open 2024. All Rights Reserved.
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.
