Page tree
Skip to end of metadata
Go to start of metadata

 

I. Use Case Description

Use Case Name

Index analysis for ETF development

Use Case Identifier

IND-EFT-DEV

Source

IND Content Team

Point of Contact

Creation / Revision Date

7/19/2019

Associated Documents

Requirements documentation, traceability matrix if applicable



II. Use Case Summary

Goal

Enable development of a new fund whose performance can be compared to a benchmark 

Requirements

State any requirement(s)specific to this use case, including any capabilities from a business architecture or process model that the use case supports, any metrics or other reporting requirements, etc., including any reference identifier for the requirement(s), as applicable

Scope

Coverage is limited to equity indices rather than indices that include bond, credit, or commodities indices or economic indicators for this use case.

Priority

This is the highest priority use case for the IND Team for Q3-Q4 2019 and Q1 2020.

Stakeholders

Traders who will be trading the fund based on the index, Compliance/Risk (for managing risk related to the fund), Clearing and Settlement Team (for trades related to the fund), Finance Team (for managing the fund flows if there are trades happening), Index Administrator, external stakeholders such as market data providers

Description

A business analyst/front-office salesperson is interested in selecting one or more equity indices as the basis for predicting/comparing the performance of a new exchange-traded fund (ETF).  This may require understanding the make-up of a benchmark based on a balance of small, medium, and large cap organizations, overall performance during some prior period, based on a mix of national and international instruments, based on avoiding being overly exposed to a single sector, company, or country, etc. in order to meet the performance goals of the fund, however the goal of this use case is for limited comparison.  In other words, we will not necessarily create a number of sector classification schemes for this use case.  In general, the goal is either for the fund to track the index or for its performance to exceed that of the index.

This means being able to describe 10- 15 benchmarks that are commonly used, without detailed sector classification, but sufficient to distinguish one major index from another.  This initial use case involves limiting the scope to equities only.  We will create a subsequent use case to cover bond/debt indicies.  We will only use content that is published about each of the indexes, and avoid assumptions about classification schemes (at least, in depth classification) for the purposes of this use case.

Indices under consideration include: 

  • Standard & Poor’s Composite Index of 500 Stocks (S&P 500)
  • The Nasdaq Composite Index
  • Morgan Stanley Capital International’s (MSCI) Europe, Australasia, Far East (EAFE) Index
  • Value Line Composite Index (stocks)
  • Russell 2000 Index (small-cap stocks)
  • Dow Jones World Stock Market Index (major international markets, including the U.S. market)
  • Wilshire 5000: U.S. Broad Market

The goal of this use case is to provide references to the definitive source for the details of how any of these indices is composed at some point in time, not to provide reference data for these indices and maintain it.  Any individuals developed that provide example reference data will necessarily represent it as a snapshot for examples only, with no intent to maintain that information going forward.

Actors / Interfaces

People:  Business Analyst developing the fund, Index Administrator (entity that manages the index), Issuer of the constituents of the index (maybe)

Systems:

  1. Requirements development tooling (DB uses JAMA) - used to define the requirements for the fund
  2.  System where the index data is mastered, may or may not be the same system where the underlying constituent data (for the equities that make up the index) is mastered

There may be another actor that represents the fund, or another system that needs to access information about the index, in addition to the above.

Assumptions

The business analyst has a template for defining the contents of the fund provided by their organization that allows them to vary the index based on desired goals. For every index, information about the stocks that participate in the index must be provided (i.e., the list of stocks).  If there are derivatives based on the benchmark, then links to those derivatives must be provided (all done by the reference data team).

Open Issues

 

III. Usage Scenarios

There are a number of usage scenarios that this use case represents.  Common scenarios that institutions perform on a daily basis include:  

  1. Get the value of an Index at any point in time. Optionally the user can seek details of the constituents' contribution to the movement of index value from a particular point in time (e.g. previous day's close) - JIRA Issue IND-86
  2. As a user of the Index service, I need to be able to get all the details of the constituents of the Index including the weighting of constituents and other details - JIRA Issue IND-85, IND-81
  3. Index constituents are changed as conditions require. Whenever this is done there may be a need to "rebalance" the index so that the change in the fundamentals of the constituents does not cause an abrupt discontinuity in the index - JIRA Issue IND-83
  4. There are certain corporate actions of the Index constituents (like stock splits and stock dividends) that require changes to be done to the Index data maintained. Other examples are share issuance and these require adjustments to prevent the value of index from changing. - JIRA Issue IND-84


IV. Competency Questions

  1. What is the value of this index on a certain date?  What are the prices for the constituents of this index as of this date and how are they weighted?
  2. What are the constituents of this index as of a given date?
  3. What indices have a given equity as a constituent as of a given date?

V. Resources

 

Knowledge Bases, Repositories, or other Data Sources

Data

Type

Characteristics

Description

Owner

Source

Access Policies & Usage

(dataset or repository name)

(remote, local/in situ, etc.)

e.g. – no cloud cover

Short description of the dataset, possibly including rationale of the usage characteristics

 

Source (possibly a system, or remote site) for discovery and access

 

 

 

 

 

 

 

 

 

 

VI. References and Bibliography

 

List all reference documents – policy documents, regulations, standards, de-facto standards, glossaries, dictionaries and thesauri, taxonomies, and any other reference materials considered relevant to the use case

 

 

VII. Notes

 

There is always some piece of information that is required that has no other place to go. This is the place for that information.