Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

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 credit indices or economic indicators for this use case.

Priority

Identify the priority of the use case (with respect to other use cases for the project)

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

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).


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.

 

Pre-conditions

N/A

Post-conditions

N/A

Triggers

Index creation, corporate action such as an M&A action that causes the constituent of the index to cease to exist

Performance Requirements

N/A

Assumptions

 

Open Issues

 

III. Usage Scenarios

 Provide at least two usage scenarios that flesh out the requirements outlined in the summary, including identification of requirements specific to any envisioned ontology or semantically-driven service or application.  Scenarios should be described as narrative, with supporting diagrams as appropriate.  In an Agile process, every user story relevant to the use case should be included and elaborated/rolled up into one or more usage scenarios, with a clear mapping from the user story to the scenario it is integrated in or mapped to.Use cases proposed by Ashwin via JIRA include the following, which we will flesh out into more complete scenarios:

  1. Get the value of 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)
  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 weightage and other details
  3. To ensure stability of the index, the index constituents are changed at regular interval. Whenever this is done there is a need to "rebalance" the index so that the change in constituents does not change index level abruptly
  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.


 

IV. Basic Flow of Events

...