Trading  

  
 

In this section, we are going to look at the various patterns associated with buying and selling of goods with respect to changing market conditions.
 

Contract  

 
A contract represents the simplest financial deal, namely, buying some instrument from another party. This is modeled as follows:

 

The instrument can be stock, a commodity like oil, foreign exchange or any other traded item. The date refers to the delivery date of the instrument. The terms, long and short, are used for buy and sell, respectively. It might seem that one party is enough for modeling a contract, since the host party is implicit. But, in some deals done within an organization, there is a need to identify the internal party. Thus, we need to have two parties. The classification of the contract as long and short above is as seen by the primary party. Alternatively, the contract pattern could be modeled as:

 

Here, the parties are shown as buyer(long) and seller(short). Both the models are equivalent, and the choice depends on what operations are useful to provide, i.e., whether primaryparty and counterparty operations are required, or long and short party operations.
 

Portfolio      

Contracts are more useful, when considered collectively, especially in risk management. For instance, we might be talking about contracts dealt by a particular trader, the contracts in a particular instrument, etc.

A portfolio is a collection of contracts. Portfolios and contracts can be valued according to a scenario. A scenario is a representation of the state of the market, either real or hypothetical. We will see scenarios in more detail later. The value of a portfolio is essentially the sum of values of the underlying contracts.

Consider the following model of portfolio:

 

Here, every portfolio is given a Boolean method that takes a contract as argument and returns true or false. The portfolio, in effect, is the collection of all contracts for which the Boolean method returns true. This is a powerful notion because we can construct portfolios by any combination of properties of contracts. Though the best approach in the abstract, we usually do not need this generality. Portfolios are commonly formed from the properties of contracts like counterparty, primary party, instrument, etc. Thus, the following model is formed:
 

 

Here, the Contract Selector object is used to match the given contract argument and those that match, become part of the portfolio. Alternatively, we can abstract the interfaces of both the Boolean method and the contract selector into a single abstract type – the portfolio filter. This is depicted below:

 
 

 

The Portfolio Filter is an abstract class which can be specialized into one of several filters, two of which are as illustrated above. This allows us to use the contract filter for simple cases and the hard-coded filter for more complex situations.

 

Quote  

Anything traded on a financial market has a price. Usually, the price is not a single number. We quote two numbers; the price to buy (which is the bid) and the price to sell ( the offer ). Although two numbers are common, they are not always used. Sometimes, the quote is a single price, which represents the mid-value of the price. This price is quoted with a spread – the difference between the bid and the offer. Sometimes, only the bid or the offer is displayed. For example, in foreign markets, an exchange rate such as USD/GBP, might be quoted as 0.6712/5, which indicates a bid of 0.6712 and an offer of 0.6715. If only a bid is present, the quote is shown as 0.6712/ ; an offer-only quote appears as /0.6715. Considering the above facts, we can model a quote object as follows:

 

 

Using the above quote object, an instrument could be modeled as:

 

 

Scenario  

In a market, the price of an instrument is never constant; it always changes. So, we need to be able to show how prices change over time and to keep a history of those changes. This is where scenarios come into picture. A scenario represents the state of the market at a certain point in time and the elements within the scenario represent the prices at that point. The following model depicts this definition:
 

 

The main use of scenario is in risk management. Much of the effort of fund managers and traders goes into managing the risks of their portfolios as market conditions change. This involves looking at alternative situations and considering their effects on prices of assets.

Example: A production manager is assessing likely production costs for cars. The costs of raw materials and labor are instruments concerned with pricing. Several scenarios can be constructed with different likely values for these instruments.

 

The above example shows the usefulness of the scenario approach. The scenario object provides a base to pull together all the factors in a hypothetical case so that different cases can be compared easily.

In the above model of scenario, we haven't described how the prices are obtained. Where do they come from? In general, there are three origins for a price: publication by some body that is widely quoted, calculations from other prices or market characteristics, or the opinion of an individual trader or team of analysts. The following model describes this, where the first case has been elaborated:

 

In this model, the object Sourced Scenario Element has been introduced. This represents the fact that the price has been obtained from an information source. For example, consider an analyst looking at the prices of some goods. The analyst can treat each company as an information source for getting the price. The sourcing index could be a page number in a catalog. He can create a scenario for each company or consolidate them into a single scenario for all companies.
Another new element in this model is Market Indicator. In scenarios, it is common to have things other than instruments. For instance, an important concept in derivative contracts is volatility - which is an indicator of  how much the value of the instrument is changing. This metric is not an instrument that can be traded, yet it is recorded in a scenario in the same way as an instrument. Hence we need a supertype that encompasses instruments, volailities, and others. Hence the inclusion of Market Indicator.
 

 Banking Patterns Home Page
 
If you have comments or suggestions, email us!