WO2002007498A2 - Method and apparatus for intermediating transactions between customers and brokers in futures exchange - Google Patents

Method and apparatus for intermediating transactions between customers and brokers in futures exchange Download PDF

Info

Publication number
WO2002007498A2
WO2002007498A2 PCT/KR2000/001061 KR0001061W WO0207498A2 WO 2002007498 A2 WO2002007498 A2 WO 2002007498A2 KR 0001061 W KR0001061 W KR 0001061W WO 0207498 A2 WO0207498 A2 WO 0207498A2
Authority
WO
WIPO (PCT)
Prior art keywords
central controller
customer
brokers
customers
margin
Prior art date
Application number
PCT/KR2000/001061
Other languages
French (fr)
Other versions
WO2002007498A3 (en
Inventor
Min-Woo Nam
Original Assignee
Samsung Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Corporation filed Critical Samsung Corporation
Priority to GB0301357A priority Critical patent/GB2380582A/en
Priority to AU2000274567A priority patent/AU2000274567A1/en
Publication of WO2002007498A2 publication Critical patent/WO2002007498A2/en
Publication of WO2002007498A3 publication Critical patent/WO2002007498A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/08—Auctions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Definitions

  • the present invention relates to a method and apparatus for
  • present invention relates to a method and apparatus for customers'
  • a central controller receiving a request for a quotation (RFQ) from
  • intermediating method between customers and brokers comprises steps of:
  • FIG. 1 shows a block diagram of an apparatus for intermediating
  • FIG. 2 shows a block diagram for requesting and processing
  • FIG. 3 shows a block diagram for an offset process according to the
  • FIG. 4 shows a detailed block diagram of a central controller
  • FIG. 5 shows a detailed block diagram of a broker interface
  • FIG. 6 shows a detailed block diagram of a customer interface
  • FIG. 7 shows a flow chart for a customer's generation of a request
  • FIG. 8(a) shows a flow chart of a process whereby a margin is
  • FIG. 8(b) shows a flow chart of a process whereby a central
  • controller provides a customer with information on whether the customer has
  • the margin and the customer is requested to pay the margin according to the
  • FIG. 9 shows a flow chart of a process of conducting an examination
  • FIG. 10 shows a flow chart of a process whereby the broker provides
  • FIG. 11 shows a flow chart of a process of an execution of the
  • FIG. 12 shows a flow chart of a process of an offset of the positions
  • FIG. 13 shows a flow chart of a process of changing positions from a first broker to a second broker according to the preferred embodiment of the
  • FIG. 14 shows a flow chart of a process of a prearrangement of a
  • FIG. 1 shows a block diagram of an apparatus for intermediating
  • a central controller 400 comprises a central controller 400, a plurality of broker interfaces 500 and a
  • gateways for communications with the central controller 400.
  • the central controller 400 controls gateways for communications with the central controller 400.
  • FIG. 2 shows a block diagram for requesting and processing
  • a customer logs in to the central controller 400 by using
  • the customer interface 600 to create an RFQ 100 and transmit the RFQ to
  • the central controller 400 checks the RFQ 100
  • the brokers transmit the quotation to the central
  • the central controller 300 then transmits the quotation 110 to
  • FIG. 3 shows a block diagram for an offset process according to the
  • central controller 400 transmits the offsetting order 300 to the brokers.
  • brokers check the offsetting order 300 and transmit a message on the receipt
  • central controller 400 transmits the message to the customer. According to a
  • FIG. 4 shows a detailed block diagram of a central controller
  • the central controller comprises a central processing unit
  • CPU central processing unit
  • position management processor 407 a position management processor 407
  • processor 420 an RFQ generation processor 425, a transaction tracking
  • processor 440 central processing unit 440
  • network interface 445 and a data storage device 450.
  • the central controller 400 operates as a web server, both receiving
  • a microprocessor such as
  • UltraSPARC-ll manufactured by Sun Microsystems Inc.
  • 400MHz UltraSPARC-ll manufactured by Sun Microsystems Inc.
  • the data storage device 450 stores the data used in processing the
  • Magnetic storage devices such as hard disk drives or optical storage
  • CD-ROM drives or flash memory can be used for the data
  • the data storage device 450 comprises a broker
  • a customer database 460 a customer database 460, an account database 465, a margin checking factor database 467, a customer position management
  • database software such as Oracle 8
  • the broker database 455 stores data on the brokers such as names,
  • information comprises authorized transactors, phone numbers of the
  • the customer database 460 stores data on the customers such as
  • transactors web page URLs, electronic mail addresses, facsimile numbers,
  • the account database 465 stores data on the customer's accounts
  • the margin checking factor database 467 stores data on the factors
  • margin requirements such as credit lines, initial margin rates, variation margins, account balances and net positions.
  • the customer position management database 470 managing the
  • the RFQ history database 475 managing data on the RFQs, stores
  • the audit database 485 stores transactional information relating to
  • the certificate database 490 stores certificates of both the brokers
  • the cryptographic processor 440 encrypts and decrypts the
  • the bill information database 495 stores contents of the bills of
  • the network interface 445 is the gateway to communicate with the
  • LAN area network cards
  • FIGs. 5 and 6 show the broker interface 500 and the customer interface 600, respectively. These interfaces are connected with the central
  • FIG. 5 shows a detailed block diagram of a broker interface
  • the broker interface 500 comprises a central processing
  • CPU central processing unit
  • RFQ radio frequency
  • the synchronizing processor 520 tracks events of the customers'
  • central controller 400 is configured to control central controller 400.
  • the data storage device 550 comprises a messaging database 570
  • the messaging database 570 managing the messages of the
  • customers and the brokers can be used for archiving brokers' responses as
  • the audit database 580 stores payment records and accesses
  • FIG. 6 shows a detailed block diagram of a customer interface
  • the customer interface 600 comprises a central processor unit (CPU) 605, a transaction confirmation receiving processor 620, a video
  • receiving processor 620 receives a final confirmation from the central
  • controller 400 and performs a cross check on the final confirmation with the
  • interface 600 the primary functionality being message creation and
  • the central controller 400 is configured as a web server
  • the customer logs in to the central controller 400, creates an RFQ
  • the central controller 400 controls the central controller 400
  • the brokers' quotations 110 are electronically transmitted to the central
  • controller 400 which transmits the quotations 110 to the customers for the
  • FIG. 7 shows a flow chart for a customer's generation of a RFQ
  • the customer logs in to the central controller 400 using the customer
  • the central controller 400 has a page on the
  • the customer selects a contract product from the contract list of the
  • step S711 the contract products
  • step S720 After the order
  • an order sheet is displayed on the video monitor 640 of the
  • This sheet is an electronic contract with terms and
  • the customer selects a buy or a sell in step S721. The customer then
  • step S730 needed in step S730, and inputs the correction in step S735.
  • FIG. 8(a) shows a flow chart of a process whereby a margin is
  • the central controller 400 checks a net position from the contracts
  • step S810 and multiplies a current initial margin rate noted by the London
  • the central controller 400 adds a
  • variation margin to the initial margin in step S820 adds the credit lines extended by the brokers in step S830, adds the customer's account balance
  • step S840 calculates the customer's margins
  • step S860 The central controller 400 moves to another broker
  • step S870 steps until the margins required by the broker are checked in step S870.
  • FIG. 8(b) shows a flow chart of a process whereby a central
  • controller provides a customer with information on whether the customer has
  • the central controller 400 checks the margins of all the customers
  • the central controller 400 multiplies a current initial margin rate noted
  • the central controller 400 adds a variation
  • the central controller 400 calculates the customer's margins with
  • step S885 moves to another broker so as to check the margins required by the broker, and repeats the above steps with respect
  • the central controller 400 provides the customer with information on
  • FIG. 9 shows a flow chart of a process of conducting an examination
  • the central controller 400 checks whether a sufficient
  • the central controller 400 extracts contract products
  • step S920 This process for checking the
  • margin requirements is repeated for all the brokers in step 930.
  • step 921 the broker's
  • the central controller 400 provides specific RFQ numbers to the
  • customer's RFQ in step 924 enters a time stamp in step 925, and transmits
  • FIG. 10 shows a flow chart of a process whereby the broker provides
  • the broker provides the quotation 110 upon receiving the RFQ 100
  • the broker receives the RFQ 100 in step S1000, provides
  • step S1010 the quotation 110 in step S1010, and then transmits the quotation to the
  • the central controller 400 transmits the quotations 110 in order of
  • FIG. 11 shows a flow chart of a process of an execution of the
  • the customer selects the best quotation and performs a transaction
  • the customer selects the best one from the quotations 110
  • controller 400 transmits an acceptance of the quotation provided by the
  • step S1120 inputs a contract number in step S1130, inputs
  • step S1131 transmits the data to the central
  • the central controller 400 receives the data from the broker in step
  • the central controller 400 transmits the broker's
  • FIG. 12 shows a flow chart of a process of an offset of the positions
  • the central controller 400 checks, whenever the customer makes a
  • the central controller 400 transmits an offsetting requirement
  • FIG. 12 shows a flow chart of a process for offsetting the positions
  • the central controller 400 checks the customers' positions according to the preferred embodiment of the present invention.
  • the central controller 400 checks the customers' positions according to the preferred embodiment of the present invention.
  • the central controller 400 transmits an
  • step S1220 Upon receiving data in step S1220, the customer selects an
  • step S1232 a password in step S1232 and transmits corresponding data to the central
  • the central controller 400 receives the data from the customer in
  • step S1240 inputs the order number in step S1242, inputs the time stamp in
  • step S1244 and transmits the offsetting order 300 to both brokers concerned,
  • step S1246
  • the brokers receive the offsetting order 300 from the central
  • controller 400 in step S1250.
  • the brokers check the customer's position in
  • step S1252 and transmit a transaction confirmation to the central controller
  • the broker designated by the customer also receives the
  • offsetting order 300 in step S1260 checks the customer's position in step S1260
  • the central controller 400 receives the transaction confirmation in step S1264.
  • the central controller 400 receives the transaction confirmation in step S1264.
  • step S1270 and transmits the same to the customer in step S1272.
  • FIG. 13 shows a flow chart of a process for giving up the positions
  • the first broker gives up the customer's positions to the second
  • step S1300 The broker gives up position to the other broker in step S1310,
  • the designated broker agrees to the position offset in step S1301 .
  • the central controller 400 receives the data from both brokers in step
  • FIG. 14 shows a flow chart of a process of a prearrangement of
  • the broker checks and reviews the terms and conditions of
  • step S1410 conditions in step S1410, and signs the agreement in step S1420.
  • the central controller 400 receives the agreement of the broker in
  • step S1440 and transmits the same to the customer in step 1441 , and
  • the futures exchange can be executed more efficiently.
  • the customer is not required to pay an additional margin.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Disclosed is a futures transaction intermediating apparatus, in an apparatus for intermediating futures transactions between customers and brokers in futures exchanges, which comprises a central controller receiving a request for a quotation (RFQ) from the customer, checking the customer's margin, and transmitting the RFQ to a plurality of brokers in order for the brokers to use the RFQ; a broker interface communicating with the brokers coupled to the central controller; and a customer interface communicating with the customers coupled to the central controller. The central controller comprises a CPU; a position management processor; an account management processor; a margin requirement processor; an auction control processor; an RFQ generation processor; a transaction tracking processor; a transaction confirmation processor; an offsetting requirement processor; a synchronizing processor; a cryptographic processor; a network interface; and a data storage device.32

Description

Method and Apparatus for Intermediating Transactions between Customers and Brokers in Futures Exchange
BACKGROUND OF THE INVENTION
(a) Field of the Invention
The present invention relates to a method and apparatus for
intermediating transactions between customers and brokers in a futures
exchange using electronic contracts on the network. More specifically, the
present invention relates to a method and apparatus for customers'
concurrently communicating a binding inquiry to a plurality of brokers and
transferring positions of the brokers, and thereby, enhancing the transactions
between the customers and the brokers.
(b) Description of the Related Art
Since the London Metal Exchange (LME) was established in 1876, it
remains unique amongst the terminal markets in that, among other things,
transactions between brokers and customers (Client Contract) are on a
principal-to-principal base. In the Ring, transactions among members
(Exchange Contract) are made by an open outcry method like exchanges in
other parts of the world, giving equal opportunities to buyers and sellers.
Customers (producers, traders and end-users) have to contact one
or more members or brokers to get quotations for their needs for buying or
selling certain tonnages of base metals. Theoretically, a customer can
contact as many brokers as he wishes at the same time if he uses many telephone lines and then compare the quotations to get the best result.
Practically, the customer contacts brokers one by one while prices change
continuously. If he gets what he thinks is the best price, it may not be a result
of comparing multiple quotations at the same time, but rather it might result
from the fact that the price changed in his favor. Thus, it is difficult to say that
he can get a better result by contacting multiple brokers in series, because
the price moves against his favor as well as in his favor. On the other hand,
a customer's identity is known to brokers even before the transaction is
made, while the customer sometimes requires anonymity until the
transaction is concluded, and even after the transaction is made.
Due to the unique system of the LME, each customer's position is in
his account at the brokers, and there are many prompt dates for the
contracts. Both factors make it difficult for customers to open a position with
one broker and to close it with another. Those two opposite positions can be
offset by several methods, but not automatically. And giving up a position
from an account at one broker to another account at another broker is not
always guaranteed.
Therefore, an auction system for the Client Contracts of the LME can
be easily utilized if and when giving up positions is guaranteed by a
prearranged give-up process that makes offsetting opposite positions
smooth and easy. SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and
apparatus for a customer to concurrently request quotations from a plurality
of brokers.
It is another object of the present invention to provide a method and
apparatus for implementing processes of giving up and transferring positions
between brokers.
It is a further object of the present invention to provide a method and
apparatus for brokers to execute transactions without checking margin
requirements of unknown customers.
In one aspect of the present invention, in an apparatus for
intermediating futures transactions between customers and brokers in
futures exchanges, a futures transaction intermediating apparatus
comprises: a central controller receiving a request for a quotation (RFQ) from
the customer, checking the customer's margin, and transmitting the RFQ to
a plurality of brokers in order for the brokers to use the RFQ; a broker
interface communicating with the brokers coupled to the central controller;
and a customer interface communicating with the customers coupled to the
central controller.
In another aspect of the present invention, a futures transaction
intermediating method between customers and brokers comprises steps of:
(a) a central controller receiving a request for a quotation (RFQ) generated
by a customer; (b) the central controller checking the RFQ; (c) the central controller transmitting the RFQ to a plurality of brokers; (d) the central
controller receiving the quotations provided by the brokers without the
brokers' checking the customers' margins; and (e) the central controller
receiving an acceptance of the quotations from the customer and concluding
the transactions.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and
constitute a part of the specification, illustrate an embodiment of the
invention, and, together with the description, serve to explain the principles
of the invention:
FIG. 1 shows a block diagram of an apparatus for intermediating
futures transactions according to a preferred embodiment of the present
invention;
FIG. 2 shows a block diagram for requesting and processing
quotations between the customers and the brokers according to the
preferred embodiment of the present invention;
FIG. 3 shows a block diagram for an offset process according to the
preferred embodiment of the present invention;
FIG. 4 shows a detailed block diagram of a central controller
according to the preferred embodiment of the present invention;
FIG. 5 shows a detailed block diagram of a broker interface
according to the preferred embodiment of the present invention; FIG. 6 shows a detailed block diagram of a customer interface
according to the preferred embodiment of the present invention;
FIG. 7 shows a flow chart for a customer's generation of a request
for a quotation (RFQ) according to the preferred embodiment of the present
invention;
FIG. 8(a) shows a flow chart of a process whereby a margin is
confirmed before the quotation is requested according to the preferred
embodiment of the present invention;
FIG. 8(b) shows a flow chart of a process whereby a central
controller provides a customer with information on whether the customer has
the margin and the customer is requested to pay the margin according to the
preferred embodiment of the present invention;
FIG. 9 shows a flow chart of a process of conducting an examination
on the customer's RFQ according to the preferred embodiment of the
present invention;
FIG. 10 shows a flow chart of a process whereby the broker provides
the quotation to the customer according to the preferred embodiment of the
present invention;
FIG. 11 shows a flow chart of a process of an execution of the
transaction according to the preferred embodiment of the present invention;
FIG. 12 shows a flow chart of a process of an offset of the positions
according to the preferred embodiment of the present invention;
FIG. 13 shows a flow chart of a process of changing positions from a first broker to a second broker according to the preferred embodiment of the
present invention; and
FIG. 14 shows a flow chart of a process of a prearrangement of a
give-up agreement.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the following detailed description, only the preferred embodiment
of the invention has been shown and described, simply by way of illustration
of the best mode contemplated by the inventor(s) of carrying out the
invention. As will be realized, the invention is capable of modification in
various obvious respects, all without departing from the invention.
Accordingly, the drawings and description are to be regarded as illustrative in
nature, and not restrictive.
FIG. 1 shows a block diagram of an apparatus for intermediating
futures transactions according to a preferred embodiment of the present
invention.
As shown, the futures transactions intermediating apparatus
comprises a central controller 400, a plurality of broker interfaces 500 and a
customer interface 600. Nodes are respectively connected via Internet
connections using public switched phone networks, data lines, mobile
networks (cellular phones and PCSs) or satellite networks. The broker
interface 500 and the customer interface 600 are provided as input/output
gateways for communications with the central controller 400. By using the above-noted components, the central controller 400
receives RFQs from the customers, makes the RFQs available to a plurality
of the brokers and allows binding transactions between the customers and
the brokers.
FIG. 2 shows a block diagram for requesting and processing
quotations between the customers and the brokers according to the
preferred embodiment of the present invention.
As shown, a customer logs in to the central controller 400 by using
the customer interface 600 to create an RFQ 100 and transmit the RFQ to
the central controller 400. The central controller 400 checks the RFQ 100
provided by the customer and transmits the same to the brokers. After
receiving the RFQ 100, the brokers transmit the quotation to the central
controller 400. The central controller 300 then transmits the quotation 110 to
the customer.
FIG. 3 shows a block diagram for an offset process according to the
preferred embodiment of the present invention.
As shown, when a customer generates an offsetting order 300, the
central controller 400 transmits the offsetting order 300 to the brokers. The
brokers check the offsetting order 300 and transmit a message on the receipt
confirmation of the offsetting order 300 to the central controller 400. The
central controller 400 transmits the message to the customer. According to a
prearranged give-up agreement, the brokers give up the customer's position
to another broker in correspondence with the offsetting order provided by the customer.
FIG. 4 shows a detailed block diagram of a central controller
according to the preferred embodiment of the present invention.
As shown, the central controller comprises a central processing unit
(CPU) 405, a position management processor 407, an account management
processor 410, a margin requirement processor 415, an auction control
processor 420, an RFQ generation processor 425, a transaction tracking
processor 430, a transaction confirmation processor 435, an offsetting
requirement processor 437, a synchronizing processor 439, a cryptographic
processor 440, a network interface 445 and a data storage device 450.
The central controller 400 operates as a web server, both receiving
and transmitting the RFQs 100 generated by the customers. A conventional
computer workstation or server with sufficient memory and processing
capabilities can be used as the central controller 400. A microprocessor such
as 400MHz UltraSPARC-ll, manufactured by Sun Microsystems Inc., may be
used for the CPU 405.
The data storage device 450 stores the data used in processing the
transactions of the present invention.
Magnetic storage devices such as hard disk drives or optical storage
devices such as CD-ROM drives or flash memory can be used for the data
storage device 450. The data storage device 450 comprises a broker
database 455, a customer database 460, an account database 465, a margin checking factor database 467, a customer position management
database 470, an RFQ history database 475, a final confirmation history
database 480, an audit database 485, a certificate database 490 and a bill
information database 495. For example, database software such as Oracle 8,
manufactured by Oracle Corporation, can be used to create and manage the
above-mentioned databases.
The broker database 455 stores data on the brokers such as names,
contract information, type of members, transaction and give-up agreements
with the customers and public/private key information. The contact
information comprises authorized transactors, phone numbers of the
transactors, web page uniform resource locators (URLs), electronic mail
addresses, facsimile numbers, or any other possible methods arranged for
mutual communications between the customers and the brokers.
The customer database 460 stores data on the customers such as
customer names, addresses, authorized transactors, phone numbers of the
transactors, web page URLs, electronic mail addresses, facsimile numbers,
past system usage and public/private key information.
The account database 465 stores data on the customer's accounts
opened at the brokers such as credit lines extended, initial margin rates,
transaction limits and transaction key information.
The margin checking factor database 467 stores data on the factors
necessary to calculate margin requirements, such as credit lines, initial margin rates, variation margins, account balances and net positions.
The customer position management database 470, managing the
data on the customers' positions, stores contractual information such as
contracts, quantities, prompt dates, and prices.
The RFQ history database 475, managing data on the RFQs, stores
the tracking history of each RFQ 100 generated by the customer.
The audit database 485 stores transactional information relating to
the auction to be retrieved for a later analysis.
The certificate database 490 stores certificates of both the brokers
and customers for authentication and encryption, and it facilitates
cryptographic functions, storing both symmetric and asymmetric keys. By
using these keys, the cryptographic processor 440 encrypts and decrypts the
data transmitted on the Internet.
The bill information database 495 stores contents of the bills of
additional margins. Here, the brokers require the above-noted bills in order
for the customers to pay additional margins in the case the positions of the
customers have margin calls.
The network interface 445 is the gateway to communicate with the
customers and the brokers through the broker Interface 500 and the
customer interface 600. Conventional built-in or external modems or local
area network (LAN) cards can be used for the network interface 445.
FIGs. 5 and 6 show the broker interface 500 and the customer interface 600, respectively. These interfaces are connected with the central
controller 400.
FIG. 5 shows a detailed block diagram of a broker interface
according to the preferred embodiment of the present invention.
As shown, the broker interface 500 comprises a central processing
unit (CPU) 505, an RFQ receiving processor 510, a synchronizing processor
520, a video driver 530, a video monitor 540 and a data storage device 550.
The synchronizing processor 520 tracks events of the customers'
accounts and synchronizes the events with the customers' accounts at the
central controller 400.
The data storage device 550 comprises a messaging database 570
and an audit database 580. A conventional magnetic-based hard disk
storage unit such as those manufactured by Conner Peripherals can be used
as the data storage device 550.
The messaging database 570, managing the messages of the
customers and the brokers, can be used for archiving brokers' responses as
well as customers' and/or brokers' special transaction conditions.
The audit database 580 stores payment records and accesses
history to the central controller 400.
FIG. 6 shows a detailed block diagram of a customer interface
according to the preferred embodiment of the present invention.
As shown, the customer interface 600 comprises a central processor unit (CPU) 605, a transaction confirmation receiving processor 620, a video
driver 630, a video monitor 640 and a data storage device 650. All of these
components are identical to those described in FIG. 5, except for the
transaction confirmation receiving processor 620. The trade confirmation
receiving processor 620 receives a final confirmation from the central
controller 400 and performs a cross check on the final confirmation with the
RFQ 100.
The configuration components of the system according to the
preferred embodiment of the present invention can be implemented on a
single computer, and further, it can be implemented as additional software
installed on a single computer or as a single software program having a
plurality of different functions.
There are many software applications that enable the
communications required by the broker interface 500 and the customer
interface 600, the primary functionality being message creation and
transmission. When the central controller 400 is configured as a web server,
conventional communications software such as the Netscape web browser
from Netscape Corporation may be used. The customers can use the
Netscape Navigator browser to transmit the RFQ 100. No proprietary
software is required.
Transactions between a customer and brokers at the London Metal
Exchange will now be described as a preferred embodiment of the present invention.
The customer logs in to the central controller 400, creates an RFQ
100, and waits for the brokers' quotations 110. The central controller 400
checks the margin checking factor database 467 so as to check the margin
required by the brokers, and transmits the RFQ 100 to the brokers whose
customers have sufficient margins satisfying the requirements of the brokers.
The brokers' quotations 110 are electronically transmitted to the central
controller 400, which transmits the quotations 110 to the customers for the
customer's decision.
FIG. 7 shows a flow chart for a customer's generation of a RFQ
according to the preferred embodiment of the present invention.
The customer logs in to the central controller 400 using the customer
interface 600 in step S700. The central controller 400 has a page on the
World Wide Web, allowing the customer to provide information through the
interface of the conventional web browser software such as MS Explorer,
manufactured by Microsoft. Inc.
The customer selects a contract product from the contract list of the
LME and LBMA in step S710. As shown in step S711 , the contract products
include Cu (Copper Grade 'A'), Al (Aluminum Primary High Grade), AA
(Aluminum Alloy), ZS (Zinc Special High Grade), Pb (Standard Lead), Sn
(Tin), Ni (Primary Nickel) and Ag (Silver) from the London Metal Exchange
and Au (Gold) and Ag (Silver) from the London Bullion Market Association (LBMA).
Then the customer selects a desired type of order, such as auction-
futures, auction-option, offsetting position, etc. in step S720. After the order
type is selected, an order sheet is displayed on the video monitor 640 of the
customer interface 600. This sheet is an electronic contract with terms and
conditions to be selected or filled in by the customer who generated the RFQ
100. The customer selects a buy or a sell in step S721. The customer then
inputs a desired quantity, a prompt date and currency in respective steps
S722, S723 and S724. The customer determines whether a correction is
needed in step S730, and inputs the correction in step S735. The customer
provides his. password to the RFQ 100 in step S740, transmits the input
items to the central controller 400 in step S745, and the central controller
400 receives the RFQ 100 from the customer in step S750.
FIG. 8(a) shows a flow chart of a process whereby a margin is
confirmed before the quotation is requested according to the preferred
embodiment of the present invention.
The central controller 400 checks a net position from the contracts
executed by the brokers in step S800. The central controller 400 then inputs
the quantity of the RFQ 100 to the customer's net position by the brokers in
step S810, and multiplies a current initial margin rate noted by the London
Metal Exchange and the London Clearing House in order to obtain a full
amount of the initial margin in step S811. The central controller 400 adds a
variation margin to the initial margin in step S820, adds the credit lines extended by the brokers in step S830, adds the customer's account balance
to the above-added items in step S840, calculates the customer's margins
with respect to the brokers in step S850, and determines whether the margin
is sufficient in step S860. The central controller 400 moves to another broker
so as to check the margins required by that broker, and repeats the above
steps until the margins required by the broker are checked in step S870.
FIG. 8(b) shows a flow chart of a process whereby a central
controller provides a customer with information on whether the customer has
the margin, and in which the customer is requested to pay the margin,
according to the preferred embodiment of the present invention.
The central controller 400 checks the margins of all the customers
every day after the market is closed, and provides the customer with
information on whether the customer presently has the margin, and he is
requested to pay the margin.
In detail, every day after the market is closed, the central controller
400 checks a net position from the contracts executed by the brokers in step
S880. The central controller 400 multiplies a current initial margin rate noted
by the London Metal Exchange and the London Clearing House in order to
calculate the margin in step S881. The central controller 400 adds a variation
margin to the initial margin in step S882, and adds the credit lines extended
by the brokers in step S884.
The central controller 400 calculates the customer's margins with
respect to the brokers in step S885, moves to another broker so as to check the margins required by the broker, and repeats the above steps with respect
to all the brokers in step S890.
The central controller 400 provides the customer with information on
whether the customer presently has the margin, and he is requested to pay
the margin in step S895.
FIG. 9 shows a flow chart of a process of conducting an examination
on the customer's RFQ 100 according to the preferred embodiment of the
present invention.
In this process, the central controller 400 checks whether a sufficient
margin to cover the transactions is provided before the brokers use the RFQ
100.
In detail, the central controller 400 extracts contract products and
quantities from the RFQ 100 in step S900, checks the customer's net
position of the contract by broker in step S910, inputs the quantity of the
RFQ 100 to the net position of the contract so as to calculate the addition
and reduction of the initial margin in step 911 , and checks whether a
sufficient margin is provided in step S920. This process for checking the
margin requirements is repeated for all the brokers in step 930.
If the provided margin is not sufficient, the broker's window is
blocked in step 921 , but if a sufficient margin is provided, the broker's
window is then opened in step 922. At the same time, the broker's window is
displayed on the customer's video monitor 640 so as to receive the broker's
quotation 110 in step 923. The central controller 400 provides specific RFQ numbers to the
customer's RFQ in step 924, enters a time stamp in step 925, and transmits
the RFQ 100 to the brokers in step 926.
FIG. 10 shows a flow chart of a process whereby the broker provides
the quotation to the customer according to the preferred embodiment of the
present invention.
The broker provides the quotation 110 upon receiving the RFQ 100
to the customers so as to compete against other brokers.
In detail, the broker receives the RFQ 100 in step S1000, provides
the quotation 110 in step S1010, and then transmits the quotation to the
central controller 400 in step S1011.
The central controller 400 transmits the quotations 110 in order of
receipt in step S1020, and displays the quotations 110 of the brokers on the
corresponding cell of the customer's monitor 640 in step S1030.
FIG. 11 shows a flow chart of a process of an execution of the
transaction according to the preferred embodiment of the present invention.
The customer selects the best quotation and performs a transaction
with the broker who provides the desired quotation.
In detail, the customer selects the best one from the quotations 110
displayed on the customer's monitor 640 in step S1100. The central
controller 400 transmits an acceptance of the quotation provided by the
customer to the broker in step S1110, and provides the customer's identity
only to the broker selected by the customer in step S1111. Upon receiving the acceptance of the quotation from the customer, the broker confirms the
transaction in step S1120, inputs a contract number in step S1130, inputs
necessary corrections in step S1131 , and transmits the data to the central
controller 400 in step S1132.
The central controller 400 receives the data from the broker in step
51140, and then deletes the RFQ 100 from other brokers' windows in step
51141. At the same time, the central controller 400 transmits the broker's
confirmation on the transaction to the customer in step S1142, inputs the
transaction history to an executed order page in step S1143, and stores the
transaction data in the customer position management database in step
S1144. The customer then receives the transaction data and thus the
transaction is concluded in step S1150.
FIG. 12 shows a flow chart of a process of an offset of the positions
according to the preferred embodiment of the present invention.
The central controller 400 checks, whenever the customer makes a
new transaction, the customer's positions in the customer's accounts
possessed by the other brokers in order to check whether an opposite
position of the identical contract and identical prompt date is provided. When
there is an opposite position in the customer's account possessed by the
other brokers, the central controller 400 transmits an offsetting requirement
to the customer in order for the customer to offset the positions.
FIG. 12 shows a flow chart of a process for offsetting the positions
according to the preferred embodiment of the present invention. The central controller 400 checks the customers' positions according
to the prompt dates with respect to the respective brokers in step S1200.
When an opposite position is found, the central controller 400 transmits an
offsetting position requirement to the corresponding customer in step S1210.
Upon receiving data in step S1220, the customer selects an
offsetting position order to select the position to be offset in step S1230. The
customer fills in the order form displayed on the customer monitor 640 in
order to generate an offset order in step S1231. The customer then provides
a password in step S1232 and transmits corresponding data to the central
controller 400 in step S1233.
The central controller 400 receives the data from the customer in
step S1240, inputs the order number in step S1242, inputs the time stamp in
step S1244, and transmits the offsetting order 300 to both brokers concerned,
one broker holding a long position and the other holding a short position in
step S1246.
The brokers receive the offsetting order 300 from the central
controller 400 in step S1250. The brokers check the customer's position in
step S1252, and transmit a transaction confirmation to the central controller
400 in step S1254. The broker designated by the customer also receives the
offsetting order 300 in step S1260, checks the customer's position in step
S1262, and transmits the transaction confirmation to the central controller
400 in step S1264. The central controller 400 receives the transaction confirmation in
step S1270, and transmits the same to the customer in step S1272. The
customer receives the confirmation in step S1280.
FIG. 13 shows a flow chart of a process for giving up the positions
from a first broker to a second broker according to the preferred embodiment
of the present invention.
The first broker gives up the customer's positions to the second
brokers following the customer's offsetting order 300 in accordance with a
prearranged give-up process.
In detail, a broker holding a customer's position contacts the other
broker, designated by the customer, who is holding the opposite position in
step S1300. The broker gives up position to the other broker in step S1310,
and transmits a completion of the give-up process to the central controller
400 in step S1320.
The designated broker agrees to the position offset in step S1301 ,
and receives the position offset by the other broker in step S1311 , and
transmits the completion of the give-up process to the central controller 400
in step S1321.
The central controller 400 receives the data from both brokers in step
S1330, stores the offsetting history to the customer database 460 in step
S1331 , and transmits the data to the customer in step 1332. The customer
receives the data in step S1340. FIG. 14 shows a flow chart of a process of a prearrangement of
giving up agreement.
The prearranged give-up process is guaranteed by the give-up
agreement duly signed by and between brokers and customers.
In detail, the broker checks and reviews the terms and conditions of
the give-up agreement in step S1400. The broker agrees with the terms and
conditions in step S1410, and signs the agreement in step S1420. The
broker then transmits the agreement to the central controller 400 in step
S1430.
The central controller 400 receives the agreement of the broker in
step S1440, and transmits the same to the customer in step 1441 , and
stores the same to the broker database in step S1442. The customer
receives the agreement of the broker in step S1450.
According to the present invention, the customer concurrently
generates the requests for quotations to a plurality of the brokers so that the
customer can perform the most profitable transaction, and the brokers can
do business with the customer without confirming the customer's margins
one by one. Since the brokers can offset the customers' opposite positions
possessed by the brokers according to the prearranged position offset and
transfer process, the transactions between the customers and the brokers in
the futures exchange can be executed more efficiently.
Since the customer does not need to divulge his identity to the brokers when requesting the quotations from the brokers, in the case the
transactions are not completed, the identity of the customer is not known by
the brokers.
Since the customer can offset the positions according to the
prearranged offset, the customer is not required to pay an additional margin.
While this invention has been described in connection with what is
presently considered to be the most practical and preferred embodiment, it is
to be understood that the invention is not limited to the disclosed
embodiments, but, on the contrary, is intended to cover various modifications
and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

WHAT IS CLAIMED IS:
1. In an apparatus for intermediating futures transactions between
customers and brokers in futures exchanges, a futures transaction
intermediating apparatus, comprising:
a central controller receiving a request for a quotation (RFQ) from
a customer, checking the customer's margin, and transmitting the RFQ to a
plurality of brokers in order for the brokers to use the RFQ;
a broker interface communicating with the brokers coupled to the
central controller; and
a customer interface communicating with the customers coupled to
the central controller.
2. The apparatus of claim 1 , wherein the central controller comprises:
a central processor unit (CPU);
a position management processor, coupled to the CPU, managing
the customers' positions;
an account management processor managing the customers'
accounts;
a margin requirement processor managing the customers' margins;
an auction control processor controlling auction processes of the
futures transactions;
an RFQ generation processor processing the RFQs generated by
the customers;
a transaction tracking processor tracking the transaction history executed between the customers and the brokers;
a transaction confirmation processor confirming the transactions
between the customers and the brokers;
an offsetting requirement processor processing the offsetting;
a synchronizing processor tracking events of the customers'
accounts and synchronizing the events with the customers' accounts;
a cryptographic processor processing passwords necessary for the
transactions;
a network interface communicating between the central controller,
the customers and the brokers; and
a data storage device storing data used in the futures transactions.
3. The apparatus of claim 2, wherein the data storage device
comprises:
a broker database storing data on the brokers;
a customer database storing data on the customers;
an account database storing data on the customers' accounts;
a margin checking factor database storing data on the factors
necessary for calculating the margins;
a customer position management database storing data on the
customers' positions;
an RFQ history database storing data on the customers' RFQs;
a final confirmation history database storing data on the final
confirmation history; an audit database storing data on the transactions related to the
auctions;
a certificate database storing data on the certificates used for
authentication and encoding; and
a bill information database storing data on the bills of additional
margins.
4. The apparatus of claim 1 , wherein the broker interface comprises:
a CPU;
an RFQ receiving processor receiving the RFQs from the customers;
a synchronizing processor;
a video driver;
a video monitor; and
a data storage device storing the data used for the futures
transactions.
5. The apparatus of claim 4, wherein the data storage device
comprises:
a messaging database storing the messages of the customers and
the brokers; and
an audit database storing payment history.
6. The apparatus of claim 1 , wherein the customer interface
comprises:
a CPU;
a transaction confirmation receiving processor receiving the brokers' transaction confirmations;
a video driver;
a video monitor; and
a data storage device storing the data necessary for the futures
transactions.
7. The apparatus of claim 6, wherein the data storage device
comprises:
a messaging database storing the messages of the customers and
the brokers; and
an audit database storing payment history.
8. A futures transaction intermediating method between customers
and brokers, comprising steps of:
(a) a central controller receiving a request for a quotation (RFQ)
generated by a customer;
(b) the central controller checking the RFQ;
(c) the central controller transmitting the RFQ to a plurality of the
brokers;
(d) the central controller receiving the quotations provided by the
brokers without the brokers checking the customers' margins; and
(e) the central controller receiving an acceptance of the quotations
from the customer and concluding the transactions.
9. The method of claim 8, wherein the customer's generating of the
quotation in step (a) comprises steps of: the central controller receiving a contract and an order selected by
the customer;
the central controller receiving a sell or buy order selected by the
customer; and
the central controller receiving quantities, prompt dates, currency,
request correcting points, and a customer's password from the customer.
10. The method of claim 8, wherein the step (b) comprises steps of:
(f) the central controller extracting contract products and prompt
dates from the RFQ;
(g) the central controller checking available margin;
(h) the central controller opening the broker's window when the
provided margin is sufficient, and blocking the window when the provided
margin is not sufficient;
(i) the central controller repeating the above-noted steps for all the
brokers; and
(j) the central controller providing specific RFQ numbers to the
RFQs;
the central controller entering a time stamp, and transmitting the
RFQ to the brokers.
1 1. The method of claim 10, wherein the step (g) comprises steps of:
the central controller checking the customer's net position;
the central controller inputting the quantity of the customer's RFQ;
the central controller multiplying a current initial margin so as to obtain the full amount of the initial margin;
the central controller adding a variation margin to the initial margin;
the central controller inputting the customer's credit lines;
the central controller inputting the customer's account balance;
the central controller calculating the customer's margins;
the central controller checking whether the margin is sufficient; and
the central controller repeating the above-noted steps for all the
brokers.
12. The method of claim 8, wherein the providing of the quotations
by the broker in the step (d) comprises steps of:
the central controller receiving the quotations provided by the broker
without the broker checking the margin;
the central controller transmitting the quotation to the customer; and
the central controller displaying the quotation on the customer's
monitor.
13. The method of claim 8, wherein the step of concluding the
transaction in the step (e) comprises steps of:
the central controller receiving the quotation accepted by the
customer;
the central controller transmitting the customer's acceptance of the
quotation to the broker;
the central controller inputting the customer's identity only to the
broker with whom the transaction is executed and not to the brokers with whom the transaction is not executed;
the central controller receiving a transaction confirmation, a contract
number and corrections from the broker;
the central controller deleting the RFQ from the windows of the
brokers with whom the transaction is not executed; and
the central controller transmitting the data, entering the transaction
on a order sheet, and storing transaction data in the customer position
management database.
14. A method for providing information on a current margin,
comprising steps of:
a central controller checking customers' net positions after a market
is closed;
the central controller multiplying a current rate of an initial margin so
as to obtain a full amount of the initial margin;
the central controller adding a variation margin to the initial margin;
the central controller inputting customers' credit lines;
the central controller inputting the customers' account balances;
the central controller calculating the customers' margins;
repeating the above-noted steps for all the brokers; and
the central controller transmitting the checked customers' margin
history to the customers.
15. A method for providing information on a request for paying a
margin, comprising steps of: a central controller checking customers' net positions after a market
is closed;
the central controller multiplying a current rate of an initial margin so
as to obtain a full amount of the initial margin;
the central controller adding a variation margin to the initial margin;
the central controller inputting customers' credit lines;
the central controller inputting the customers' account balances;
the central controller calculating the customers' margins;
repeating the above-noted steps for all the brokers;
the central controller determining whether or not the customer is
requested to pay the margin; and
the central controller transmitting the request for paying the margin to
the corresponding customer when the customer is requested to pay the
margin.
16. An offset order method, comprising steps of:
(a) a central controller checking customers' positions according to
prompt dates for respective brokers when a customer performs a new
transaction;
(b) the central controller transmitting an offset order request to the
customer when an opposite position is provided;
(c) the central controller receiving the offset order from the customer;
(d) the central controller transmitting the customer's offset order to
the brokers; (e) the central controller receiving a confirmation on the customer's
offset order from the brokers; and
(f) the brokers giving up the position to other brokers through the
central controller.
17. The method of claim 16, wherein the step of a customer's offset
order in the step (c) comprises steps of:
the central controller receiving a selection of the offset order from the
customer; and
the central controller receiving a password from the customer.
18. The method of claim 16, wherein the step (d) comprises steps of:
the central controller receiving data from the customer;
the central controller entering an order number and a time stamp;
and
transmitting the offset order to both related brokers.
19. The method of claim 16, wherein the broker's confirming the
offset order in step (e) comprises steps of:
the central controller transmitting the customer's offset order to the
broker; and
the central controller receiving a receipt confirmation of the offset
order from the broker.
20. The method of claim 16, wherein the giving up of the position in
the step (f) comprises steps of:
(g) the central controller contacting the broker possessing the customer's position with other brokers possessing opposite positions;
(h) the central controller receiving the position given up from the
broker to another broker according to a prearranged agreement; and
(i) the central controller storing the offset order and transmitting the
data to the customer.
21. The method of claim 20, wherein the step (h) comprises steps of:
the central controller receiving conditions of giving-up agreement and
a signature from the broker; and
the central controller transmitting the conditions and the signature to
the customer and storing the same in a broker database.
PCT/KR2000/001061 2000-07-25 2000-09-22 Method and apparatus for intermediating transactions between customers and brokers in futures exchange WO2002007498A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB0301357A GB2380582A (en) 2000-07-25 2000-09-22 Method and apparatus for intermediating transactions between customers and brokers in futures exchange
AU2000274567A AU2000274567A1 (en) 2000-07-25 2000-09-22 Method and apparatus for intermediating transactions between customers and brokers in futures exchange

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020000042820A KR20020009251A (en) 2000-07-25 2000-07-25 Method and apparatus to intermediate between customers and brokers in futures exchange
KR2000-42820 2000-07-25

Publications (2)

Publication Number Publication Date
WO2002007498A2 true WO2002007498A2 (en) 2002-01-31
WO2002007498A3 WO2002007498A3 (en) 2003-04-24

Family

ID=19679872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2000/001061 WO2002007498A2 (en) 2000-07-25 2000-09-22 Method and apparatus for intermediating transactions between customers and brokers in futures exchange

Country Status (4)

Country Link
KR (1) KR20020009251A (en)
AU (1) AU2000274567A1 (en)
GB (1) GB2380582A (en)
WO (1) WO2002007498A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EA010700B1 (en) * 2006-11-21 2008-10-30 Сергей Владимирович МИГАЛЕВ Remote communication terminal for stock market game system
US8001036B2 (en) 2006-05-30 2011-08-16 Altex-Ats Ltd System for matching orders for futures contracts which facilitate electronic trading of over the counter futures contracts
CN108009898A (en) * 2017-12-25 2018-05-08 宋新建 Services processing method, apparatus and system

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100782069B1 (en) * 2007-04-05 2007-12-04 (주)한국증권선물거래소 System for controlling a futures/option trading process based on the online network
KR100762061B1 (en) * 2007-05-15 2007-10-01 (주)한국증권선물거래소 The system for checking a entrustment possibility of a new futures/option order based on the online network
US9715621B2 (en) 2014-12-22 2017-07-25 Mcafee, Inc. Systems and methods for real-time user verification in online education

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997033215A2 (en) * 1996-02-22 1997-09-12 Joseph Giovannoli Computerized quotation system and method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997033215A2 (en) * 1996-02-22 1997-09-12 Joseph Giovannoli Computerized quotation system and method
US5842178A (en) * 1996-02-22 1998-11-24 Giovannoli; Joseph Computerized quotation system and method

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8001036B2 (en) 2006-05-30 2011-08-16 Altex-Ats Ltd System for matching orders for futures contracts which facilitate electronic trading of over the counter futures contracts
US8548897B2 (en) 2006-05-30 2013-10-01 Icap Services North America Llc System for matching orders for futures contracts which facilitate electronic trading of over the counter futures contracts
EA010700B1 (en) * 2006-11-21 2008-10-30 Сергей Владимирович МИГАЛЕВ Remote communication terminal for stock market game system
CN108009898A (en) * 2017-12-25 2018-05-08 宋新建 Services processing method, apparatus and system

Also Published As

Publication number Publication date
AU2000274567A8 (en) 2002-05-02
AU2000274567A1 (en) 2002-02-05
GB2380582A (en) 2003-04-09
WO2002007498A3 (en) 2003-04-24
GB0301357D0 (en) 2003-02-19
KR20020009251A (en) 2002-02-01

Similar Documents

Publication Publication Date Title
US7979343B2 (en) System, method and computer program product for providing an efficient trading market
CA2624097C (en) Ioi-based block trading systems and methods
US8074873B1 (en) Systems and methods to perform credit valuation adjustment analyses
CA2544785C (en) System and method for a hybrid clock and proxy auction
US20140304098A1 (en) System and Method for a Dynamic Auction with Package Bidding
US20020178087A1 (en) Internet-based instant messaging hybrid peer-to-peer distributed electronic commerce system and method
US20060095361A1 (en) Methods and apparatus for automatic settlement of foreign securities trades in trader's operating currency
JP2003536146A (en) System and method for reverse auction of financial instruments
US8538847B2 (en) Method for investing working capital
US20230044775A1 (en) Cost-adjusting order/quote engine
US7349881B1 (en) Computer borrow and loan securities auction system
KR20210146274A (en) Summing transaction system and method of cryptocurrency
US20100125526A1 (en) Three Party Services Transaction System
WO2002007498A2 (en) Method and apparatus for intermediating transactions between customers and brokers in futures exchange
KR20070105851A (en) Integrating the internet system of mediation of financial loans, purchase of goods and providing services
US20180082363A1 (en) Online auction platform for invoice purchasing
US10354331B2 (en) Receiving and processing transaction requests using a distributor portal
US20200364708A1 (en) Generating a portfolio of blockchain-encoded rived longevity-contingent instruments
Ravindran et al. Strategies for smart shopping in cyberspace
KR20020011603A (en) System for intermediating trade of foreign exchange
KR20050008008A (en) Method and System for Providing Peer to Peer Banking Service by Using Messenger
WO2020047106A9 (en) Blockchain-enabled electronic futures trading system with optional computerized delivery of cryptocurrency
US20240221085A1 (en) Processing a contingent action token securely
US20160321746A1 (en) Trading system and method with user-defined installments
US20240223374A1 (en) Processing a contingent action token securely

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

ENP Entry into the national phase

Ref country code: GB

Ref document number: 0301357

Kind code of ref document: A

Free format text: PCT FILING DATE = 20000922

Format of ref document f/p: F

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
ENP Entry into the national phase

Ref document number: 2003130071

Country of ref document: RU

Kind code of ref document: A

Format of ref document f/p: F

NENP Non-entry into the national phase

Ref country code: JP