JP2001052081A - Financial transaction system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically perform mutual transactions by an automatic financial transaction system. SOLUTION: A financial transaction system 20 meets requests from clients (users) 10. A market price presenting processor 21 processes the requests of the clients and automatically generates market prices with respect to requests having parameters within a prescribed range. The market price presenting processor 21 automatically transfers requests which are received by this system but are not set so that the system itself should process them (for example, those which have parameters within an extended range outside the prescribed parameter range) to another financial transaction system (mother organization) 11 or 12. Requests having parameters outside the extended range are rejected or transferred to a dealer intervened unit and are processed by an operator.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001] The present invention relates to an automatic financial transaction system, and more particularly to an apparatus and a method for enabling automatic mutual transaction by an automatic financial transaction system.

2. Description of the Related Art A substantive organization that performs direct sales operations or has several functions, including direct sales, needs to buy or sell foreign currency, buy or sell stock, buy books or compact discs, buy or sell goods, or require a rate or price. Have a client who needs financial transaction services, such as buying and selling of all general items. Organizations that provide these services on a large scale may have automated systems in place to capture financial transactions, but require human operator services to handle requests outside the scope that automated systems are set to handle. It is thought that it also provides. Automated systems generally consist of a user interface where clients make requests for specific prices.
The system also includes some type of processor that the customer uses when communicating by digital system rather than by voice, and that automatically returns a rate or price to the client. Many confirmations are made automatically by the system when a client requests a price or rate. These may involve a credit limit check and a check on the request itself, for example, a check on the requested currency, a check on the specific goods requested. The system then automatically calculates the price or rate using the base price plus the client-specific margin and sends it back to the client. Upon receiving this price or rate, the client may accept or reject this price or rate. Operator services are required, for example, for transactions involving amounts that exceed the customer's normal credit limit or the organization's transaction limit, or for requests involving transactions of rare currencies or commodities. These requests, such as those relating to currencies not handled by the organization, involve the operator in seeking services from further organizations.

SUMMARY OF THE INVENTION The general object of the present invention is to improve upon known systems.

According to the present invention, there is provided a quote presenting processor for a supplier trading system, the quote presenting processor comprising: means for receiving a request from a client / user; Means to automatically respond to requests in
Means for converting requests outside the above range but within the extended range into requests to be forwarded to further financial transaction systems, and means for sending requests outside the extended range to operator intervention and / or automatic rejection means. Prepare. Basically, the system provides three ways to process the request. The first method is to automatically process requests with parameters within a predetermined range by the quote presentation processor itself. These requests can be referred to as "medium" requests, where the bank is willing to receive from the client, and the bank has the technical ability to process the request itself, and the bank is satisfied with the processing It is. The parameters used include:
It typically includes credit limits and other data, mainly about clients, as well as other data about currencies and mainly banks themselves. A second method is to automatically send requests whose parameters are outside the above range but within the extended range to further banks. These requests are
Usually something the bank is willing to accept, but the bank is not willing to take the risks associated with this transaction, such as requests involving currencies that the bank usually does not handle. In addition to the risk underwriting problem, a bank may not be able to handle certain transactions technically and may have to transfer the transactions to further banks.
The third way is to send out-of-scope requests,
To the intervention of an operator or dealer. These requests are usually what the bank thinks the operator should consider rather than automatically receive from the client. The operator may decide to reject this request. If it decides to handle this request, it will be automatically processed, either by the bank or sent to a further bank. Alternatively, certain requests may be automatically rejected immediately. For example,
In a highly automated system without operator assistance, if the parameter exceeds the rejection threshold (for example, the client simply attempts a transaction that is too large for the bank to handle, regardless of its credit status) All other requests may be automatically rejected, and the automatic rejection may be made for a particular request, even in systems with dealer intervention. The present invention also provides a banking transaction system with a quote submission processor and dealer intervention, as well as a multi-bank participating transaction system capable of transferring requests between one another. The present invention, in a preferred embodiment thereof, provides an organization that has an automated financial transaction system,
It improves upon known systems by implementing a method that can automatically offset the risks associated with financial transactions requested by clients. The present invention promotes liquid automatic brokerage and separates market and client credit risk. Apart from direct foreign exchange, other situations may arise where the supplier organization wants to offset the risks. For example, stock trading on the New York Stock Exchange involves buying and selling stock in US dollars. For overseas clients, this means holding a US dollar deposit account or paying in dollars for each transaction. Brokers can offer quotes in foreign currencies, but are then required to take market risk. In such a case, it is convenient for the broker to have an automated trading system that generates a foreign exchange request between the Japanese yen and the US dollar at the same time that the broker receives a request from the client in the Japanese yen. The use of the amount to broker the stock as usual. This puts the broker at the client's credit risk and the bank to which the foreign exchange request was sent carries the currency risk. In the context of the present invention, a client
/ The organization receiving the request from the user is "dota"
, And the organization to which the daughter forwards requests outside of the predetermined range but within the extended parameter range is called the "mother". The client making the initial request is Dota's client, who is not responsible for the customer's credibility, while Mother is at market risk. The mother does business with the daughter, not the customer, and the daughter does not give the mother the details of the customer. Mother also has its own customers making requests for prices and rates. In this way, daughters can provide broader and more efficient service to their customers for extended range requests. Without this system, the daughter would have to reject certain requests made to him or manually send the requests to another organization, such as by telephone.

