Trading 
Contract
The kernel of all trading applications are contracts, also referred to
as deals or trades. A deal is a legal contract between two or more parties
(usually two). The parties agree to swap some assets or cash flows either
on the spot or at a later time. Some systems do only keep track of the
counterparty as the primary party is always the same (eg. a trader trading
on its behalf), others keep both parties (eg. the EBS system needs to store
both parties for whom two orders have been matched).
In the Financial Objects Framework the term Trade is used. A
Trade has two or more parties and contains instruments and flow
groups. A flow group is a collection of asset flows. An asset flow is a
transfer of some quantity of one asset from one party to another on a specific
date. An instrument is a standardized flow group. This model is particularly
useful for risk management as part of which future asset flows are evaluated.
The Contract pattern assumes that for every deal one of the
legs is an instrument and the other is money. However, this might not be
appropriate for all kind of deals. For example, in a swap the two parties
exchange two streams of future cash flows (eg. interest rate payments),
ie. it should be possible to have two legs that are both instruments.
Portfolio
In the Financial Objects Framework Portfolio is used the same way
as Martin Fowler does, ie. as a collection of contracts where membership
is defined by a filter. This gives the user the flexibility to do an overall
evaluation on any group of contracts. For risk management purposes the
term Selection is used for a construct that seems to be just like
a Portfolio.
In SwapsManager portfolios do not use a filter but are merely a collection
of deals that have manually be added by a user. As instruments and portfolios
have some common behavior, such as being valuated for a specific scenario,
Portfolio is a subclass of CompositePortfolio which is a
subclass of Instrument.
DEVON gives the user the possibility to use a filter to add deals to
a portfolio at a given time, but the portfolio keeps a reference of all
deals it contains and does not use the filter later on. In a backoffice
system I have worked on the term blotter was used for a dynamically
filtered (usually by state) lists of deals. However, this filter was set
in the application and could not be changed by the user. After opening
a blotter the user had the possibility to set additional filter criteria,
but this filter was only active till the blotter was closed.
Quote
I am not sure whether the Quote pattern is useful as described.
The systems I have seen use either bid and offer or mid and spread, not
both concepts. Mid is common in foreign exchange applications, but I do
not know if it makes sense to quote mid for a stock deal.
As quotes continuously change it may not be appropriate to instantiate
Quote objects for every new quote. Maybe a Quote should only
be instantiated when a user asks for a quote. If the Quote class
does not have additional functionality to that described in the book it
might even be reasonable to just keep the quotes in tables without creating
any objects at all.
Scenario
The notion of Scenario is used in every system providing some risk
management functionality.
In the Financial Objects Framework Simulations is used to perform
a "what-if" scenario against a portfolio. Simulated Market Data
temporarily replaces real market data while running a risk management or
pricing application. The same valuation algorithms are used for real and
simulated data. The user can also change the date to a future date to see
the effects on his portfolio. Simulated Trading allows the user
to simulate real trading by creating a series of time points with different
market conditions and evaluate the portfolio at each time point.
In SwapsManager the user can create interest rate scenarios graphically
by directly manipulating the interest rate curve for a currency. The scenario
can then be applied to a single swap or a portfolio which is then re-evaluated.
Further changes to the scenario immediately invoke recalculation of dependent
data.
DEVON allows the user to create a scenario by loading a file of exchange
rates or manually setting the rates. The date can be shifted back and forward.
The scenario can then be applied to a real or hypothetical portfolio. Portfolios
are also part of a scenario: The user can add deals or update deals within
a scenario without affecting the real-world environment.
Other Patterns
Electronic trading systems such as EBS and SOFFEX need to match pairs of
orders. Unmatched orders are kept in an order-book and compared against
new orders. The matching is done on a price/time base. I have not seen
the design of such systems but I assume that some patterns on how to do
the matching exist.
In th eFinancial Objects Frameworks patterns are described for the
valuation of an instrument (Valuation, Valuation Controller).
In contrast to a quote which stands for what the market is willing to pay
for an instrument, the value represents the internal value of an instrument.
Different algorithms exist for calculating the value for a given instrument
and may produce different results. The same instrument may have different
values to different companies depending on algorithms used and resources
available to a particular company. The Chicago Object Group suggests that
the instrument should not know how it is valuated. The valuation is done
in separate Valuation objects. The user can select which algorithm
to use for each different instrument and the Valuation Controller keeps
track of what Valuation objects exist for which kind of instrument.
Banking
Patterns Home Page
If you have comments or suggestions, email
us!