Methods of exchanging an obligation6912510Abstract A method of exchanging an obligation between parties where the exchange is administered by a supervisory institution that ensures real-time settling of obligations between parties by updating shadow records in real-time and instructing one or more exchange institutions to effect, from time to time, the exchange of obligations in accounts maintained external to the supervisory institution. Updates to the exchange institution accounts may reflect the net obligations of parties over a nominated period of time. The role of the supervisory institution is to ensure that obligations are only settled where parties have sufficient balance in their shadow records to complete the transaction. Obligations that can be exchanged include, but are not limited to: shares in financial or physical assets, participation rights in wagers, national or synthetic currencies, exchange settlement account deposits, taxation account deposits, and deposits of financial instruments or precious metals. Claims 1. A method of exchanging an obligation between parties, wherein an exchange obligation is administered by a supervisory institution, and wherein at least one credit record and one debit record is maintained with an exchange institution, the method comprising: Description TECHNICAL FIELD
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 detailed discussion of the nine CONTRACT APP processes is given in the section headed DESCRIPTION OF CONTRACT APP PROCESSES hereinbelow. All these processes collectively access multiple data files and multiple records within these files. A description of the variables and data files used by Process 2, a key component process of a CONTRACT APP, is provided in the section headed PROCESS 2 VARIABLES AND DATA FILES hereinbelow. 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 the section headed RISK MANAGEMENT CONTRACTS hereinbelow. 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" (XPWs). That is, warrants providing 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 XPW 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 parties (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, Application Specification, to the final step, Contract Settlement, is shown in FIG. 6. FIGS. 43A-50B are eight detailed explanatory charts supporting FIG. 6. They should be read together with the following description. Looking at the first step in the timeline (Application Specification) in conjunction with FIGS. 43A and 43B, it can be seen that Demdata Inc. established a Contract APP (Application ID100) on 92.02.10.17.00.00 (that is, in inverse order, 5 pm on Feb. 10, 1992) to deal with defect liability management. Application ID100 supports a range of products (Applicable Product ID's 1200-1250). Looking at the second step in the timeline (Product Specification) in conjunction with FIGS. 44A and 44B, 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 Indices, 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 Warrants (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 2% increments in respect of the sub-market outcomes. Looking at the third step in the timeline (Potential Counterparty Product Pricing Specifications), 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 FIGS. 45A and 45B, 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). FIGS. 45A and 45B show the specific "pay-off" parameters that Denisons has defined for the contract it is seeking at this time, including 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 FIGS. 46A and 46B, it can be seen that Demdata (using the specified pricing parameters set at (93.07.01.14.00.00.00) prices the Denison order 93.07.01.15.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 signify 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.10%, 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 multiplied by the potential counterparty-specified assessed probabilities of occurrence to yield a corresponding number of net contingent entitlement valuation amounts. When added together, these sum to (30.770). 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, (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 of FIGS. 46A and 46B are used for checking that this contract, if entered into by Demdata, will 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 sixth step in the timeline (Order Matching), 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.00. 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 determined 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 Valuation) in conjunction with FIGS. 47A and 47B, 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 (with a standard deviation of 6,213). On FIGS. 48A and 48B it 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 which may be netted against these payments/receipts). 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 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 FIGS. 49A and 49B). As can be seen, the market estimate of the future product value of the 64 BMFT 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,209). 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 FIGS. 50A and 50B, this product value of the 64 BMFT 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). 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 cities) 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 units 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 difference 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 itself); 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 Specification, to the final step, Contract Settlement, is shown in FIG. 7. FIGS. 51A-59B are nine detailed explanatory charts supporting FIG. 7. They should be read together with the following description. Looking at the first step in the timeline (Application Specification) in conjunction with FIGS. 51A and 51B, it can be seen that Newcom Inc. established a Contract APP (Application ID 001) on 93.11.01.17.00.00 (that is, 5 pm on Nov. 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 FIGS. 52A and 52B, 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 normalized in the range of -;1.0 to +1.0, respectively signifying the proportionate utilization 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 FIGS. 53A and 53B, 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). FIGS. 53A and 53B show 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). Looking at the fifth step in the timeline (Order Specification Pricing) in conjunction with FIGS. 54A and 54B, it can be seen that Tasnet (using the specified pricing parameters set at 94.06.01.14.00.00.00) prices the Basstel Co. order at 94.06.01.14.26.40.00. Tasnet's pricing parameters indicate that their appropriate Defined Circumstances ID for Basstel Co. is 8. As is shown, this ID in 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 1, 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 with FIGS. 55A and 55B, it can be seen that Aarcom (again using the specified pricing 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 Commission Rate of 0.90%, a Discount Rate of 8.50% per annum, a particular set of Component product prices and a particular set of Assessed Probabilities of Occurrence. This results in a Contract Bid Price of 55,390 (denominated 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). Looking 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 specified maximum 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) immediately assign the required consideration amount of 55,180 TTUs to Tasnet. Looking at the eighth step in the timeline (Contract Valuation) in conjunction with FIGS. 56A and 56B, 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 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,207). On FIGS. 57A and 57B 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 payments/receipts). 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 FIGS. 58A and 58B). 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 0.010), 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 FIGS. 59A and 59B, 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). 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, subject to this price being at or below the specified maximum price the ordering party has indicated it is prepared to pay. Second, accommodate portfolio 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 basis, with partial matching of product orders, and without conditional order matching rules. As shown in FIG. 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 confirms 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 implemented 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 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 "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 is 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 file 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 fail this test are rejected at block 1140, with 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 verified (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 1200 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 matching 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 maximum "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 down 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 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 including 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 1250. 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 their 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 variable, 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 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 P1. 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 P1 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: 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 is 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): At block 1470, the price bid is adjusted according to the formula: 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: 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 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 in detail. Starting at test 1560, a check is made to ensure the potential counterparty shortlist is not empty. If it is, no match is possible and flow continues at block 1612. At this point SID is assigned "0" 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 priced 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 national 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 identification is stored in SID, and its price offer is stored in BPRICE. At block 1580, the following check is made: If the selected price is greater than the ordering party's specified maximum consideration payment (MAXCONSID) limit, a match with the current potential counterparty is not deemed possible. This must also be true for any of the remaining counterparties in the counterparty short list. This part of the matching process returns without any potential 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 limits to be read from the PSEL LIMIT master file (block 1600) and stored in ALL1(SID), ALL2(SID), ELL1(SID), ELL2(SID), ELL3(SID), ELL4(SID), ELL5(SID), EVL1(SID), MC(SID) and MCC(SID). The current absolute and expected losses accumulated are also read and stored in CAL2(SID), CEL2(SID), CEL3(SID), CEL4(SID), and CEL5(SID). 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). Proceeding 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 rejections were received, program flow continues at block 1627 where the order is rejected. Otherwise, flow continues at 1624. Block 1624 effects the consideration payment by creating transactions in the payment shadow file (PAYACC SHADOW-block 1625). However, this may fail if the 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. With 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. 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 1996, relative to the assumed current (June 1991) 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 index 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. FIGS. 60A to 72B are thirteen detailed explanatory charts supporting FIG. 17. They should be read together with the following description. Looking at the first step in the timeline (Application Specification) in conjunction with FIGS. 60A and 60B, it can be seen that BLC Inc established a Contract APP (Application ID 001) on 91.06.03.17.00.00 (that is, 5 pm on Jun. 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 FIGS. 61A and 61B, 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 in the timeline (95.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 FIGS. 62A and 62B, it can be seen that an Ordering Party, Abbotts & Taylor, is seeking a contract, from an offering party, in Product 10061 at that time (95.01.01.17.37.06.00). FIGS. 62A and 62B show 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: "[ ]". Looking at the fifth step in the timeline (Order Specification Pricing) in conjunction with FIGS. 63A and 63B, it can be seen that Abrahamsons' specified pricing parameters, as set at 95.01.01.17.37.06.06 are used to price the Abbotts & Taylor order at 95.01.01.17.38.02.00. Abrahamsons' pricing parameters indicate that their appropriate Defined Circumstances ID for Abbotts & Taylor is 26 [1240]. As is shown, this ID in turn implies a Commission Rate of 1.25%, a Discount 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 1, 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) [1250]. Still looking at the fifth step in the timeline, in conjunction with FIGS. 64A and 64B, it can be seen that Carpenters Inc specified pricing parameters, as set at 95.01.01.17.37.06.00, are also used to price the Abbotts & Taylor order at 95.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.30%, 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 in 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 conjunction with FIGS. 65A and 65B, it can be seen that Abrahamsons' pricing-related parameters (also set at 95.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 is below the maximum consideration price that Abbotts & Taylor has specified, in its order specification (FIGS. 62A and 62B), it is prepared to pay. Finally, still looking at the fifth step in the timeline, but now in conjunction with FIGS. 66A and 66B, it can be seen that Carpenters Inc's pricing-related parameters (set at 95.01.01.17.37.06.00) for determining the acceptability of ordered-contract oil 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 (FIGS. 62A and 62B), 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 95.01.01.17.38.07.00 [1260]. The seventh step in the timeline (Order/Contract Confirmation) takes place five seconds later at 95.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 FIGS. 67A and 67B, one can see a contract valuation report for Abbotts & Taylor published nearly six hours after confirmation of the contract, that is, at 95.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 is 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 FIGS. 68A and 68B one can see in the equivalent report for Abrahamsons that their required expected future entitlement payout is identical to Abbotts & Taylor's expected future entitlement receipt (ignoring future fee payments which may be netted against these payments/receipts). The ninth step in the timeline (Secondary Order Specification), detailed on FIGS. 69A and 69B, occurs nearly six months after the above-described contract valuation event; that is, at 95.06.06.08.00.00.00. At this time, Abbotts & Taylor is seeking to sell its position in the contract which was matched/confirmed at 95.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 FIGS. 70A and 70B, 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 96.01.01.17.00.00.00 (see FIGS. 71A and 71B). 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, 96.06.03.17.00.00.00. As can be seen on FIGS. 72A and 72B, this product value of the PTSE Index was specified by BLC Inc (as Product Sponsor) to be 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 96.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). Life Cycle of Economic Management Contract: EXAMPLE IV This further example of a risk management contract is an extension of Example III. More particularly, however, it is a special case of the general case of Example III, in that for a particular phenomenon the same entitlement is specified by the ordering party for each of the possible outcomes. This is a case where X=1, α(X) is not applicable, β(X)=the specified non-contingent entitlement (constant), and γ(X)=11, where "11" denotes a mathematical shape that is a straightline with respect to the 'outcome' axis, drawn from a menu of such shapes. Put another way, the gradient of the graph of entitlement (y-axis) against outcome (x-axis) is zero. The counterparty registering data remains the same as for Example III. It can be thought of as the scenario where the outcome is not of concern to the ordering party. When its future entitlement is positive, the contract, from the ordering party's view, is in the nature of a loan, in that the consideration is made available now for a future known entitlement. It is of course possible for the consideration and entitlement to be negative so that the nature of the contract from the ordering party's viewpoint is borrowing. The example shows just this situation, in that one party (such as an institutional fund manager) seeks to avoid the adverse consequences of not having immediate possession of a defined resource (say, Australian dollars) by becoming a party to a contract with another, as-yet-unknown, party (such as another fund manager seeking to avoid the adverse consequences of being unable to adequately utilise the defined resource). The specific contract offering is one which provides an ordering party with a specified non-contingent obligation (that is, a negative future entitlement) to make an Australian dollar future payout to the contract's counterparty upon that counterparty's payment of a calculated up-front consideration money amount to the ordering party. Thus, for a given guaranteed entitlement payout amount by the ordering party to its counterparty on a contract's maturity date, the up-front consideration payment is essentially a function of two matters implicitly determined between the ordering party and the counterparty registering data:
Note that if, say, the contract entitlement is based in US dollars, the matter of the counterparty's defined forward Australian dollar/U.S. dollar exchange rate would also be relevant. As noted, the relevant key stakeholders are the same as in Example III: 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). A timeline depicting the steps in the contract from the first step, Application Specification, to the final step, Contract Settlement, is shown in FIG. 41 and further supported by FIGS. 73-77B. Looking at the first step in the timeline, Application Specification, in conjunction with FIG. 73, we see that BLC Inc established a Contract APP (Application ID 001) on 91.06.03.17.00.00 (that is, 5 PM on Jun. 3, 1991) to deal with economic risk management. The application involves a pricing and matching objective function of: "minimize pre-tax consideration payment under an expected value (EV)/certainty equivalent (CE) value". Note that a negative consideration payment is allowed. Looking at the second step in the timeline, Product Specification, in conjunction with FIG. 74, we see that BLC Inc was also product sponsor of Product 10061 at the same time (91.06.03.17.00.00). This product relates again to the market of stock indices. The maturity date for Product 10061 is 96.06.03.17.00.00.00. The sub-market is the PTSE 75 stock index. 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 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 in the timeline (95.01.01.17.00.00.00), 43 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 FIG. 75, it can be seen that Abbotts & Taylor is seeking a contract in Product 10061 at that time (95.01.01.17.37.06.00). FIG. 75 shows the specific parameters that Abbotts & Taylor has defined for the contract it is seeking at this time, namely $A 83,830 for any feasible product value including a minimum acceptable contract consideration amount of ($A 55,000). The parentheses indicate that the consideration is negative. The calculated counter consideration (≧$A 55,000) will be paid by the counterparty to Abbotts & Taylor immediately after contract matching. Looking at the fifth step in the timeline, Order Specification Pricing, in conjunction with FIGS. 76A and 76B, it can be seen that Abrahamsons (using the specified pricing parameters set at 95.01.01.17.37.06.00) prices the Abbotts & Taylor order at 95.01.01.17.38.02.00. Abrahamsons' pricing parameters, indicated by their defined circumstances ID of 31, require a commission rate of 1.25% and a discount rate of 10.00% pa. A particular set of component product prices together with a particular set of assessed probabilities of occurrence are specified. This results in a counter consideration of ($A 58,710), which Abrahamsons' parameters calculate will yield them a base margin on the contract of $A 1,980. Still looking at the fifth step in the timeline, in conjunction with FIGS. 77A and 77B, it can be seen that Carpenters Inc (again using the specified pricing parameters set at 95.01.01.17.37.06.00) also prices the Abbotts & Taylor order at 95.01.01.17.38.02.00. Carpenters Inc's pricing parameters, indicated by their defined circumstances ID of 19, require a commission rate of 1.30% and a discount rate of 9.8% pa. A particular set of component product prices and a particular set of assessed probabilities of occurrence are specified. This results in a contract bid price of ($A 58,640), which Carpenters Inc's parameters calculate will yield them a base margin on the contract of $1,990. Looking at the sixth step in the timeline, Primary Order Matching, it can be found that Abrahamsons' price bid of ($A 58,710) is above Carpenters Inc's bid of ($A 58,640) and above Abbotts & Taylor's specified minimum consideration price of ($A 55,000). This leads to a formal matching of Abbotts & Taylor's order by Abrahamsons at 95.01.01.17.38.07.00. Before the matching formally occurs, a check is made that absolute loss, expected loss, expected value and portfolio attribute limits are not violated. The seventh step in the timeline, Contact Maturity, refers to the actual determination of the product value at time of maturity, 96.06.03.17.00.00.00. The eighth step in the timeline involves the formal payment of $A 83,830 by Abbotts & Taylor to Abrahamsons. The example just described can also be thought of as a case where the market is irrelevant, and therefore there is no minimum or maximum product definition value nor product step value. This equates to there being no future outcome, rather simply a known specified entitlement that is not dependent upon the outcome of any particular phenomenon. The mathematical representation of curves or lines no longer is relevant. The counterparty counter consideration thus becomes a function only of the discount rate, commission and (if applicable) entitlement exchange rate. Life Cycle of Economic Management Contract: EXAMPLE V This embodiment relates to an economic management contract (based on a variation of Example IV) and describes the formulation of an immediate exchange contract involving an entitlement of a defined $US amount in return for a to-be-determined consideration denominated in commercial bank Australian dollars. This example is a special case of the general case of Example II in that it is independent of the outcome of any particular phenomenon. It has only a single outcome for which a single entitlement is specified by the ordering party. Unlike Example IV, however, this case also involves a unique notion of a contract maturity date/time. This is the notion of "as soon as possible after the date/time the transaction is originated by the ordering party", implying an immediate exchange. That is, the date of maturity is now. In this example, the offering is one which provides a contract ordering party with a specified non-contingent entitlement to receive its desired $US currency amount ($US 70,000) as soon as possible after the ordering party specifies it is prepared to immediately pay not more than $A 102,900 (as a consideration) in exchange for this US currency. 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), 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. 42, and are supported by FIGS. 78-82B. Looking at the first step in the timeline, Application Specification, in conjunction with FIG. 78, we see that BLC Inc established a contract APP (Application ID 201) on 91.06.03.17.00.00 (that is, 5 pm on Jun. 3, 1991) to deal with economic risk management. The application involves a pricing and matching objective function of: "maximize pre-tax consideration/entitlement exchange rate". Application ID 201 supports a range of products. Looking at the second step in the timeline, Product Specification, in conjunction with FIG. 79, we see that BLC Inc was also product sponsor of Product 11099 at the same time (91.06.03.17.00.00). This product relates to the market of immediate exchange. The maturity date for Product 11099 is "as soon as possible after transaction initiation". The consideration for a specific contract involving Product 11099 is commercial bank deposits denominated in Australian dollars. The entitlement is in the form of commercial bank deposits denominated in US dollars, payable immediately after the product's specified maturity date/time (that is, as soon as possible after transaction initiation). Looking at the third step in the timeline, Potential Counterparty Product Pricing Specifications, two entities, Abrahamsons and Carpenters Inc, are potential counterparties for forthcoming primary product orders dealing with Product 11099. At this point in the timeline (92.06.03.15.00.00.00), 12 months after the specification of Product 11099, 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 FIG. 80, it can be seen that an ordering party, Abbotts & Taylor, is seeking a contract from an offering party in Product 11099 at that time (92.06.03.17.00.00.00). FIG. 80 shows the specific parameters that Abbotts & Taylor has defined for the contract it is seeking at this time, including a maximum exchange (consideration) amount of ($A 102,900) and a defined $US 70,000 entitlement. Looking at the fifth step in the timeline, Order Specification Pricing, in conjunction with FIGS. 81A and 81B, it can be seen that the system determines that the counter consideration amount Abrahamsons judge to be ideal given their specified parameters is $A 94,500. This occurs at 92.06.03.17.38.02.00. Abrahamsons' pricing parameters specify an exchange rate of 0.75, a commission rate of 1.25% and a single assessed probability of occurrence of one (1) (discount rate and component product prices being irrelevant in this example). The counter consideration of $A 94,500 is lower than Abbotts & Taylor's specified maximum consideration amount of $A 102,900. Still looking at the fifth step in the timeline, in conjunction with FIGS. 82A and 82B, the system determines that the counter consideration amount Carpenters Inc judge to be ideal given their specified parameters is $A 101,300. Carpenters Inc's pricing parameters imply an exchange rate of 0.70, a commission rate of 1.30% and a single assessed probability of occurrence of one (1) (discount rate and component product prices again being irrelevant). Looking at the sixth step in the timeline, Order Matching, it can be found that the system assesses Abrahamsons' to be superior to that of Carpenter Inc and below Abbotts & Taylor's maximum consideration. This leads to a formal matching of Abbotts & Taylor's order by Abrahamsons' at 92.06.03.17.38.12.00. Matching coincides in time with maturity, and very shortly thereafter there is the transfer of $A 94,500 from Abrahamsons to Abbotts & Taylor and a corresponding transfer of $US 70,000 from Abrahamsons to Abbotts & Taylor. This then represent finalisation of the transaction, including all the transfers involved at the date/time of maturity of other contract types. A further embodiment, relevant to each of the embodiments of Examples III to V above, involves the order pricing procedure as before, followed by a step of obligating the ordering party with the would-be matched counterparty for a period of time before the match is formally made. As before, the consideration can be payable immediately upon match or deferred for a time (even up until maturity), and the date of maturity can be at a future time from matching (or even immediately upon match). The period of obligation can be specified by the promoter stakeholder, and thus be known to the ordering party and the registering counterparties. The period of obligation thus enables parties to contract to future contingent contracts (in the case of Examples I and IV) or future exchange (in the case of Example V). 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 credits to INVENTCO stakeholder accounts, typically at maturity of a contract, with participating consideration/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. First, 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 INVENTCO, with which they maintain 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 entity. 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 SHADOW file account record should be equivalent to the true, but usually unknown, time-of-day balance of the actual account maintained by the C/E transfer entity. The purpose of two accounts is to enable only credits to be effected through one account and only debits through another account. And the purpose of "net-credit balance only" accounts is to ensure that accumulated debits to the debits-only account never exceed the account opening balance plus accumulated credits to the credits-only account. C/E transfer entities will typically 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 clearing houses and depositories. The resources transferred by these entities may be of any type. However, most typically, they will be deposits appropriate for the entity concerned: With 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, each C/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 credit 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 combination 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 15 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 "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 itself, 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. Where 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 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 appropriate device(s), confirms that remote messages received from that customer, and processed by the "black box", are authentic. Second, the consideration/entitlement 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 with 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 direct, 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 their account records. Where an INVENTCO stakeholder has authorised other INVENTCO stakeholders to initiate debits 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 in VIRPRO-specified INVENTCO communication procedures). Once again, the type of procedure, set down by all participating C/E transfer entities in this respect, involves (at least) the following: First, the C/E transfer entity supplying VIRPRO with a confidential file of account Pin 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 initiating any of a number of possible proprietary password request-response processes involving an entity nominated by any of its 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 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 SHADOW 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 shadow 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. Where applicable, at days-end for the "clearing house" of clusters 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. Glossary of Key Terms 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-including the specific products offered for trading; categories of, and conditions of involvement, of stakeholders; nature of involvement and dispute resolution procedures of stakeholders. Automatic/Manual Deal and No Deal Flags Indicators notified by each stakeholder to CONTRACT APP specifying the manner in which that stakeholder wishes to deal with each other s | ||||||