DESCRIPTION OF THE PREFERRED EMBODIMENTS An automatic financial transaction system illustrating the present invention will be described in detail by way of example with reference to the drawings. FIG.
According to the organization 20 (daughter), multiple clients
/ Users 10, each of which may send a request for price and rate to organization 20, respectively. The organization 20 includes a quote / routing processor 21 and an intervention module 22. The quote / routing processor 21 automatically processes requests within a predetermined parameter range and forwards requests outside the aforementioned parameter range but within the extended parameter range to further organizations, The request is forwarded to the intervention unit 22 for direct handling by the dealer / operator. Further, the daughter 20 is connected to the mother 11. Market quote
The request received by the routing processor 21 and determined to be a request to be sent to the mother is automatically sent to the mother 11 by the quote presenting / routing processor (21). The organization has similar quote / routing processors and intervention units that, when receiving such requests, automatically process those requests or provide Forward. This system can be expanded in various ways, some of which are shown in FIG. First, the daughter 20 can be connected to the mother 11. In this configuration, the daughter quote / routing processor has automatic means of determining which request to forward to the mother. For example, a fixed transaction amount (eg, 200
All requests over $ 10,000) should be forwarded to the mother, or all requests for certain products,
It will be transferred to the mother. Second, daughter 20
The mother 11 and the mother 12 can be connected to a plurality of mothers. In this state, the quote / routing processor includes determining means for determining which mother to forward the request to. For example, a request for African currency trading may be forwarded to one mother, a request for Asian currency trading may be forwarded to the other mother, or a request for compact disc may be forwarded to one mother, and a request for DVD may be forwarded to one mother. Can be transferred to the other mother. Also according to FIG. 1, the mother 11 itself can be linked to a further grand mother or to a plurality of grand mothers 13 and 14 to which requests can be forwarded. For example, if Mother 11 receives a request for all African currencies, Mother 11 itself will process most of it, but will send requests for North African currencies to Grandmother 13 and some of the other currencies. It can be transferred to the grandmother 14. It can be seen from all these figures that the system can be extended by as many generations as is feasible. It should also be noted that each of this set of organizations can have a client associated with it, making requests for rates or prices. Also, the mother / daughter relationship may be different for each connection in the chain,
It depends on the composition of the daughter's tissue. For example, a daughter can be configured to forward all requests to the mother. Daughters can also be configured to forward certain requests to the mother. This can be done in a variety of ways. You can configure your daughter to forward all requests for a particular currency to one mother and another currency to another mother. For example, if the request involves a two-stage currency exchange transaction (eg, Spanish Pesetas / Japanese Yen), Dota will send a request for US Dollars / Spanish Pesetas to a certain mother and US Dollar / A request for Japanese yen can be made to another mother. The daughter quote / routing processor can then inter-calculate and provide the Spanish Peseta / Japanese Yen rate to the requesting client. Also, a daughter may provide part of a transaction by the daughter itself and obtain the other part of the transaction from the mother. As another example, if an organization receives a request for two automotive parts, one of the parts may be obtained from one supplier and the second part may be obtained from another supplier. The daughter sends two requests, one to each supplier. These suppliers return their own price for each such part, and the daughter then returns the total price to the client, with a margin on that price.
The organization can be configured so that a request arrives at one mother until a certain time of the day, and then the request is forwarded to another mother. These are just a few of the examples. There are various combinations and permutations to determine what requests go where and when. If a client of the organization 11 desires a price that the organization cannot readily offer, its quote / routing processor can generate a request for the organization 13. Therefore, regarding the transaction, the organization 11 becomes a daughter and the organization 13 becomes a mother. The daughter 20 can also receive a request from the mother 11. These tissues are compatible mother / daughter tissues. A tissue can be both a mother and a daughter. At each link in the series, it should be noted that if certain limits are breached or the request is not granted for any reason, the intervention module can be invoked. At that time, the dealer / operator
You can either reject the request or indicate an automatically transmitted price or rate.
FIG. 2 is a highly simplified process flow diagram for the operation of the intervention. The process begins with a client making a request for a rate or price (block 31). A request is received from a client / user and analyzed first (block 32) to determine if the request is within a predetermined set of parameters for the client and is a valid request. If not, it is forwarded to the daughter intervention unit (block 44). Next, the request is analyzed to determine if it is handled by the organization itself or if it needs to be forwarded to the mother organization (block 33). If the request is handled by the organization itself, the quote submission routing processor calculates the quote and sends the quote to the client (block 37). The client then determines whether he wants to accept the price (block 3).
8). If the client accepts, a confirmation is made to determine if the offer price is available from the mother (block 39). If not, the organization confirms the transaction by returning a confirmation number to the client (block 43). The process ends. When calling an intervention unit on a daughter (block 44),
The dealer / operator determines how to handle the request. The dealer / operator can reject the request, in which case it sends the rejection to the client (block 49) and the process ends. The dealer / operator may eventually determine that the request is acceptable, in which case processing is returned to block 37. If the client does not respond to the quote,
The system verifies that the quote was obtained from the mother (block 50). If not, the process ends immediately. If so, notify the mother that the request has been rejected before terminating the process (block 51). In another embodiment, the intervention unit comprises an automatic rejection means that can selectively divert some (or all) requests from the human dealer and issue a rejection for the client's request. This automatic rejection means may be used if the parameter exceeds a threshold value (for example, if the bank refuses to automatically handle an amount greater than a predetermined percentage of the bank's reserves) or if a meaningful transaction is May be started if it cannot be executed for the reason described above. Alternatively, the request may be activated when a human operator is busy due to an excessive request and cannot respond to the request within a predetermined time. If the request is forwarded to the mother (block 34), the mother performs a self-verification (other than in this case, the verification is performed by the daughter). The mother then automatically returns the price to the daughter (block 36) or moves the process to the mother's intervention module (block 46). If all tests pass at block 35, the mother calculates the price and sends it to the daughter (block 36). The process then begins at block 37, where the daughter calculates the price and sends it to the client. If the client accepts the price, another message is sent from the daughter to the mother (block 40). The mother confirms the transaction by sending a confirmation number to the daughter (block 4
1). A "back-to-back" transaction is made between daughter and mother (block 42). This effectively causes the daughter to revert the original transaction since it has not processed the position. The difference between these transactions manifests itself in the profits generated by daughters. The daughter confirms the transaction with the client by returning a confirmation number to the client (block 43). The process ends.
If the intervention module works on the mother (block 4
6) The mother determines how to handle the request (block 47). If this occurs, the mother goes through the same process as the daughter. The mother can reject the request, in which case the process proceeds to block 48, where a reject message is sent to the daughter, which results in the daughter sending a reject message to the client (block 49). . However, if the mother replies with the quote, processing transfers to block 36. Thereafter, the process continues as previously described. Of course, it will be appreciated that the process illustrated is fairly simplified and will typically involve many variations and sophistication. For example, in blocks 32 and 35 of the flow diagram shown, the process for determining whether the request is a valid request for the client is typically quite complex. For example, here the client's contract and transaction limits are confirmed. The requested price / product is confirmed. These are just a few examples. Also, in block 33, the criteria used to determine whether a request should be sent to the mother are typically very complex. In this block, the determination of the time of day, the currency involved, the currency requested, the amount of the transaction, etc. are used to determine whether the request should be sent to the mother organization. It is also used to determine to which mother the request should be sent. Again, these are merely examples, and any variation or permutation of the decision can be used. In this flow diagram, the mother operates in the same manner as the daughter as a whole, but in a more simplified manner. Thus, mother blocks 35, 36, 46, 47 and 48 correspond to daughter blocks 32, 33, 44, 45 and 49, respectively. FIG. 3 shows the configuration of the quote presenting / routing processor 21 in detail. The processors are controlled by a control unit 23, which arranges the processors according to the order of the process flow diagram of FIG. The buffer 24 receives a request sent from a client, and stores a client identifier (CLIENT ID), a product (PROD), and an amount (AMT). The client's credit limit is
Stored in a client table 25, which stores individual clients and their credit limits. The received product is stored in the product table 26
Is stored. The market price calculation unit 29 performs market price calculation. A flag register 28 can be used to indicate when a potential mother is available or unavailable. This register stores one flag for each possible mother. A flag is set when the mother is available, and cleared when the mother is unavailable. The flag may be manually operated, for example, when the mother is unavailable for any reason, cleared remotely, or, for example, when the daughter knows that the mother is available or unavailable. It can be operated automatically according to the time or the period. The processor 21 also comprises a comparator unit 23A, which handles how to handle requests from customers (whether client / user 10 or a daughter whose mother is the system shown). Use in making decisions. Buffer request 24
When receiving and storing at, the comparator 23A performs two series of comparisons. In a first series of comparisons, it is determined whether all parameters of the request are within a predetermined range. If all requests are within the predetermined range, the requests are forwarded to the quote calculation unit 29. If any parameter is outside the predetermined range, the comparator jumps to a second series of comparisons to determine if all parameters of the request are within the extended range. If all parameters are within the extended range, forward the request to the mother organization. If there is a parameter outside the extended range, the request is rejected or sent to an operator operation. The parameters identified in the first comparison can typically include client validation, client credit limits, organizational transaction size limits, the nature of the requested product (eg, unusual product or currency), and the like. . The parameters will be checked in the second comparison, such as the transaction size limit of the organization, the products that the organization can forward requests to the mother organization, etc.
Usually, it may include some (but different values) of the parameters in the first task. Some parameters (for example, parameters related to an organization's transaction size limit)
It is understood that the organization is not set by the client / user, but is set by the organization for all requests (or all requests within a particular category). FIG.
Thus, the quote / routing processor is shown in a fairly schematic and simplified form. The goods mentioned may be foreign currencies, books, CDs, equity, etc. These other details need to be remembered,
Sent between organizations for different types of transactions. For example, credit limits are not always stored by an organization. This may come from external sources, such as credit companies. The "amount" shown in this figure is
Not required. This is only necessary if the request is for a foreign exchange or money market transaction. In other cases, "goods" are usually fulfilled. Many tables or other such methods exist for determining what confirmation to perform for each request received. There may be many tables or other such methods for determining what request to forward and to whom to forward the request.

According to the communication between the client / user and the (daughter) organization and the communication between the daughter organization and the mother organization,
Any convenient communication media such as a digital PSTN line or the Internet can be used.

[Brief description of the drawings]

FIG. 1 is a block diagram of a system.

FIG. 2 is a process flow chart for the operation of the system.

FIG. 3 is a more detailed block diagram of the system.

[Explanation of symbols]

 10. Client (user) 11. Mother organization 12. Mother organization 13. Grandmother organization 14. Grand mother organization Grand mother organization 16. Grand mother organization 20. Daughter tissue 21. Quote presentation processor 22. Dealer intervention

Claims (11)

[Claims] 1. A financial transaction system, comprising: means for receiving a request from a client / user; means for automatically responding to a request whose parameters are within a predetermined range; A quote submission processor comprising: means for converting a request that is within to a request for forwarding to a further financial transaction system; and means for forwarding a request that is out of range to an operator intervention and / or automatic rejection means. 2. The quote presentation processor according to claim 1, comprising means for storing client details. 3. The client details include a credit limit,
3. The quote submission processor according to claim 2, wherein the quote presentation processor is selected from a trade limit, a contract limit, and a combination thereof. 4. The quote presentation processor according to claim 1, further comprising means for storing a list of products that the system is configured to handle. 5. The quote quotation processor according to claim 1, comprising means for storing, for each of the systems, a list of further financial trading systems, together with information defining the parameter ranges in which requests can be forwarded to the system. 6. The set of flags according to claim 4, comprising a set of flags, one for each said further financial transaction system, wherein said set of flags is set to indicate whether each financial transaction system is operating. Quote presentation processor. 7. A method for responding to a request from a client / user in a financial transaction system, the method comprising:
(A) receiving a request from the client / user; (b) responding to the request along with quotes if the request has parameters within a predetermined range; Forwarding the request to a further financial transaction system if it has parameters that are outside the range but within the extended range; and (d) the request comprises:
Forwarding the parameter to an operator intervention and / or rejecting it if it has parameters outside the extended range. 8. The method of claim 7, comprising comparing the size of the request with a client / user credit limit.
The method described in. 9. The method of claim 7, comprising comparing the requested product with a stored list of products configured to handle the system. 10. The step (c) comprising, for each of the further financial transaction systems, comparing a stored list of further financial transaction systems with the request, together with information defining a parameter range that can be transferred to each of the systems. The method of claim 7, comprising selecting the further financial transaction system by: 11. A method comprising maintaining a set of flags, one set for each said further financial transaction system, each set to indicate whether the financial transaction system is operating. Item 13. The quote presentation processor according to Item 10.