Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
~O 94/28496 ~ 1 6 3 7 6 8 PCT/AU93/00250
--1--
Methods and Apparatus Relating to the Formulation
and Trading of Risk Management Contracts
TECHNICAL FI~LD
This invention relates to methods and apparatus, including
electrical computers and data processing systems applied to financial
matters and risk management. In particular, the invention is concerned
with the management of risk relating to specified, yet unknown, future
events.
BACKGROUND ART
Individuals and enterprises are continually exposed to risk
because of future events beyond their control. The outcome of those
events can either positively or negatively impact on their wellbeing.
Individuals and enterprises should generally prefer not to face exposure
to the possibility of adverse consequences, regardless of their
perception of the likelihood of such events occurring. It is in their
interest to consider foregoing 'resources' they currently possess if
doing so would reduce the possibility of being so greatly exposed to
future outcomes.
Risk can take many forms in view of the large range and type of
future events which might result in adverse consequences. Risk can be
categorised, in one instance, as 'economic' in nature. Phenomena tllat
constitute economic risk include: commodity prices, currency exchange
rates, interest rates, property prices, share prices, inflation rates,
company performance, and market event based indices.
Another characterisation of risk concerns 'technical' phenomena.
This can include things like the breakdown of an electricity generation
plant, aircraft engine failure, and the damage to, or failure of,
orbiting telecommunications satellites. The outcomes for each of these
phenomena will be adverse for the users and/or supplier.
Other forms of risk defy ready characterisation, such as
weather-based (viz., rain damage or lightning strike), or other natural ~-
occurrences (viz., earthquakes or iceberg collision with sea-going
vessels).
There are also less tangible risks associated with, for example,
WO 94/28496 . PCT/AU93/00250
~163~68
--2--
the emission of atmospheric pollutants or the disposal of intractable
toxic wastes, in the sense that the future consequences are unknown,
save that there is a notion, based on current information, that they
could be adverse.
The capability to manage risk is more important today than it was
in the past, and is likely to become ever-more important into the
future, because there is an ever increasing exposure to a wider generic
range of future phenomena beyond the control of individuals or
enterprises. There is also a wider feasible range of possible future
events, and greater uncertainty about the likelihood of occurrence,
associated with any single future phenomenon viz., an increasing
volatility.
It is also thought that individuals are now more risk-averse in
recessionary times, when there are fewer available discretionary
resources to trade-off to protect themselves from such adverse future
events.
In the prior art, individuals and enterprises faced with
'technical' risk have hedged against future outcomes by mechanisms such
as the adoption of quality assurance practices, warranties, increased
research and development actlvity (and associated intellectual property
rights such as patents, utility models and registered designs), the
purchase of modernised plant and equipment, and lmproved inventory,
occupat~onal health and safety and employer/employee relations practices.
Consider a manufacturer of, say, integrated circuits (ICs), which
has many clients wishing to purchase its ICs. The demand may result in
a delay in del~very due to limited manufacturing capacity, thereby
requiring advance production scheduling for orders already in-hand.
Typically, the manufacturer w~ll give a warranty to a purchaser as to
measurable performance criteria for its ICs; if a batch does not perform
to the specified criteria, the manufacturer is required by contract to
replace that batch. That is, a purchaser may have no interest in
obtaining monetary compensation for the poor quality ICs, as the
purchaser needs the components for their own products. In that case,
the 'conslderation' the warranty makes is the priority schedul~ng of a
substitute batch of that type of IC, possibly displac~ng other scheduled
production runs, or deferring delivery to another purchaser.
~O 94128496 216 ~ 7 ~ 8 PCT/AU93/00250
.
--3--
Such contractual arrangements are piece-meal in nature, and can
only be struck between the manufacturer and each ~ndividual purchaser.
They also leave the manufacturer exposed to claims from other customers
whose orders are delayed by the re-scheduling. The manufacturer has no
convenient mechanism available to it to hedge against such claims,
perhaps by way of reserving production rights with another manufacturer,
in lieu of unavailability of their own manufacturing facility.
In the face of such 'economic' risk, it is known for individuals
and enterprises to hedge against adverse outcomes by indirect means such
as self-insurance, and directly by means such as futures contracts,
forward contracts, and swaps.
There are disadvantages or limitations associated with such
available economic risk management mechanisms. Particularly, they
provlde, at best, only indirect approaches to dealing with the risk
management needs. The available mechanisms are relatively expensive,
and provide limited phenomenon coverage, and therefore cannot meet the
requirements of the party seeking to hedge against such wide-ranging
future risk. The infrastructure and pay-out costs associated with
switching between, say, a commodities market and a stock market are
often prohibitive for entities small and large alike; As a consequence,
entities find themselves saddled with obligations they have little
control over and cannot escape.
In respect of the "less tangible" forms of risk, an example in the
prior art of a form of management of that risk is that of 'pollution
rights' sold by the U.S. Environmental Protection Agency (EPA) in March
lg93 for the atmospheric emission of sulphur dioxide. This was done by
an auction of "allowances" permitting the release into the atmosphere.
By the year 1995, any company or organ~sation emitting sulphur dioxide
in the U.S. w~thout enough allowances to cover their total emissions
will face prosecution. This means polluters must either buy further
allowances, or else modify or replace their plant and equipment to
reduce these emisslons. The EPA will regulate the total number of
allowances able to be obtained. The existing allowances have already
become a valuable tradeable 'property' as between sulphur dioxide
emitters, that is, even before the time when no further allowances will
be able to be purchased.
WO 94/28496 PCT/AU93/00250~
21~3768
Management techniques for the "less tangible" forms of risk are in
their infancy. The existing forms indicate an emerging demand for
systems and methods to enable effective management.
Specific examples in the prior art of patents relating to methods
and apparatus which deal with various forms of risk management include
British Patent No. 2 180 380, in the name of Merrill Lynch Pierce Fenner
and Smith Incorporated, directed to an Automated Securities Trading
Apparatus (corresponding to U.S. Patent No. 4,674,004, and further
related to U.S. Patents No. 4,346,442 and 4,376,g78). Other examples
include U.S. Patent No. 4,739,478 assigned to Lazard Freres and Co.,
directed to Methods and Apparatus for Restructuring Debt Obligations,
U.S. Patent No. 4,751,640 assigned to Citibank, N.A., directed to An
Automated Investment System, and U.S. Patents No. 4,752,877, 4,722,055,
and 4,839,804 assigned to College Savings Bank directed to Methods and
Apparatus for Funding Future Liability of Uncertain Cost.
The present invention comes about in view of the shortcomings of
existing risk management mechanisms, and the perceived increasing
importance of the management of risk relating to specified, yet unknown,
future events.
In this sense, the invention is directed to something having
economic value to individuals, enterprises and societies as a whole.
Methods and apparatus that provide for the management of risk offer
material advantages by, for example, minimising adverse future outcomes,
providing both a form of compensation in the event of adverse future
outcomes, and forms of risk management not otherwise supported or
available in the prior art, and thus have value in the field of economic
endeavour.
DISCLOSURE OF THE INVENTION
The invention encompasses methods and apparatus enabling the
management of risk relating to specified, yet unknown, future events by
enabling entities (parties) to reduce their exposure to specified risks
by constructing compensatory claim contract orders on
yet-to-be-identified counter-parties, being contingent on the occurrence
of the specified future events. The entities submit such orders to a
'system' which seeks to price and match the most appropriate
~0 94/28496 216 3 7 6 8 PCTIAU93/00250
,
--5--
counter-party, whereupon matched contracts are appropriately processed
through to thelr maturity.
Therefore, the lnvention enables parties to manage perceived risk
in respect of known, yet non-predictable, possible future events. These
future events may relate to measurable phenomena whose outcome is
veriflable, and cannot be materially lnfluenced by any other entity
having a stake ln that outcome.
The ablllty to price and match rlsk aversion contracts essentially
comes about because of the nature of rlsk itself. Any number of people
will each have differing views as to the likelihood of an outcome of
some future event. This means that when each person ls required to
independently assess a range of outcomes for a specified future date,
there almost always will be a variance in those assessments. Thus it is
posslble to match these expectatlons as between parties to form a
contract. The potential counter-parties to an offered contract have the
motivation of taking up an opportunlty to exploit differing views of
future outcomes to their advantage, elther for some gain or, again, as a
form of risk management.
It is important that the assessments as to future outcomes of
events are made independently of any other party who could be a
counter-party to a contract. The nature of the pricing and matching,
therefore, is totally different to conventlonal negotiation or bidding
as between parties.
The present invention enables entities to better manage risk, as
they are able to think more explicity about possible future events
beyond their control which they perceive wlll have adverse consequences
for them. They wlll have the capacity to utilise existing resources to
reduce exposure to a speciflc risk, and have access to a generally
avallable mechanism by which they can expllcity trade-off existing
assets for increased certainty about the future. They are also free to
decide upon the degree to which they should make such trade-offs, and to
actually effect and subsequently manage such trade-offs in a simple and
low cost manner.
The present invention also provldes an automated lnfrastructure to
whlch parties have access without restrictions relating to nationality
or residential requirements. This allows the parties to partlcipate
WO 94/28496 PCT/AU93/00250~
2 ~ 63768 -6-
dir~ectly without requiring an intermediary.
Therefore, in accordance with one aspect of the present invention,
there is disclosed a data processing system to enable the formulation of
multi-party risk management contracts, the system comprising:
at least one stakeholder input means by which ordering
stakeholders can input contract data representing at least one offered
contract in at least one predetermined phenomenon, each said phenomenon
having a range of future outcomes, and said contract data specifying a
future time of maturity, entitlements due at maturity for the range of
outcomes, and a consideration due to a counter-party stakeholder;
at least one counter-party stakeholder input means by which at
least one counter-party stakeholder can input registering data as to a
respective view of the outcomes in said predetermined range of outcomes
in the future for one or more of said predetermined phenomena;
a data storage means linked with each said stakeholder input means
and linked with each said counter-party stakeholder input means to store
said contract data and said registering data; and
data processing means, linked with the data storage means, for
pricing and matching contracts from said contract data and said
registering data, said pricing including selecting the registering data
corresponding to the time of maturity for each predetermined phenomenon,
and calculating a counter-consideration derived from said entitlements,
and said matching including comparing said consideration and said
counter-consideration to match an offered contract with at least one of
said counter-party stakeholders.
In accordance with a second aspect of the present invention there
is disclosed a method to enable the formulation of multi-party risk
management contracts, the method comprising the steps of:
(a) inputting into data processing apparatus, by at least one
ordering stakeholder input means thereof, contract data representing at
least one offered contract in at least one predetermined phenomenon
having a range of future outcomes, and said contract data specifying a
future time of maturity, entitlement due at maturity for the range of
outcomes, and consideration due to a counter-party stakeholder;
(b) ~nputtlng ~nto said data processing apparatus, by at least
one counter-party stakeholder input means thereof, counter-party
~ o 94/28496 - ~ 1 6 3 76 8 PCT/AUg3/00250
registering data as to a respective view of each outcome in said
predetermined range of outcomes in the future for one or more of said
predetermined phenomena;
(c) storing, in a data storage means of said data processing
apparatus linked with each said stakeholder means and linked with each
said counter-party stakeholder input means, said contract data and said
registering data; and
(d) pricing and matching at least one of the offered contracts,
by data processing means of the data processing apparatus linked with
said data storage means said pricing and matching comprising the steps,
for each offered contract, of:
(i) selecting the registering data corresponding to the
time of maturity for a predetermined phenomenon;
(ii) calculating a counter-consideration derived from the
said entitlement;
(iii) comparing the said consideration and the said
counter-consideration; and
(iv) matching a contract on the basis of the said comparison.
In preferred embodiments, the ordering stakeholders and
counter-party stakeholders can be considered to be contract buyers and
contract sellers respectively. The entitlement for each outcome can be
in the form of 'money' payoffs (both positive and negative) at maturity
of a matched contract, or can be other types of compensation, possibly
in the form of goods, services, promises, credits or warrants. The
consideration, whether buyer specified or seller calculated, can again
be in the nature of a premium or payments, or can relate to other
~non-money' forms of property or obligations, typically transferablé
when a contract is matched, although possibly deferable, until, and
potentially beyond, the time of maturity.
In the period between the match of a contract and maturity the
various buyers, sellers and other contract stakeholders can review any
contract to which they are a party and seek to trade that contract to
other parties by the pricing and matchlng procedure, or variations on
the pricing and matching procedure. They would tend to do so if their
view of the future outcome of the phenomenon, being the subject of the
contract, had changed markedly, or as a means to minimise expected
WO 94/28496 PCT/AU93/00250~
21~768 -8-
losses if some unforseen adverse trend in the present day outcome of the
phenomenon has occurred. As well as trading existing contracts, further
contracts can be offered to 'lay off' or avert risk. Stakeholder
parties can build up a portfolio of matched contracts and offered
contracts, which are continually traded to obtain the best possible
position at any time, and that position can be continually reviewed with
time.
It is further possible for offered contracts to be based on the
difference between phenomena, and so manage perceived risk as between
the phenomena. Elemental contract phenomena can therefore be developed
to meet the most particular needs of buyers and sellers, thus creating
great flexibility.
In most instances the date of maturity will be predetermined by a
'product sponsor' stakeholder, who otherwise cannot be a buyer or seller
of contracts they sponsor. Even so, it is conceivable that the date of
maturity can be tied to a specified time from the instant a contract is
matched. This may be appropriate where the time of maturity is in the
near future, in which case offered contracts could otherwise remain
unmatched following initial offer even up until the time of maturity.
Other stakeholders have executive roles in administration,
guaranteeing the performance of buyers and seller, regulation,
supervision and so on. In this way the number and types of buyers and
sellers that can be considered in pricing and matching offered contracts
can be controlled.
The invention also encompasses apparatus and method dealing with
the handling of contracts at maturity, and specifically the transfer of
entitlement.
Therefore, in accordance with a further aspect of the invention,
there is disclosed a method of exchanging obligations as between
parties, each party holding a credit record and a debit record with an
exchange institution, the credit records and debit records for exchange
of predetermined obligations, the method comprising the steps of:
(a) creating a shadow credit record and debit record for each
party to be held independantly from the exchange institutions by a
supervisory institution;
~O 94/28496 2 16 3 7 6 ~ PCT/AU93/00250
_g_
(b) obtaining ~rom each exchange institution a start-of-day
balance for each shadow credit record and debit record;
(c) for every transaction resulting in an exchange obligation,
the supervisory institution adjusts each respective party's shadow
credit record or debit record, allowing only those transactions that do
not result in the value of the shadow debit record being less than the
value of the shadow credit record at any time, each said adjustment
taking place in chronological order; and
(d) at the end-of-day, the supervisory institution instructing
ones of the exchange institutions to exchange credits or debits to the
credit record and debit record of the respective parties in accordance
with the adjustments of the said permitted transactions, the credits and
debits being irrevocable, time invariant obligations placed on the
exchange institutions.
BRIEF DESCRIPTICN OF THE ~RA~INGS ANP APPENDICES
A number of embodiments of the inventlon will now be described
with reference to the accompanying drawings, in which:
Fig. 1 shows a block diagram of a gener~c 'system' embodying the
invention;
Fig. 2 shows a block diagram of an indicative hardware platform
supporting the system of Fig. l;
Fig. 3 shows a representation of INVENTCO and its main component
parts;
Fig. 4 shows a block diagram of a subset of the components of an
INVENTCO system's markets-depository (M-INVENTCO);
Fig. 5 shows a block diagram of the process components of a subset
of one type of 'market' (termed CONTRACT APP) wh;ch can reside within
M-INVENTCO;
Fig. 6 shows a timeline applicable to Example I;
Fig. 7 shows a timeline applicable to Example II;
Figs. 8 to 16 show flow diagrams of the contract pricing and
matching methodology;
Fig. 17 shows a timeline applicable to Example III; and
Figs. 18 to 40 show flow diagrams of the first to ninth process
components for a CONTRACT APP.
WO 94128496 PCT/AU93100250~
2 1 ~
--10--
There are a number of 'appendices' supporting the described
embodiments all of which form an integral part of this specification.
The appendices are:
Appendix A i5 a glossary of non-conventional terms;
Appendix B is a detailed description of CONTRACT APPS, and the
stakeholders thereto;
Appendix C is a detailed description of each of the nine processes
of a CONTRACT APP;
Appendlx D is a detailed description of the nature of risk
management contracts;
Appendix E has tables and charts associated with Example I;
Appendix F has tables and charts associated with Example II;
Appendix G has tables and charts associated with Example III; and
Appendix H is a listing of the main variables and data files used
by process 2 of a CONTRACT APP.
DETAILED DESCRIPTION OF A BEST MODE FOR CARRYING OUT THE INVENTION
1. Introduction
The description firstly discusses the relation of the various
users tstakeholders) of the 'system', followed by a consideration of a
hardware data processing platform and peripheral inputloutput devices by
which stakeholders interact with each other and the system.
This is followed by a discussion of the scope of the
'applications' that can be supported by the system in relation to the
various stakeholders, and the interrelation of component parts thereof.
Details as to software methodologies for implementation of the
applications supported by the system are also described, including a
number of worked examples relating to the formulation and trading of
risk management contracts.
In the course of the detailed description reference is made to a
number of non-conventional expressions and terminologies. For
convenience, an explanation of these is listed in Appendix A.
2. 'Systems' Confiaurations
Fig. 1 shows a block diagram of a generic 'system' embodying the
~O 94/28496 ~ 1 6 3 ~ 6 ~ PCT/AU93/002~0
_ 1 1 _
invention. The various stakeholders or parties to the system 10 each
have access to a centralised processing unit 20. The processing units
20 can be constituted by one or more data processing apparatus, with
each one thereof providing access for any one or more of the various
stakeholders to applications software supported by the system 10, as all
the processing units would be interconnected. Access to the one or more
data processing apparatus is controlled by a generic form of
communications co-ordination and security processing unit 25.
Fig. 1 also indicates that there are a number of types of
stakeholder, and a number of individual stakeholders w~thin each
stakeholder type. The basic types of stakeholder are described as:
applications promoters 11, product sponsors 12, product ordering parties
(buyers) 13, potential product counter-parties (sellers) 14,
counter-party guarantors 15, regulators 16, consideration/entitlement
transfer ('accounting') entities 17, and miscellaneous parties 18. The
detailed roles of each of these stakeholders will be subsequently
described in greater detail at a later time. The number of types of
stakeholder represented in Fig. 1 is typically the largest that will be
supported by the system 10.
An embodiment of a computer system for the system 10 is shown in
Fig. 2~ The core of the system hardware is a collection of data
processing units. In the embodiment described, the processing unit 20
comprises three inter-linked data processors 93,97,104, such as the Sun
670 MP manufactured by Sun Microsystems, Inc. of the USA. Each
processing unit 93,97,104 runs operational system software, such as Sun
Microsystems OS 4.1.2, as well as applications software. The
applications software is, in part, written around the flow diagrams
subsequently described ~n Figs. 8 to 16, and Figs. 18 to 40, and
accesses, or otherwise creates, the data files as summarised in Appendix
H. The processor configuration shown in Fig. 1 represents a large
system designed to handle the transactions of thousands of stakeholders,
the input and output data generated by those stakeholders, and risk
management contract pricing, matching and subsequent processing
functions.
Each processing unit 93,97,104 is operably connected with it one
or more mass data storage units 95,100,110 to store all data received
WO 94/28496 . PCT/AU93/00250~
21~376~ `
-12-
from stakeholders, and other data relating to all other software
operations generating or retrieving stored information. Suitable mass
storage units are, for example, such as those commercially available
from Sun Microsystems.
A number of communications controllers 80,84,87, forming the
communications co-ordination and security processing unit 25, are
coupled with the processing unit 20. These controllers effect
communications between the process~ng units 93,97,104 and the various
external hardware devices used by the stakeholders to communicate data
or instructions to or from the processing units. The communications
controllers are such as the Encore ANNEX II, the IBM AS/400 server or
the CISCO Systems AGS ~.
A large range of communications hardware products are supported,
and collectively are referred to as the stakeholder input/output devices
70. One amongst many of the communication devices 70 are personal
computers 51 and associated printers 52, which have communlcations
connection with the communications controller 80 by means of a modem
50. There can also be an external host device 53, such as a minl or
mainframe computer, agaln linked with the communlcations controller 80
by means of a modem 54. In other forms, communications can be
established simply by means of a tone dialing telephone 56, which
provides for the input of instructlons or data by use of the tone
dialing facllity itself. In the alternative, a voice connection via an
operator 75 can be effected by a conventional telephone 58. Both these
external devices are shown connected with the communications controller
84. A further possibility is to have data transfer by means of a
facsimile machine 65, in this case shown linked to the communications
controller 87.
In all cases, users of the input devices are l~kely to be required
to make use of system access password generation and encryption devices
such as the Racal RG 500 Watchword Generator 66,67,68,69, (for personal
use) and the Racal RG 1000, which is incorporated in a mainframe
computer 53. The correspond~ng decoding units for these devices are
incorporated in the communications controllers 80,84,87.
The generic process~ng unit 20 also includes a large number of
'portable' information recordal devices, such as printers, disc drives,
~O 94/28496 PCT/AU93/00250
216~8
13
and the like, which allow various forms of information to be printed or
otherwise written to storage media to be transferable. This is
particularly appropriate where confirmatory documentation of matched
risk contracts is required to be produced, either for safekeeping as a
hard copy record, else to be forwarded to any one or more of the
stakeholders that are a party to each individual matched contract.
The generic system 10 shown in Fig. 1 encompasses many variedconfigurations, relating not only to the number and types of
stakeholders, but also the 'architectures' realisable by the system
hardware and software in combination. In that sense the arrangement
shown in Fig. 2 is to be considered only as broadly indicative of one
type of hardware configuration that may be required to put the invention
into effect.
The 'virtual' level of the system 10 is termed INVENTC0. INVENTC0
is a collection of one or more potentially interrelated systems, as
shown in Fig. 3. Each INVENTC0 system (INVENTC0 SYSTEM #1... INVENTC0
SYSTEM #N) enables the formulation and trading of a wide range of
contractual obligations, including risk management contracts. The
hardware configuration shown in Fig. 2, ls to be understood both as a
realisation for a single INVENTC0 system, and equally can represent a
number of INVENTC0 SYSTEMS, where the processing unit 20 is common to
all and supports a number of communications co-ordination and security
units 25, others of which are not shown, together with associated
external communications devices 70, also not shown.
While INVENTC0 allows the formulation and trading of risk
management contracts, it is also responsible for processing of such
contracts through to, and lncluding, their maturity, and in some
respets, subsequent to maturity.
Where there are a number of INVENTC0 systems, those systems may be
inter-dependent or stand-alone in nature. If inter-dependent, INVENTC0
(10) ~s responsible for transactions between those systems.
INVENTC0 and all of its component parts can be legally or
geographltally domiciled in separate countries or states. The
supra national nature of INVENTC0 enables the stakeholders to avail
themselves of the risk management mechanisms independently of legal
domicile or other such restrictions that are often a feature of some
WO 94128496 PCT/AU93/00250~
~37~8
-14-
conventional risk management mechanisms, subject to meeting certain
criteria regarding credit worthiness and such. Indeed, the legal
domicile, location, ownership and participating stakeholders of
INVENTCO, or any of the sub-systems, can be continually changing.
Fig. 3 further shows that each INVENTCO SYSTEM comprises an
infrastructure component, termed I-INVENTCO, and a markets depository
component M-INVENTCO. I-INVENTCO is concerned with coordination of
communications and other security considerations, that part termed
AXSCO, and also provides a network and general management system, termed
10 VIRPRO. M-INVENTCO is a depository of authorised product-market
(applications) software residing within INVENTCO under the authorisation
of VIRPRO, and as distributed using I-INVENTCO.
One or more local or wide area telecommunication networks may link
VIRPRO and M-INVENTCO to AXSCO, and thus to each other. In this way
both VIRPRO and M-INVENTCO effectively reside around AXSCO.
AXSCO therefore comprises multiple, uniquely addressed
communications controllers linked together in a number of possible
ways. In one embodiment, AXSCO is represented by the communications
co-ordination and securlty processing unit 25 shown in Fig. 2. The
component hardware, such as the three controllers 80,84,87 shown in Fig.
2, typically are responsible for three types of operational
applications. The first is in respect of time stamping data received
from other parts of INVENTCO and data similarly transmitted to entitles
external of INVENTCO. The second is in respect of protecting the
identity and/or location of entities within INVENTCO from one another,
and from entities external to INVENTCO. The third is responslble for
overall management of the routing of data received and to be transmitted
with~n INVENTCO and to external ent~ties thereto.
Referring now to Fig. 4, within M-INVENTCO reside different
collections of system sponsored phenomena or 'markets', one collection
of which is termed CONTRACT APPS. Each CONTRACT APP within the CONTRACT
APPS 'markets' collection is essentially related to a specific type of
risk management phenomenon. The purpose of individual CONTRACT APPS is
two-fold. Flrst, to effect the trading/exchange/transfer of r~sk
management contracts (and derivatives of these transactions) between
participat~ng product ordering parties and counter-parties on terms
~j~O 94/28496 2 1 637 6 8 PCTIAU93100250
--1 5--
acceptable to the parties involved, as well as to others within INVENTCO
registered as having a legitimate interest in the nature, $ize and
composition of these trades/exchanges/transfers. And second, to
appropriately manage all matched/confirmed contracts through to their time of maturity.
Individual CONTRACT APPS are responsible for performing the
above-described tasks according to the specific rules they embody,
defined by their applicable stakeholders.
The role played by the various stakeholders to CONTRACT APPS,0 remembering that in many cases it would not be necessary to have the
involvement of all the possible types of stakeholder, briefly stated is
as follows:
(a) An application promoter is an entity having overall
responsibility for the functioning of a CONTRACT APP, having being
granted that responsibility by VIRPRO.
(b) A product sponsor is an entity which promotes and administers
the rules of trading, and subsequent management of defined
"products" selected for inclusion in a CONTRACT APP by its
application promoter.
(c) An ordering party (buyer) is an entity seeking to acquire a
CONTRACT APP product from a potential counter-party (seller).
~d) A counter-party (seller) is an entity potentially prepared to
satisfy the CONTRACT APP product needs of an ordering party
(buyer).
(e) A guarantor is an entity guaranteeing a seller's ability to
settle or meet obligations as a result of a CONTRACT APP effected
match.
(f) Regulators are entities overseeing the on-going performance
of all other stakeholders involved in a CONTRACT APP, and
especially guarantors.
(g) Consideration/entitlement transfer ('accounting') entities
are those parties with which all other CONTRACT APP stakeholders
maintain 'accounts' to transfer required
considerations/entitlements to or from each other.
(h) Other miscellaneous parties are those having some other
defined stake in the functioning of a CONTRACT APP.
WO 94/28496 PCT/AU93/00250~
2~ ~7~8
-16-
In any implementation of the system, multiple numbers of each form
of stakeholder are accommodated. A detailed consideration.of the nature
of CONTRACT APPS and the types of stakeholders to a CONTRACT APP is
given in Appendix B.
As shown in Fig. 5, any one CONTRACT APP consists of a cluster of
nine (and potentially more, or fewer) specific processes, these include:
(a) a process handling file administration and updating tasks
supporting all other processes (termed Process l);
(b) a process handling the receipt and processing of "primary"
risk aversion contract transactions (termed Process 2);
(c) a process handling the receipt and processing of "secondary"
risk aversion contract transactions (termed Process 3),
(d) a process handling the receipt and processing of
"derivative-primary" risk aversion contract transactions (termed
Process 4);
(e) a process handling the receipt and processing of
"derivative-secondary" risk aversion contract transactions (termed
Process 5);
(f) a process handling the "back office" management of all four
types of risk aversion contract transactions, and transactions
handled by Processes 7 to 9 (termed Process 6);
(g) a process handling non-CONTRACT APP-transaction related
consideration, entitlement, and other "payment" obligation
transfers between stakeholders (termed Process 7);
(h) a process handling CONTRACT APP (and authorised other
INVENTCO) stakeholder access to specialist systems to assist the
stakeholder concerned to decide how best to interface with a
defined element of INVENTCO (termed Process 8); and
(i) a process handling CONTRACT APP (and authorised other
INVENTCO) stakeholder access to a range of INVENTCO-facilitated
"value added services" (termed Process 9).
A detailed discussion of the nine CONTRACT APP processes is given
in Appendix C.
All these processes collectively access multiple data files and
multiple records within these files. A description of the variables and
~p 941~8496 PCT/AU93/00250
~ ~6376~
-17-
data files used by Process 2, a key component process of a CONTRACT APP,
is provided in Appendix H.
The foregoing description identifies the essential inter-reaction
between the hardware platform and the applications computer software run
thereon.
A first example of the life-cycle of a risk management contract
will now be described. A further detailed discussion of the nature of
risk management contracts is given in Appendix D.
WO 94/28496 PCT/AU93/00250~
~163768
-18-
3. Life Cycle of Risk Management Contract: Example I
The first example of a risk management contract describes a
contract to manage risk associated with faults in microprocessors. In
summary, the example shows how the system could enable one party, such
as a supplier of military standard equipment seeking to avoid the
adverse consequences of faulty microprocessors (specifically, 64-bit
microprocessors) used in that equipment to make a contract with another
party, such as a manufacturer of these microprocessors, who is seeking
to exploit an opportunity based on their view of the future incidence of
faults in the microprocessors they produce.
The specific offering is one which provides a contract ordering
party with a specified contingent entitlement to "exclusive production
warrants" (XP~s). That is, warrants prov~ding the holder with priority
access to a specified quantity of replacement and additional
microprocessors sourced, immediately, from a defined, different,
guaranteed high-quality, production line available to the supplier in
consideration of payment of a money amount. The XP~ entitlement is
contingent on the value, at contract maturity date, of a percentage
index of the proportion of 64-bit microprocessors shipped by the
manufacturer, during a specified prior period, which are subsequently
determined to be faulty to a defined degree. The defined degree, in
this case, is the microprocessor being fault-free, as determined by
successful completion of self-tests.
In this example, the relevant key stakeholders are: an application
promoter (Demdata Inc); various product sponsors (the relevant one for
the example being Demdata Inc itself); various primary product ordering
partles (the relevant one for the example being Denisons); a single
potential counterparty (Demdata Inc again); and an application regulator
(the Department of Defence).
The timeline depicting the steps in the contract from the first
step, Applicatlon Specification, to the final step, Contract Settlement,
is shown in Fig. 6. Appendix E contains eight detailed explanatory
charts supporting Fig. 6. This Appendix should be read together with
the following description.
Looking at the first step in the timeline (Application
~O 94/28496 ~ 16 3 7 6 ~ PCT/AU93/00250
_1 9_
Specification) in conjunction with chart E2, it can be seen that Demdata
Inc established a Contract APP (Application ID 100) on 92.02.10.17.00.00
(that is, in inverse order, 5pm on February 10, lg92) to deal with
defect liability management. Application ID 100 supports a range of
products (Applicable Product ID's 1200-1250).
Looking at the second step in the timeline (Product Specification)
in conjunction with chart E3, it can be seen that Demdata was also
Product Sponsor of Product 1210 at the same time (92.02.10.17.00.00).
This Product relates to the market termed: Factory Output Quality
Ind~ces, and to the sub-market termed 64-bit Microprocessor Fault
Tolerance Index. The maturity date for Product 1210 is
95.02.10.17.00.00.00. The consideration for a specific contract
involving Product 1210 is in the form of money (commercial bank deposits
denominated in Australian dollars). The entitlement is in the form of
Exclusive Product ~arrants (XPWs); these entitle the contract ordering
party to priority access over the forward production capacity of a
defined, guaranteed-high-quality, 64-bit microprocessor production
line. Product 1210 specifies a range of 0~. to 100% in 2X increments in
respect of the sub-market outcomes.
Looking at the third step in the timeline (Potential Counterparty
Product Pricing Specificatlons), it can be found that Demdata is acting
as the sole potential counterparty for forthcoming primary product
orders dealing with Product 1210. At this point in the timeline
(93.07.01.14.00.00.00), 17 months after the specification of Product
1210, Demdata has currently-specified parameters for pricing potentially
forthcoming orders for the product.
Looking at the fourth step in the timeline (Primary Order
Specification) in conjunction with chart E4, it can be seen that an
Ordering Party, Denisons, is seeking a contract (from the offering
party, Demdata) in Product 1210 at that time (93.07.01.14.25.30.00).
chart E4 shows the specific 'pay-off' parameters that Denisons has
defined for the contract it is seeking at this time, lncluding a maximum
acceptable contract consideration (premium) amount of 32,000
(denominated in commercial bank, Australian dollars).
Looking at the fifth step in the timeline (Order Specification
Pricing) in conjunction with chart E5, it can be seen that Demdata
WO 94/28496 PCT/AU93/00250~
21637~8 -20-
(using the specified pricing parameters set at 93.07.01.14.00.00.00)
prices the Denison order at 93.07.01.14.26.40.00. Demdata's pricing
parameters indicate that their appropriate Defined Circumstances ID for
Denisons is 14. As is shown, this ID in turn implies a Commission Rate
of 1.10%, a Discount Rate of 9.90%, a particular set of Component
product prices and a particular set of Assessed Probabilities of
Occurrence over the range of feasible product values (outcomes).
The Contract Bid Price is calculated automatically by the
application software in the following manner: The ordering
party-specified desired contingent entitlement amounts, i.e. the
"registered data", (covering the feasible product definition value
range) are multiplied by the potential counterparty-specified component
product prices (which will rarely add to "1" because each counterparty
is endeavouring to 'game' potential ordering parties in different ways)
to yield the corresponding number of implied contingent entitlement
amounts. When added together, these figures sum to (34.110), where the
brackets slgnify a negative value. This figure represents an expected
future counterparty-entitlement payout amount (as at the designated
contract maturity date of 95.02.10.17.00.00). The present day value of
this figure, calculated using the specified discount rate of 9.90% per
annum, is 29,220. To this amount is added the potential counterparty's
desired flat commission amount of 1.107., yielding a contract Bid Price
(in the consideration/entitlement denomination of the product,
commercial bank-denominated Australian dollars) of 29,540. No exchange
rates are applicable in this case, because the ordering party, Denisons,
is not seeking to deal in a consideration or entitlement denomination
different to the denominations formally specified for the product.
Demdata's parameters calculate that a consideration bid price of 29,540
will yield them a base margin on the contract of 3,180 (again
denominated in commercial bank, Australian dollars).
This margin amount is calculated in the following manner: The
ordering party-specified desired contingent entitlement amounts
(covering the feasible product definition value range) are multiplled by
the potential counterparty-specified assessed probabilities of
occurrence to yleld a corresponding number of net contingent entitlement
valuation amounts. When added together, these sum to (30.770).
~O 94/28496 . 216 3 7 ~ 8 PCT/AU93/00250
,
-21-
This amount represents an expected future counterparty-entitlement
loss-on the contract (as at the designated contract maturity date of
95.02.10.17.00.00). The present value of this amount, calculated using
the specified discount rate of 9.90% per annum, is 26,360. Thus,
~ 5 (ignoring for this example the margin Demdata may gain from using, in
some manner, the consideration amount of 29,540 through to the time the
contract expires, and various transaction fees) the margin Demdata can
expect from entering into this contract with Denisons is their
calculated present-value indifference price of 29,540 less their
calculated present-value expected loss on the contract of 26,360 (or
3,180).
The amounts in the last two rows of the table contained on E5 are
used for check~ng that this contract, if entered into by Demdata, w~ll
not result in them violating any self imposed portfolio valuation or
composition limits. This notion is explained in detail in Example III.
Looking at the s~xth step in the timeline (Order Match~ng), it can
be found that Demdata's contract bid price of 29,540 is below Denison's
specified maximum consideration price of 32,000, leading to a matching
of the order at 93.07.01.14.29.10.Q0.
The seventh step in the timeline (Order/Contract Confirmation) can
be seen to take place twelve minutes later at 93.07.01.14.38.50.00,
after the system has determlned that Denisons is able to (and then does)
immediately pay the required consideration funds amount of 29,540 to
Demdata.
Looking at the eighth step in the timeline (Contract Valuatlon) in
conjunction with chart E6, it can be seen that a contract valuation
report for Denisons was published not much longer than one hour after
confirmation of the contract, that is, at 93.07.01.16.00.00.00. As can
be seen, the market estimate of the future product value of the 64BMFT
Index at this moment is 38 (with a standard deviation of 4), which
implies that this contract has an expected future value of 29,330 XPWs
(w~th a standard deviat~on of 6,213).
On chart E7 1t can be seen the equivalent report for Demdata Inc
of their expected future entitlement payout is identical to Denisons'
expected future entitlement receipt (ignoring future fee payments whi.ch
may be netted a~ainst these payments/receipts). The above-described
WO 94/28496 PCT/AU93/00250~
2~ ~768 -22-
market estimate of the future product value is determined by the system
applying a defined composite of contract-counterparty assessed
probabilities of occurrence figures drawn from the collection of all
like contracts recently matched/confirmed by the system.
The ninth step in the timeline (Contract Valuation) refers to a
contract valuation report published for Denisons sixteen months later,
at 94.11.15.10.00.00.00 (see chart E8). As can be seen, the market
estimate of the future product value of the 64BMFT Index at this moment
is 58 (with a standard deviation of 5), which implies that this contract
now has an expected future value of 42,160 XPWs (with a standard
deviation of 6,Z09). This is an increase in expected future value of
12,830 XPWs for Denisons since the former valuation date/time.
The tenth step in the timeline, Contract Maturity, refers to the
actual determination of the product value at time of maturity,
95.02.10.17.00.00.00. As can be seen on chart E9, this product value of
the 64BMFT Index was specified by Demdata (as Product Sponsor) to be 74,
implying a contract value of 100,660 XPWs to Denisons and a
corresponding obligation on Demdata. The amount of 74 represents the
percentage of 64-bit microprocessors shipped by Demdata, during a
specified period some time before the designated contract maturity date,
which are subsequently determined (possibly by the application
regulator, The Department of Defence) to be faulty.
The eleventh step in the timeline involves the formal assignment
of 100,660 XPWs by Demdata to Denisons (ignoring possible fee payments
by one or both parties).
~O 94/28496 21 6 3 7 ~ 8 PCT/AU93/00250
,
-23-
4. Life Cycle of Risk Management Contract: Example II
The second example describes a risk management contract associated
with the utilisation of telecommunications carrying capacity. In
summary, the example shows how the system could enable one party (a
telecommunications carrier) seeking to avoid the adverse consequences of
under and over-committing their call carrying capacity between specified
points (say, between the two cities, New York and Boston) to make a
contract with another party (say, another telecommunications carrier
with call carrying capacity between the same two clties) similarly
prepared to hedge against the consequences of this occurring.
The specific offering is one which provides a contract ordering
party with a specified contingent entitlement to transmission time un~ts
between the hours 1200-1800 daily on the NY-Boston link within a defined
future period (termed, Prime TTU's) upon assignment by the ordering
party - to the counterparty - of a calculated consideration amount of
Prime TTUs on the ordering party's own NY-Boston line within another
defined future period (these defined TTUs may or may not be convertible
to TTUs on other city links). The TTU entitlement is contingent on the
value, at contract maturity date, of the log of the d~fference between
the ordering party's utilisation of the counterparty's network and the
counterparty's utilisation of the ordering party's network, during a
specified prior period ending on the contract maturity date.
In this example, the relevant key stakeholders are: an application
promoter (Newcom Inc); various product sponsors (the relevant one for
the example being Newcom Inc ltself); various primary product ordering
parties (the relevant one for the example being Basstel Co.); two
potential counterparties (Tasnet and Aarcom); and an application
regulator (ITT).
The timeline depicting the steps in the contract from the first
step, Application Speciflcation, to the final step, Contract Settlement,
is shown in Fig. 7. Appendix F contains nine detailed explanatory
charts supporting Fig. 7. This Appendix should be read together with
the following description.
Looking at the first step ~n the timeline (Application
Specification) in conjunction with chart FZ, it can be seen that Newcom
-
WO 94/28496 PCT/~U93/00250~
-24-
Inc established a Contract APP (Application ID 001) on
93.11.01.17.00.00 (that is, 5pm on November 1,1993) to deal with
hardware capacity management. Application ID 001 supports a range of
products (Applicable Product ID's 2001-2020).
Looking at the second step in the timeline (Product Specification)
in conjunction with chart F3, it can be seen that Newcom Inc was also
Product Sponsor of Product 2001 at the same time (93.11.01.17.00.00).
This Product relates to the market termed Telecommunications Carrying
Capacity and to the sub-market termed Prime TTUs. The maturity date for
Product 2001 is 96.11.01.17.00.00.00. The consideration for a specific
contract involving Product 2001 is in the form of "Ordering Party
TTUs". The entitlement is in the form of "Counterparty TTUs"; these
entitle the contract ordering party to "transmission time units between
the hours 1200-1800 daily on the NY-Boston link (within a defined future
period)". The feasible values of PRIME TTUs are normalised in the range
of -1.0 to +1.0, respectively signifying the proportionate utilisation
of respective networks as between the parties to a contract.
Looking at the third step in the timeline (Potential Counterparty
Product Pricing Specifications), one can find two other carriers,
Tasnet and Aarcom, acting as potential counterparties for forthcoming
primary product orders dealing with Product 2001. At this point in the
timeline (94.06.01.14.00.00.00), 7 months after the specification of
Product 2001, both Tasnet and Aarcom have currently-specified parameters
for pricing potentially forthcoming orders for the product.
Looking at the fourth step in the timeline (Primary Order
Specification) in conjunction with chart F4, it can be seen that an
Ordering Party, Basstel Co., is seeking a contract, from an offering
party, in Product 2001 at that time ~94.06.01.14.25.30.00). Chart F4
shows the specific parameters (entitlements) that Basstel Co. has
defined for the contract it is seeking at this time, including a maximum
acceptable contract consideration amount of 58,000 (denominated in its
own TTUs).
Look~ng at the fifth step in the timeline (Order Specification
Pricing) in conjunction with chart F5, it can be seen that Tasnet (using
the specified pricing parameters set at 94.06.01.14.00.00.00) prices the
~O 94/28496 ~ 1 ~ 3 7 6 8 PCTtAU93/00250
- 25 -
Basstel Co. order at 94.06.01.14.26.40.00. Tasnet's pricing parameters
indicate that the~r appropriate Defined Circumstances ID for Basstel Co.
is 8. As is shown, this ID ~n turn implies a Commission Rate of 1.00%,
a Discount Rate of 9.90% per annum, a particular set of Component
product prices and a particular set of Assessed Probabilities of
Occurrence. In a similar process to that described for Example I, this
results in a Contract Bid Price of 55,180 (denominated in Basstel Co.
TTUs), which Tasnet's parameters calculate will yield them a base margin
on the contract of 10,760 (again denominated in Basstel Co. TTUs).
Still looking at the fifth step in the timeline, in conjunction
w~th chart F6, it can be seen that Aarcom (again using the spec~fied
pr~cing parameters set at 94.06.01.14.00.00.00) also prices the Basstel
Co. order at 94.06.01.14.26.40.00. Aarcom's pricing parameters indicate
that their appropriate Defined Circumstances ID for Basstel Co. is 9.
As is shown, this ID in turn implies a Commiss~on Rate of O.90X, a
Discount Rate of 8.50% per annum, a particular set of Component product
prices and a particular set of Assessed Probab~l~ties of Occurrence.
Th~s results ~n a Contract Bid Price of S5,390 (denomlnated in Basstel
Co. TTUs), which Aarcom's parameters calculate will yield them a base
margin on the contract of 9,430 (again denominated in Basstel Co. TTUs).
Look~ng at the sixth step in the timeline (Order Matching) it can
be found that Tasnet's price bid of 55,180 is below Aarcom's bid of
55,390 and, in turn, that the 55,180 amount is below Basstel Co.'s
spec~fied max~mum consideration price of 58,000. This leads to a formal
matching of Basstel Co,'s order by Tasnet at 94.06.01.14.29.10.00.
The seventh step in the timeline (Order/Contract Confirmation) can
be seen to take place nearly ten seconds later at 94.06.01.14.38.50.00,
after the system has determined that Basstel Co. is able to (and then
does) immed~ately assign the required consideration amount of 55,180
TTUs to Tasnet.
Looking at the elghth step in the timeline (Contract Valuat~on) in
conjunction with chart F7, one can see a contract valuation report for
Basstel Co. published about two hours after confirmation of the
contract, that is, at 94.06.01.16.00.00.00. As can be seen, the market
estimate of the future product value of the log of the difference
WO 94/28496 . PCT/AU93/00250~
~ ~ ~ 3 7 ~ 8 -26-
between Basstel Co.'s utilization of Tasnet's network and Tasnet's
utilization of Basstel Co.'s network (during a specified prior period
ending on the contract maturity date~ at this moment is (0.150) (with a
standard deviation of 0.023), which implies that this contract has an
expected future value of 54,236 Tasnet TTUs (with a standard deviation
of 9,Z07). On chart F8 one can see in the equivalent report for Tasnet
that their required expected future entitlement payout is identical to
Basstel Co.'s expected future entitlement receipt (ignoring future fee
payments which may be netted against these paymentstreceipts).
The ninth step in the timeline (Contract Valuation) refers to a
contract valuation report published for Basstel Co. five months later,
at 94.11.22.10.00.00.00 (see chart F9). As can be seen, the market
estimate of the future product value of the log of the difference
between Basstel Co.'s utilization of Tasnet's network and Tasnet's
utilization of Basstel Co.'s network (during a specified prior period
ending on the contract maturity date) at this moment is (0.400) (with a
standard deviation of O.O10), which implies that this contract now has
an expected future value of 350,181 Tasnet TTUs (with a standard
deviation of 74,200). This is an increase in expected future value of
295,945 TTUs for Basstel Co. since the former valuation date/time.
The tenth step in the timeline (Contract Maturity) refers to the
actual determination of the product value at time of maturity,
96.11.01.17.00.00.00. As can be seen on chart F10, this product value
of TTU's was specified by Newcom Inc (as Product Sponsor) to be (0.400),
unchanged from the prior valuation date/time, implying a contract value
of 368,340 Tasnet TTUs to Basstel Co. and a corresponding obligation on
Tasnet. The amount is higher than the prior valuation figure due to the
actual determination figure being naturally without a standard deviation
element.
The eleventh step in the timeline involves the formal assignment
of the 368,340 TTUs by Tasnet to Basstel Co. (ignoring possible fee
payments by one or both parties).
~0 94/28496 2 1 ~ ~ 7 6 8 PCT/AU93/00250
-27-
5. PRIMARY PRODUCT ORDER PROCESSING
Before describing the third, and most detailed, example,
consideration will be given to the 'core' product (contact) ordering,
pricing and matching processes. Note that expressions such as (PORD
NEW) represent file names.
The flow charts in FIGS 8 to 16 depict the processing flow of the
matching system for primary product orders submitted by ordering party
stakeholders to a CONTRACT APP, where this APP is based upon: an EV-CE
counterparty pricing regime (assuming paid consideration amounts do not
yield an income stream in their own right); a sequential order matching
process; consideration/entitlement value dates which are immediately
after a product sponsor-designated date/time; and matching rules which
do three things: First, identify, for each ordering party's order, a
counterparty offering the lowest price bid for an order, sub~ect to this
price being at or below the specified maximum price the ordering party
has indicated it is prepared to pay. Second, accommodate portfollo
expected loss constraints on an 'equivalent maturity date products',
'same-month maturity products', and 'all-products' basis. And third,
apply the above-described matching rules on a pre-tax basls, with
partial matching of product orders, and without conditional order
matching rules.
As shown in Flg. 8, starting at block 610, and proceeding to block
625, the system determines which set of orders to process, authorises
these orders, matches them with counterparties where possible, and then
conf~rms them. As shown in blocks 1010 to 1070 in Fig. 9, the system
holds newly submitted orders (PORD NEW), and all previously submitted,
but as yet unmatched, orders which are defined as queued orders (PORD
QUEUE). Parameters and algorithms can be ~mplemented to give the system
the ability to determine whether new or queued orders are to be
processed at any time. For example, a simplistic algorithm would be to
alternate between PORD NEW and PORD QUEUE one order at a time. Another
example would be to load queued orders only when there is a change in
the counterparty parameters. Test 1020 checks the decision made in block
1010.
For new orders, the system moves to block 1030. Details of the
WO 94/28496 PCT/AU93/00250~
2~63~68
-28-
next recorded new order are loaded from the PORD NEW master file (block
1040). The order data fields include: the ordering party identification
(BID); the ordering party's own reference (BREF); the product
identification (PID) specified by the ordering party; the entitlement
S "payoff" function type (PAYFUNC); the parameters for the entitlement
"pay off" function (PAYPARAM); a "deal type" identifier (DTID); the
anonymous and manual deal identifiers (OANON and OMANUAL); the order
retention time limit (RET LIM); the maximum consideration the ordering
party is prepared to pay (MAXCONSID); the number of the account from
which the consideration ~s to be "paid" (ACC CONSID); and the number of
the account to which any entitlement "pay off" amount is to be paid (ACC
ENTITL). With this information set, the system's next step is to
authorise the order. This occurs at block 1050.
Order Authorisation
Blocks 1100 to 1162 in Fig. 10 provide an expansion of block 1050.
Starting at block 1100 the order is assigned a unique identification,
which is set in the order data field OID. Before verifying the order,
additional information is required by the system. At block 1110, details
of the product (order data field PID) are loaded from the master flle
PPRODUCT (block 1120). The information includes the product maturity
date (PMAT); the product consideration/entitlement denomination (PC/ED);
the product currency denomination (PCUR) and national currency
denomination (PNCUR); and the product limits and parameters (PMIN, PMAX,
and PSTEP). The test 1130 checks that the order parameters are
consistent with the master file parameters implied by the defined
product identification (PID). Orders which fall this test are re~ected
at block 1140, w~th details of these orders being stored in the master
file PORD REJ (block 1150). In turn, the ordering party is informed of
this event (block 1160). Processing then returns to the start of the
flow chart (block 1010), ready to load the next order. When an order is
authorised, processing continues at block 640.
In the case of a queued order being loaded (block 1060), the order
fields are set using the details stored in the queue file PORD QUEUE
(block 1070). This data is a combination of new order data (as described
in block 1030) and the data loaded/set when the order was originally
~O 94/28496 ~ 1 63 7 68 PCT/AU93/00250
--29--
ver~fied (block 1110). Authorised order processing continues with the
order matching process at block 640.
Order Matching
Blocks 1200 to 1616 in Figs. 11 to 15 provide an explanation of
block 640. Orders have retention time limits , stored in the order
variable RET LIM. Test lZOO checks that the order retention time has not
expired. If it has, the order is rejected at block 1210, with the order
details copied to the rejected order file (PORD REJ). The ordering party
is then informed of the rejection at block 1230, and processing returns
to the main loop via connector "A". If the order is still valid, the
order matchin~ process proceeds. The aim now is to find a suitable
counterparty (or counterparties) who "prices" the ordering party's
"entitlement function" within the limits set by the ordering party.
Starting at block 1240, the matching process described is one which
seeks to identify, for each ordering party's order, a counterparty
offering the lowest "price bid" for an order subject to this price being
at or below the specified maxlmum "price" the ordering party has
indicated it is prepared to pay.
Blocks 1300 to 1370 in Fig. 12 provide an explanation of block
1240. The first step is to narrow do~n a group of counterparties
prepared to at least deal with the ordering party. This is described as
obtaining the available counterparty short list. First the counterparty
short list is wiped (block 1300). Next, the order data fields BID
(ordering part identification) and PID (product identification) are used
to search the PDEAL LIST master file (block 1320) for all counterparties
prepared to consider dealing with the ordering party in the specified
product. Any stakeholders who have set a MANUAL or ANON flag are also
loaded. For each counterparty selected, SID is set to the corresponding
identification. Test 1330 commences a loop which allows every
counterparty available to be dealt with in turn. For any currently
selected counterparty (with identification set in SID), the data flow
proceeds to test 1365. Where the order data field OANON has been set by
the ordering party and some stakeholder requires manual confirmation
(MANUAL (SID)), the current potential counterparty is not included in
the short list. Likewise if the ordering party set OMANUAL and some
WO 94/28496 . PCT/AU93/00250~
~63768
-30-
other stakeholder required anonymity (ANON (SID)). In both cases, data
flow returns to test 1330. Otherwise, flow continues at block 1335. At
this point, the system determines the applicable "defined circumstances"
for the order. It uses the order data fields currently loaded and
parameters set in the PSEL DC masterfile (block 1336) to determine this.
At block 1340, pricing parameters including consideration/entitlement
exchange rates (if applicable), commission rates, and discount rates are
selected from the PSEL PRICE master file (block 1350). Using the
"defined circumstances" identification (set in DCID) all potential
counterparties can have different sets of pricing parameters specified
based on any of the order data fields of each order. Test 1360 checks
that all the necessary parameters have been found. It is possible that
the counterparty, though prepared to deal with the ordering party, does
not have a complete set of pricing parameters for the current order
specifications. Such a counterparty is not included in the counterparty
short list, and processing returns to test 1330. At block 1370, the
counterparty is added to the counterparty short list by lncluding the
pricing details in the variables: PRICEFUNC(SID), CR(SID~, DR(SID),
C-C/EDXCHANG(SID), C-CXCHANG(SID), C-NCXCHANG(SID), E-C/EDEXCHANG(SID),
E-CXCHANG(SID), E-NCXCHANG(SID), MANUAL(SID), and ANON(SID). Processing
then returns to test 1330 where the next selected potential counterparty
is dealt with. When all selected potential counterparties have been
processed, program flow returns to block 12S0. At this point a potential
counterparty short list has been obtained.
Blocks 1400 to 1550 in Figs. 13 and 14 depict block 1250 in more
detail, where every potential counterparty has its price offer
calculated, based on thelr individual pricing parameters, for the
currently loaded order. At block 1400 a loop commences allowing each
potential counterparty in the potential counterparty shortlist to be
dealt with in turn. SID is set to the identification of the counterparty
currently selected. Test 1410 checks whether any counterparties are left
for processing. At block 1420, the potential counterparty's price bid is
calculated. Blocks 1490 to 1550 describe this calculation in more
detail. At block 1490 the var~able, INDEX, is assigned the starting
value of the product value range (PMIN). Also, "price" is initialised to
zero. Test 1500 commences a loop, where every index point in the product
~O 94/28496 . 2 ~ 6 3 7 6 8 PCT/AU93100250
-31-
range is traversed. Block 1520 calculates the pricing value returned by
the potential counterparty's pricing function, PRICEFUNC, as stored in
(PRICEFUNC(SID)), at the current index point, and stores the value in
Pl. Block 1530 determines the pay-off amount required by the ordering
party at the current index point and stores this value in P2. At block
1540, the total price at the current index point is calculated by
multiplying Pl by P2. This value is added to the running total stored in
PRICE(SID). At block 1550, the index counter (INDEX) is incremented by
the product step size (PSTEP), and flow returns to the test 1500. When
the end of the product range has been reached (PMAX), flow proceeds to
block 1510, where the calculated price bid is modified by the following
calculation:
PRICE(SID) . PRICE(SID) * E-C/EDXCHANG(SID) * E-CXCHANG(SID) *
E-NCXCHANG(SID).
Returning to block 1430, the price bid stored in PRICE(SID) will
be in the applicable product's consideration/entitlement denomination,
currency denomination, and national currency denomination. The following
steps (block 1430-1470) determine and apply the applicable discount rate
to the calculated price bid (currently in future value terms) to yield a
price bid in present value terms. This is done as follows: At block 1430
the number of days to product maturity ls determined. Block 1440
initialises the loop counter and discount rate divisor. For each day (or
appropriate part thereof) between the current date/time and the product
maturity date/time, the divisor is changed according to the formula
(block 1460):
DIV = DIV * (1 + ((DR(SID) / 100) / 365))
At block 1470, the price bid is ad~usted according to the formula:
PRICE(SID) ~ PRICE(SID) / DIV
Once the price bid in present value terms is known, the potential
counterparty's defined commission is added to the price (block 1480).
Given that CR(SID) is a percentage commission rate, the formula is:
PRICE(SID) _ PRICE(SID) ~ ((CR(SID) / 100) * PRICE (SID))
When test 1410 confirms that every potential counterparty has been
priced, program flow continues at 1255.
The test at 1255 checks whether the order was a "quote only"
order. If so, flow continues at block 1256 where one or more of the
WO 94128496 PCTIAU93/00250~
2~3~68
-32-
counterparty bid prices are selected. At block 1230, the ordering party
is informed of the pricing information gathered. If the order was not a
quote order (that is, it was a real product order), an attempt is now
made to identify a counterparty from the potential counterparty short
list matching the requirements of the current order. This is done at
block 1260. Blocks 1560 to 1616 in Fig 15 describe this process 1n
detail.
Starting at test 1560, a check is made to ensure the potential
counterparty shortlist is not empty. If ~t ls, no match is possible and
flow continues at block 1612. At this point SID is assigned "O" to
indicate that no counterparty was selected from the potential
counterparty short list, before moving to block 1614 where the entire
order (as no part was matched) is queued. When the list is not empty,
program flow continues at block 1570, where the lowest pr~ced
counterparty is selected from the counterparty short list. This
determination is done based upon each potential counterparty's bid price
(PRICE(SID)), being converted to the consideration/entitlement type,
currency, and nat1Onal currency consideration "payment" denominations
sought by the ordering party (that is, PRICE(SID) ~ PRICE(SID) ~
C-C/EDXCHANG(SID) * C-CXCHANG~SID) * C-NCXCHANG(SID)). The counterparty
identificat~on is stored in SID, and its prlce offer is stored in
BPRICE. At block 1580, the followlng check 1s made:
BPRICE > MAXCONSID
If the selected price 1s greater than the ordering party's
specified maximum consideration payment (MAXCONSID) limlt, a match with
the current potential counterparty ls not deemed possible. This must
also be true for any of the remainlng counterparties in the counterparty
short 11st. This part of the matchlng process returns wlthout any
potent1al counterparty in the short list having been selected for a
match (block 1612). Otherwise, the current price is acceptable, and the
process proceeds to attempt a match with the current selected
counterparty.
The next step (block 1590~, requires all the applicable contract,
product, and portfolio absolute loss, expected loss, expected value
limits, and maximum composition lim1ts to be read from the PSEL LIMIT
master file (block 1600) and stored in ALLl(SID), ALL2(SID), ELLl(SID),
~o 94,28496 ~ ~ 6 3 7 ~ 8 PCT/AU93/00250
-33-
ELL2(SID), ELL3(SID), ELL4(SID), ELL5(SID), EVLl(SID), MC(SID) and
MCC(SID). The current absolute and expected losses accumulated are also
read and stored in CAL2(SID), CEL2(5ID), CEL3(SID), CEL4(SID), and
CEL5(5ID).The ELFUNC(SID) and EVFUNC(SID) values are also set for use
when calculating the expected loss and expected value for the current
order. Block 1602 calculates the price of the order entitlement function
using the counterparty product expected loss and expected value
parameters ELFUNC(SID) and EVFUNC(SID). The order's expected loss is
stored in EL(SID); the order's expected value is stored in EV(SID). The
absolute loss function is also determined at block 1602 and it is stored
in AL(SID). Proceedlng to block 1604, the portion of the order which
will not violate the counterparty limits is calculated. This check is
made at test 1606. If no part of the order is matched, process flow
continues at block 1608. The potential counterparty is removed from the
counterparty shortlist.
If some portion of the order is matched with the current
counterparty, processing continues at block 1610. Here the SID is set to
the identification of the matching counterparty. The unmatched portion
(if any) is stored at block 1614 as a new order in the PORD QUEUE
masterfile (block 1616). Flow then returns to test 1261 in Fig. 11. When
a match occurs, program flow returns to block 650. The matched order
must now be confirmed by carrying out a number of additional steps, as
shown in Fig. 16, blocks 1620 to 1641. If no match occurred, processing
of the current order steps, and program flow returns to the beginning
via connector "A". The system is ready to load the next available order.
Matched Order Confirmation
For matched orders to become a contract, a number of additional
actions are required. First, at test 1620, a check for manual
authorisation is made. If required, program flow moves to block 1621
where authorisation requests are sent to the relevant stakeholders.
Block 1623 then tests the replies for any rejections. If one or more
re~ections were received, program flow continues at block 1627 where the
order is re~ected. Otherwise, flow continues at 1624. Block 1624 effects
the consideration payment by creating transact7Ons in the payment shadow
file (PAYACC SHADOW - block 1625). However, this may fail if the
WO 94/28496 PCT/AU93/00250~
2~3~
-34-
accounts specified do not exist or if at least the required
consideration amount is shown not to be available. Test 1626 checks that
"consideration payment" was effected successfully. If "consideration
payment" fails, the matched order is rejected (block 1627), with details
stored in the rejected order master file, PORD REJ (block 1628). The
ordering party is then informed of this event at block 1640.
~ ith successful payment, program flow proceeds to block 1630 where
the counterparty's current accumulated absolute and expected loss
figures are updated (masterfile PSEL LIMIT - block 1631). At block 1632,
the order data field OPRICE is set to the price given by the
counterparty PRICE(SID), and SPRICE set to the counterparty's
identification, SID. At block 1634, the matched order is certified as
confirmed, with full details recorded in the masterfile PORD CONF (block
1636). The next step, block 1638, reports details of the newly created
contingent contract to all stakeholders concerned. Program flow then
returns to the beginning, via connector "A". The system is now ready to
start processing the next order submitted by a specified ordering party.
~O 94/28496 2 1 fi 3 7~ 8 PCT/AU93/00250
.
-35-
6. Life Cycle of Risk Management Contract: Example III
The third example of a risk management contract describes a
contract to manage risk associated with potential future movements in
the value of a specified index of share prices (termed the PTSE 75
index). In summary, the example shows how the system could enable one
party (such as an institutional fund manager) seeking to avoid the
adverse consequences of a significant decline in the future value of the
PTSE 75 index (specifically a decline by June 1994, relative to the
assumed current (January 1993) value of the index) to make a contract
with another, as-yet-unknown, party, such as another fund manager
seeking to avoid the adverse consequences of a significant corresponding
increase in PTSE 75 i ndex value.
The specific offering is one which provides a contract ordering
party with a specified contingent entitlement to a compensatory
Australian dollar future payout upon payment of a calculated up-front
consideration money amount by the ordering party to the as-yet-unknown
counterparty. The future money entitlement is contingent on the value,
at contract maturity date, of the independently determined value of the
PTSE 75 index.
In this example, the relevant key stakeholders are: an application
promoter (BLC Inc); various product sponsors (the relevant one for the
example being BLC Inc itself); various product ordering parties (the
relevant ones for the example being Abbotts & Taylor and Shearer &
Associates); various potential counterparties (the relevant ones for the
example being Abrahamsons and Carpenters Inc); a counterparty guarantor
(CNZ Banking Corporation); and an application regulator (the Pacific
Central Bank).
The timeline depicting the steps in the contract from the first
step (Application Specification) to the final step (Contract Settlement)
is shown in Fig.17. Appendix G contains thirteen detailed explanatory
charts supporting Fig.17. This Appendix should be read together with
the following description.
Looking at the first step in the timeline (Application
Specification) in conjunction with chart G2, it can be seen that BLC Inc
established a Contract APP (Application ID 001) on 91.06.03.17.00.00
.
WO 94128496 PCT/AU93100250~
~i6~68 -36-
(that is, 5pm on June 3, 1991) to deal with economic risk management.
Application ID 001 supports a range of products (Applicable Product ID's
10020-11400).
Looking at the second step in the timeline (Product Specification)
in conjunction with chart G3, it can be seen that BLC Inc was also
Product Sponsor of Product 10061 at the same time (91.06.03.17.00.00).
This Product relates to the Market termed Stock Indices and to the
Sub-market termed PTSE 75. The maturity date for Product 10061 is
94.06.03.17.00.00.00. The consideration for a specific contract
involving Product 10061 is in the form of money (commercial bank
deposits denominated in Australian dollars). The entitlement is also in
the form of commercial bank deposits denominated in Australian dollars,
payable (if necessary) immediately after the Product's specified
maturity date/time.
Looking at the third step in the timeline (Potential Counterparty
Product Pricing Specifications), one can find two entities, Abrahamsons
and Carpenters Inc, acting as potential counterparties for forthcoming
primary product orders dealing with Product 10061. At this point ~n the
timeline (93.01.01.17.00.00.00), 19 months after the specification of
Product 10061, both Abrahamsons and Carpenters Inc have
currently-specified parameters for pricing potentially forthcoming
orders for the product.
Looking at the fourth step in the timeline (Primary Order
Specification), in conjunction with chart G4, it can be seen that an
Ordering Party, Abbotts & Taylor, is seeking a contract, from an
offering party, in Product 10061 at that time (93.01.01.17.37.06.00).
chart G4 shows the specific parameters (entitlement) that Abbotts &
Taylor has defined for the contract it is seeking at this time,
including a maximum acceptable contract consideration amount of 54,000
(denominated in commercial bank, Australian dollars).
In order to provide a more detailed explanation of the following
fifth to seventh steps in the timeline, selected processing block
numbers from Figs. 8-16 will be referred to in brackets as follows:
"t ~".
Looking at the fifth step in the timeline (Order Specification
Pricing) in conjunction with chart G5, it can be seen that Abrahamsons'
~0 94/28496 21 6 3 76 3 PCT/AU93/00250
.. . .
-37-
spec~fied pricing parameters, as set at 93.01.01.17.37.06.00 are used to
price the Abbotts & Taylor order at 93.01.01.17.38.02.00. Abrahamsons'
pric~ng parameters indicate that their appropriate Defined Circumstances
ID for Abbotts & Taylor is 26 [1240]. As is shown, this ID in turn
~ 5 implies a Commission Rate of 1.25%, a D~scount Rate of 10.00% per annum,
a particular set of Component product prices and a particular set of
Assessed Probabilities of Occurrence. In a similar process to that
described for Example I, this results in a Contract Bid Price of 51,920
(denominated in commercial bank, Australian dollars), which Abrahamsons'
parameters calculate will yield them a base margin on the contract of
4,580 (again denominated in commercial bank, Australian dollars) tl250].
Still looking at the fifth step in the timeline, in conjunction
with chart G6, it can be seen that Carpenters Inc specified pricing
parameters, as set at 93.01.01.17.37.06.00, are also used to price the
Abbotts & Taylor order at 93.01.01.17.38.02.00. Carpenters Inc's
pricing parameters indicate that their appropriate Defined Circumstances
ID for Abbotts & Taylor is 17 [1240]. As is shown, this ID in turn
implies a Commission Rate of 1.307., a Discount Rate of 9.80% per annum,
a particular set of Component product prices and a particular set of
Assessed Probabilities of Occurrence. This results ~n a Contract Bid
Price of 53,050 (denominated in commercial bank, Australian dollars),
which Carpenters Inc's parameters calculate will yield them a base
margin on the contract of 5,610 (again denominated in commercial bank,
Australian dollars) [1250].
Again, still looking at the fifth step in the timeline, in
con~unction with chart G7, it can be seen that Abrahamsons'
pricing-related parameters (also set at 93.01.01.17.37.06.00) for
determining the acceptability of ordered-contracts on the basis of their
absolute loss, expected loss, expected value, and maximum portfolio
composition attributes are satisfied by Abbotts & Taylor's order [1604].
From Abrahamsons' perspective, this qualifies Abbotts & Taylor's order
for inclusion in their product/contract portfolio, as long as
Abrahamsons' consideration price bid turns out to be lower than
Carpenters Inc's price bid, and, in turn, this bid ls below the maximum
consideration price that Abbotts ~ Taylor has specified, in its order
specification (chart G4), it is prepared to pay.
W O 94/28496 PCT/AU93/00250 _
21~37~8 ~
-38-
Finally, still looking at the fifth step in the timeline, but now
in conjunction with chart G8, it can be seen that Carpenters Inc's
pricing-related parameters (set at 93.01.01.17.37.06.00) for determining
the acceptability of ordered-contract on the basis of their absolute
loss, expected loss, expected value, and maximum portfolio composition
attributes are also satisfied by Abbotts & Taylor's order. Now, from
Carpenters Inc's perspective, this qualifies Abbotts & Taylor's order
for inclusion in their product/contract portfolio, in this case, as long
as Carpenters Inc's consideration price bid turns out to be lower than
Abrahamsons' price bid, and, in turn, this bid is below the maximum
consideration price that Abbotts & Taylor has specified, in its order
specification (Page G4), it is prepared to pay.
Looking at the sixth step in the timeline (Order Matching), it can
be found that Abrahamsons' price bid of 51,920 is below Carpenters Inc's
bid of 53,050 and, in turn, that the 51,920 amount is below Abbotts &
Taylor's specified maximum consideration price of 54,000. This leads to
a formal matching of Abbotts & Taylor's order by Abrahamsons' at
93.01.01.17.38.07.00 [1260].
The seventh step in the timeline (Order/Contract Confirmation)
takes place five seconds later at 93.01.01.17.38.11.00, after the system
has determined that Abbotts & Taylor is able to (and then does)
immediately pay the required consideration funds amount of 51,920 to
Abrahamsons ~650].
Looking at the eighth step in the timeline (Contract Valuation) in
conjunction with chart G9, one can see a contract valuation report for
Abbotts & Taylor published nearly six hours after confirmation of the
contract, that is, at 93.01.01.23.00.00.00. As can be seen, the market
estimate of the future product value of the PTSE 75 Index at this moment
~s 1970 (with a standard deviation of 333), which implies that this
contract has an expected future value of 53,000 commercial
bank-denominated Australian dollars (with a standard deviation of
21,160). On chart G10 one can see in the equivalent report for
Abrahamsons that their required expected future entitlement payout is
ident~cal to Abbotts & Taylor's expected future ent~tlement rece~pt
(ignoring future fee payments which may be netted against these
payments/receipts).
~p 94/28496 PCT/AU93/00250
~ . 21~37G8
-39-
The ninth step in the timeline (Secondary Order Specification),
detalled on chart Gll, occurs nearly six months after the
above-described contract valuation event; that is, at
93.06.06.08.00.00.00. At this time, Abbotts & Taylor is seeking to sell
~ 5 its position in the contract which was matched/confirmed at
93.01.01.17.38.11.00 ~and at that time assigned the Order ID of
9156515800 by the system) at a price better than 57,000. Shearer &
Associates is prepared to pay 60,000 (commercial bank
deposit-denominated Australian dollars) for this position. In all other
respects the contract's attributes remain unchanged. On chart G12, the
tenth step in the timeline, a contract sale is seen to have occurred at
a price of 58,300, just below the above-described 60,000 upper limit
purchase-price amount specified by Shearer & Associates. This amount is
the current best estimate of the contract's expected future value, with
the standard deviation of this expected future value calculated by the
system, utilizing other recent transaction data, as being 10,610.
Shearer & Associates has now formally taken the place of Abbotts &
Taylor as a stakeholder to the contract.
The eleventh step in the timeline (Contract Valuation) refers to a
contract valuation report published for Shearer & Associates seven
months later, at 94.01.01.17.00.00.00 (see chart G13). As can be seen,
the market estimate of the future product value of the PTSE 75 Index at
this moment is 1800 (with a standard deviation of 283), which implies
that this contract now has an expected future value of 162,360
commercial bank deposit-denominated Australian dollars (with a standard
deviation of 35,160). This is an increase in expected future value of
104,060 for Shearer & Associates since the former valuation date/time.
The above-described market estimate of the future product value is
determined by the system applying a defined composite of
contract-counterparty assessed probabilities of occurrence figures drawn
from the collection of all like contracts recently matched/confirmed by
the system.
The twelfth step in the timeline (Contract Maturity) refers to the
actual determination of the product value at time of maturity,
94.06.03.17.00.00.00. As can be seen on chart G14, this product value
of the PTSE Index was specified by BLC Inc (as Product Sponsor) to be
WO 94/28496 . PCTIAU93/0025~
~ ~37~ -40-
1820, implying a contract value of 187,200 (commercial bank
deposit-denominated Australian dollars) to Shearer & Associates, and a
corresponding obligation on Abrahamsons. The figure of 1820 represents
the actual value of the PTSE share price index at 94.06.03.17.00.00.00
as obtained by BLC Inc from the independently verifiable information
source, the identity of which they would have disclosed at the time they
first announced their sponsorship of trading in the PTSE 75 share index
product.
The thirteenth step in the timeline involves the formal payment of
187,200 (commercial bank deposit-denominated Australian dollars) by
Abrahamsons to Shearer & Associates (ignoring possible fee payments by
one or both parties).
~O 94/28496 2 ~ 6 ~ 8 PCT/ ' U93100250
--41--
7. Description of Consideration/Entitlement Payment Process
The purpose of the CONTRACT APP consideration/entitlement (and
related transactions) payment/receipt process is to effect debits and
~ 5 credi,ts to INVENTCO stakeholder accounts, typically at maturity of acontract, with participating considerat5,on/entitlement transfer (or
exchange) entities, reflecting payment/receipt entitlements and
obligations originated within INVENTCO. The process effects these
payments/receipts in a two-stage process. F5,rst, by debiting/crediting,
on a real-time basis, the relevant shadow records (in the data file
PAYACC SHADOW) of the applicable stakeholder accounts with a
participating consideration/entitlement transfer entity (C/E entity),
external to INVENTC0, w~,th which they ma~,ntain an account. And second,
by periodically effecting, via existing and potential payment
mechanisms, corresponding payment instructions to the payment entities
concerned.Details of the above-described mechanism are as follows.
All INVENTCO stakeholders maintain (a minimum of) two
special-purpose (net-credit balance only) accounts with (at least) one
selected, VIRPRO authorised, C/E transfer ent5,ty. The purpose of
special-purpose accounts is to ensure that only INVENTCO-initiated
debits and credits are capable of being effected to the accounts. Thus,
at any time the balance of each PAYACC SHADO~, file account record should
be equivalent to the true, but usually unknown, time-of-day balance of
the actual account ma~,ntained by the C/E transfer entity.
The purpose of two accounts is to enable only credits to be
effected through one account and only debi,ts through another account.
And the purpose of "net-credit balance on1y" accounts is to ensure that
accumulated debits to the debits-only account never exceed the account
opening balance plus accumulated cred5,ts to the credits-only account.
C/E transfer entities will typ~,cally be (but do not need to be)
institutions of any/all of six types: public/private record-registries
of various types; credit card companies (typically for retail
transactions only); commercial banks; central banks; taxation
authorities; and non-bank clearlng houses and depositori,es.
The resources transferred by these entiti,es may be of any type.
However, most typically, they will be depos5,ts appropriate for the
WO 94/28496 ` PCT/AU93/00250 _
21~7~8 -42-
entity concerned: ~ith respect to public/private record-registries -
entitlement deposits (including shares in financial or physical assets,
participation rights in wagers, and so on). With respect to credit/debit
card companies - normal card company deposits (denominated in national
currencies or synthetic currencies (for example, SDRs)). With respect to
commercial banks - normal bank deposits (denominated in national
currencies or synthetic currencies (for example, SDRs)). With respect to
central banks - exchange settlement account (or equivalent) deposits.
With respect to taxation authorities - taxation account deposits. And
with respect to non-bank clearing houses and depositories - deposits of
financial instruments, precious metals and the like. CONTRACT APP
potential counterparties will also effectively be C/E transfer entities,
as will ordering party guarantors (external to INVENTCO) where they
offer credit to product ordering parties. Also, some accounts will be
trust accounts maintained on behalf of potential counterparties (and
some product ordering parties) involved in applications requiring the
periodic payment of collateral to independent third parties to serve as
an additional security device.
Immediately after the completion of its daily - or more frequent -
transaction processing, and their associated settlement functions, eachC/E transfer entity electronically notifies the applicable CONTRACT APP
of the "opening balances" of all the debit and credit INVENTCO accounts
it maintains (At this stage, the debit account balance should be zero
and the credlt account balance should be greater than or equal to zero).
Where an INVENTCO stakeholder has an overdraft or line-of-credit with
its C/E transfer entity, the credit value of this will be reflected in
the non-zero balance of its credit account at this time.
Upon receipt of the above-described notifications, the applicable
CONTRACT APP updates/confirms its stakeholder shadow balances. Thus, at
this point-in-time, all credit and debit shadow account balances should
be equivalent to their actual debit and credit account balances.
Progressively throughout the day ~where "day" here is likely to be
different for each C/E transfer entity due to a combinat~on of
differences in the time-zone locations of payment entities in relation
to the applicable CONTRACT APP, and the likely different account
processing cycles of these entities), INVENTCO-stakeholder- authorised
~0 94/28496 2 1 6 3 ~ 6 8 PCT/AU93/00250
-43-
debits and credits to INVENTCO stakeholder shadow accounts are effected
on a real-time basis - debits to debit accounts and credits to credit
accounts. At all times, the CONTRACT APP ensures that the cumulative
debit balance of each stakeholder's debits account does not exceed the
- 5 "opening balance" plus the cumulative credit balance of the
stakeholder's credit account. Thus, at any time, for every INVENTCO
stakeholder, the combination of each stakeholder's debit account and
credit account will represent the "true", net, time-of-day value of the
stakeholder's two actual special-purpose accounts maintained external to
INVENTCO.
Debits and credits to INVENTCO stakeholder accounts are effected
according to strict rules and conditions, being different for credits
and debits. Credits can be made to any INVENTCO stakeholder's credit
account with its nominated C/E transfer entity by any other INVENTCO
stakeholder for any reason. Naturally, as INVENTCO stakeholders will not
know the account details of other stakeholders, such credits will be
effected either automatically, according to information and rules known
by the applicable CONTRACT APP, or semi-automatically by way of an
INVENTCO stakeholder requesting from VIRPRO, as they need to do so, a
credit-account number of the stakeholder to which they wish to transfer
assets. This account number may only be valid for a nominated period and
would not typically be the specified stakeholder's actual account number
with its nominated consideration/entitlement transfer entity - it would
only be a reference to an INVENTCO file containing this number.
On the other hand, debits can only be made to an INVENTCO
stakeholder's debit account with its nominated C/E transfer entity by
the stakeholder ltself, and by other stakeholders explicitly granted
this right by each stakeholder, subject to these other stakeholders
exercising this right according to the rules and conditions specified
for them.
~here an INVENTCO stakeholder seeks to initiate/authorise debits
to its nominated account(s) on its own, this can only be done through
the stakeholder satisfactorily completing the identification and
security procedures set down by their C/E consideration/entitlement
transfer entity (and reflected in VIRPRO-specified INVENTCO
communication procedures). The type of procedure set down by all
WO 94/28496 PCT/AU93/00250~
21~7~8
..
--44--
participating C/E transfer entities involves (at least) the following:
First, the consideration/entitlement transfer entity supplying VIRPRO
with a confidential file of account Pin numbers corresponding to each of
its INVENTCO stakeholder debit accounts, and a similarly confidential
"black box" which, by initiating any of a number of possible proprietary
password request-response processes involving any one of its customers
possessing the appropr~ate device(s), confirms that remote messages
received from that customer, and processed by the "black box", are
authentic. Second, the consideration/ent~tlement transfer entity
supplying their INVENTCO customers with a programmable smart card (or
equivalent device) enabling each customer, remotely - via telephone or
direct computer line, to unambiguously confirm their identity wlth their
INVENTCO-maintained account, thereby having the capability to authorise
debits to their account within predefined parameters concerning factors
such as maximum transaction amounts, possible transaction types, account
usage patterns and so on. Third, INVENTCO providing the mechanisms for
d~rect, confidential, stakeholder communications with their C/E transfer
entity shadow debit accounts, and the formal updating of these accounts,
through non real-time processes, utilizing the unique time-stamped
reference numbers created as/when stakeholders authorise access to the~r
account records.
Where an INVENTCO stakeholder has authorised other INVENTCO
stakeholders to initiate deb~ts to (any of) its nominated account(s)
according to a standing authority of some type, this can only be done
through the authorised stakeholder itself satisfactorily completing the
identification and security procedures set down by the
authorisation-granting stakeholder's nominated C/E transfer entity (and
reflected ~n VIRPRO-specified INVENTCO communication procedures). Once
again, the type of procedure, set down by all participating C/E transfer
entit~es in this respect, involves (at least) the following: F~rst, the
C/E transfer entity supplying VIRPRO with a confldential file of account
Pln numbers corresponding to each of its INVENTCO stakeholder debit
accounts and each other INVENTCO stakeholder which has been authorised
to effect debits (within defined parameters~ to these accounts. Second,
the C/E transfer entity supplying VIRPRO with a similarly confidential
black box which, by in~tiat~ng any of a number of possible proprietary
~0 94/28496 2 1 ~ 3 7 6 8 PCT/AU93/00250
-45-
password request-response processes involving an entity nominated by any
of it:s customers possessing the appropriate device(s), confirms that
remote messages received from that authorised entity, and processed by
the black box, are authentic. Third, the C/E transfer entity supplying
~ 5 their INVENTCO customers with a collection of programmable smart cards
(or equivalent devices), for distribution to these authorised entities,
enabling each authorised entity, remotely - via telephone or direct
computer line - to unambiguously confirm their identity with the
customer's PAYACC SHADO~ account, thereby having the capability to
authorise debits to this account (again, within predefined parameters
concerning factors such as maximum transaction amounts, possible
transaction types, account usage patterns and so on). And four, INVENTCO
providing the mechanisms for direct, confidential, authorised
stakeholder communications with a stakeholder's C/E transfer entity
slladow debit account(s).
At the end of each C/E transfer entity's specified day (or part of
a day), the applicable CONTRACT APP transfers (at least) two things to
the entity: First, if required, a series of figures representing the
exchange settlement (or equivalent) accounting entries it has or will
communicate to the C/E transfer entity's appropriate clearing authority
(for each of the applicable consideration/entitlement denomination,
currency and national currency types of the payments/receipts involved)
where these figures represent the balancing net debit or credit figure
corresponding to the aggregation of all of the entity's INVENTCO
customer transactions in the prior day. And second, a detailed file of
all customer transactions effected during the day (corresponding, if
required, to the above-described net figures). Upon their receipt of
these transactions and summary figures, the C/E transfer entity then
debits/credits each transaction to the appropriate actual customer
accounts, enabling new "closing" account balances to be calculated
(these "closing" balances should be exactly the same as the end-of-day
balances commumicated by the applicable CONTRACT APPS with it's file of
customer transactions). In turn, these "closing balances" become the C/E
transfer entity's account "opening balances" for the next day. The
CONTRACT APPS notification process then repeats itself.
~here applicable, at days-end for the "clearing house" of clusters
WO 94/28496 PCTtAU93/00250~
~ 1 ~37~ ~ -46-
of like C/E transfer entities (for example, a national central bank),
CONTRACT APP transfers netted exchange settlement accounting entries to
the clearing houses concerned. These entries serve to "balance the
individual customer account entries transferred to each associated C/E
transfer entity individually.
8. Industrial Applicability
The invention has industrial application in the use of electrical
computing devices and data communications. The apparatus and methods
described allow the management of risk in an automated manner by means
of programming of the computing devices. The types of events associated
with the risk management apparatus and methodologies includes physical
and technical phenomena, and therefore have value in the field of
economic endeavour.
~O 94/28496 216 ~ 7 ~ 8 PCT/AU93/00250
- 47 -
APPENDIX A
GLOSSARY OF KEY TERMS
~ 5 A.
Alpha (X)
The Ordering party-specified event value corresponding to the Xth
future product event value contract entitlement payoff (payout)
inflection point.
Application Promoter
An entity authorised by VIRPRO that specifies and administers
defined rules and regulations underlying a defined CONTRACT APP -
~ncluding the specific products offered for trading; categories
of, and conditions of involvement, of stakeholders; nature of
lnvolvement and dispute resolution procedures of stakeholders.
Automatic/manual deal and no deal flags
Xndicators notified by each stakeholder to CONTRACT APP specifying
1:he manner ~n which that stakeholder wishes to deal with each
other stakeholder.
AXSCO
A communications co-ordination and security system, linked to all
stakeholders and component applications.
.
B.
~.
Base Pricing probabilities
The prices set by sellers for unit entitlement payoffs of a
WO 94/28496 216 3 7 68 ~ PCT/AU93/002501~
-- 48 --
contract at each of its possible future index values denominated
in the contract's formally specified consideration/entitlement,
currency and national currency.
Beta (X)
The Ordering party-specified desired entitlement payoff (payout)
amount in the desired currency denomination of contract
entitlement payout (payoff) and national currency denomination of
contract entitlement payout (payoff) corresponding to the Xth
event value inflection point.
Bilateral Obligations Netting indicator
An indicator that individual 'rolling' net present values of
future payment/receipt commitments to/from all pairs of
participating stakeholders are to be netted.
Bilateral Payments Netting indicator
An indicator that lndividual end-of-day gross payments/receipts
to/from all pairs of participating INVENTCO stakeholders are to be
netted.
Commission rate
The minimum required percentage profit margin required by a
Potential Counterparty above the "breakeven" bid price for an
Ordering party purchase order.
Consideration/Entitlement Transfer Entity
An entity acceptable to VIRPRO and the Application Promoter,
satisfy~ng defined minimum standards of financial strength, credit
standing and integrity, able to maintain Consideration/entitlement
~'O 94t28496 . 2 1 G 3 7 ~ ~ PCT/AU93/00250
-- 49 --
accounts on behalf of stakeholders and effect transfers of those
assets as directed.
CONTRACT APP stakeholder types
Expected stakeholder types are Application Promoter, Product
Sponsor, Product Ordering party, Counterparty,
Counterparty-Guarantor, Regulator, Consideration/entitlement
Transfer Entities and Miscellaneous other parties.
Contract and Product "absolute loss" limit
A value limit specified by a potential counterparty of the maximum
absolute loss lt is prepared to sustain on a contract/product
lrrespective of the assessment of the llkelihood of any particular
level of possible loss being incurred.
Contract and Product "expected loss" llmit
A value llmlt speclfied by a potentlal counterparty of the maxlmum
expected loss ~t is prepared to sustaln on a contract/product
based on the counterparty's assessment of the likelihood of all
levels of posslble loss being lncurred.
Contract Authorlsation
A process of ver~fylng that an Ordering Party product purchase
order contalns data appropriate to the product being sought and
that the Ordering Party is accurately ldentlfied and credentialled.
Contract Collateralisation indicator
A descriptor set by the Appllcation Promoter specifylng whether
and on what basls, counterpartles may be requlred to per~odically
transfer assets/monles (collateral) to an lndependent trust fund
WO 94128496 PCT/AU93100250
21~37~8 ~ `
- 50 -
to ensure they will be able to meet their potential entitlement
payoff obligations on the maturity date of a contract.
Contract Confirmation
The process of securing the positive agreement of all affected
stakeholders to a purchase order, including acknowledgement by the
relevant Consideration/entitlement transfer entity of the Ordering
party's ability to pay the required product consideration and
fees, either automatically or through manual approvals.
Contract Matching
See Ordering party/Potential counterparty matching process.
Contractual Obligation
a. A binding commitment one entity (or group of entities) has
to provide products or services or information to another entity
(or group of entities) in exchange for an agreed quantity of
other products, services or information.
b. A binding commitment all entities have to the network and
general management system entity VIRPRO and thus to each other, to
accept constraints on their activities imposed by other authorised
entities on terms specified and agreed to by them as a condition
of their participation in one or more of the component systems.
Contract Portfolio Netting
A term used to describe the process of "setting-off" or
"netting", the future payment entitlement obligations between
Ordering parties and Counterparties, either bi-laterally or
multi-laterally.
~O 94/28496 ~ ~ 6 3 ~ 6 ~ PCT/AU93/00250
-- 51 --
Currency and National Currency exchange rates
The rates used to convert contract consideration/entitlement
currency and national currency requirements into the product's
~ 5 consideration/entitlement currency and national currency
denomination.
D.
Deal flag
An indicator or "flag" notified to CONTRACT APP signifying that
the stakeholder is satisfied to deal unreservedly with the
stakeholder against whom the flag has been set.
Defined Circumstances
, ,~,
The possible combinations of the categories of product-order
information provided by Ordering parties.
Defined Probab~lity Distributions
A set of pricing probability parameters specified by an Orderlng
party and including at least, a probability distribution type
identifier, the expected value of the distribution, the standard
deviation of the distribution and a probability distribution
adjustment value or function.
Desired Currency Denomination of Contract Entitlement
A term indicating the currency in which an Ordering party wishes
to receive potential entitlement payments from the sought contract.
., .
Desired Currency Denomination of Consideration Payment
A term indicating the currency in which an Ordering party wishes
to pay the required consideration for the contract sought.
WO 94/28496 ~ : PCT/AU93/00250~
~3~
- 52 -
Desired National currency Denomination of Contract Entitlement
A term indicating the National currency in which an Ordering party
wishes to receive potential entitlement payments from the sought
contract.
Desired National currency Denomination of Consideration Payment
A term indicating the National currency in which the Ordering
party wishes to pay the required consideration for the contract
being sought.
Discount rate
The rate used to determine the present value of a potential
counterparty's expected future entitlements.
E.
Entitlement
The payout expected by the offering party at maturity as specified
for each outcome in the range of outcomes. The payout can be both
positive and negative in value over the range of outcomes, and can
be in the form of money or other non-money types of goods,
services, promises, credits or warrants.
EV-CE pricing
A price d~scovery mechanism for primary contracts meaning
"expected value certainty equivalent pricing" being the calculated
expected present value or future value of the contract.
~0 94/28496 ~3 7 6 ~ PCT/AUg3/00250
, ,
.: . . .; .
- 53 -
Expected Value
A function in EV-CE pricing which means the sum of the products of
all possible contract entitlement payoff/payout amounts and the
~ 5 Ordering party's/Counterparty's assessment of the probability of
occurrence of the future events which would contractually give
- rise to these entitlement payoff amounts.
Expected value limits on a Counterparty's aggregate product portfolio
Optional value limits specified by a Potential counterparty at
any one time, where time can be specified in terms including
"equivalent maturity date"; "same-month maturity date" and "all
possible maturity dates" including product expected loss limits
and maximum (and possibly minimum) proportion of the expected
total loss of the aggregate of the Counterparty's product
portfolio that can be accounted for by the expected loss on the
individual contract/product.
G.
Gamma(X)
The Ordering party-specified desired shape of the function between
each of the co-ordinates Alpha(l), Beta(l) and Alpha(2), Beta(2)
and so on; such that Gamma can represent all possible
mathematically definable shapes.
I-INVENTCO
- The infrastructure component of INVENTCO.
WO 94/28496 PCT/AU93/00250 ~
21~768 54 _
, INVENTCO
A collection of one or more (potentially interrelated) systems, where
each system is the combination of a telecommunications, computing and
other forms of infrastructure, and a variety of markets and support
services distributed by this infrastructure.
M.
M-INVENTCO
A depository of VIRPRO authorised "markets" application software.
Manual deal flag
An indicator or "flag" notified to CONTRACT APP by a stakeholder
signifying that the stakeholder wishes to manually approve a
transaction involving the other stakeholder against whom the flag
has been set.
Multilateral Payments Netting indicator
An indicator that individual end-of-day gross payments/receipts
to/from all participating stakeholders fromlto a specified third
party trustee/clearing entity are to be netted.
Multilateral Obligations Netting indicator
An indicator that individual 'rolling' net present values of
future payment/receipt commitments to/from all participating
stakeholders from/to a third party trustee/clearing entity are to
be netted.
~o 94,284g6 2 1 ~ 3 ~ 6 8 PCT/AU93100250
,
- 55 -
N.
Negative Contract Payoffs
A type of contract in which the contract Ordering party may have a
contingent payoff to the contract's Potential counterparty (i.e.
the reverse of a normal contract).
No Deal flag
An indicator or "flag" notified to a CONTRACT APP by a stakeholder
signifying that the stakeholder does not wish to deal in any way
with the other stakeholder against whom the flag has been set.
O.
Ordering party Contingent Claims Function
Specifications of a product payoff or a mathematical function to
calculate an Ordering party's product payoff requirement.
Portfolio Product "expected loss" limit
A value limit, specified by a potential Counterparty, of the
maximum expected loss the potential Counterparty is prepared to
sustain on its product portfolio based on the Counterparty's
assessment of the likelihood of all levels of possible loss being
incurred.
Product Ordering party
An entity acceptable to VIRPRO and the Application Promoter,
interested in and able to acquire a CONTRACT APP product.
WO 94/28496 i PCT/AU93/00250~
2~6~768
- 56 -
Product Establishment date/time
The date/time an Application Promoter first offers a defined
product for trading.
S
Product future event value "density" indicator
An indicator specifying the number of intermediate points between
the minimum and maximum future event product definition values
specified for the product by the Application Promoter/Product
Sponsor.
Product event value "width" indicator
An indicator specifying the range (minimum-maximum) of future
event values accommodated by the product as set by the Application
Promoter/Product Sponsor.
Product future event value
A term used to indlcate the actual value of a defined product at
its date/time of maturity.
Product Maturity date/time
The date-time at which the Application Promoter is required to
make a determination of the actual event value to enable
entitlement and related payoffs on successful contracts.
Product Price Quote requests
A type of product purchase order for which the matching process is
terminated and the result communicated to the Ordering party,
when a desired price bid or range of price bids has been obtained.
~o 94,28496 2 ~ ~ 3 7 ~ ~ PCT/AUg3/00250
- 57 -
Product Purchase Orders
Specific product purchase orders for which the Ordering party is
seeking a potential Counterparty match, which may be of three
types: automatic orders; manual orders and "hide" orders.
Product Purchase Order withdrawals
Ordering party-initiated requests to withdraw from processing
pre-submitted but as yet unconfirmed product purchase orders.
Product potential Counterparty
An entity acceptable to VIRPRO and the Application Promoter,
lS exceeding a defined minimum standard of financial strength, credit
standing and integrity, offering defined CONTRACT APP products to
product Ordering parties.
Product Sponsor
An entity acceptable to VIRPRO and the Application Promoter,
havlng responsibillty for detailed definition of product
parameters including the continual determination of product values
over time.
R.
Regulator
An entity acceptable to VIRPRO having local, state, national or
international jurisdiction over one or more CONTRACT APPS.
-
WO 94/28496 . PCT/AU93/00250
~lG3~68 - ~8 -
S.
Set of Pricing Probabllities
The range of probabilities a potential Counterparty applies to a
class of Ordering party order, specif7ed by the value of "defined
circumstances" and applying to every feasible future product event
defined for that product by an Application Promoter.
Stakeholder
An entity that is a registered participant in one or more of
INVENTCO's component parts.
V.
Value Dates
The respective dates/times at wh~ch matched contract consideration
and entitlements are agreed to be made by the relevant Order~ng
party/Counterparty to a contract.
VIRPRO
The network and general management system component of INVENTCO.
30 "X"
A term ~ndicating the number of contract payoff (payout)
inflection points the Ordering party is seeking within the
allowable range of future product event values (~ncluding the
3~ value range extremity points).
~O 94/28496 . 2 1 ~ 3 7 6 8 PCT/AU93/00250
APPENDIX B
CONTRACT APPS
~ 5 Overview
CONTRACT APPS is a term used to refer to certain types of units of
applications software which can, but do not need to, reside within an
INVENTCO system's (M-INVENTCO) depository of "markets" software. The
purpose of individual CONTRACT APPS is two-fold: First, to effect the
trading/exchange/transfer of risk aversion transactions (and derivatives
of these transactions) between particlpating ordering parties and
counterparties on terms acceptable to the parties involved as well as to
others within INVENTCO registered as having a legitimate interest in the
nature, size and composition of these trades/exchanges/transfers. And
second, to appropriately manage all matched/confirmed contracts through
to their time of maturity, including their ultimate settlement.
Individual CONTRACT APPS perform theses tasks according to the
specific rules they embody, defined by their own stakeholders. CONTRACT
APPS effectively reside upon AXSCO and within M-INVENTCO.
Stakeholder Types
CONTRACT APPS accommodate eight (and potentially fewer) generic
types of their "own" stakeholders ~as distinct from other INVENTCO
stakeholders) termed: application promoter, product sponsors, product
ordering parties, potential product counterparties,
counterparty-guarantors, regulators, consideration/entltlement transfer
entities, and other miscellaneous parties.
Some details of these stakeholders are as as follows: an
appl~cation promoter is an entity having overall responsibility for the
functioning of a CONTRACT APP (that responsibility having been granted by
VIRPRO); a product sponsor ls an entity which promotes and administers
the rules of trading, and subsequent management, of defined contingent
~ cla~ms contracting product(s) selected for lnclusion in a CONTRACT APP by
its application promoter; a product ordering party is an entity seeking
to acquire a CONTRACT APP product from a potential product counterparty
(where a product ordering party can also be a product counterparty); a
WO 94/28496 PCT/AU93/00250~
~ ~3~8
-60-
potential product counterparty is an entity potentially prepared to
sat~sfy the CONTRACT APP product needs of a product ordering party (where
a potential product counterparty can also be a product ordering party); a
counterparty-guarantor is an entity guaranteeing a product counterparty's
ability to settle any/all of ~ts potential entitlement transfer
obligations to a product ordering party to which it has become a
counterparty as a result of a CONTRACT APP effected "match"; regulators
are entities overseeing the on-going performance of all other
stakeholders involved in a CONTRACT APP, especially
counterparty-guarantors; consideration/entitlement transfer entities are
entities with which all other CONTRACT APP stakeholders maintain
"accounts" to transfer requ~red considerations/entitlements to/from all
each other; and miscellaneous parties are all other entities having a
defined stake in the functioning of a CONTRACT APP.
Miscellaneous parties include: independent entities contracted by
application promoters or product sponsors to formally determine the
"value" of products on their date-of-maturity; multilateral obligations
and payment netting trustee/clearing entity organisations; independent
(non-regulator) taxation and other governmental authorities; electronic
"gateway" providers (external to INVENTCO); and host system organizations
(in the case of CONTRACT APPS within INVENTCO systems linked to a common
host system). CONTRACT APPS accommodate any number of their own
stakeholders of each of the above-defined generic types.
Product Types
CONTRACT APPS can support risk aversion contract "product types"
with any combination of values of multiple attributes, including: the
fundamental nature/purpose of the product; the establishment/maturity
date/time of the product; the considerat~on/entitlement denomination
type, currency (if applicable), and national currency (if applicable)
consideration/ent~tlement identifiers associated with the product; the
"width" and "density" identifiers of possible future event values of the
product; and miscellaneous other product descriptors.
The "fundamental nature/purpose of the product" attribute may
incorporate ~dentifiers including: a conditional entitlement-payoff
dimensioins identifier; a market identifier; a sub-market identifier; and
~0 94/28496 2 1 6 3 7 6 8 PCT/AU93/00250
-61-
a market-type identifier. The "conditional entitlement-payoff dimensions
identifier" specifies the number of dimensions to an ordering party's
sought-after conditional entitlement-payoffs. The market identifier
specifies whether the product relates to an "actual" or "perceived"
phenomenon (or phenomena), the number of such phenomena ~if applicable),
and the applicable phenomenon category (for example, industrial,
scientific, financial market hedging, and so on). The sub-market
ident~fier provides a more specific description of the product concerned.
The market-type identifier specifies the applicable future period
date/time (where this can be anything - for example, "at a defined
contract maturity date/time", "at a specified time on or before contract
maturity date/time", and so on), and type-of-future event involved
(where, again, this can be anything - for example, as an indicator of
some relative value of a phenomenon (spot value, average value and so
on), or as an ~ndicator of the "rate-of-change" of some value of a
phenomenon.
The "establishment and maturity date/time of the product" attribute
specifies, respectively, the date/time an application promoter first
offered a product for trading, and the dateltime at which the defined
product matures (that is, the date/time at which the product sponsor is
required to make a determination of the actual event value at that
dateltime so enabling contract entitlement transfers to be effected).
The "consideration/entitlement denomination type, currency (if
applicable), and national currency (if applicable)
considerationlentitlement identifiers associated with the product"
attribute specify: the type of considerationlentitlement involved (where
this can include rights and entitlements, physical assets, and "money" of
all possible types); in the case of a "money" consideration/entitlement
type, the currency of the consideration/entitlement (where such currency
types can include: public/private record-depository deposits, commercial
credit card company deposits, commercial bank deposits, central bank
deposits, taxation authority deposits, and deposits in non-bank clearing
~ houses and depositories, and the like); and, again, in the case of a"money" considerationlentitlement type, the national currency of the
considerationlentitlement identifier (where such national currency types
can be in any national currency, or form of synthetic currency).
-
W O 94/28496 ~ PCTtAU93/00250
2 ~6 ~ 68 -62-
The "width and density identifiers of possible future event values
of the product" attribute specifies, respectively: the minimum and
maximum values of the allowable range of future event values accommodated
by a product; and the number of intermediate points between the defined
minimum and maximum future event values accommodated by the product.
The "miscellaneous other product descriptors" attribute specifies
such things as: the degree of stakeholder access granted the product by
the application promoter in question; the forms of trading-services
granted the product by the application promoter in question (where this
product attribute specifies the accessibility of the product to a range
of feasible "stakeholder services" with respect to such things as
contract portfolio netting, contract collateralisation, consideration
credit provision, ordering party ability to specify negative contract
entitlements, and availability of secondary/derivative market product
trading) ; and the degrees of trading, clearing and settlement
"transparency" granted the product by the application promoter in
question.
Transaction Types
A range of primary, secondary, derivative-primary, and
derivative-secondary risk aversion contract transactions are accommodated
by CONTRACT APPS.
The range of "primary" (and derivative-primary (options, for
example)) risk avers~on contract transaction-types (handled principally
by Processes 2 and 4 - described in Appendix C) include: ordering party
product orders (and option orders) for which the ordering party is
seeking a counterparty "match", ordering-party prlce quote (and options
price quote) requests; and ordering-party withdrawals of existing product
orders (and withdrawal of options on product orders). Ordering party
product orders consist of: automatic orders and manual orders. Automatic
orders consist of: normal-automatic orders (being orders the ordering
party is prepared to have matched automatically, sub~ect only to the
constraints defined in the ordering party's order, ~n add~tion to
whatever "match" constraints other CONTRACT APP stakeholders have
prespecified), and anonymous-automatic orders (being orders the ordering
party ~s prepared to have matched automatically, subject to the
~O 94/28496 2~ 376 8 PCT/AU93/00250
,
-63-
constraints defined in the ordering party's order, in addition to
whatever "match" constraints other CONTRACT APP stakeholders have
prespecified, provided that no CONTRACT APP stakeholder has sought to
manually authorise the transaction and, through so doing, being able to
5 potentially identify the ordering party). Manual orders consist of
normal-manual orders (being orders the ordering party wishes to manually
authorise before they are finalised - that is, after a counterparty
"match~ has been effected but before the contract has been "confirmed" -
subject only to ~he constraints defined in the ordering party's order, in
addition to whatever "match" constraints other CONTRACT APP stakeholders
have prespecified); and anonymous-manual orders (being orders the
ordering party wishes to manually authorise before they are finalised -
that is, after a counterparty "match" has been effected but before the
contract has been "confirmed" - subject to the constraints defined in the
ordering party's order, in addition to whatever "match" constraints other
CONTRACT APP stakeholders have prespecified, provided that no CONTRACT
APP stakeholder has also sought to manually authorise the transaction
and, through so doing, potentially identify the ordering party).
The range of "secondary" (and derivative-secondary (options, for
example) risk aversion contract transaction-types (handled principally by
Processes 3 and 5 - described in Appendix B) include: acquiring party
product orders (and option orders) for which the acquiring party is
seeking to "acquire" the position of a specified "risk counterparty"
stakeholder in an existing contract; acquiring-party product price
indications (and option prlce indications); and acquirlng-party
withdrawals of existing product orders (and option withdrawals).
Acquiring party product orders for which the acquiring party is
seeking to "acquire" the position of a specified "risk counterparty"
stakeholder in an existing contract, consist of automatic orders and
manual orders.
Automatic orders consist of: normal-automatic orders (being orders
the acquiring party is prepared to have matched automatically, sub~ect
only to the constraints defined in the acquiring party's order, in
addition to whatever "match" constraints other CONTRACT APP stakeholders
have prespecified); and anonymous-automatic orders (being orders the
acquiring party is prepared to have matched automatically, sub~ect to the
WO 94/28496 - PCTtAU93/00250_
21 63~8 -64-
constraints defined in the acquiring party's order, in addition to
whatever "match" constraints other CONTRACT APP stakeholders have
prespecified, provided that no CONTRACT APP stakeholder has sought to
manually authorise the transaction and, through so doing, being able to
potentially identify the acquiring party).
Manual orders consist of normal-manual orders (being orders the
acquiring party wishes to manually authorise before they are finalised -
that is, after a "match" has been effected but before the contract "sale"
is "confirmed" - subject only to the constraints defined in the acquiring
party's order, in addition to whatever "match" constraints other CONTRACT
APP stakeholders have prespecified); and anonymous-manual orders (being
orders the acquiring party wishes to manually authorise before they are
finalised - that is, after a "match" has been effected but before the
contract "sale" is "confirmed" - subject to the constraints defined in
the acquiring party's order, in addition to whatever "match" constraints
other CONTRACT APP stakeholders have prespecified, provided that no
CONTRACT APP stakeholder has also sought to manually authorise the
transaction and, through so doing, potentially identify the acquiring
party).
Primarv Product Pricinq Process Types
CONTRACT APPS enable potential counterparties to automatlcally
establish "bids" on any defined (primary and derivative-primary) product
order according to either an "expected value/utility-certainty
equivalent" (EV/U-CE) pricing regime, or any other
mathematically-definable pricing regime.
In the case of an "expected value-certainty equivalent" (EV-CE)
pricing regime, each potential counterparty specifies, amongst other
things: an indicator of certain deflned attributes of an as-yet-unknown
product order; a base commission rate; a base discount rate; (if
applicable) a set of base consideration/entitlement denom~nation,
currency, and national currency exchange rates; base unit product prices;
and desired adjustments to the preceding base-bid-price determinants
dependent on any specific order (submitted by a specified ordering party).
The above-described indicator of certain defined attributes of an
as-yet-unknow.n.product order (termed, defined circumstances) may reflect
~O 94/28496 2 1 6 3 7 6 8 PCT/AU93/002~0
-65-
any combination of the multiple characteristics of an order (irrespective
of the ordering party concerned), including: the multiple attributes of
the contingent claims function sought; the ordering party's interest or
otherwise in being granted credit by a counterparty; the ordering party's
interest or otherwise in participating in the possible netting and
collateralisation features of the APP; and the maximum (and possibly
- minimum) consideration amount the ordering party is prepared to pay for
their defined product. The above-described base commission rate specifies
the minimum required percentage profit margin required by the
counterparty above their breakeven consideration bid price for a product
order.
l'he above-described base discount rate determines the present value
of the counterparty's expected future entitlement associated with a
contract (net of the ordering party's consideration, and making allowance
for the future income stream this consideration is expected to generate).
The above-described set of base consideration/entitlement denomination,
currency and national currency -exchange rates are used, where applicable,
to convert an ordering party's contract requirements into the base
consideration/entitlement denomination, currency and national currency of
the product so enabling the contract matching process to make like
comparisons of counterparty bids for product orders.
The above-described base unit product prices are prices set by
potential counterparties for unit entitlement-payoffs of a contract at
each of its possible future values, denominated in the contract's
formally specified consideration/entitlement type and, if applicable,
currency type and national currency type (where these unit prices can be
specified as directly input figures for every feasible future product
event (the sum of which may or may not add to 1), or as parameters of
defined mathematical functions). The above-described desired adjustments
to the preceding base-bid-price determinants dependent on the specific
ordering party submitting a specific order can include: a commission rate
adjustment; a discount rate adjustment; a considerationldenomination
exchange rate adjustment; a currency exchange rate ad~ustment; and a
nationa'l currency exchange rate ad~ustment.
In the case of an "expected utility-certainty equivalent" (EU-CE)
pricing regime, each potential counterparty specifies all of the
WO 94/28496 PCT/AU93/00250
~3768 -66-
above-described parameters applicable to a EV-CE pricing regime as well
as "utility bench-mark" figures for all possible consideration and
entitlement "payment amounts" which could, conceivably, be associated
with a product/contract.
r
Primary Product Matching Process Types
CONTRACT APPS may similarly accommodate any of a number of possible
(primary and derivative-primary) order matching processes where these
processes can be of multiple types, including sequential processes and
10 simultaneous processes.
Sequential order matching processes can be characterised according
to the "sequence determining" and "matching" rules they embody, where
"sequence" rules may be of various types: "last-in-first-out (LIFO)",
"first-in-first-out" (FIFO)", priced priority, and so on; and matching
15 rules may also be of various types - for example, a specific matching
process could seek, for each product ordering party, a counterparty (or
counterparties) offering a product price at or below the maximum prlce
the orderlng party is prepared to pay (where the determined contract
price could be either the lowest price offered by a potent7al
20 counterparty, the mid-point between the an ordering party's specified
"maximum consideration amount" and the lowest price offered by a
potential counterparty, and so on); or seek for each potential product
counterparty an ordering party prepared to pay the maximum price above a
prlce at which the counterparty is prepared to deal (here, the determined
25 contract price could be either: the ordering party's "maximum
consideration amount " price, the mid point between the minimum price the
counterparty is prepared to receive and the ordering party's "maximum
consideration amount" price, and so on).
Simultaneous order matching processes are those seeking some type
30 of optimum solution according to pre-defined objectives. For example:
"maximise the number of ordering party-counterparty matches"; "maximize
the aggregate consideration and/or entitlement value of ordering
party-counterparty matches"; or "minimize the value of a function
specifying the sum of the differences (possibly weighted according to
35 their perceived importance) between the actual and desired values of
match attributes of ordering parties and counterparties".
~0 94/28496 21 & 3 7 6~ PCT/AU93/00250
-67-
Both of the above-described sequential and simultaneous matching
processes can also accommodate conditional contract matching rules; and
pre and post tax price optimisation mechanisms.
Application Types
CONTRACT APPS may be: "in-house" APPS or "public" APPS; "single
potential counterparty" APP5 or "multiple potential counterparty" APPS;
APPS with differing degrees and forms of "regulator" oversight of other
application stakeholders; and APPS with differing degrees and forms of
"counterparty-guarantor" oversight of product potential counterparties.
CONTRACT APPS support consideration "payment" value dates being
"immediate" (meaning exactly the time at which a contract match is
confirmed); or deferred until a defined time in the future, measured in
terms of seconds, minutes, hours, or days. Similarly, CONTRACT APPS
support entitlement "payment" value dates being "immediate" (meaning
exactly the time at which the applicable application promoter formally
notifies other CONTRACT APP stakeholders of the "result" of a maturing
contract); or deferred until a defined time after the "result" of a
maturing contract is known.
CONTRACT APPS allow contracts to be modified and liquidated after
their creation. Contracts can be modified through: direct negotiation by
the rlelevant "risk counterparties" to a particular contract; or the
purchase/sale of "derivative" secondary risk aversion contract
transactions (See Process 5 description in Appendix C). Contracts can be
similarly liquidated after their creation through sale of the contract
(within or outside INVENTCO); and through direct negotiation between the
initial ordering party and counterparties to the contract. They can also
be effectively liquidated through the ordering party/counterparty
acquiring a mirror image of the contract to which they are a party
(with~n or outside of INVENTCO).
Post Order Process Tvpes
CONTRACT APPS undertake various generic types of
"post order-process" management functions for all the above-described
generic types of "transactions", including: a function which maintains a
formal record of contractual commitments entered into by all CONTRACT APP
WO 94/28496 . . - PCT/AU93/00250 ~
2 i ~
-68-
stakeholders with one another, and with VIRPRO-authorised entities
external to either the applicable CONTRACT APP or INVENTCO overall; a
function which effects the independent valuat~on of consideration and
entitlement obligations between CONTRACT APP stakeholders, and between
CONTRACT APP stakeholders and VIRPRO-authorised entities external to each
applicable CONTRACT APP; a function which determines and effects
"collateralisation" considerationlentitlement transfers between CONTRACT
APP stakeholders, and between CONTRACT APP stakeholders and
VIRPRO-authorised entities external to each applicable CONTRACT APP,
based on above-described valuations of consideration and entitlement
obligations assoc~ated w~th CONTRACT APP transactions; a function which
determines and effects, as required, the bi-lateral netting of
accumulated "considerat~on/entitlement" obligations " between CONTRACT
APP stakeholders, and between CONTRACT APP stakeholders and
VIRPRO-authorised entities external to each applicable CONTRACT APP; a
function which determines and effects, as required, the multi-lateral
netting of accumulated "consideration/entitlement" obligations" between
CONTRACT APP stakeholders, and between CONTRACT APP stakeholders and
VIRPRO-authorised entities external to each applicable CONTRACT APP
(involving a nominated third-party "clearing house" entity); a function
which manages the processing, accounting, reporting, and entitlement
"payment" tasks associated with maturing contracts; a function which
determines system usage and access fees payable to/from all CONTRACT APP
(and other INVENTCO) stakeholders, and to/from VIRPRO-authorised entities
external to INVENTCO; a function which determ~nes and effects, as
required, "bi-laterally netted" consideration/entitlement transfers
from/to CONTRACT APP stakeholders themselves, and from/to CONTRACT APP
stakeholders and VIRPRO-authorised entities external to each applicable
CONTRACT APP; a function which determines and effects, as required,
"multi-laterally netted" consideration/entitlement transfers from/to
CONTRACT APP stakeholders themselves, and from/to CONTRACT APP
stakeholders and VIRPRO-authorised entities external to each applicable
CONTRACT APP (involving a nominated third-party "clearing house" entity);
and a function which compiles and distr~butes CONTRACT APP (and other
INVENTCO) stakeholder customised information.
~O 94/28496 ~ 1 6 3 7 6 8 PCT/AU93/00250
,
-69-
Supplementary Process Types
CONTRACT APPS undertake various other types of support processes,
including: enabling stakeholders to transfer consideration, entitlement
and other "payment" obligations to and from one another, independently of
5 transfers initiated by CONTRACT APP transactions (See Process 7
description in Appendix C); providing CONTRACT APP (and other INVENTCO)
stakeholders with shared access to specialist systems to assist them to
decide how best to interface with the multiple aspects of INVENTCO (See
Process 8 description in Appendix C); and providing CONTRACT APP (and
other INVENTCO) stakeholders with access to a range of
INVENTCO-facilitated "value added services" (See Process 9 description in
Appendix C).
Order ~atching Constraint Types
For their operation, CONTRACT APPS require all stakeholders to a
specific APP to specify, amongst other things, which other stakeholders
they do and do not want to have interactions with, and the conditions
under which they wish to manually authorise some aspect of a transaction
involving any other CONTRACT APP stakeholder over which they have control
authority of some form.
In specifying which other stakeholders they do and do not want to
have interactions with, CONTRACT APP stakeholders have various options.
Application promoters can specify acceptable product sponsors, products,
ordering parties and potential counterparties withln their application -
individually and by type. Similarly, product sponsors can specifyacceptable application promoters, products, ordering parties, potential
counterparties and counterparty-guarantors within their application -
individually and by type.
Product counterparties and ordering parties (collectively) can
specify: ordering parties/potential counterparties they do and do not
want to deal with - individually and by type; the extent of their
preparedness to be involved in contract netting and collateralisation
arrangements provided for by their application promoter; application
promoters, product sponsors, products, and consideration/entitlement
transfer entities they do and do not want to deal with - individually and
by type; ordering parties/potential counterparties they prefer to deal
WO 94/28496 PCTIAU93/00250~
2~ ~3~
-70-
with, and those with which they wish to deal exclusively; the degree of
trading transparency they require; and their wish or otherw~se to
manually authorise order matches before they are confirmed.
Potential counterparties can specify which ordering parties, or
classes of ordering parties, they are prepared to offer credit to (and
under what terms), and ones they are prepared to allow "ordering
party-guarantors" to offer credit to and under what terms. Similarly,
product order~ng parties (uniquely) can specify: counterparty-guarantors
with which they do and do not want to deal (individually and by type);
counterparties with which they wish to deal exclusively or preferentially
to obtain a particular form of counterparty-credit; and potential
"ordering party-guarantors" (external to INVENTCO) with which they do and
do not want to deal.
Counterparty-guarantors can specify which potential counterparties
have their authority to operate and which application promoters, product
sponsors and ordering part~es they are prepared, indirectly, to have
relationships with. Similarly, regulators can specify which
counterparty-guarantors, potential counterparties, ordering parties,
application promoters, product sponsors and products have their authority
to operate. Finally, consideration/entitlement transfer entities can
monitor and maintain up-to-date rules with respect to ordering parties,
counterpart~es, appl~cation promoters, product sponsors,
counterparty-guarantors, and regulators they are and are not prepared to
deal with - individually and by type.
Ordering Party Requirements
For their operation, CONTRACT APPS require primary product ordering
party stakeholders to a C~NTRACT APP, in registering an order for a
product of their choice, to specify: the above-described "product type"
and "other stakeholder involvement" information; multiple attributes of
the specific order they are seeking; their interest or otherw~se in being
granted credit by potential counterpart~es for their contract
consideration amount, or in availing themselves of the possible netting
and collateralisation features of the APP concerned; the maximum (and
possibly minimum) consideration "price" they are prepared to pay for
their defined product; and various other dimensions of their needs, ~here
_~VO 94/28496 PCT/AU93/00250
2~ 63768
-71-
these include: the name/title by which they wish to be identified by
other APP stakeholders; the time at which they wish their order to be
submitted; the period of time after an order has been submitted that they
wish the order to be retained before it is automatically withdrawn;
whether or not they are prepared to accept partial matches of their
order; the degree of market transparency they wish to be exposed to;
r whether or not they wish wish to have the option of trading a matchedcontract on an authorised INVENTC0 secondary market (See Process 5
description in Appendix C); whether or not they wish to manually
consider/authorise potential counterparty quotes on an order; in the case
where potential counterparty quotes are required to be manually
considered/authorised, the maximum time after potential counterparty
quote details are provided to the ordering party that the ordering party
wishes to consider the quote(s); and the consideration/entitlement
transfer entity accounts from which/to which they wish to have relevant
"payments" made/received.
The above-mentioned multiple attributes of a specific primary order
an ordering party is seeking include: their wish or otherwise to directly
input the entitlement "coordinates" of their desired contingent claim
order; their wish or otherwise to mathematically specify an entitlement
function reflecting their desired product order, where such functions can
be single or multidimensional (indicating a contingent contract
entitlement conditional on two or more phenomena); the
"consideration/entitlement unit", "currency" (if applicable), and
"national currency" (if applicable) in which they wish to "pay"/"receive"
their contract consideration/entitlement. Where an ordering party wishes
to mathematically specify their desired primary product order as a
single-dimensional entitlement function: the input term "X" can indicate
the number of contract entitlement "inflection points" the ordering party
is seeking wlthin the allowable range of future product event values
(including the value range extremity points); the input term "Alpha (X)"
can indicate the ordering party-specified event value corresponding to
the Xth future product event value contract entitlement inflection point;
the input term "Beta (X)" can indicate the ordering party-specified
desired entitlement amount (in the desired "consideration/entitlement
form", "currency" and "national currency" entitlement denomination)
WO 94/28496 PCT/AU93100250
,
21~3~8 -72-
corresponding to the Xth event value inflection point; and the input term
-"Gamma (X-l)" can indicate the ordering party-specified desired shape of
the function between each of the co-ordinates: [Alpha (1), Beta (1)] and
[Alpha (2), Beta (2)], [Alpha (2), Beta (2)] and [Alpha (3), Beta (3)],
and so on (as applicable), where Gamma can represent all possible,
mathemat~cally definable, shapes.
Potential Counterparty Requirements
For their operation, CONTRACT APPS also require primary product
"potential counterparty" stakeholders to a CONTRACT APP to define various
parameters on the basis of which they can automatically price orders,
including parameters with which they wish to establish a "consideration
bid" on a defined product order; possible individual contract and product
constraints they require to be satisfied if they were to become a
counterparty to a defined product ordering party order; and possible
expected-value product-portfolio constraints they require to be satisfied
if they were to become a counterparty to a defined product ordering party
order.
In defining parameters with which they wish to establish a
"consideration bid" on a defined product order under a "EV-CE" pricing
regime ~described above), each potential counterparty is required to
specify, amongst other things: an indicator of the appropriate "defined
circumstances" of all possible product orders; a base "commission rate";
a base "discount rate"; (if applicable), a set of base
"consideration/entitlement denomination", "currency" and "national
currency" exchange rates; base "unit product prices"; and desired
ad~ustments to the base commission rate, discount rate, exchange rates,
and unit product prices on specific product orders according to the
determined-value of the "defined circumstances" indicator (based on a
specific product order).
Possible individual contract and product constraints the potential
counterparty requires to be satisfied if they were to become a
counterparty to a defined product ordering party order, ~nclude: an
absolute loss limit constraint (this constraint being specified as a
single-figure constraint and/or as a function constraint); an expected
loss limit constraint (this constraint defining the maximum "expected"
~VO 94/28496 PCTtAU93/00250
2163~8
-73-
aggregate loss the potential counterparty is prepared to incur on a
contract/product, taking into account their assessment of the likelihood
of all feasible future product values occurring); and a constraint on the
maximum proportion of the expected total loss of the aggregate of the
potential counterparty's contracts/products that can be accounted for by
the expected loss of the defined individual contract/product. Similarly,
possible expected-value product-portfolio constraints the potential
counterparty requires to be satisfied if they were to become a
counterparty to a defined product ordering party order include the
maximum (and possibly minimum) proportion of the expected total loss of
the aggregate of the potential counterparty's product portfolio that can
be acccounted for by the expected loss of an individual contract/product.
Communications
CONTRACT APP stakeholders communicate with their applicable APP via
AXSCO. Individual "stakeholder-to/from-AXSCO" communications can be by
way of any/all of the following: voice communications with an
AXSCO-linked "live operator" or "recorded messaging" system;
touch-telephone communScation with AXSCO directly; or
computer-to-computer link with AXSCO (via a dedicated or dial-up
communications line). With all three forms of communication, CONTRACT APP
stakeholders may be required to utilize specified computer hardware
and/or software mechanisms in their communications with AXSCO (including
"payments" authorisation "black box" dev~ces referred to in Appendix H).
Component Processes
In their manifestation as telecommunications/computer software
residing on telecommunications/computer hardware, individual CONTRACT
APPS consist of a cluster of processes (detailed in Appendix C),
utilizing a number of data files, residing on one or more processing
units. A cluster of nine (and potentially more or fewer) specific
processes and their related data files reside within a CONTRACT APP: a
process handling file administration and updating tasks supporting all
other processes (termed Process l); a process handling the receipt and
processing of "primary" risk management contract transactions`(termed
Process 2); a process handling the receipt and processing of "secondary"
WO 94/28496 PCT/AU93/00250
.. , ~
21~3768
-74-
risk management contract transactions (termed Process 3); a process
handling the receipt and processing of"derivative-primary" risk
management contract transactions (termed Process 4); a process handling
the receipt and processing of "derivative-secondary" risk management
contract transactions (termed Process S); a process handling the "back
office" management of all four types of risk management contract
transactions (termed Process 6); a process handling non-transaction
related consideration, entitlement, and other "payment" obligation
transfers between stakeholders (termed Process 7); a process handling
CONTRACT APP (and other INVENTCO) stakeholder access to specialist
systems to assist these stakeholders decide how best to interface with
the multiple aspects of INVENTCO (termed Process 8); and a process
handling CONTRACT APP (and other INVENTCO) stakeholder access to a range
of INVENTCO-facilitated "value added services" (termed Process 9). These
processes may function concurrently.
~O 94/28496 PCT/AU93/00250
~ 2163768
-75-
APPENDIX C
DESCRIPTION OF CONTRACT APP PROCESSES
Process 1
Process 1 handles file administration and updating tasks
supporting all other processes (Fig. 18). The PRODUCT, PRODUCT TRANS,
DEAL LIST and DEAL LIST TRANS files referred to in Fig. 18 are
applicable, individually or collectively, to primary, secondary,
derivative-primary, and derivative-secondary contract orders. The SEL
PRICE, SEL PRICE TRANS, SEL LIMIT and SEL LIMIT TRANS files are
applicable only to primary and derivative-primary contract orders. The
TRADE PRICE, TRADE PRICE TRANS, TRADE LIMIT and TRADE LIMIT TRANS
files are applicable only to secondary and derivative-secondary
contract orders.
The file administration and updating tasks handled by Process 1
comprise: dealing with general data-file information received from
CONTRACT APP stakeholders; dealing with general data-file and order
processing information received from relevant other INVENTCO
stakeholders, particularily VIRPRO and AXSCO; dealing with trading
support information received directly from CONTRACT APP stakeholders;
dealing with potential counterparty primary,-and derivative primary,
product order "consideration bid" parameters and order-match
constraints; dealing with existing-contract offering party secondary,
and derivative secondary, order match conditions; and dealing with
miscellaneous informat70n from entities external to INVENTCO.
Existing and prospective stakeholders are required to supply
their applicable CONTRACT APP with specified identification and other
information, and to continually maintain the integrity of this
information. For each stakeholder, this information includes:
applicable name(s), addresses, contact numbers, and references; their
desired system access medium; their consideration/entitlement transfer
entity account details; and, if applicable, their required schedule of
fees and charges payable by other INVENTCO stakeholders.This
information is maintained in the data file ADMIN, updated lnformation
being received by way of the transaction file ADMIN TRANS.
.
WO 94/28496 PCTIAU93/00250 ~
2~637~8
-76-
~ VIRPRO is required to supply the applicable CONTRACT APP with
various forms of general data-file information including:
identification data relating to the application promoter for (each)
CONTRACT APP; details of the permitted types of system access mediums;
and consideration/entitlement denominations available in each
application. Again, this information is maintained in the data file
ADMIN, updated information being received by way of the transaction
file ADMIN TRANS.
VIRPRO is similarly required to supply the applicable CONTRACT
APP with various forms of general data-file information including:
information on all data received by and sent from the various parts of
INVENTCO to one another and to entities external to INVENTCO; and
statistical information of various types, including data traffic
volumes, data file location information and so on.This information is
continuously collected by AXSCO and maintained in the data file
HISTORY.
Trading support information received directly from CONTRACT APP
stakeholders comprises stakeholder relationship information of a
general nature, and specific information from individual stakeholders
(detailed in Append~x B).
Stakeholder relationship information of a general nature
comprises "transaction communicat~on parameters" and automatic/manual
deal and no deal flags". Transaction communication parameters are
parameters set by all (reg~stered) CONTRACT APP stakeholders defining
the bounds within which they wish, for security reasons, all of their
communications within INVENTCO to fall. Automatic/manual deal and no
deal flags are "flags" set, as required, by all (registered) CONTRACT
APP stakeholders indicatlng their requirements with respect to dealing
with other CONTRACT APP stakeholders. This information is maintained
in the data file DEAL LIST, updated information being received by way
of the transaction file DEAL LIST TRANS.
Specific information from individual stakeholders differs
according to the category of stakeholder involved.
Application promoters provide, amongst other things: information
for the data file, PRODUCT (updated transactions being received from
the file, PRODUCT TRANS), and further information for the data file
~O 94/28496 . 2 1 6 3 7 6 8 PCT/AU93/00250
--77--
ADMIN (updated transactions being received from the file, ADMIN
TRANS). Information for the data file, PRODUCT includes details of the
specific products application promoters offer for
trading/exchange/transfer. Information for the data file, ADMIN
includes: the order pricing and matching process upon which the
application is based; the consideration/entitlement "value date"
regime upon which their application is based; the categories of other
stakeholders allowed to participate in the application and the
conditions under which they can do this; the specific rules of
engagement of counterparty-guarantors by potential counterparties; the
availability and, in turn, the terms and conditions for CONTRACT APP
stakeholder utilization of "consideration credit",
"collateralisation", and "netting" features of the application
(embodied in the various post-order-processing management routines);
and details of the consideration/entitlement transfer entities
involved in the application and relevant security information
concerning account access.
Product sponsors provide full details of the product(s) they are
sponsoring; product ordering parties and potential counterparties
(collectively) indicate, with respect to each other, the parties they
e~ther prefer to deal with or wish to deal w~th exclusively. Potential
counterparties ~exclusively) provide a variety of specific
information, including: details of the Application promoter, Product
sponsor, and Counterparty-guarantor rules under which they have chosen
to operate; data recording the lines of credit (if any) offered to
ordering parties and the general and specific terms and conditions of
these credit lines (applicable to ordering parties ind~vidually andlor
to defined classes of ordering parties); parameters with which a
potential counterparty wishes to determine its consideration "bids" on
orders. Counterparty-guarantors provide details of the potential
counterparties (if any) they have agreed to guarantee and the nature
of such guarantees. Regulators provide details of: all entities having
a stake in the application and their relationships to one another (for
example, which counterparty-guarantors cover which counterparties,
which potential counterparties offer which products, and so on);
specific regulations developed for the regime; and parameters defining
WO 94/28496 PCT/AU93/00250 _
~ 7 ~ 8 . -78-
the taxation treatment of all types of orders and related
transactions. Consideration/entitlement transfer entities provide
"set-up" and on-going account access and balance-updating services.
All of the above-described information is maintained in the data file,
ADMIN, updated information being received by way of the transaction
file ADMIN TRANS.
In dealing with potential counterparty primary product order
"consideration bid" parameters and order-match constraints, potential
product order counterparties are required, amongst other things, to:
define various parameters with which they wish to establish a
"consideration bid" on a defined product order; and define parameters
with which the potential counterparty wishes to determine adjustments
to the "base-price" bids on product orders according to the specific
ordering party involved (this information is maintained in the data
file SEL PRICE; updated information is received by way of the
transaction files SEL PRICE TRANS); define possible individual
contract and product constraints the potential counterparty requires
to be satisfied if they are to become a counterparty to a defined
product ordering party order; and define possible expected-value
product-portfolio constraints the potential counterparty requires to
be satisfied if they are to become a counterparty to a defined product
order~ng party order (these latter two categories of information are
maintalned in the data files SEL LIMIT and BUY LIMIT; updated
information being received by way of the transaction file SEL LIMIT
TRANS) (See Appendix B for further details).
In dealing with existing-contract offering party secondary order
match conditions, offering parties are required, amongst other things,
to specify: the Order IDs of the contracts in which the entity
concerned wishes to "sell" its position as a contract stakellolder,
and, for each such contract, the pricing and other parameters it
requires to be satisfied before a contract position "sale" is
effected.This information is maintained in the data file TRADE PRICE;
updated lnformation is received by way of the transaction file TRADE
PRICE TRANS.
In dealing with potential counterparty derivative-primary
product order "consideration bid" parameters and order-match
~'0 94128496 2 16 3 7 G 8 PCT/AU93/00250
--79--
constraints, potential product order counterparties are required to
provide essentially the same information described above in relation
to primary product orders. However, in addition, information directly
applicable to the relevant type of derivative-primary transaction
concerned (say, an option to establish a primary product order at a
later date) is also required.
In dealing with existing-contract-offering party
derivative-secondary order match conditions, offering parties are
requlred to provide essentially the same information described above
in relation to secondary product orders. However, in addition,
information directly applicable to the relevant type of
derivative-secondary transaction concerned (say, an option to sell a
position in a primary product order at a later date) is also required.
In dealing with miscellaneous information from entities external
to INVENTC0, this information can be of any type and may, potentially,
be used by any part of INVENTC0; the information is maintained in the
data-file ADMIN with updated information being received by way of the
transaction file ADMIN TRANS
Process 2
Process 2 handles the receipt and processing of "primary" risk
management contract transactions (this term being defined in Appendix
D), such transactions being of multiple types (detailed in Appendix
B). ~arious sub-processes of Process 2 handle the recelpt and
processing of all possible types of these transactions, including
product order processing, price quote requests, and withdrawals of
existing product orders.
Primary "product orders" constitute the core "primary" risk
management contract transaction type (Fig. 19 provides a summary flow
chart, and the document text provides a detailed flow chart and
description of the processing of this transaction type).
Primary product orders incorporate the following key items of
information: ordering party identification information; CONTRACT APP
application and product identification information; "other stakeholder
involvement" information; the ordering party's desired form of product
speciflcation (directly input as entitlement coordinates or as
WO 94/28496 PCT/AU93/00250~
2~637~
-80-
mathematical function(s)); when the order specification is by way of a
single-dimensional mathematical function, the parameters of such a
function (whlch can include: the term "X", the term "Alpha (X)", the
term "Beta (X)", the term "Gamma (X-l)"; the contract consideration
and entitlement "denomination type", "currency (if applicable)" and
"national currency (if applicable)"; the ordering party's interest or
otherwise in being granted credit by potential counterparties for the
yet-to-be-determined contract consideration amount; the ordering
party's interest or otherwise in availing themselves of the possible
netting and collateralisation features of the APP concerned; the
consideration "price" range within which the ordering party is
prepared to "pay" for their defined product; miscellaneous other
dimensions of the ordering party's needs, and the
consideration/entitlement transfer entity accounts from which/to which
they wish to have relevant "payments" made/received). Upon its
receipt, all of this information is written to - and subsequently
processed from - the file PORD NE~.
Three sub-processes are involved in processing primary product
orders - order authorisation, order matching, and matched order
confirmation . In the case of the anticipated most typical form of
order, termed a "normal-automatic" primary product order these
sub-processes function as follows:
The primary product order authorisation sub-process verifies
that all orders contain data appropriate to the product being sought
and that each ordering party is accurately identified and
credentialled (thls sub-process draws prlncipally on the data-flle,
PPRODUCT).
The primary product order matching sub-process locates the best
possible counterparty(ies) for the ordering party's transaction
according to the appiication promoter-specified"matching rules"
embodied in the APP; it does this utilizing three component
sub-processes, termed: short-listing of potential-counterparties,
individual potential-counterparty "pricing" calculations, and
counterparty selection.
3S The "short-listing of potential counterparties" sub-process
component establishes a list of potential counterparties (if any)
~O 94/28496 2 ~ ~ ~ 7 6 8 PCT/AU93/00250
.
-81-
willing to offer the product sought by the ordering party, upon their
receipt from the ordering party of a consideration they deem to be
appropriate (this sub-process draws principally on the data-file,
PDEAL LIST).
The individual potential-counterparties pricing calculations
sub-process component utilises the above-described pricing parameters
pre-specified by each short-listed potential counterparty to calculate
the "bid" each of them is prepared to make on the ordering-party's
product order (or part thereof), and to add these to the potential
counterparties short-list file (this sub-process draws principally on
the data-file, PSEL PRICE).
The "counterparty selection" sub-process component extracts from
the above-described "potential-counterparties short-list" file the
best possible counterparty(ies) for the ordering party's transaction,
according to the application promoter-specified "matching rules"
embodied in the APP, taking into account whatever matching constraints
all applicable APP stakeholders may have prespecified. This selection
being made, and the price bid being within the allowable limits
specified by the ordering party, and there being no requirements for
manual-approval intervention by any relevant stakeholder, a matched
order is deemed to be ~n existence ~th~s sub-process draws principally
on the data-file, PSEL LIMIT).
The matched order confirmation sub-process effectively secures,
automatically, the positive agreement of all affected stakeholders to
the contract, including confirmation of the product ordering party's
ability to immediately pay (or be granted counterparty credit, or
ordering party guarantor credit, for) the required contract
consideration (and possible other applicable fees). Automatic
approvals of contracts are made by the CONTRACT APP electronically
transferring resources recorded in the ordering party's applicable
consideration/entitlement transfer entity account to the account of
the applicable counterparty (See Appendix H for a description of the
consideration/entitlement "payment" process). In turn, automatic
updates of the counterparty's matching constraints maintained in the
file PSEL LIMIT are made.
WO 94/28496 PCT/AU93/00250 ~
2~ 637 68 -82-
Upon completion of the above-described processing steps:
unmatched order transactions are written to the file, PORD QUEUE, for
subsequent match attempts; matched and confirmed order transactions
are confirmed to the relevant CONTRACT APP stakeholders (this process
drawing principally on the data-file, ADMIN) and are written to the
f~le PORD CONF for subsequent "back-office" processing; and relevant
CONTRACT APP stakeholders are notified of rejected orders (again,this
process drawing principally on the data-file, ADMIN), records of this
being written to the file PORD REJ for subsequent "back-office"
processing. A copy of all processing outputs is written to the file,
HISTORY.
Process 3
Process 3 handles the receipt and processing of "secondary" risk
management contract transactions (this term being defined in Appendix
D). Like "primary" risk management contracts, "secondary" risk
management contracts are of multiple types (detailed in Appendix B);
various sub-processes of Process 3 handle the receipt and processing
of all possible types of these transactions, including product order
processing, product price indications, and withdrawals of existing
product orders.
"Secondary product orders" constitute the core "secondary" risk
management contract transaction type (Fig. 20 provides a summary flow
chart of the processing of this transaction type).
"Secondary" product orders incorporate the following key items
of information: potential acquiring party identification information;
the pre-established Order ID reference to the sought-after primary
contract; the potential acquiring party's interest or otherwise in
being granted credit by offering parties for the yet-to-be-determined
contract acquisition amount; the acquiring party's interest or
otherwise in availing themselves of the possible netting and other
features of the APP concerned; the acquisition "price" range within
whlch the potential acquiring party is prepared to "pay" for the
contract they have specified; other dimensions of the potential
acquirlng party's needs; and the consideration/entitlement transfer
entity accounts from which/to which they wish to have relevant
~0 94/28496 2 ~ 6 3 7 ~ 8 PCT/AU93/00250
-83-
"payments" made/received. The above-described lnformation is, upon
receipt, written to - and subsequently processed from - the file SORD
NEW.
Three sub-processes are involved in processing secondary product
orders -order authorisation, order matching, and matched order
confirmation. In the case of the anticipated most typical form of
order, termed a "normal-automatic" secondary product order these
sub-processes function as follows:
The secondary product order authorisation sub-process verifies
that all orders contain data appropriate to the contract sought and
that each potential acquiring party is accurately identified and
credentialled (this sub-process draws principally on the data-file,
SPRO~UCT).
The secondary product order matching sub-process locates
sought-after contract records and, based on the contents of these
records, determines whether a "sale" of the position of the specified
stakeholder in the contract to the potential acquiring party is
possible - in particular, whether the acquisition "price" range within
which the potential acquiring party has specified it is prepared to
"pay" for the position of the specified current stakeholder is equal
to, or in excess of, the "allowable sale price" figure prespecified by
the applicable contract stakeholder. If a contract "sale" is found to
be possible, and there being no requirements for manual-approval
intervention by any relevant stakeholder, a "match" is deemed to have
occurred.
The secondary product matched order confirmation sub-process
effectively secures, automatically, the positive agreement of all
affected stakeholders to the contract position "sale", including
confirmation of the contract acquiring party's ability to immediately
pay (or be granted current stakeholder credit, or acquiring party
guarantor credit, for) the required "sale price" consideration (and
possible other applicable fees). Automatic approvals of such "sales"
are made by the CONTRACT APP electronically transferring resources
recorded in the acquiring party's applicable considerationlentitlement
transfer entity account to the account of the applicable current
contract stakeholder.
WO 94/28496 . PCT/AU93/00250 ~
%~63~8
-84-
Upon completion of the above-described processing steps:
unmatched order transactions are written to the file, SORD QUEUE, ~or
subsequent match attempts, matched and confirmed order transactions
are confirmed to the relevant CONTRACT APP stakeholders (this process
drawing principally on the data-file, ADMIN), required records being
written to the file SORD CONF for further "back-office" processing as
required; and rejected order transactions are similarly notified to
the relevant CONTRACT APP stakeholders (again, this process drawing
principally on the data-file, ADMIN), required records being written
to the file SORD REJ for further"back-office" processing. A copy of
all processing outputs is written to the file, HISTORY.
Process 4
Process 4 handles the receipt and processing of
"derivative-primary" risk management contract transactions (this term
being defined in Appendix D). Like "primary" risk management
contracts, "derivative-primary" risk management contracts are of
multiple types (detailed in Appendix B); various sub-processes of
Process 4 handle the receipt and processlng of all possible types of
these transactlons, includlng product order processing, product prlce
indications, and existing product order withdrawals.
"Product option orders" is one illustrative "derivative-primary"
risk management contract transaction type (Fig. 21 provides a summary
flow chart of the processing of thls transaction type~.
"Derivative-primary" product option orders incorporate the
following key items of information (detailed in Appendix B): ordering
party identification information; CONTRACT APP application and product
ldentification information; "other stakeholder involvement"
information; the ordering party's desired form of product
specification (directly input as entitlement coordinates or as
mathematical function(s)); when the order spec~fication is by way of a
single-dimensional mathematical function, the parameters of such a
function (which can include: the term "X", the term "Alpha (X)", the
term "Beta (X)", the term "Gamma (X-l)"; the contract consideration
and entitlement "denomination type", "currency (if applicable)" and
"national currency (if applicable)"; the ordering party's interest or
~O 94/28496 2 1 ~ 3 7 ~ ~ PCT/A1~93/00250
.
-85-
otherwise in being granted credit by potential counterparties for the
yet-to-be-determined contract option consideration amount; the
ordering party's interest or otherwise in availing themselves of the
possible netting and collateralisation features of the APP concerned;
the consideration "price" range within which the ordering party is
prepared to "pay" for their defined product option; miscellaneous
other dimensions of the ordering party's needs, and the
consideration/entitlement transfer entity accounts from which/to which
they wish to have relevant "payments" made/received). Upon its
receipt, all of this information is written to - and subsequently
processed from - the file DPORD NEW.
Three sub-processes are involved in processing
derivative-primary product orders - order authorisation, order
matching, and matched order confirmation . In the case of the most
likely form of the above-mentioned illustrative option order, termed
a "normal-automatic" derivative-primary product option order (see
Appendix 5 for details) these sub-processes function as follows:
The primary product option order authorisation sub-process
verifies that all orders contain data appropriate to the product
option being sought and that each ordering party is accurately
identified and credentialled (this sub-process draws principally on
the data-file, DPPRODUCT).
The primary product option order matching sub-process locates
the best possible counterparty(ies) for the ordering party's
transaction according to the application promoter-specified "matching
rules" embodied in the APP; it does this utilizing three component
sub-processes, termed: short-listing of potentlal
option-counterparties, indivldual potential option-counterparty
"pricing" calculations, and option-counterparty selection.
The "short-listing of potential option-counterparties"
~ sub-process component establishes a list of potential
option-counterparties (if any) willing to offer the product option
sought by the ordering party, upon their receipt from the ordering
party of an option consideration they deem to be appropriate (this
sub-process draws principally on the data-file, DPDEAL LIST).
WO 94/28496 . PCT/AU93/00250 ~
2~37~8
-86-
Tl~e "individual potential option-counterparties pricing
calculations" sub-process component utilises the above-described
pricing parameters prespecified by each short-listed potential
option-counterparty to calculate the "bid" each of them is prepared to
make on the ordering-party's product option order (or part thereof),
and to add these to the potential option-counterparties short-list
file (this sub-process draws principally on the data-f~le, DPSEL
PRICE).
The "option-counterparty selection" sub-process component
extracts from the above-described "potential option-counterparties
short-list" file the best possible counterparty(ies) for the ordering
party's transaction, according to the application promoter-specified
"matching rules" embodied in the APP, taking into account whatever
matching constraints all applicable APP stakeholders may have
prespecified. This selection being made, and the price bid being
within the allowable limits specified by the ordering party, and there
being no requirements for manual-approval intervention by any relevant
stakeholder, a matched option order is deemed to be in existence (this
sub-process draws principally on the data-file, DPSEL LIMIT).
The matched option order confirmation sub-process effectively
secures, automatically, the positive agreement of all affected
stakeholders to the options contract, including confirmation of the
product-option-ordering party's ability to immediately pay (or be
granted counterparty credit, or ordering party guarantor credit, for)
the required option product consideration (and possible other
applicable fees). Automatic approvals of contracts are made by the
CONTRACT APP electronically transferring resources recorded in the
ordering party's applicable consideration/entitlement transfer entity
account to the account of the applicable counterparty (this process
3Q being detailed in Appendix H). In turn, automatic updates of the
option-counterparty's matching constraints maintained in the file
DPSEL LIMIT are made.
Upon completion of the above-described processing steps:
unmatched option-order transactions are written to the file, DPORD
QUEUE, for subsequent match attempts; matched and confirmed
option-order transactions are confirmed to the relevant CONTRACT APP
~ o 94/28496 2 3 6 3 ~ 6 8 PCTtAUg3/00250
,
-87-
stakeholders (this process drawing principally on the data-file,
ADMIN) and are written to the reference file DP MSTR, and t!le file
DPORD CONF for subsequent "back-office" processing; and relevant
CONTRACT APP stakeholders are notified of rejected orders (again, this
process drawing principally on the data-file, ADMIN), records of this
being written to the file DPORD REJ for subsequent "back-office"
processing. A copy of all processing outputs is written to the file,
HISTORY.
If/when an option-holder wishes to exercise its option over a
pre-established contract, it does so by appropriately notifying the
CONTRACT APP which, in turn, retrieves the contract record from
DPMSTR, effects the necessary additional consideration payments, and
writes a new record to PORD CONF for subsequent back office
processing. As described above, the appropriate HISTORY and other
files are updated in this process.
Process 5
Process 5 handles the receipt and processing of
"derivatlve-secondary" risk management contract transactions (this
term being defined in Appendix D). Like "secondary" risk management
contracts, "derivative-secondary" risk management contracts are of
multiple types (detailed in Appendix B); various sub-processes of
Process 5 handle the receipt and processing of all possible types of
these transactions, including product order processing, product price
indlcations, and withdrawals of existing product orders.
"Product option orders" is an illustrative
"derivative-secondary" risk management contract transaction type (Fig.
22 provides a summary flow chart of the processing of this transaction
type).
"Derivative-secondary" product option orders incorporate the
~ follow~ng key items of information: potential acquiring party
identification information; the pre-established Order ID reference to
the sought-after primary contract (in relation to which an option is
to be purchased or sold), the potential acquiring party's interest or
otherwise in being granted credit by offering parties for the
yet-to-be-determined option contract acquisition amount; the acquiring
W O 94/28496 PCT/AU93/00250 ~
~163768 -8B-
party's interest or otherwise in availing itself of the possible
netting and other features of the APP concerned; the acquisit70n
"price" range within which the potential acquiring party is prepared
to "pay" for the contract option they have spec7fied; other d7mensions
of the potential acquiring party's needs; and the
consideration/entitlement transfer entity accounts from which/to wh7ch
they wish to have relevant "payments" made/received. The
above-descr7bed 7nformation 7s, upon receipt, wr7tten to - and
subsequently processed from - the f71e DSORD NE~.
The subprocesses involved in the processing of
derivat7ve-secondary product option orders are essentlally a
comb7nation of the processes descr7bed above 7n the case of secondary
product orders (Process 3) and derivative-pr~mary product option
orders (Process 4). At the completion of the match7ng process, matched
orders are written to the reference file DSMSTR and the file DSORD
CONF for subsequent back off7ce processing.
If/when an opt70n holder wlshes to exerc7se 7ts option over a
pre-established contract, it does so by approprlately not7fying the
CONTRACT APP whlch, in turn, retrieves the contract record from
DSMSTR, effects the necessary addlt70nal cons7derat70n payments, and
wr7tes a new record to SORD CONF for subsequent back off7ce
process7ng. As described above, the appropr7ate HISTORY and other
files are updated ln this process.
Process 6
Process 6 handles the "back off7ce" management of
"matched/conflrmed" primary, secondary, derlvat7ve-primary, and
der7vative-secondary rlsk management contract transact70ns and
transact70ns handled by Processes 7-9. The process incorporates
multiple sub-processes, collectively accesslng multiple data files
(F7g. 23): prlmary rlsk management contract back off7ce processlng;
secondary risk management contract back office processlng;
derlvati~e-prlmary rlsk management contract back offlce processlng;
derlvatlve-secondary r7sk management contract back off7ce processing;
"Process 7" transactlons back office processing; "Process 8"
~0 94/28496 PCT/AU93/00250
':
-89-
transactions back office processing; and "Process 9" transactions back
office processing.
In relation to the back-office management of confirmed/matched
primary risk management contracts - a number of sub-processes are
involved, including: Receipt of the previous operating day's
"matured-contract actual product event value" sub-process;
"Start-of-day PAYACC management" sub-process; Contract maturity
management sub-process; Confirmed contract processing sub-process;
Information compilation and distribution sub-process; Information
extraction from primary orders sub-process; Contract valuation
sub-process; Contract collateralisation payments sub-process; System
Access and usage fee determination and payments sub-process; Bilateral
obligations netting sub-process; Multilateral obligations netting
sub-process; Bilateral payments netting sub-process; Multilateral
payments netting sub-process; and "end-of-day PAYACC management"
sub-process.
Receipt of the previous operating day's "matured-contract actual
product event value" details. This sub-process is flowcharted in Fig.
24; it involves the applicable CONTRACT APP receiving
"matured-contract actual product event value" details from the
relevant product sponsors (external to INVENTCO).The primary
data-file, MAT PROD VALUES, is updated with this information. The
support data-files, ADMIN, HISTORY, and INFO are similarly updated
with applicable information.
"Start-of-day" PAYACC management. This sub-process is
flowcharted in Fig. 25; it involves the applicable CONTRACT APP
receiving consideration/entitlement "actual account" opening-balances
from participating consideration/entitlement transfer entities
(external to INVENTCO) (see Process 7 for details). The primary
data~files, PAYACC SHADOW and PAYACC FINAL are updated with this
~ information. The support data-files, HISTORY, INFO and ADMIN, are
similarly updated with applicable information.
Contract maturity management. This subprocess is flowcharted in
Fig. 26; it involves the applicable CONTRACT APP determining and
giving effect to primary and related entltlement-transfers to/from
applicable CONTRACT APP stakeholders, applicable other INVENTCO
WO 94/28496 PCT/AU93tO0250 ~
~63768
--so--
stakeholders, where such transfers are principally reflected in
entries to the data-file, PAYACC SHADO~I. CONTRACT APP determines and
gives effect to these transfers, principally by drawing upon
product/contract information maintained in the data files, INTREG, MAT
S PROD VALUES, COLLAT, CREDIT MGMT, BILAT OBLIG NET, and MULTILAT OBLIG
NET. These data-files are appropriately updated in the process as are
the support data-files, ADMIN, HISTORY, TAX/SUB, PAYACC SHADOW and
INFO.
Confirmed contract processing. This sub-process, flowcharted in
Fig. 27, operates continually throughout each operating day. Details
of new matched/confirmed contracts are read from the file PORD CONF
and are then time-stamped and written to the file INTREG as two
records - one record pertaining to the contract ordering party and the
other to the contract counterparty. The support data files, INFO,
ADMIN, and HISTORY are appropriately updated in the process.
Information compilation and distribution. This sub-process,
flowcharted in Fig. 28, operates continually (beyond a defined
operating day ), drawing on the data-file INFO. As already described,
INFO is updated continually as CONTRACT APP and other INVENTCO events
occur, including pertinent AXSCO message information written in the
first instance to HISTORY. All relevant INVENTCO stakeholders have
access to preauthorised parts of INFO.
Information extraction from primary orders. This sub-process,
flowcharted in Fig. 29, is effected after the completlon of the
Z5 defined operating day. Essentially, it involves the single task of
processing the data-file, HISTORY, to yield pertinent information for
the data-file INFO. One of the most important items of information
drawn from HISTORY is (confidential) information on all of the prior
day's potential counterparty consideration bid parameters, in
particular the data items termed "assessed probabilities of
occurrence". This information yields "market" information for the
subsequent contract valuation sub-process.
Contract valuation. This sub-process, flowcharted in Fig. 30,
draws principally upon the above-described "markets" information
previously written to INFO. Pertinent data from this file is l'applled
against" all outstanding contracts maintained in INTREG, thereby
~jO 94/28496 2 ~ ~ 3 7~ 8 PCT/AU93/00250
..
_91 _
yielding updated "future product value (FPV)", "expected value" and
"distribution" value information for all contracts and, from this,
revaluations of all future entitlement "expected values" and
"distribution" values. All these revaluation figures are maintained in
INTREG with applicable information also being written to INFO and
HISTORY.
Contract collateralisation payments. This sub-process,
flowcharted in Fig. 31, draws principally on the data-file INTREG.
Following the contract valuation process, this collateralisation
process involves relevant INTREG records being read and, depending
(amongst other things) on the precalculated "present value" of the
expected future entitlement associated with each relevant contract, a
calculated portion of the present value of the expected future
consideration amount is debited or credited to the PAYACC SHADOW file
of the applicable collateralisation trustee entity, and the product
ordering party and/or counterparty as is applicable.
Generally, if the most recent precalculated "present value" of
the expected future entitlement associated with each relevant contract
indicates a negative contract value, and if this negative value
exceeds the prior contract valuation figure, the applicable entity's
trust account is credited with the funds difference, with the entity's
own consideration/entitlement transfer entity account being debited
correspondingly. If this negative value does not exceed the prior
contract valuation figure, the applicable entity's trust account is
debited with the funds difference, with the entity's own
consideration/entitlement transfer entity account being credited
correspondingly. On the other hand, if the most recent precalculated
"present value" of the expected future entitlement associated with
each relevant contract indicates a positive contract value, the only
collateralisation payment adjustment called for is one in which all
funds (if any) in the applicable entity's trust account are
transferred to the entity's own consideration/entitlement transfer
entity account. In each of the above-described cases, a record of all
entries effected is written to the data-file, COLLAT, and a subset of
this information is written to the data-files HISTORY and INFO.
WO 94/28496 PCT/AU93/00250~
2~6~76~ -92-
System Access and usage fee determination and payments. Th~s
subprocess, flowcharted in Fig. 32, deals with the determination and
payment of system access and usage fees (as distinct from contract
maturity date fee payments). The function draws principally on the
data-files ADMIN, and HISTORY. Fee payment parameters are maintained
in data-file ADMIN. These parameters are applied against the day's new
records already written to HISTORY. Debits and credits for fees so
determined are written to PAYACC SHADOW with summary ~nformation
written to INFO and HISTORY.
Bilateral obligations netting. This subprocess, flowcharted in
Fig. 33, effectively maintains an up-to-date matrix of the present
values of expected future entitlement (and other) obligations between
pairs of participating ordering parties and counterparties (as well as
other participating CONTRACT APP and INVENTCO stakeholders),
continually adjusted on the basis of required current consideration,
entitlement and other payments/receipts as they occur. As required,
the function updates the above-descrlbed matr~x ~n two stages. First,
w~th the most recent contract revaluation figures contained withln
INTREG. And second, with the end-of-day payment/receipt amounts
contained within PAYACC SHADOW. Consideration/entitlement transfer
entity transfers from/to applicable entities are determined (according
to the application-promoter specified parameters for so doing) on the
basis of whether or not any/all of the ad~usted bilateral present
value figures are in excess of their allowable limits. These entries
are written to PAYACC SHADOW, with the data-files BILAT OBLIG NET,
INTREG, HISTORY, and INFO being subsequently updated.
Multilateral obligations netting. This subprocess, flowcharted
in Fig. 34, is essentially the same as the bilateral netting function
except that a specified "clearing/trustee" entity is effectively
interposed between all bilateral counterparties and, as such, netted
obligations are only between the specified "clearing house/trustee"
entity and each participating entity.
Bllateral payments netting. This subprocess, flowcharted in
Fig. 35, is independent of the above-described bilateral and
multilateral obligations netting subprocesses. The subprocess operates
by producing a matrix of bilaterally netted payments/receipts based on
~O 94/28496 ~ ~ 6 3 ~ 8 PCT/AU93/00250
,
-93-
records contained in the data-file, PAYACC SHADO~. Single netted
payment/receipt figures are then rewritten to PAYACC SHADO~, with the
data-files BILAT PYMTS NET, ADMIN, HISTORY and INFO being subsequently
updated.
Multilateral payments netting. Like bilateral payments netting,
this subprocess, flowcharted in Fig. 36, is independent of the
above-described bilateral and multilateral obligations netting
subprocesses. The subprocess operates by producing a matrix of
bilat:erally netted payments/receipts to/from the applicable "clearing
house/trustee" entity based on records contained in the data-file,
PAYACC SHADOW. Single netted payment/receipt figures (to/from the
"clearing house/trustee" entity) are then rewritten to PAYACC SHADOW,
with the data-files MULTILAT PYMTS NET, ADMIN, HISTORY and INFO being
subsequently updated.
"End-of-day" PAYACC management. Th~s subprocess, flowcharted in
Fig. 37, involves a three-stage process. First, the preparation of
inter-consideration/entitlement transfer entity "balancing"
transactions. Second, the transfer of the final contents of the PAYACC
SHADO~ data-file to the data-file, PAYACC FINAL. And third, the
- 20 electronic transmission of the contents of PAYACC FINAL to the
applicable considerat~on/entltlement transfer entities (external to
INVENTCO). In turn, the subsidiary data-files, ADMIN, HISTORY, and
INFO are updated.
Process 7
Process 7 handles non-CONTRACT APP-related obligation transfers
between applicable INVENTCO stakeholders, that is, the transfer of
ownership title over "assets" registered by INVENTCO - typically
matched/confirmed contracts (recorded as CONTRACT APP INTREG records)
and consideration/entitlement transfer entity resources (recorded as
PAYACC records). Both of the above-mentioned items have value to their
holder. This process enables holders of these items to assign or lend
any portion of their holdings to others at their will through
initiating the appropriate transactions as NCAROT TRANS. The process
accesses a relatively small number of data files (See Fig. 38). NCAROT
TRANS received result in appropriate updates to the primary
WO 94128496 PCT/AU93100250 ~
~ ~ ~3 7 ~8 -94-
data-files, PAYACC S~ADOW and INTREG. In turn, the subsidiary data
- files, HISTORY, ADMIN and INFO are updated.
Process 8
Process 8 (flowcharted in Fig. 39) handles CONTRACT APP (and
other INVENTCO) stakeholder shared-access to specialist systems to
ass~st them decide how best to interface with one or more aspects of
INVENTCO. In the case of CONTRACT APP stakeholders, the most likely
users of this process, one collection of such specialist systems are
termed "decision support systems". The purpose of these systems is to
guide a user-stakeholder as to how it should react to/deal with the
continually changing circumstances within the CONTRACT APP with which
they are dealing. Different clusters of systems are applicable for
different CONTRACT APP stakeholders. These systems involve a hierarchy
of potentially any number of value-added components.
An example of one such system, useful to primary product
ordering parties, is a system which helps an ordering party determine
which of its prespecified, but as yet un-matched, orders it should
withdraw and which of its potential new product orders it should
submit. This system is in the form of a "utility optimization"
mechanism which seeks to identify the best possible composition of
outstanding orders (and thus, which exlsting, unmatched orders should
be withdrawn and which new orders should be submitted) based on two
things. First, an objective function which seeks to minimize the
difference between a weighted sum of actual and desired values of a
series of attributes (involving single or multiple products, covering
the ordering party's "real business exposure" to each product, the
ordering party's portfolio of contracts which have been "matched" but
are not yet confirmed, orders which have been subm~tted but not yet
matched, and potential yet-to-be-submitted orders (collectively termed
the "buyer's objective portfolio"), these attributes including,
amongst other things: the "expected value" of the objective portfolio;
the "standard deviation" of the objective portfolio; the "incremental
cash outflow" attribute of the objective portfolio; the "maximum
absolute loss" attribute of the objective portfolio; the "expected
loss" attribute of the objective portfolio; the "implied minimum
return on investment" of the objective portfolio; and the "implied
~0 94/28496 2 1 ~ 3 7 6 8 PCT/AU93/00250
-95-
expected return on investment" of the objective portfolio. And second,
a series of constraints specifying, amongst other thin~qs: the required
"minimum values" of each objective function attribute; and required
minimum product-shares in the ordering party's overall product
portfolio. The mathematical form of this "optimization" could take any
of a number of alternative forms.
An optimization mechanism similar to the one described above can
also aid potential counterparties in defining their pricing parameters
for application against incoming product orders.
Effectively, systems of the above-described type are
collectively maintained as a software "library" within the applicable
CONTRACT APP (although they may also be loaned by VIRPRO-authorised
entities independent of INVENTCO and/or acquired by VIRPRO-authorised
parties whether they are INVENTCO stakeholders or not). CONTRACT APP
lS (and other INVENTCO) stakeholder requests to make use of software
within this library are received by way of records in the file, SSA
TRANS. These requests result in the appropriate records in the file
SSA being accessed and made available for use via AXSCO and the
applicable entity's authorised electronic link to INVENTCO.
20 Appropriate records of the utilizatlon of SSA records are written to
the data-files HISTORY, ADMIN and INFO.
Process 9
Process 9 (flowcharted in Fig. 40) handles CONTRACT APP (and
25 other INVENTCO) stakeholder shared-access to a range of
INVENTCO-facilitated value added services. These services can include:
accounting, reconciliation, and information services; value added
information reseller services; financial services of multiple types;
and data processing and telecommunications services. Effectively,
30 software relating to these services is maintained as a software
"library" within the applicable CONTRACT APP (although they may also
be loaned by VIRPRO-authorised entities independent of INVENTCO and/or
< acquired by VIRPRO-authorised parties whether they are INVENTCO
stakeholders or not ). CONTRACT APP (and other INVENTCO) stakeholder
35 requests to make use of software within this library are received by
way of records in the file, VAS TRANS. These requests result in the
WO 94/28496 . PCT/AU93100250~
~1 6~ 7 ~ 8 -96-
appropriate records in the file VAS being accessed and made available
for use via AXSCO and the applicable entity's authorised electronic
link with INVENTCO. Appropriate records of the utilization of VAS
records are written to the data-files HISTORY, ADMIN and INFO.
~O 94128496 2 ~ 6 376 8 PCT/AU93/00250
,
-97-
APPENDIX D
RISK MANAGEMENT CONTRACT$
Risk management contracts is a term used to refer to one type of
contractual obligation which can be, but does not need to be,
traded/exchanged/transferred, and subsequently processed and settled,
using an INVENTC0 system. Risk management contracts consist of "primary"
risk management contracts; "secondary" risk management contracts;
"derivative-primary" risk management contracts; and
"der~vative-secondary" risk management contracts.
"Primary" risk management contracts can be "simple" and "complex"
in nature ("simple" contracts being derivatives of "complex" contracts).
A "s~mple" primary risk management contract is a tradeable or
untradeable contract conveying an obligation on an entity, upon that
entit-y being granted a consideration by another entity (or accepting a
pledge to be granted a consideration by the other entity), to make an
entitlement to that other entity depending on the value of a defined
phenomenon, determined at a defined time in the future.
A "complex" primary risk management contract is a tradeable or
untradeable contract conveying an obligation on either or both of two
entities, upon one entity ~usually] being granted a consideration by the
other entity (or accepting a pledge to be granted a consideration by the
other entity), to make an entitlement to pay/receive an entitlement from
one another, depending on the value of a defined phenomenon, determined
at a defined time in the future. A "complex" contract may, in turn, be
"basic" or "advanced" in nature: a "complex-basic" contract being one
that does not involve order~ng party and/or matched order counterparty
"collateralisation payments" to a third-party trustee or clearing entity
during the life of a contract; and a "complex-advanced" contract being
one that does involve ordering party and/or matched order counterparty
"collateralisation payments" to a third-party trustee or clearing entity
during the life of a contract.
"Secondary" risk management contracts are pre-existing "primary"
risk management contracts offered for trade (individually or as a
-
WO 94/28496 PCT/AU93/00250
~G3768
-98-
portfolio) by a "risk-counterparty" stakeholder to the underlying
contract.
"Derivative-primary" risk management contracts are options
contracts, or futures contracts, or forward contracts, or forward rate
agreements, or swaps, or like financial instruments based on specified,
but yet-to-be-established, primary risk management contracts.
"Derivative-secondary" risk management contracts are options
contracts, or futures contracts, or forward contracts, or forward rate
agreements, or swaps, or like financial instruments based on
pre-existing primary risk management contracts (which may have been
traded since they were first established), including instruments based
on: specified, but yet-to-be established, secondary risk management
contracts; and the intended tertiary trading/exchange/transfer of
specified, established, secondary risk management contracts.
~O94/28496 2~ 63768 PCTIAU93/00250
_99_
APPENDIX E
.
. .
~
~ V~
C~ ~
O
V~
2 ~
~ o
E-
C~
L~
V~
~ f 6 3 76 8 ` PCT/AU93/00250
~
--100--
' $
C ~r
-- Z Z \~
^" g . \~;
,. ' '' ' ' .
_
o~ Z Z Z ~ Z Z Z Z Z Z Z Z
'' , ' ; ' ' ~
Z ~ o -` . ~ L,
~ Z Z
Z
0~
~ L ' ,
~o 94/28496 2 1 6 3 7 6 8 PCT/AUg3/00250
,,
~ --101--
- ' ~
,, X , ~ .
~ b g ~ L '
L~ ~ O
r . æ ~
L_ ~
? -
-- o ~- ~ _
~ ' 8, .
t~) C~ 8 80 , ~ ' '`'
en g I ~ t
~L . , L~6, ~ L L _ ' ~ L
wo 94l284962 3L 6 3 7 ~ g 102-- PCT/AU93/00250 ~
_ ~ 3
y
oo ~
L '~ :
Y ~ ~ ~ 8~ ' "
~,
,. . .r --C
o , 5 ~: Z Z . . g
~ Oe ~
, , . . ,~ , .,
_
~ V~ 8 æ
X c~ ' ~ Z- ~. ~. L L. L. t~
C
.~ æ
~" , ;
Z
. ~
O . ~. ' ;Z: Z ~ Z ~ Z Z
~ g O . . . .
V V
~ 8 o
O ~ P _ r . .~4
D; ~ ~ ~ ' g ~ ~ ~; ' ~ ~ t ~, ~ . ..
3 ~ E c
~1 ~ 0 ~ . X Z ~ O
~0 94/28496 Z ~ 6 3 7 6 ~ PCT/AUg3/00250
--103--
Z Z
' ' ~ g o ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ _ . ~ ~ ~ V ~ g V
;~ o c ~ o ~ 8 ~
~ ~ O _0 0 0 0 o,o c , , _------~ ~ " ^'
8 e
h ~ ~^ j v~ ~ 00 v~
r ~ ~ ~ j ~ v~ v 8 ~8 ~ t~ ~ ~ t~ ~ g 8 8 8 8 ~ 8 8 8 8 0
.
O O ~ ~ æ c~ O ~ 0 w t ~ O~ O~ O~ & _ ~ _
~ ~O 'r & o, _ o, & & o~ ~O~ o & &~ ~ ~~ , ~ ~ r~
t.~r ~ vw æ ~ ~ ~ t ~ ~ W ~ t~ wt ~` w t` O ~ v~ ~ ~ ~ ~ ~
o ~o o~ ~o ~o 8 8 8 8 18~ ~8~ &8 8 8 08 8 8 8 8 8 80 8 0 ~ tJ 1
o o o o o o o o o d o o o o o o o o o o o o o o o -- z
~ 8 O O ~ 0~ o~
- y '~ o ~ ~3f.~ C~ 8 0 _____~
~ ~ ,... _ _
Z
. 2 ~ t~ 8888888888888888888888888 ~ ~
O O O O O O O O O O O O O O O O O O O O O O- O O O
t,_ ~
~ o ~ ~ t~ Oi ~
~ ~ p ~ 3 ~ t ~ ~r t~ tW- w t~ wr ~WO ~ O~ Oi ~
~ ~ + u ~ u + n
WO 94/28496 21 6 3 7 ~ 8 PCT/AU93/00~50
--104--
~.o
.,, '. ~'
1' - 86
t -~6
; ~ r ~ z E \ - Z6
O _ ' L \ ' 8~
o \ 9L
- OL
- 89
o. \ Z9
G ~ ~ ~ g \ ~9 1
.c, \ - ~5 ~
. 0
8E --
_" C ~ ~ ~ ~ -
. ,. ,~. . ,. - ' Z~
- 9Z
' o~
.. 8
1-1' .' . .,,; ~ ~ ~ 8 8 .. g 8 8 r~
~o 94/28496 . 216 3 7 ~ 8 PCT/AUg3/00250
--105--
1--
~ .
-
Z Z ~
,
r ~ E ~ ~ ` 85
t ~ r~ 56 -
~6
Z6 -
E ~ _ 8 - /
8 - /
, ` ^" E 08
-~ ~; , 8L -
8 r r_ r ~.L -
O~ - /
~ 89 -
o
~ zg9- / r
o ~ E - / _
ZS -
8~ /
n
z~
o~ -
dC' ~ 8~ ~
9~
z~
~ .
_ 8Z
~. g g 8
¢ u~ g 8 Zz
F ~ ~ E . ' g o r~ r ,_ ~ 9
¢ ' Z~ -
O~ -
8 -
.
' ¢ ~, ' _ ' O
o o ~ ~ J ,~ 8 æ ~o, a~ ~ ~
O ~
WO 94/28496 PCTIAU93/00250
~1~37~8 -106- --
~Ll
~ .
., ;~ ~' ' . .
Z ~ ' oo~
86
~ 3 \ - z
; -- E \ Z8
~ ' L' \ 8L
8 r~ \ tL
o ' \ OL
99
C o ~ o \ -ZZ ~
_ r,~ 8~ t
0~
L~ ~ 8E --
o ~ r~ rA - tE
-- OE
~ ~ 8Z
~ rn 8 8 ~ z
~ c ~ ~ æ 0~ J æ ~, 9~
g ~ ~ ~ ., . 8
r~ ` - 9
t~ I O
o z ~ 8 ~~ ~
~ o r~
216~7~8
~0 94/28496 . PCT/AU93/00250
--107--
a~
~ ~ ~
Z ~
OO L
E ~ ~ 86
~ ~ ~ L \ Z5
C r ' \ ~ 88
; ~ 8
E . \ - Z8
C ' ~ ~ 08
8L
O ~ L
O \ OL
O _ \ ~ 89
O \ 99
Z
007~ ~ ~ o \ V~
~ t,. ~ 05 ~
CLI C I
,~ O~
Zt L_
t . , : ~ ~ ~ 8
- ~ 9
; O ~ - L13 UD - - t
Z
~S - 8Z
~ - 9Z
~, g 8 8 - ~Z
8 8 ~ ZZ
~> -- 8 - oz
o o
o~
t-- tL _ 8
ri 9
~ ' r. ~ t
D ~ 2 o O r~ ~ ~3 o O O
WO 94/28496 PCT/AU93/00250 ~
2~7~8 -108-
APPENDIX F
3~
Z ~
o ~
~ E
~O 94/28496 2 ~ ~i 3 7 6 8 PCT/AU93/00250
--109--
;, Yt'' ~''
L ~ \
- Z Z '
t t
.
r
~ U _ S ~ , .
Z ~ ZZ Z ~ Z Z Z Z
t
Z ~ ,~ ~, '", ;,~,S" `~
Z
Q .
Z ' ;~
O
~ L
WO 94/28496 21 6 3 7 6 8 PCT/AU93/00250 ~
--110-
~ .
. o -~,
,
n ' D
_
'~ L ~ _
7` ' . O
C') ~D
8 . _ g,
8 o .. ~ 8
,~ o
E~ . , .~_,
~7 ~ , ~
~ G ' _ ~ ..
D
t ' -- _.
t E ,~
' t- ~:
p~
Z ~, ~ 8 ;~ t:
~ 8 8 .~ ' o ~,
U~ a g i ~ v~ æ ~ ID E ~
C ~ r
O r ' . ; , r ,
2~37~8
~O 94/28496 PCT/AU93/00250
~ '--11 1 _
. ~; .
O
.. .. . .
. z z ,.~
. i j ~
: ~ ~ z z z
' . L.
O ` ' D ~ ` ~
v r~ L~ ! o
C ~ Z Z ' -
Lg
O~ ~
o_' Z
8 '
a
-- L_ . '
~ ,, .
z z z z
g o ~ ~
O. 8 . 8 g --~ w ~ Z .,
Q E _~ r-w
a
C ~ E E ~
O ~ ~ ~ L X C tiS O ~ '!: Z
:
WO 94/28496 PCT/AU93/00250
--112--
21~3~
O
.
. ~ o~
~ ~ 3 o ~ t _ ~ _
_
~ L ~ ~ _
r~r ~ ~ C ~ O ` ` _ _ -- ~
C 1 _ ..~ o o o. o, o, O, O O, O, , O
_~ c ~0 ~ ~ ~ ~ æ ~ 0 ~ æ
~ _
C~ ^ ~", e ~ Z ~ ~l g ~ Z 3 ,~
V, ZCo C~Z o o o o o o o o c~Z o ,~ U
oooo~oooooooo -- Z Z
Z ~ _
z 8 Z ~ ` C~ o V ~ Z_ ~Z ,.~ u
Z
88088888888g ~ Z
Q ~ o o o c~ o o o o o o o o ~ a
~
i ' ' . I ~ i G
tY ~ ~ ~ ~ ~ O V. O VZ O v~ VZ O VZ -- ~ ~~, S! ~Z ~Z
Z Z~,Z ~ ~ o o o ~ ~ Z. ~ ~
; --o o æ o o o o o o o. ~, ~ ~ ~ E ~ ~E
-
~0 94/28496 2 1 6 37 6 8 PCT/AU93100250
--113--
' -U o
~ ~ X
U C~ _
,_ ~o ~ -- ~, ~ X ~ V ~ ~
8 ~
. 5 . .~ ~ ', O ~ ~0 v~
oooOOOOOOOOO
~ æ ' ~ O ~. ~ ~ ~ X ~ o g C æ ~ æ
oo
e ,~ - o ~
~t ~ ~ r ~ ~ w ~ r) ~ ~ _ O ~;
' ~ g 00 oo x w ~ ~ V~ V ~ ~ ~ ~ rv
C V o, o, o, o, o, o, o, o, o o ~ o -- S
oooooooooooo -- Z Z
y o o o o ~ ~~ ~ 2 ~
'C _ _
o o o o, o o o 0 0, o 0, o, rL _ ~ e
O ~ r ~ o _ .
I_ Z' ~' . ~ '_
~ ~ c~ ,g . ~ ~ ~ ~ ~ ~ W ~ ~ ~ ~ W X 2 ' ~ 2: '' ~
W ,Oq
G 0
u~ ~ e -, ' ~.-U~ 5~
5 ~ ô ~ ô v- ô ~ o v~ 8 c ~ t o: ~ t
8 ' 8 ~o ~ ~ c - O c
WO 94/28496 , PCT/AU93/00250
~37~8 -114- --
Z Z
ooo ~
L'Q~ ~ E -- OS6 0
2 - 006 0
- oss 0
L -- OSL O
- OOL'O
O ; _ ~ - 059 0
o
E - OOg O
c~ ~'' L -- OSS O
~C : - OOSO
2 ~ ' . osl~ o
- oo~o
8 iL ~ OS O
` - OOE O
~; - OSZ'O
~ OOZ O
c ~ 00~ 0
g _ E- g - OSO'O / 3
' ~ ~ - o
~ 0)
../~ (OS~'O~
/~ (OOZ'O)
~ (OSZ'O)
-- L ~ ; ~ (OOE O)
~ (OSE O)
00~'0)
_~ ~ (OS~ O)
' ~ (005 0)
-- (055 0)
,~ ~, o 2 8 ~ ~ (0090)
z X O , O O ~o ,, ~ (058 O)
r g ~ ~ (OSL O)
¢ ~ ~ æ . c~ - (0080)
~ (0580)
~ (006'ô)
~ (os6~0)
~ ~ ~ & ~ - ~o~)
; 8 8 8 8 8 ,y 8 8
U O ~
~O 94/28496 . 21 6 3 7 6 8 PCT/AU93/00250
,
. - .
.
æ - ODO ~
~' - 05s-o
OOS'O
L -- 0S8'0
z z z ~ - 008 0
- 05L-0
O ;~ ~ - OOL'O
E - osg o
-- oos o
~Y ",; ,
: - oss o
8 ~ t . - oos o
-- oç~ o
-- oo~ o
o ~ 05'0
o -- 00'0
-- OSZ'O
o ~ . ~ g \ - oo~o
g \ - 050'0 ~ ~
L~ ~ \ -- 00 0 :.
~ 00~'0)
,, - ~0)
C
; ~ - (OOZ'O)\
r . v . ~ -
" 1~, c , ~ ~, -- (00'0)
_ o ~
---- . -- (OS'0) ~
.
-- ' ' -- (OD~'0)
', -- ~05~-0)
C-' A ' -- (OD5'0)
r ,~ 8 8 ~ "' . - (05S0)
Z c~ 8 , 8 8 ,., .. ~
O ~ ~ - (ooLo)
C~ L~ ~; ~ - (05L0~
"' - (058'0)
; 1 ~ ' ~ -- ~0DS'0)
C~ ~ ~. .
_ool) _
WO 94/28496 . PCT/AU93/00250
6 8 -116-
~,
~. Z Z Z
O ' .~ ~ -- ooo
E -- 056 0
~Eb -- 006 0
,, . r~l - 058'0
Z Z z X ~ -- 008 0
- -- OOL'O
. . .
~ - Or 9'0
¢ - oos o
C ' -- L _ CSS 0
- oaso
8 ~ I . - os~ o
- oo~ o
- OSE'O
'` ~ -- OOE'O
r 1~ OSZ O
- 00;~'0 ~
X " - 00~0 / ~,
g _ ;~ r;~ - 050~0 / 3~
O ~ o ~
~00~ 0~ ~
~ (05~'0)
~ (00~'0)
r ~ /~ (05~'0)
~ r ~ /- (OOE'O)
~ J ~ ~ ~ a .~ - (OSE'O)
-- (00~'0)
~ -- (OS~'O)
U ~ OOS O)
-- (OSS'O)
~, ~, 0 8 8 :, _ (OO9 o)
Z ~ 0 88 2 " - (oiso)
O ~ q ~ -- (OOL'O)
a ~ ,q ~ . , '~ ~ (OSL'O)
r~ - (008'0)
--(006'0)
c ~ ' ~ - (000'~)
z ~ 8 i~ 8~ 8 8 8 i~ 8
C~ V ~ ~ ~ rn
21~37~
~0 9412849C PCT/AU93/00250
-117-
o
_=
~) -
rJ ~ 000
E~ Z ~ v~ ~ -- 056 0
006 0
~ ~ 058 0
-" ~ ~ 008 0
I ~ c .
~ 00~'0
r ~ ,~, a _ 059 0
o ~ - oos o
L -- 055 0
' ' . - 005'0
O ~ 05~'0
O -- 00~'0
O
~` ~ 05 0
~ 00 0
æ -- or~z o
-- 0O~O
¢ ~ g
~ ~ ~ 00'0
o ~ ~ o
~00- 0~ ~
/ -- (Os~ o)
~ - (Ooz o)
r , r~ . ~ ~ / ~ (or,z o)
~, I ~ -- (00 0)
L ~ S ul ~ -- (0.' 0)
-- (OOtr'O)
_l - (OS~'O)
~ (OOS'O)
~: -- (OSS'O)
¢ " 8 8 v~
X ~ o . ~ (osgO)
æ ~ ~
~ ~ r~; ~ ~ (OSL O)
æ
~- (0580)
'
~ (0580)
;;~ (006 0)
X c ~ - ~ (OS6 0)
c ~ ~ ~ (000~)
¢ ~
1~ L I ~ g 0 8
V C~ C ~
WO 94/28496 PCTtAU93/00250 ~
~ ~ ~ 3 7 6 8 -118- APPENDIX G
E-- ,V
¢ ~
~ ~
E-- V
V
2~
~ Cq
O~
V ~I~
O ~
V~ ,
2 1 ~ 3~ ~8 pcrrl~93/00
og41~8496 _~9~
8 _
r~ "~
WO 94/28496 ~ 1 ~ 3 7 ~ 8 PCT/AU93/00250
--120-
~o
~ ~ t:
_, ' t
Z ~ ~
8 8
o g.
oO
r ~ ~ ~ r ~g g r.
cr. r_
¢ ~ .
u~ . æ
¢ Y - _
~ 0 ;;
~ E I ' 8 8
~ ~. 80 .cr~
Lll r o c y 5 . 8 t .'.
V ,. ~ D , .~
e ~ L
CL _ ~ ~ ~ ~ ~ ~. L ~ L ~ ,.. ~
2~6~68
WO 94/28496 PCT/AU93/00250
--121--
L ~
~ t ~ ~ r~ .
r~
~ ~ , ~ r
r~ ~
~ , r~
t~ ~ r ~ ' ~ O
O
o ~ r; ~ O . . ~' ., !
ti ti t t~ ~- -- o .
U
c. _ L ~ ~ ~. ~ L. L L3~ ' ~
~ ~ t~ ~
-
--ta
V ~ 3 ;, t_
r ' ,
~ ~ ~
g L
- ~ 3 ~ X ~ E E ~
~ r...... x ;~ 1~ 0 - ~ L ~ r~ ~ z
WO 94/28496 PCT/AU93100250
7 ~ 8
--122--
b
_ ~ o o o 5 _ ~ o ~o N 1~~ 8 ô
E~ o g o o o o o \ I\\-- o o c~ o
~ ~ _ . ~, ~ ~ ~ ~ ~ -- -- _ _ ~ _ o o o o O O ~n
'
fi ~ - - ~ ~ ` o ~- o ~ ~ r
~ ' 'o o 8 ~ ~ ~ ~
;j~ , . . ~ o, O O O O oO o, O O o, o. O oO O _
r
g c _ ~ o o o o o o o ~\ _ o o c~ ~ w w o
o o o o o o o _ _ _ o o o o o ~
a 8 ~ o ~ ~o ,~ ,, N æ ~c O ~,, , , ~,
~ O O O O O C O O O O O O O O O O Z
~ ~ Z ~ ~8oo~ æ~æ~8~ o~ ,o-~,~,co ~ ,~
6 t, ~, ~ _ _ _ _ _ _ _ ~ ~ ~ ,., ,.~ ", ~"" o u
Z
8 8 O O 8 0 O 0 \ ~\ O O O g 8 8 g
~ ~ OOOOOOOO OOOCOOOOo ~ ~o ~ U_ '
0 _
g 8 8 ~1\ ~r - - ~ ~ - o - ~
cn t`- ~ ~
8 ~ ; ~ ~ O ~ c A ~
. I z + n .~ n + n
wo 94,28496 2 1 6 3 76 8 PCT/AUg3/00250
,
~g -123-
'~ g o
--i
.
~. ~ _______ ________
~ m r rJ~ N ' r~ r o r ~ ~ ~ ro r o ~
r~ ~ ooooooo --__oooor~o,~,
~ ~zz
r ~ _)
z ~ o c o c c r ~ r O r C~ r r "0 r 8 ~
L ' ~ -- ' -- _ _ o o o o o o V ., i v Vi
~ C. ~ O ro r.~ C~ Vl 1~ ~
-- ' r' ' ~ X - ~ o Q o O C O = ~ ~r ~ o -- ~o -- ~ 8
-- -- ~ g o o o o OoO 8 \/ ~ ~ ~ ~ ,~1 ,~, ~ ~ v~ g
ooooooo ooooo~oooo--
r X L.~ ~
--`G ,V ~ ~ _ o~ ~ r^ ô ~ ô~ ~ r~ r~l r c~ ~ 8 -- ~r r r.c v~ v~
8 8 c: - o o o O o o o o \ i \ _ o o c~ rJ~ ro rJo r o rc re ~ ~0 o _ o
_ F; ~ o o o o o ra o ~ -- -- ~ OG ~
r
r1 2 _ V N ` r c~ ~,
o o 8 o o o o \~ o r ~ N ~ N ~ ~ rq ~ ~ ~ -- ~ ~i
_~ r OOOOOOO OOOOOOOOO '~
_
-- u 3~ 8 N r~ N r~ r' N N ~\ --r " ~, ~, ~, ~ o
~ ~ Z ~ o 0~, r r r r x r \ r r r r r r r r o
Z _ ~ -- _
tY~q ~ rJ ~ .~ 8. o 8. 8 8 o 8 8 ~ \ o 8 o 8 8 8 8 8 o ~" ~ ~ 5
~ O ~ ~ o o o o o o o o o o o o o o o o _ c ~ ,E
O _ ~ -- E -- ~'
t.~ tL ~ ~ 8 N N . 8. 8. N N ~ r ~ ~ 8. t
-- -- _ _ _ _ _ _ _ _ o --' ~ O
U~ tL . -- L ~ `'
~ v 8 -- N r~ ~ ~ ` ~\ ~ ~r V~ ~0 r ~o o~ 8 t ~ ~ 8 t t3~
o O L~. 1~ y~ ~ -- -- -- -- -- -- ~ N N N r'~ N N N N ¢ t ~ Z J e J E L E
u Z + ~ ~ n + I
WO 94/28496 . PCT/AU93/00250
~ ~ 6~ 768 -124-
. . ~ ' _..
t' ~E
o.
U
8 ~ ,, E
t
L ' ~ ~
.
Z
E ~ `
P~ ~
3 z
~ . .
E . ~ E
8 8 ~ -
Z ~ L ~ , ~
;,,,
L -- ~ ~ o
z O ~, ,~
~0 94/28496 ~ ~ ~ 3 7 fi 8 PCT/AU93/00250
--125--
_
2 ~
E
o
t
2 ~ ~ E
V~
-- ~ ~o~
;:
~ Z
E
3 z _ ~
Y E ~ E
Z ~,, ~ . ,
E--
~: ~ 8 8 ~ --
O ~ '
WO 94128496 PCTIAV93100250
~1~3~68
c~ --126--
e
~ ' ' ~ - oozz
E~ ~ 9 ~ o 081Z
V p - O9~Z
- OS~Z
- f~ ~ U o~z
' ~ O~Z
- OO~Z
_ _ - 060Z
o ~ - 080Z
- OLOZ
C ; L - OSOZ
- OSOZ
P~ : - O~OZ
g , - OEOZ
o ~ - OZOZ
o - O~OZ
o. ' - OOOZ
- 066
-- - 086~
~ - 0~6~_
- ~ OS6
g ~ 0~6
~3 5 ,~ . - 088
~; ` ~ - OL8 1
o - 098
` - 058 1
u - 0~8~
3 - - OE81 ~-
- I ~ - OZ8 1
- 0~8
08~
_l - OLL I
- 091
V - OSL~
- 0
- OEL
p ~; ~ 8 8 8 ` o~L~
a ~ ~ O ~ "~ Oo~ ~ ~ OL9~
- 09
u ~ 8 8 Y 8 ~ 9
~ ~ ~ 3 ~ ~ ~ P~,TIAU93100250
WO 94128496
--127--
O
r ~8~
rJ ~ oOZZ
06~Z -
g ~ ~, oasL~IZz
re 091Z
,~ ~, e OS~z-
- ~ o~z
C OZ~Z
~ ~e . OO-Z
r~ r ~ ~ o60Z
080Z
' _ r OLOZ
OZ '
osoz
C ' o~70Z
r~ r . 080Z
P~ r . ~ OZOZ
8 r- ~' O~OZ
` OOOZ
8 ~ s- - oL6- \
os6-
a ' ' ~ R ~ ~
~ ~ ~ O, 068~
o ~ ~ ~ OL8
o 058~ r~
r~ ' or78~ '
.. r~ oz8~
008~ -
55;, ~ ' ~ ai 08L-
Z ~ __ Oog
SLl
d ~ o~L-
OU~ '
ozL~ -
R o o o 8 R . 9, 8 8
WO 94/28496 PCT/AU93/00250
2~ ~3 ~ ~8 -128- --
C
~ . .
o y
, t~ :
8 .; r
8 ~ ~ , tL
Z - ~ ' '~-
-- r~
t - r ~ ~
o t _ -
o ~
t~ ~ :
c ~ ~ . . ; ~ r~
Z _ 2~
O ~ æ ~ ~
~ 5 Z Z ;~ Z
8, '~
8 :3 ~ z
,~ æ ~ ræ ~ ~ u ~ ~~
P~ - t l - Z .
~, -- } ~ - 8 L ~ L'
IY 3 ~ ., '' . ~ C ~ ~ ~ E F ~ o ' ~ L t~ '
, x a ~
WO 94n8496 ~ L 6 3 7 6 8 PCT/AUg3/00250
~ --,.29--
V
C,l .
~. 8 : ~ OZZ
~ r ~ 08~Z
L ~ r~ O9~z
f- , - Ob~Z
o~Z
E - 060z
` t~ - 080Z
- OLOZ
-; ' O90Z
- ObOZ
g . ~ ~ - 00Z
8 - ozoz
g .- 0~02
o~ ; - OOOZ
.~ ~086~
. - 0~6~ _
æ ~ ~ 8 ~o ~ Ol~b~ A
~ t 8 0-6,~
- 068
. ~ ~ ~ 088-
- 098~
- OS8 ~ '
fi ' - 08~ ~
8~
0~8~_
- 08L~
¢ O9L~
X ~ ! 08LI
Z O V~ o g '. _' ~ OZL~
F ~ 'O~ O _ - E99
oss~
n . ~ . - 099
, 8 8 5~ 8 ~ ~
O O ~
WO 94/28496 PCT/AU93/002~0
~1~37~ ~
--130--
_,
.
" p .
oozz
- O~Z
p - O9~Z
- OS~Z
O~ ~Z
' L~ ' O~:~Z
: ~ ~ ~ Z - OZ~Z
~~ ' ' O~Z
C~ ~ ' OO~Z
- 060Z
o - 080Z
. E - OLOZ
o ; ~ ~ ~ - O90Z
~, _ - 050Z
- : - O~OZ
8 1 - 00Z
OZOZ
8 . - O~OZ
o ' - OOOZ
-- -- - 066
~ - 086~
- ~ - OL6~_
- 096
~ - 056
Y ~ ~ ~ 06
~ ~ _ ~ - OZ6 ~ Lo
~3 Q c ~ 8 0~6
8 068~
-- 5 !~! ~ - 088~-
~ ~; èi~i r - OL8
- - 098
- OS8~
- Ob81
ë ~ ~ 3, - 08~ L
- OZ8
- ' ^ ~Z 0~8
- 008
_ 06
08~
- OLL I
~ - O9L
V OS~
~ - 0
o~ ~ - oL~
z ~ ~ 8 8 ~ xgl
~ -- . OL9
~ L~ æ_ ~ OS9~ ~
- 0~9
~ ~ 0~9 ~
'~ 2 ~ ~ - o~s~
c . . . ,r æ ~ ~ 8 æ 8 ~ ~ 8 8 ~ ~
_ .
~O 94128496 2 1~ 3 76 8 PCT/AU93/00250
,t --131--
.
, .
- oozz
~ g - 06~Z
8 - OL~Z
o - O9~Z
- OS~Z
a ~ 0~ OO~Z
Z OZ~Z
,, O~Z
- 060Z
, - 080Z
'; '' ~ ~ - OLOZ
o ~ ~ ~ - O90Z
D - -; - osoz
- O~OZ
~ r - 00Z
8 - OZOZ
g : , - O~OZ
,~ ; . - OOOZ
- 066
- 086~
0~6~_
OZ6
o r æ O OL8
~ - 098~
c - 058~
-- ~; 08~
OZ8
t 06L~
- 08L
- OLL~
¢ - O9L~
- OSL~
- O~L~
- OL
t~ ~ 8 o o
. a ~ . . . æ _ ~ - 0"~
~ 09-
æ r . 2 _ ~ æ 8 = _ N Z Z~ O N
O ~ r ~_ r~q
WO 94/28496 PCT/AU93/00250
~ ~37~8
.
-132-
APPENDIX H
PROCESS 2 VARIABLES AND DATA FILES
This Appendix lists the file name and description therefor.
Order Data Fields
OID Unique identification assigned by CONTRACT APP to every
new order submitted.
BID Ordering party identification.
BREF Ordering party's own reference for this order.
PID Order field specifying the required product.
PMAT Product maturity date.
15 PC/ED Product consideration/entitlement denomination.
PCUR Product currency denomination.
PNCUR Product national currency denomination.
PPARAM Product specification parameters (eg. mlnimum value
~PMIN), maximum value ~PMAX), and the step size (PSTEP)).
20 MAXCONSID Maximum consideratlon the ordering party will pay for
this contract.
PAYFUNC Pay-off function type, contingent on one or more index
variables.
PAYPARAM Parameters assoc~ated w~th the PAYFUNC.
25 ACC CONSID The ordering party account the consideration is to be
paid from. Implied is the account
consideration/entitlement, currency, national currency.
ACC ENTITL The ordering party account the contract entitlement is
to be paid into. Implied ~s the account
consideration/entitlement, currency, nat~onal currency.
RET LIM Retention time limit for the order, which sets an
expiration time for the order whilst remaining
un-matched.
OPRICE Price calculated and selected for this order (this value
will be the matching price).
WO 94/28496 , 2 ~ ~ 3 7 ~ 8 PCT/AU93/00250
-133-
SPRICE Counterparty identification with which the order was
matched.
PAY ~RAN Payment transaction number.
DCID Defined circumstances identification.
5 OANON Anonymous flag, set by the ordering party when seeking
to avoid manual authorisation requests by other
stakeholders.
OMANUAL Manual authorisation request flag. If set, the ordering
party requires manual authorisation before the matched
order is fully confirmed.
DTID Deal type identification which codes a combination of
miscellaneous flags such as collateralisation, bilateral
and multilateral netting requirements.
Counterparty Short List Arrays
PRICEFUNC(SID) Pricing function: function type and associated
parameters.
ELFUNC(SID) Expected loss determination function: function type
and associated parameters.
EVFUNC(SID) Expected value determination function: function type
and associated parameters.
CR(SID) Commission rate to be used for the current defined
circumstances.
25 DR(SID) Discount rate to be used for the current defined
circumstances.
PRICE(SID) Price calculated by each counterparty.
EL(SID) Expected loss calculated for the current order by
each counterparty.
30 AL(SID) Absolute loss calculated for the current order by
each counterparty.
EV(SID) Expected values determined for the current order by
each counterparty.
MCC(SID) Maximum composition any contract (as an expected
loss) can have of the entire portfolio.
-
WO 94/28496 PCT/AU93/00250
2~6~6~
-134-
MC(SID~ Maximum composition the product (as an expected
loss) can have of the entire portfolio.
ELLl(SID) Order expected loss limit.
ELL2(SID) Expected loss limits set by the counterparty for the
product.
ELL3(SID) Expected loss limits set by the counterparty for
equivalent maturity date products.
ELL4(SID) Expected loss limits set by the counterparty for
same month maturity products.
10 ELL5(SID) Expected loss limits set by the counterparty for
orders in all products.
CEL2(SID) Current accumulated expected losses for the product.
CEL3(SID) Current accumulated expected losses for equ~valent
maturity date products.
15 CEL4(SID) Current accumulated expected losses for same month
maturity products.
CEL5(5ID) Current accumulated expected losses for orders in
all products.
ALLl(SID) Absolute loss limit function for each contract.
20 ALL2(SID) Absolute loss limit function set for the product.
CAL2(5ID) Current absolute limit function accumulated for the
product.
EVLl(SID) Expected value lim~t on each order.
C-C/EDXCHANG(SID) Counterparty consideration/entitlement denomination
exchange rates which convert the ordering party's
consideration denomination of ACC CONSID (and
MAXCONSID) into the product's consideration
denomination.
C-CXCHANG(SID) Counterparty currency exchange rates which covert
the ordering party's currency of ACC CONSID (and
MAXCONSID) into the product's denominated currency.
C-NCXCHANG(SID) Counterparty national currency exchange rates which
convert the ordering party's national currency of
ACC CONSID (and MAXCONSID) into the product's
denominated national currency.
~ o 94/28496 ~ 1 6 3 7 6 8 PCT/AUg3/00250
-135-
E-C/EDXCHANG(SID) Counterparty consideration/entitlement denomination
exchange rates which convert the ordering party's
consideration denomination of ACC ENTITLinto the
product's consideration denomination. E-CXCHANG(SID) Counterparty currency exchange rates which covert
the ordering party's currency of ACC ENTITL into the
product's denominated currency.
E-NCXCHANG(SID) Counterparty national currency exchange rates which
convert the ordering party's national currency of
ACC ENTITL into the product's denominated national
currency.
Miscellaneous Variables
15 BPRICE Best price selected from the PRICE(SID) array.
SID The currently selected or viewed counterparty
identificatlon.
INDEX Index counter variable required for calculating
order prices.
20 Pl Value calculated by a pricing function at an index
potnt.
P2 Value calculated by a pay-off function at an index
point.
25 Master Files
FILE DESCRIPTION/CONTENTS
PORD NEW Holds detalls of all new orders submitted by ordering
parties:
BID Ordering party identification.
BREF Order~ng party's own reference for this order.
PID Order field specify~ng the required product.
MAXCOIYSID Maximum consideration the orderlng party will pay for
th~s contract.
WO 94/28496 PCT/AU93/00250 ~
' ''''"
21~768 -136-
PAYFUNC Pay-off function type, contingent on one or more index
variables.
PAYPARAM Parameters associated with the PAYFUNC.
ACC CONSID The ordering party account the consideration is to be
paid from.
ACC C/ED The ordering party account consideration/entitlement.
ACC CUR The ordering party account currency.
ACC NCUR The ordering party account national currency.
ACC ENTITL The ordering party account the contract entitlement is
to be paid into.
RET LIM Retention time limit for the order, which sets an
expiration time for the order whilst remaining
un-matched.
OANON Anonymous flag, set by the ordering party when seeking
to avoid manual authorisation requests by other
stakeholders.
OMANUAL Manual authorisation request flag. If set, the ordering
party requires manual authorisation before the matched
order is fully confirmed.
20 DTID Deal type identification which codes a combination of
miscellaneous flags such as collateralisation, bilateral
and multilateral netting requirements.
PORD QUEUE This master file holds details of orders which have
already been authorised, and have attempted to match
once before. Fields as in ORD NEW plus some additional
fields:
OID Unique identification assigned by P-CONTRACT to every
new order submitted.
30 PMAT Product maturity date.
C/ED Product considerationlentitlement denomination.
PCUR Product currency denomination.
PNCUR Product national currency denomination.
PPARAM Product specification parameters (eg. minimum value
(PMIN), maximum value (PMAX), and the step size (PSTEP)).
DCID Defined circumstances identification.
~0 94128496 21~ 8 PCT/AU93/002S0
-137-
PORD REJ All rejected orders reside in this file. Fields as in
ORD QUEUE plus some additional fields:
ERRCODE Error code indicating why the order was rejected.
5 PORD CONF When an order is matched and fully confirmed, full
details are stored in this master file. Fields as in ORD
QUEUE plus some additional fields:
OPRICE Price calculated and selected for this order. This value
will be the matching price.
10 SPRICE Counterparty identification with which the order was
matched.
PAY TRAN Payment transaction number.
PPRODUCT This master file holds information (definition details)
about each product known to the system:
PID Product identification.
PMAT Product maturity date.
PC/ED Product consideration/entitlement denomination.
PCUR Product currency denomination.
20 PNCUR Product national currency denomination.
PPARAM Product specification parameters (eg. minimum value
(PMIN), maximum value (PMAX), and the step size (PSTEP)).
PDEAL LIST This file holds a l,ist of the ordering
partylproduct/counterparty tuples of allowable deals to
occur. Thus by specifying an ordering party (BID) and
product (PID), a list of counterparties who are prepared
to enter into a deal with the ordering partylproduct
combination, can be obtained:
30 BID Ordering party identification
PID Product identification
SID Counterparty identification
ANON All stakeholder identifications requiring anonymous
confirmation.
35 MANUAL All stakellolder identifications requiring manual
authorisation
WO 94/28496 PCTIAU93/00250
6 ~ - --
-138-
PSEL DC This file allows counterparties to define
identifications for sets of potential order parameters.
Any order data field can be used to define an order.
Each defined circumstance identification is then used to
set unique pricing parameters:
DCID Defined circumstances identifications.
BID Ordering party identification
PAYFUNC Pay-off function type, contingent on one or more index
variables.
10 PAYPARAM Parameters associated with the PAYFUNC.
ACC CONSID The ordering part account the consideration is to be
paid from.
ACC ENTITL The ordering party account the contract entitlement is
to be paid into.
15 DTID Deal type identificatlon.
PC/ED Product consideration/entitlement denomlnation.
PCUR Product currency denomination.
PNCUR Product national currency denomination.
20 PSEL PRICE Contains all counterparty pricing parameters, lncluding
commlsslon rates, discount rates and exchange rates:
SID Counterparty identification
PID Product identificatlon
DCID Deflned circumstances identiflcatlon
25 PRICEFUNC Priclng function: functlon type and assoclated
parameters.
CR Commisslon rate to be used for the current ordering
party in the current product.
DR Discount rate to be used for the current ordering party
in the current product.
C-C/EDXCHANG Counterparty conslderation/entltlement denomlnatlon
exchange rates which convert the ordering party's
consideration denomination of ACC CONSID (and MAXCONSID)
into the product's consideratlon denomination.
C-CXCHANG Counterparty currency exchange rates which covert the
ordering party's currency of ACC CONSID (and MAXCONSID)
.
~O 94/28496 216 3 ~ 6 8 PCT/AU93/00250
-139-
into the product's denominated currency.
C-NCXCHANG Counterparty national currency exchange rates which
convert the ordering party's national currency of ACC
CONSID (and MAXCONSID) into the product's denominated
national currency.
E-C/EDXCHANG Counterparty consideration/entitlement denomination
exchange rates which convert the ordering party's
consideration denomination of ACC ENTITL into the
product's consideration denomination.
10 E-CXCHANG Counterparty currency exchange rates which covert the
ordering party's currency of ACC ENTITL into the
product's denominated currency.
E-NCXCHANG Counterparty national currency exchange rates which
convert the ordering party's national currency of ACC
ENTITL into the product's denominated national currency.
PSEL LIMIT Holds all counterparty portfolio limits and current
accumulated exposures in the various mathematical forms
allowed by the system:
20 SID Counterparty identification
PID Product identification
DATE Product maturity date.
MCC Maximum composition any contract (as an expected loss)
can have of the entire portfolio.
MC Maximum composition the product (as an expected loss)
can have of the entire portfolio.
ELLl Order expected loss limit.
ELL2 Expected loss limits set by the counterparty for the
product.
ELL3 Expected loss limits set by the counterparty for
equivalent maturity date products.
ELL4 Expected loss limits set by the counterparty for same
month maturity products.
35 ELL5 Expected loss limits set by the counterparty for orders
in all products.
WO 94/28496 2 7 ~7~ 8 PCT/AU93/00250~
- 1 40-
CEL2 Current accumulated expected losses for the product.
CEL3 Current accumulated expected losses for equivalent
maturity date products.
CEL4 Current accumulated expected losses for same month
maturlty products.
CEL5 Current accumulated expected losses for orders in all
products.
ALLl Absolute loss limit function for each contract.
ALL2 Absolute loss limit function set for the product.
10 CAL2 Current absolute limit function accumulated for the
product.
EVLl Expected value limit on each order.
PAYACC Payment accounts for all registered stakeholders (inc.
balances and previous SHADO~transactions), are stored in
this master file:
ID Stakeholder identification.
N0 Account number.
ACC C/ED The ordering party account consideration/entitlement.
20 ACC CUR The ordering party account currency.
ACC NCUR The ordering party account national currency.
BALANCE Available funds.
GID Stakeholder identification guaranteelng the account.
