Enterprise
License Project
August 1, 1997
Project Status
The FISD User Committee drafted a working paper (July 9, 1997) outlining user
requirements, objectives and priorities related to the use of enterprise licenses
as the basis for an open discussion among the financial information industry.
That paper was distributed to FISD members and provided the foundation for a meeting
(July 23, 1997) among North American exchanges and user firms. The purpose of
that meeting was to allow the User Committee to present their basic concepts to
the exchange community.
The FISD Exchange
Committee is meeting via conference call on August 13 to organize their thoughts
and reactions to the User Committee document. A second meeting between exchanges
and user firms is planned for the first week in September. The main points discussed
during the July 23 meeting are outlined below:
Benefits
of an Enterprise License
From the
user perspective, the key potential benefits of an enterprise license relate to
increased flexibility in the use of data, reduction in the administrative burden
associated with tracking and reporting market data entitlements, and alternatives
to reconciling uncoordinated billing variances with vendors/exchanges on a monthly
basis. In addition, an annual enterprise license would enable subscribers to benefit
from being able to budget and determine internal cost allocation configurations
for the year in advance. User control of entitlements and permissioning would
also allow for better internal inventory management and enable firms to save time
(i.e. instant access to data and flexibility over moves) and money (i.e.
service charges associated with entitling a new user) associated with order
processing.
From the exchange perspective,
the key benefits relate to the ability to more accurately forecast revenue on
an annual basis and a reduction in the administrative costs associated with managing
the add/change/delete process on a monthly basis. In addition, an enterprise license
arrangement would reduce the need for exchanges to become intimately involved
in understanding how each firm manages cost allocation and internal charge backs.
Unit of Count/Basic Model
User firms
suggested that a number of models were possible and indicated that exchanges might
choose from among the following range of possible options and allow the firms
to select the model(s) that best meet their requirements:
- Transaction Based -- enterprise
models based on trading volume with a specific exchange were discussed briefly
but generated little interest by either users or exchanges.
- Applications
Based -- an applications license based on types of usage was conceptually
appealing to firms in that it would allow for wider dissemination and more flexibility
over usage. Users and exchanges believe that such a model would be difficult and
costly to administer.
- Functional
Based -- the concept of a license based on type of data -- real time continuous
access, real time snapshot access, and everything else -- was mentioned but not
discussed.
- People Based
-- accounting metrics based on Registered Reps (RR) were discussed at length.
Users felt that a RR based approach was a potentially valid model although they
argued that only revenue producing RR's should be counted in the formula. They
note that many people within their firm hold a Series 7 license even though they
don't use market data. The users also note that the concept of registered reps
does not translate well on a global basis and does not match the structure of
some types of firms (e.g. Lehman or Goldman Sachs).
Exchanges
participating in the discussion had varying perspectives on the validity of using
only "production registered reps" as the basis of an enterprise license.
Some exchanges believe that market data has value to all people using it within
the firm (e.g. back office), not just to those engaged in revenue producing
activities. Other exchanges were open to an enterprise model based on production
RR's -- providing firms flexibility to use the data anywhere in the firm -- as
long as it results in revenue neutrality for the exchange.
- Terminal/User
ID Based -- of all the potential enterprise models discussed, the user
firms participating in the discussion prefer one based on the number of terminals/user
ID's that have access to data from a specific exchange. Firms maintain that their
internal charge back procedures are based on terminal/user ID and that firms with
technical control systems in place can identify terminal level usage as the starting
point for an enterprise model discussion.
Unit
of Count Definition
User firms
would like all exchanges to adopt consistent terminology for configuring the basic
unit of count for an enterprise license. Users noted that while precise terminology
is critical, the definition of the unit is not as simple as "keystation"
or "workstation" or "user ID" -- and will depend on the configuration
of the specific applications environment. For example, users suggested that all
these examples should be counted as one unit: three keyboards in front of one
person; multiple services accessed on multiple terminals connected by one keyboard;
and one workstation in front of two people.
Global
Enterprise License
User firms participating
in the meeting maintain that most large, full service, user firms operate global
distribution networks and seek an enterprise license that would cover distribution
to all business centers on a global basis. Those firms suggested that the definition
of "the firm" include business centers, divisions, operating groups,
and entities with ownership by the parent organization of 50% or greater.
Counting is Required
Exchanges participating in the discussion were clear in their requirement that
an enterprise license must be based on some "consistent, objectively determinable,
auditable" metric that can be counted and applied on an equal/non-discriminatory
basis within the industry.
Users supported
that requirement and reinforced their perspective that an enterprise license does
not mean no counting. They maintain that even with a global enterprise license,
they will continue to maintain an accurate desk level accounting of usage to meet
their internal cost allocation/charge back/cost containment requirements. Firms
also pointed out that precise entitlement control is essential in order to determine
the basis of an enterprise license and for re-negotiation of the license in subsequent
years.
From all perspectives, the issue
is not whether you count, but rather what is counted, the auditability of the
metric, and the basis for determining whether a firm is in compliance with its
contractual obligations.
Capable of
Accessing
In addition to the need
to agree on the unit of count (strong preference for terminal/user ID),
the key issue relates to the determination of the basis of an enterprise license.
It was pointed out during the meeting that the underlying metric being proposed
relates to access capabilities (i.e. the number of people that are connected
to the server and technically able to access the data).
The
challenge for the industry relates to the method of reconciliation between the
potential "universe of access capabilities" and the "number of
licenses" contracted for by the firm. (i.e. the universe of accesses might
be 20,000, while the firm only wants a license for 10,000). The principal
questions therefore are -- how does the firm determine the number of licenses
and how do data suppliers determine whether the firm is in compliance?
According to the users, the starting point for
determining the number of terminals/user ID's covered in the license would be
based on what the firm is currently contracting from the exchange, verified by
existing configuration reports. Users note that the total user base would include
datafeed subscribers as well as users of vendor controlled terminals. Users reinforced
the point that they would still count positions, still charge back on a desk unit
basis, and then use those reports as the basis for renewal negotiations. They
also suggested that many firms would likely purchase "blocks of units"
over and above the number of current users -- for the flexibility necessary to
use the data throughout the year. (i.e. user has 1,500 users and might want
to buy 2,000 licenses to have the flexibility for the year and avoid the service
initiation and billing processing charges).
Contention
Access
One of the more significant
issues relates to the concept of contention access. Users would like the ability
to share passwords and pay for information based on the number of simultaneous
accesses (i.e. users suggest that 500 investment bankers sharing 40 simultaneous
user ID's should be counted as 40 licenses).
Exchanges
maintain that with today's technology, those 500 users can share 40 passwords
on a virtual real-time basis without any degradation of service. They maintain
that existing technology makes contention access transparent to the user. Exchanges
maintain that this scenario becomes important in negotiations about the number
of terminals included and counted in an enterprise agreement. They further maintain
that while users might not have the technology currently in place within their
firm, exchanges are making long-term policy decisions which need to stand up to
technological reality.
The Issue of
Technical Control
Users participating
in the discussion agreed that verification of compliance with the terms of an
enterprise license would require that both technical systems and administrative
control procedures are in place. They maintain that the larger firms, with global
distribution networks, would be among those most likely to qualify for enterprise
license agreements and suggested that most have technical controls in place.
The user firms also suggested that the determination
of qualification could be facilitated by having the audit staff of the exchange
"certify or otherwise approve" their entitlement systems and control
procedures. Those that meet the criteria of an exchange would qualify, those that
don't meet the criteria wouldn't.
Relationship
Driven Process
There was general
agreement during the discussion that the implementation of an enterprise license
would require a thorough and clear understanding of how each firm is using the
data, the type of flexibility desired, how they deal with contention access, evaluation
of the control environment, and a careful comparison of records. Exchanges and
users agreed that it would be unlikely that there would be a single blanket agreement
covering all eligible firms.
Ability
to Opt Out
There was consensus during
the discussion that an enterprise license must provide the ability for both exchanges
and users to opt out, revert to other models, or re-negotiate in the advent of
a significant reduction-in-force, acquisition, merger, or other dramatic business
adjustment.
Consistency is Important
Users emphasized during the discussion the importance of consistency among exchanges
for achieving administrative savings with an enterprise licenses arrangement.
Users are concerned about the viability of changing internal procedures and administrative
processes in response to multiple enterprise models. Users also noted that there
is currently inconsistency among the exchanges which firms are dealing with and
that any progress along these lines would be welcome.
Billing
Cycles
Users pointed out during the
discussion that conversion to an annual payment cycle could result in immediate
administrative savings. Exchanges agreed (in principle) that if the two
sides could agree on an annual billing amount -- it would be possible to divide
that number into twelve payments with an adjustment clause for significant business
changes. At a minimum, both user firms and exchanges could benefit from the ability
to budget for market data on an annual, rather than on an (unpredictable)
monthly, basis.
Phased Implementation
Both exchanges and user firms recognized the potential value of implementing an
enterprise license in stages. An enterprise agreement covering only digital feed/trading
room environments (for example), would allow the industry time to evaluate
how to best deal with the issues of contention access and vendor controlled terminals.
Enterprise Licenses for Web Distribution
Firms would like to see an enterprise license developed to cover external dissemination
of market data to their client base via the Internet, based on the maximum number
of simultaneous users. They maintain they are able to track and permission market
data distributed via the Web and want to enable both internal subscribers and
customers to dial in and get information regardless of location.
According
to the discussion, more and more firms will be looking to offer full service,
integrated products (i.e. information, transactions, trade confirmation, and
portfolio management) to their customers which will require the provision
of real time market data. In addition, firms maintain that it would be unlikely
that they would be able to pass quotation charges on to their customers. As a
result, they are looking to limit their potential liability (i.e. no way to
predict the number of hits or to predict the relationship between the request
for quotes and commissionable trades) associated with new service offerings.
The users suggested that one way to limit exposure
would be to implement a pricing model based either on the number of potential
simultaneous users (i.e. contention access) or on the maximum number of
customers.
Multiple Access Fees
User firms would like to pursue the elimination of multiple access fees and double
billing. They maintain that (for example) one user could be running multiple
applications with CBOT data delivered by multiple vendors -- which results in
a multiple access fee for that user. They suggest the establishment of a direct
billing/reporting relationship as the most efficient way of achieving that objective.
Users acknowledge that this is not an enterprise
license issue. They brought up the subject in light of the fact that an enterprise
license pre-supposes a direct relationship with the exchange. Without a direct
billing and reporting relationship, one way to address the issue would be for
users to generate a report which identifies where duplications exist. And while
that would be possible, it would result in a significant and complex administrative
burden for both users and exchanges.
It
was also suggested that the creation of a common billing identifier -- identifying
a user-defined cost center and used by all vendors -- could also be an alternative
way of dealing with the multiple access fee issue.
