Patent Application
20060010064
1. Field of Invention
The present invention relates to a system and method for managing margin accounts. More specifically, the present invention relates to a system and method for real time margin account management.
2. Discussion of Related Art
Certain types of investments may be margined or serve as the basis for margin account collateral finds. Margin investment may be subject to various regulations or rules. The federal government may impose different regulations on each individual margin account. For instance, for a short sale using margins, the federal government may require a certain minimum percentage of equity to be held in the associated account. A long sale or an option transaction using margins may invoke different requirements. In addition, an investment institution where margin accounts are held may also impose some in-house rules that may further restrict the activities to be performed on margin accounts.
Margin related investment often presents relatively higher risk. Opportunities to success often rely on correct estimation of where the market is heading and at what time frame. Slight differences in price associated with a security being bought or sold at a certain time may play a crucial role in determining gains. In addition, computations of margins are often complex and adaptive with respect to changing market, regulations, and rules. Investment decisions regarding margin investment are often made based on a snap shot situation of a dynamic market.
In accordance with at least one embodiment of the invention, systems and methods are provided to manage client margin accounts. Specifically, methods and systems are provided to enable real time on-demand margin inquiry and computation of margin requirements based on a hypothetical scenario.
In some embodiment, a user may inquire, through a real time interface, margin account status using a specified security price. A user may be, for example, an investor, a financial agent representing a group of investors, or a corporate official. The specified price may be the current market price (or intraday price), the price from the end of the previous day, or an arbitrary price indicated by the requesting user. A market price for a security may be retrieved from an intraday database which may record current market prices of various securities on a regular basis. A market price may also be acquired through a real time connection to an appropriate source.
Each on-demand inquiry may specify various parameters that are used to generate a real time response to the inquiry. Such parameters may include, but are not limited to, a price used to compute the margin requirements for the accounts involved in the inquiry. An on-demand margin inquiry may be requested against a single account or, alternatively, simultaneously against a plurality of accounts. For example, an individual investor may inquire as to the current position of his/her margin account. A financial agent who represents a plurality of clients may inquire as to the current positions of all of his/her clients' accounts. A corporate officer may also send an on-demand inquiry request for all margin accounts managed by the corporation.
In at least one embodiment, a user may also inquire, in real time, regarding a margin status arising from a hypothetical scenario. Such a hypothetical scenario may be associated with situations, including but are not limited to, a proposed transaction, a change in margin management policy, a change in price of a certain security, or a change in the value of an index. A hypothetical margin inquiry may be a corporate level margin inquiry or a client level margin inquiry. A corporate level margin inquiry may be initiated by a corporate officer to assess the impact of a proposed (or hypothetical) corporate level change in a policy, in a security price, or in an index value. The proposed change may be used to compute margins against relevant accounts and such resultant hypothetical margins may then be used to assist the assessment of the impact of the change. In case of a change in an index value, the prices of the securities that contain the index may be appropriately adjusted based on certain criteria such as the index's proportion with respect to the security.
In at least one embodiment, a client level margin inquiry may include an inquiry about the impact on the margin status resulting from a hypothetical transaction. Such a proposed transaction may be a sell or a buy transaction associated with certain product(s) at some specified price(s). A price may be determined based on a market (intraday) price, the price as of the end of the previous day, or an arbitrary price based on some condition. The proposed transaction may be applied in computing the resultant margins and the impact assessed based on the resultant margins.
In at least one embodiment, a client level margin inquiry may also include an inquiry about possible sale(s) that can be carried out to cure a margin violation or to satisfy a certain requirement. A violation amount may be identified in order to determine a proposed sale. A proposed sale is expressed as the product(s) to sell and the quantity to be sold to satisfy the violation amount. A client level margin inquiry may be initiated by a user who may be an investor, a financial agent representing a plurality of clients, or a corporate officer. A hypothetical margin inquiry, including both corporate level and client level margin inquiries, may be requested for a single account or simultaneously against a plurality of accounts.
Further, a framework or a system configuration may be provided to facilitate a margin management service. The framework may be configured to enable a service provider to offer one or more types of margin management services to a plurality of clients. The service provider may offer different functions for real time margin management. It may also combine real time margin management functionalities with batch mode margin management functionalities. The framework may support different interface means through which a user may interact with a margin management service to perform different inquiries or transactions. In addition, the framework may also provide a backend support for data storage, retrieval, and processing and the capability of integrating the margin management services with other services such as accounting and data management. Furthermore, the framework may be configured to enable a service to generate reports in compliance with governmental regulations.
The invention claimed and/or described herein is further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:
If an inquiry request from the user 170 corresponds to a real time inquiry, the real time margin management processor 120 may process the request and respond to the user's request in real time. If an inquiry request from the user 170 corresponds to batch computation of margins, the EOD margin calculator 145 may process and respond to the request. Both the real time margin management processor 120 and the EOD margin calculator 145 may process a corresponding inquiry request. Each may construct an appropriate margin computation request according to the processed inquiry request and invoke the margin calculation mechanism 140 to perform specific margin computations required by the request.
Margins may be computed for one or more accounts. Depending on specific accounts, different regulations/rules may apply. Regulations may include governmental regulations 150 and rules may include in-house rules 155. The former may be issued by the government, which governs the determination of margin requirements and other restrictions applied to different types of accounts. The latter may involve in-house policies initiated by a specific investment institution such as an investment firm or a bank. Different accounts may be governed by different regulations or rules. Therefore, when requesting margin computations, the real time margin management processor 120 may specify different regulations or rules to be applied in the margin computation with respect to different accounts. The margin calculation mechanism 140 may also invoke different regulations/rules for specific accounts for which margins are computed.
In at least one embodiment, the real time margin management mechanism 120 may further include an on-demand margin calculator 125 and a hypothetical margin calculator 130. The on-demand margin calculator 125 may be responsible for processing a real time on-demand margin inquiry. The hypothetical margin calculator 130 may be responsible for processing a real time hypothetical margin inquiry. An on-demand margin inquiry may be related to a query by which the user 170 may request certain margin computations to be carried out for one or more accounts using some specified prices. An on-demand margin request may request computation of margins against a single or multiple accounts.
A hypothetical margin inquiry may be related to a query by which the user 170 may issue a request to compute margins in order to assess the impact to margin requirements if some hypothetical scenarios were to occur. For example, a hypothetical scenario may involve one or more hypothetical transactions using certain hypothetical prices. Other exemplary hypothetical scenarios may include a change in the value of an index or a change in in-house rules related to margin requirements. Depending on the request, margins may be computed for a single account or multiple accounts.
In addition to computing margins in real time upon a request, margin computation may also be performed at the end of a particular period. For example, margins may be computed at the end of each day when the market is closed. Such margin computation or process may be termed EOD processing. The EOD processing may be performed by the EOD margin calculator 145. Its processing may be dynamically triggered by the user 170 through the margin inquiry interface 105. It may also be programmed to be activated automatically at the end of each of such period (fixed interval) through an EOD processing activation signal 175.
Margin computation may involve determining whether a violation has occurred. Violation detection may be performed by the violation detector 135. Such a violation determination may be invoked either during real time margin inquiry processing or EOD processing. For example, in order to respond to a real time margin inquiry to compute margins using a hypothetical scenario, violation detection may be activated by the real time margin management mechanism 120 to see whether a hypothetical transaction would lead to a violation. Similarly, at end of each day, when trades are actually carried out, violation processing may be called to determine whether a violation occurs. Since different accounts may be governed by different regulations/rules, regulations or rules to be applied to compute violations for accounts may differ.
In computing margins, prices of different securities may need to be specified. Such prices may be determined according to a hypothetical scenario specified by the user 170. They may also be determined based on dynamic market prices (or intraday prices) or the prices as of the end of the previous day. The intraday price may be acquired through real time access to the market (not shown), or there may be an intraday database 160 recording security prices of the current market. For instance, the market prices of securities may be tracked every 10 seconds and then stored in the intraday database 160. There may also be an EOD database 165 that records information related to end of day processing such as security trading prices at the end of each day.
Depending on a margin inquiry request, the margin calculation mechanism 140 may compute margins using certain specified security prices. For example, in a hypothetical margin inquiry, the user 170 may indicate to use intraday prices to assess the impact of a hypothetical transaction. As another example, the user 170 may request an on-demand margin inquiry using security prices as of the end of the previous day. End of day processing scheduled to be performed after the market is closed each day may always use the prices as of the current day. Based on such specifications, the margin calculation mechanism 140 computes margins using prices retrieved from either the intraday database 160 or the EOD database 165.
There may be different modes of communications between the margin calculation mechanism 140 and the mechanisms that invoke the margin calculation mechanism 140 to compute margins (e.g., the on-demand margin calculator 125, the hypothetical margin calculator 130, and the EOD margin calculator 145. In one embodiment, the communication may be direct. That is, to activate the margin calculation mechanism 140 to perform margin computations, the invoking mechanism may trigger the margin calculation mechanism 140 directly. Alternatively, the mechanism may send a request to a database 110 that records all requests. The margin calculation mechanism 140 may retrieve a request from the request database 110 and carry out the requested operation before storing the computed margin result in a result database 115. The requesting mechanism may then retrieve the corresponding result from the result database 115. Communication in this alternative mode may be facilitated using request identifications so that corresponding requests and results may be uniquely identified.
A business administrator 215 may use the margin management mechanism 100 for different purposes. For example, a corporate level administrator may request the margin management mechanism 100 to assess the impact of a change in some in-house rules. In addition, such a business administrator may also want to assess the impact caused by a change in the value of a particular index on all accounts. Furthermore, such a business administrator may sometimes also want to see the impact of a change of a security price on a group of accounts. The interface(s) provided to such business administrators to facilitate such inquiries may be different from those provided to a client 205.
Furthermore, a system operator 225 may use the margin management mechanism 100 to compute margins for some other different purposes. For instance, a system operator may request the margin management mechanism 100 to compute certain margins in order to debug the system. For such purposes, the interface provided to support such a need may be different.
To support different types of users, the margin inquiry interface 105 may facilitate interfaces that may be appropriate for different users with respect to their different needs. The margin inquiry interface 105 may comprise a client query interface 210, an administrative query interface 220, and a system inquiry interface 230. Each of these interfaces may facilitate the interactions that are appropriate for the intended purposes. For example, the administrative query interface 220 may provide the interfaces that allows a business administrator 215 to enter proposed in-house rules, proposed security prices, or proposed value of a particular index. Such changes may not be allowed, for example, if the user is a client or a financial agent who may merely like to see the impact of a hypothetical sale of a certain security at a certain price on a single account.
The margin inquiry interface 105 may further comprise a margin inquiry request processor 240 and a margin inquiry responding mechanism 260. The margin inquiry request processor 240 may form a margin computation request with information specified by a requester (e.g., a client 205, a business administrator 215, or a system operator 225) through appropriate interfaces. Such a margin computation request is sent to an appropriate mechanism (e.g., the real time margin management mechanism 120 or the EOD margin calculator 145). When the requested margins are computed, the margin inquiry responding mechanism 260 retrieves a query result 265 and directs such result to appropriate interfaces so that the result may be displayed to the requester.
Alternatively, the margin inquiry interface 105 may also include a margin inquiry request notifying mechanism 250, which notifies an appropriate mechanism (e.g., the real time margin management mechanism 120 or the EOD calculation mechanism 145) of a request for computing margins. Such a notification may contain the information related to the inquiry so that when the notification is received, the corresponding mechanism may directly compute what is requested. In a different embodiment, such a notification may not include information specific to the inquiry request and may merely inform a corresponding mechanism that there is a request. In this case, the request itself including necessary information indicating how the margins should be computed may be stored at an agreed location (e.g., the request database 110) which may be retrieved based on some identification.
Both the corporate level hypothetical margin inquiry 310 and the client level hypothetical margin inquiry 320 may be directed at either a single account, i.e., a single account margin inquiry 330, or a plurality of accounts, i.e., a multiple account margin inquiry 340. That is, a hypothetical inquiry may include a corporate level inquiry directed at a single account, a corporate level inquiry directed at a group of accounts, a client level inquiry directed at a single account, and a client level inquiry directed at a group of accounts. Some of the inquiries may be made in the form of a detailed margin information report inquiry 350. Other inquiries may be made in the form of a summary margin information inquiry 360. For example, a single account margin inquiry 330 may be made to obtain detailed margin information. A multiple account margin inquiry 340 may be made to obtain summary margin information. Such an option may affect the results received as a response to the query.
The client hypothetical scenario constructor 620 may construct a hypothetical scenario based on a client's input 605. For example, the client hypothetical scenario constructor 620 may gather all the detailed input related to a proposed transaction that may be entered by the user through, for instance, a web based graphical user interface. Detailed information related to a proposed transaction may include information related to the nature of the transaction (e.g., buy or sell), the price involved (e.g., at a specified price), and the quantity involved in the transaction (e.g., number of shares of a particular security to be sold).
Information related to a hypothetical scenario (either corporate level or client level) may then be forwarded to the hypothetical margin request generator 630 so that a specific margin inquiry request may be generated. Such a generated margin inquiry request may then be further forwarded to the hypothetical margin calculation requester 640 which may be responsible for sending the margin inquiry request to an appropriate mechanism. For example, a margin inquiry request may be sent to the request database 110, which may be subsequently retrieved by the margin calculation mechanism 145, or directly to the margin calculation mechanism 145 (not shown).
When the requested margin computation for a hypothetical margin inquiry is completed, the hypothetical margin calculator 130 may then retrieve the result. Different embodiments may be employed to obtain the computed margin information. The margin calculation mechanism 145 may place the result in the result database 115 and the margin calculation result retriever may subsequently retrieve the result (e.g., using a request identification corresponding to the initial margin inquiry request). Alternatively, the margin calculation mechanism 145 may also send the result directly to the hypothetical margin calculator 130 (not shown).
The hypothetical margin calculator 130 may also optionally comprise a result posting mechanism 680 which may be responsible for outputting or posting the received margin result computed according to a given hypothetical scenario on a certain web based interface to the user who issues the inquiry request. In addition, the hypothetical margin calculator 130 may also optionally include a detailed report generator 660 and a summary report generator 670. The former may be responsible for creating a detailed report on margins computed based on a hypothetical scenario and the latter may be responsible for creating an alternative summary report on the same result. The activation of either of the report generators may depend on the specification of the user who issues the hypothetical margin inquiry.
As mentioned earlier, another alternative real time margin inquiry may be associated with on-demand margin inquiry.
There may be alternative or multiple selections in terms of the types of information to be computed to respond to an on-demand margin inquiry.
The requirements 810 may include requirements under different regulations or rules. For instance, some requirements may be determined by governmental regulations (e.g., regulation T requirement 835) or by local rules (e.g., in-house requirements 840). There may be further different kinds of requirements including short requirements 860, long requirements 865, option requirements 870, and requirements by position 875.
There may also be different types of excess related information. For example, this may include excess in terms of house maintenance 845 and excess in terms of cash account 850. Similarly, equity may be computed in terms of cash account 850 or in terms of net margin equity 855.
The client demand analyzer 905 may perform analysis on a margin inquiry request received from the user 170. The analysis may distinguish different types of inquiry requests and associated inquiry parameters based on a client's demand 900. For instance, an on-demand inquiry may be initiated to request information about a single account or multiple accounts. Under each of such inquiries, there may be associated parameters such as whether to compute certain types of requirements. The single account on-demand request constructor 910 may construct an on-demand margin inquiry request against a single account. The multiple account on-demand request constructor 915 may similarly construct an on-demand margin inquiry request against a plurality of accounts.
An on-demand margin inquiry request (either constructed for a single account or for multiple accounts) is forwarded to the on-demand margin calculation requester 920 which may be responsible for sending the on-demand margin inquiry request to an appropriate mechanism. For example, a margin inquiry request may be sent to the request database 110, which may be subsequently retrieved by the margin calculation mechanism 145. Alternatively, the on-demand margin inquiry request may also be sent directly to the margin calculation mechanism 145 (not shown).
When the requested margin computation for an on-demand margin inquiry is completed, the on-demand margin calculator 125 may retrieve the result. Different embodiments may be employed to obtain the computed margin information. The margin calculation mechanism 145 may place the result in the result database 115 and the margin calculation result retriever 925 may subsequently retrieve the result (e.g., using a request identification corresponding to the initial margin inquiry request). Alternatively, the margin calculation mechanism 145 may also send the result directly to the on-demand margin calculator 125 (not shown).
The on-demand margin calculator 125 may also optionally comprise a result posting mechanism 945 which may be responsible for outputting or posting the received margin result computed according to a specific demand on, for example, certain web based interface to the user who issues the inquiry request. In addition, the on-demand margin calculator 125 may also optionally include a detailed report generator 930 and a summary report generator 935. The former may be responsible for creating a detailed report on margins computed based on a demand and the latter may be responsible for creating an alternative summary report on the same result. The activation of either of the report generators may depend on the specification of the user who issues the on-demand margin inquiry.
FIGS. 10(a)-10(e) are illustrative client inquiry interfaces for real time margin related inquiries according to at least one embodiment.
Individual securities and their associated positions may also be displayed in 1009. In such summary information, each security may be described in one row with various information associated with the security. For example, security 1010 has a symbol ADP with description “Automatic Data Processing” and it has a position of 115.00 shares with a price of $31.23, total value of 3,591.00, a maintenance percentage of 30 at 1,781 and a regulation requirement of 50 percent at 1,795. Such an inquiry interface provides both some detailed and some summary information associated with a single account.
Based on selected prices, margins and related measures against the account are computed and displayed. A margin summary 1023 is provided with various requirements (e.g., long, short, option), balances, equities, and market values. In this example, the trade date balance 1025 for this account is −8,195.00. In addition, other summary information 1026 may also be displayed. Examples include various types of calls (e.g., house call, federal call, equity call, or NYSE calls), buying power, liquid equity, and cash account excess.
At the bottom part of the exemplary client inquiry interface 1020, a table 1027 may be used to not only display the status of each security according to the selected intraday prices but also specify hypothetical actions to be taken with respect to each security. For example, each row represents a security with its current trading position 1030, current price 1031, and current value 1032. For example, security AOL has a trading position of 370.00 with an intraday price of 23.65 at a value of 8,750.00. In addition, requirements according to both regulations and maintenance are also computed against each security within the account.
Through this interface, a user may also specify a proposed transaction on any of the securities in the portfolio. A proposed transaction may be specified in terms of an action 1028 (e.g., buy or sell), the action quantity 1029) (e.g., number of shares to be sold),. and the price used 1031 in the proposed transaction (e.g., intraday price or market price). Such specified hypothetical actions may be part of a hypothetical scenario. For instance, for security DIS (for Walt Disney Co.), there is a specified “sell” action 1033 specified with an action quantity of 11 shares 1034. The proposed sell of DIS security is to be carried out against the current trading position of DIS 1035 (i.e., 111 shares) using the selected intraday price 1036 for DIS (i.e., 23.08 per share).
In row 1027 of
The information displayed corresponds to the margin related information when the proposed hypothetical transaction is carried out. For instance, the information displayed in 1047 and 1048 differs from what is shown in section 1023, 1026, and 1027. The difference is due to the hypothetical sale. For example, the trade date balance in 1047 is −7940.11 compared with the corresponding trade date balance −8195.86 1025 in
After the margin computation, the margin calculation mechanism 140 may send the result directly back to the invoking mechanism (not shown) or may store the result in the result database 115 under some identification that may uniquely identify the inquiry. In one embodiment, the margin calculation mechanism 140 comprises a margin calculation request retriever 1110, a margin calculation request analyzer 1120, a single account margin calculation mechanism 1130, and a multiple account margin calculation mechanism 1140. The margin calculation request retriever 1110 may retrieve a margin inquiry request from the request database 110. Such a request may be stored there by an invoking mechanism with a unique identification number, which can be used to subsequently store the corresponding result for result storage and retrieval.
Each request may include various parameters specifying what needs to be computed and what criteria to be applied during the computation. Such information may be analyzed by the margin calculation request analyzer 1120, which may consequently generate appropriate signals to control the margin computations. Depending on whether the inquiry is a single account or multiple account inquiry, the margin calculation request analyzer 1120 may invoke the single account margin calculation mechanism 1130 to compute margins against a single account or invoke the multiple account margin calculation mechanism 1140 to compute margins across a group of accounts.
The multiple account margin calculation mechanism 1140 may interact with the single account margin calculation mechanism 1130 to compute margins for each of the multiple accounts for which margins are to be computed. One exemplary implementation of the multiple account margin calculation mechanism 1140 in relation to the single account margin calculation mechanism 1130 is illustrated in
When the single account result receiver 1220 receives computed margin results for a single account, it may forward such results to an individual account result summary mechanism 1230 and a multiple account result summary mechanism 1240. Such forwarded result may be summarized, organized according to some format required by the display or by the user who requests the margin computation. The result summary and organization may be performed in an incremental fashion. Whenever results for another account are received, it may be incorporated into the results that are already organized and summarized. When the computation of margins for all the accounts is completed, the organized results may be stored in the result database 115 under a unique identification under which the margin inquiry request is received.
The margin calculation mechanism 140 may be invoked by either the real time margin management processor 120 or the end of day margin calculator 145. When the margin calculation mechanism 140 is invoked to perform end of day processing in a batch mode, margins computed may differ from what is required to be computed for real time margin related inquiries.
End of day batch margin calculations 1300 may include the computation of buying power 1310, marginable market value 1320, excess under different criteria 1330, SMA process 1340, equity 1350, and house maintenance requirements 1360. The criteria under which excess may be computed may include federal excess according to federal regulations 1370, house excess according to in-house rules 1380, and NYSE excess according to NYSE regulations 1390. When the margin calculation mechanism 140 is invoked to perform margin computation in batch mode, the computed results may be stored into the EOD database 165 as shown in both
With specified query parameters, the margin inquiry interface may then construct accordingly a margin inquiry request and send such a request, at 1430, to a real time margin management processor. When the real time management processor receives the margin inquiry request at 1440, it may then determine, at 1450, whether the request is an on-demand margin inquiry or a hypothetical margin inquiry. If the request is for an on-demand margin inquiry, an on-demand margin calculator may be invoked at 1460 to process the on-demand margin inquiry. Further details related to the processing of an on-demand margin inquiry are discussed with reference to
To proceed with margin computation according to the demand, an on-demand margin calculator may further determine, at 1507, the specified prices used to compute the margins. There may be different alternatives such as intraday price or end of day price, as determined at 1510. If the user specifies to use the intraday (market) price, intraday prices related to corresponding securities are retrieved at 1515 from a intraday database. If the user specifies to use end of day prices, EOD prices of the corresponding securities are retrieved, at 1520, from the EOD database. Such retrieved EOD prices may correspond to the prices as of the end of the previous day.
The on-demand margin calculator may then determine, at 1525, whether the on-demand margin inquiry is directed at a single account or a plurality of accounts. If the inquiry is for a single account, the on-demand margin calculator may invoke a margin calculation mechanism to compute, at 1530, margins for a specified single account. The computed margins and relevant information (e.g., requirements, violation, calls, market value) may be outputted or posted to the requesting user at 1535.
If the on-demand inquiry is for a plurality of accounts (e.g., all the accounts under one financial agent), the on-demand margin calculator may invoke a margin calculation mechanism to compute, at 1540, margins and relevant information for all the specified accounts. Results produced to respond to an on-demand multiple account margin inquiry may then used, at 1545, to generate summaries or reports before such results are posted or output to the requesting user at 1535. The process 1500 may end at 1550.
If the change is related to a price increase of a specific security, determined at 1810, the proposed increase in price may be entered at 1815 and used to compute, at 1855, margins and related measures against all accounts to facilitate the evaluation of the impact. Similarly, if the change is related to a price decrease of a specific security, determined at 1820, the proposed decrease in price may be entered at 1825 and used to compute, at 1855, margins and related measures against individual or all accounts.
If the change is related to a value increase with respect to a particular index, determined at 1830, the proposed value increase may be specified and proportionally applied at 1835 to adjust the prices of all the securities that contain the index. Such adjusted prices may then be used to compute, at 1855, margins and related measures against individual or all accounts to evaluate the impact of the value increase. Similarly, if the change is related to a decrease in the value of a particular index, determined at 1840, the proposed value decrease may be proportionally applied, at 1845, to adjust the prices of the securities that contain the index. Those adjusted securities prices may then be used to compute, at 1855, margins and related measures against individual or all accounts.
Other alternative changes may also be specified, at 1850, and used to compute, at 1855, hypothetical margins to evaluate their impact. When the hypothetical margins are computed, they may be posted or output, at 1860, to assist the requesting user to review and to evaluate the impact. The process 1800 may then end at 1865.
If the proposed transaction is a sell transaction, the product to sell and its sale quantity are determined at 1935 and 1940. Such determined hypothetical scenario is then applied in determining, at 1945, the impact of the hypothetical transaction on margins and relevant measures. The computed hypothetical margins are then posted or output, at 1950, to the requesting user.
A hypothetical margin inquiry may also be related to an evaluation in terms of how to cure a violation associated with a particular account. A violation may be defined with respect to some requirement (e.g., federal regulation requirement or house requirement). For example, if a federal regulation requires that the equity in an account be at least 50% of the total market value of the account, if the equity is lower than the required percentage (e.g., 48%), a violation exists. A violation may be associated with a specific violation amount (e.g., 2% of the total market value). To determine how to cure a violation, the violation amount associated with an account may be first determined at 1905. With respect to the violation amount, a specific product or security may be proposed, at 1910, to be sold by a certain quantity, determined at 1915, to satisfy the underlying requirement. Such proposed transaction may then be hypothetically applied in computing, at 1945, the rest of the margins and related measures, which may then be posted, at 1950, to the requesting user. In addition, the client may hypothetically consider sending additional funds to fully or partially satisfy the violation amount (not shown). The violation amount may be computed by taking this hypothetical payment into account which may subsequently affect the computation of a proposed transaction to cure the violation. The process 1900 may then end at 1955.
The network 2015 may represent a generic network, which may correspond to a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, a proprietary network, a telephone network, a wireless network, or a conventional postal mail network. Depending on the nature of the network employed for a particular application, the network 2015 may be implemented accordingly. The network 2015 may serve the purpose of delivering information between connected parties.
A service provider that offers the margin management service 2040 may correspond to a bank, an investment institution, or other organization or company that provides financial services. The service provider may offer other services on the same or a different server as well in addition to the margin management service. For example, an investment institution may offer banking services in addition to its investment services. In the margin management methods described earlier, the margin management service 2040 may interface with different types of users such as individual investors, financial agents 2025 representing individual investors or corporate investors, corporate administrators who may adjust firm wide policies regarding margins, and system administrators who may debug the margin management service application when needed.
The margin management service application 2040 may include one or more modules or mechanisms including sequences of programmed instructions, which cooperate to perform client margin management operations. The programmed instructions, upon execution, are operable to configure a computer system (discussed with reference to
The margin management service running on the server 2035 may be connected to different parties for different needs or purposes via different means. For example, the margin management service application 2040 may interact with its users through an online web site supported by a web server 2020 (for example, a Netscape™ web server) or through its representatives such as a financial agent 2045 who interacts with clients via telephone calls routed from a call center 2030. It is also possible for the call center 2030 to forward a margin management request that is automatically constructed based on a user's oral request made via a telephone connection and routed to the web server 2020.
The margin management service application 2040 may also interact with other service providers 2080. Those other service providers may provide some form of support or functions to the margin management service as part of a coherent service. For example, a service provider that offers the margin management service may outsource the billing function to an outside company or service provider. Such billing functions may include generating monthly statements with respect to margins of individual accounts and sending such statements to the contact addresses of the account holders.
The margin management service application 2040 may also interact with other related services from the same service provider. For example, since the margin management service application 2040 may facilitate margin management based on both actual or hypothetical investment decisions, the margin management service application 2040 may interface with a trading system 2060. The trading system 2060 may periodically invoke the margin management service application 2040 to perform, for instance, end of day processing to carry out registered trading transactions. Furthermore, the margin management service application 2040 may also interface with an accounting system 2055 to provide integrated services. The accounting system 2055 may perform accounting related functionalities such as computing the interest or gains associated with individual accounts. For example, for investment accounts, a gain may be computed daily according to the market. For a cash account, the gain may be computed as accrual of interest according to a dynamic interest rate associated with each individual account. Such computed gains may then be deposited back into the corresponding accounts or invested according to some pre-specified instructions.
There may be other combinations between the margin management service and other services. For instance, the margin management service may be integrated with a sweeping service, which provides automated means to sweep funds among different types of investment accounts (not shown). The margin management service may also be interfaced with conventional banking services to handle, for example, cash transactions (now shown).
The margin management service application 2040 may also perform some functions in compliance with laws or certain governmental regulations. The margin management service application 2040 may be in communication with some governmental agency (or agencies) 2050 to synchronize its service with dynamic governmental requirements. For example, federal regulations regarding the required percentage of equity in each margin account may change over time and need to be adaptively applied to all accounts. As another example, the service provider offering the margin management service may be required by regulation to report to the federal government on detailed transaction activities performed on the accounts that it serves.
Functionalities performed in compliance with governmental regulations may be performed, for example, via a proprietary interface between the margin management service application 2040 or a secure web interface supported by the web server 2020. Such functionalities may be implemented as web based application programs executed on one or more web application servers.
The margin management service may be distributed (not shown). Different offices or locations that support various aspects of the margin management service may manage their own local accounts on their local secure environment. The management at different locations may differ in terms of service policies. Although the management may be distributed, the margin management service application or service provider may have access to individual offices for management purposes through, for example, secure communication channels. Alternatively, there may be a centralized management of all distributed sites so that services supported at distributed sites may be controlled in a synchronous fashion.
A database system 2070 may be responsible for providing data storage and data access, including retrieval, update, and deletion. The margin management service application 2040 may communicate with the database system 2070 in a secure manner. Connections may be accomplished via different protocols such as TCP/IP. The margin management service application 2040 may communicate with the database system 1250 in accordance with Java Database Connectivity (JDBC) protocol. Alternatively, database connectivity may be accomplished using a ColdFusion™ server engine either via Open Database Connectivity (ODBC) or native connections.
The database system 2070 may be provided in conformance with a database management system format such as, but not limited to, the Structured Query Language (SQL) format. The database system 1250 may also be implemented using Sybase® database management system provided by Sybase® Corporation of Emeryville, Calif. and executing on, for example, an IBM® RS6000™ workstation AIX® version 4.2.1. Alternatively, the database system 2070 may also be implemented in accordance with the DB2 database product standard available from IBM® Corporation. Furthermore, the database system 2070 may be a SQL Server 7.0 database supporting the ActiveX Data Object (ADO) and ODBC protocols, provided by IBM® Corporation or Oracle® Corporation.
The database system 2070 may further include information such as, but not limited to, database query and access instructions in the form of one or more scripts which, when executed by a processor, serve to store, retrieve, or update data maintained in the database system 2070 according to instructions contained in the scripts, and in particular regarding the data fields to be accessed as well as their arrangement of the fields.
The database system 2070 may be distributed. This may be done particularly so that services are offered in a distributed manner with each office site maintaining its own local database system. In this case, there may be a centralized data management scheme in addition to individual data management systems and this central data management may regularly communicate with individual local management to ensure data consistency and integrity.
In at least one embodiment, databases used by the margin management service application to store data related to margin management (e.g., intraday database 160 or EOD database 165 according to the margin management mechanism 100) may reside in the database system 2070. Alternatively, such databases may also reside on the server 2035, which may interact with the database systems 2070 for data related to other integrated services.
The front-end system 2115 may comprise a HyperText Transfer Protocol (HTTP) server 2120, a web application server 2130, and a connecting mechanism 2125. The HTTP server 2120 may serve as the web server 2020, capable of being configured to generate and output interactive pages to a user station using the World Wide Web and suitable for display using a web browser. The web application server 2130 may serve as the server 2035. Such a web application server may correspond to a secure web application server behind the HTTP server 2120 (or web server 2020) employed to run one or more web based application programs (e.g., an application program to carry out the margin management methods described above) in a secure fashion.
The web application server 2130 may be configured to execute one or more web based application programs, responsive to commands and data received from the users via a web page supported by the HTTP server 2120 (or web server 2020), and providing data and results to the users. The HTTP server 2120 and the web application server 2130 may be implemented using a single computing platform. Alternatively, they may also be implemented using separate computing platforms.
The connecting mechanism 2125 may be responsible for connecting the front end system 2115 with the backend system 2150 through a connect gateway 2140. Such connection may be realized using certain communication protocols such as an Embedded Communication Interface (ECI). The backend system 2150 may comprise one or more components of the margin management mechanism 100 such as the real time margin management processor 120, the EOD margin calculator 145 (not shown), the violation detector 135 (not shown), . . . , and the margin calculation mechanism 140. The backend system 2150 may also optionally include various databases used for margin management purposes. This may include the request database 110, the result database 115, the intraday database 160, and the EOD database 165. Alternatively, some of those databases may also reside on the web application server 2130.in the front-end system 2115 such as the request database 110 or the result database 115. In addition, the intraday database 160 or the EOD database 165 may reside on either the web application server 2130 (i.e., the server 2035) or on the database system 2070.
At least one embodiment relates to the use of a computer system for client margin management using a server.
The computer system 2300 further may include a Read-Only Memory (ROM) 2335 or other static storage device coupled to the bus 2355 for storing static information and instructions for the processor 2305. A storage device 2340, such as a magnetic disk or optical disk, may be provided and coupled to the bus 2355 for storing information and instructions.
The processor 2305 may fetch the instructions, decode them, and act or instruct other elements 2310-2360 to, for example, transfer data to or from the memory 2345 or to work in combination with the data entry device 2310 or the display 2325 (for example, to input or output data), etc. The processor 2305 may actually be implemented as more than one processor. It should be appreciated that the processor 2305 may be implemented as a general purpose microprocessor, for example, in a central processing unit, a micro controller, or other similar device.
A database 2350 may be coupled to the bus 2355 for storing static information and software instructions. Information stored in or maintained using the database 2350 may be provided in conformance with a database management system format such as, but not limited to, the SQL format. The database 2350 may be a SQL database provided by the Oracle® Corporation of Redwood Shores, Calif. Alternatively, the database 2350 may be a SQL Server 7.0 database supporting the ADO and ODBC protocols provided by IBM® Corporation or Sybase® Corporation. The database 2350 may include information including, but not limited to, database query and access instructions in the form of one or more scripts which, when executed by a processor such as the processor 2305, serve to store and retrieve data maintained using the database 2350 according to the instructions contained in the script, and in particular regarding the data fields to be accessed, as well as their arrangement, provided in the response to the processor 2305.
According to at least one embodiment, margin management as described herein may be provided by the computer system 2300 in response to the processor 2305 executing one or more sequences of instructions contained in the main memory 2345. Such instructions may be read into the main memory 2345 from another computer-readable medium, such as the storage device 2340 or the database 2350. Execution of the sequences of instructions contained in the main memory 2345 may cause the processor 2305 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in the main memory 2345. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The computer system 2300 may be coupled via the bus 2355 to a display 2325 for outputting information to a computer user. In one embodiment, the display 2325 may be a Cathode Ray Tube (CRT) computer display monitor capable of displaying information using multiple colors. Alternatively, the display 2325 may be a liquid crystal display, a monochrome monitor, a web-enabled wireless terminal or handheld terminal such as, for example, a Personal Digital Assistant (PDA). The computer system 2300 may include other output devices as well such as, but not limited to, a printer.
A data entry device 2310, including alphanumeric and other keys, may be coupled to the bus 2355 for communicating information and command selections to the processor 2305. Another type of user input device which may be coupled to the bus 2355 is a pointing device 2320, which may be a computer mouse, trackball, cursor direction keypad, tactile directional finger pad, or other such device for allowing a user to control cursor location and movement on the display 2325, and for communicating direction information and command selections to the processor 2305. This pointing device 2320 typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the pointing device to specify positions in a plane.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to the processor 2305 for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as the storage device 2340. Volatile media include dynamic memory, such as the main memory 2345. Transmission media can also take the form of acoustic or light waves, such as those generated during Radio Frequency (RF) and InfraRed (IR) communications. Common forms of computer-readable media include, for example, floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a Compact Disc Read Only Memory (CD ROM), Digital Video Disc (DVD) or any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a Random Access Memory (RAM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read Only Memory (EPROM), a Flash EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor 2305 for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer. The remote computer may load the instruction into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 2300 may receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal and place the data on the bus 2355. The bus 2355 may carry the data to the main memory 2345, from which the processor 2305 retrieves and executes the instructions. The instructions received by the main memory 2345 may optionally be stored on the storage device 2340 either before or after execution by the processor 2305.
The computer system 2300 may also include a communication interface 2330 coupled to the bus 2355. The communication interface 2330 may provide a two-way data communication coupling to the network 2315. For example, the communication interface 2330 may be a modem or an Integrated Services Digital Network (ISDN) card to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface 2330 may be a LAN card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface 2330 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
The communication interface 2330 may provide data communication through one or more networks to other data devices. For example, the communication interface 2330 may provide a connection through a local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP may in turn provide data communication services through a worldwide packet data communication network such as the Internet. These networks use electrical, electromagnetic, or optical signals that carry digital data streams. These signals are exemplary forms of carrier waves transporting the information.
The communications interface 2330 may include Ethernet interface or a LAN communication card, a dial-up modem interface using the PSTN, an intranet, or any combination thereof.
The computer system 2300 may send messages and receive data, including program codes, through the network(s) and the communication interface 2330. In the Internet example, a server might transmit a requested code for an application program through the Internet, ISP, and the communication interface 2330. One such downloaded application may, for example, provide for event monitoring as described herein. The received code may be executed by the processor 1405 as it is received, and/or stored in the storage device 2340, or other non-volatile storage for later execution. In this manner, the computer system 2300 may obtain an application code in the form of a carrier wave.
The server 2035 may receive commands and data from the clients' terminals (e.g., 2010a ) and output program code and data to the client terminals 2010a using the network 2315. In an embodiment, the server 2035 may generate and transmit the requested information to the requesting user via Hypertext Transfer Markup Language (HTML) formatted or eXtensible Markup Language (XML) formatted pages, which may be provided as World Wide Web pages, using the network 2315. As described previously, the network 2315 may be, for example, a network of interconnected networks such as the Internet, a LAN, a WAN, an intranet including any of these, and/or the PSTN. Interactive pages transmitted and received using the network 2315 may conform to the SSL protocol.
The communications interface 2330 may further include a web browser or a so-called thin client. A thin client may be a client portion of an application designed to require little memory so that the bulk of the data processing occurs on a corresponding server. In at least one embodiment, a thin client may be Java-based. The web browser displays data and is capable of communicating with other computers via a network such as, for example, the Internet or an intranet. The web browser provides a user with a way to navigate, via, for example, hyperlinks which are selected by the pointing device 2320 such as a computer mouse, or as typed in by the user. The web browser uses a protocol such as, for example, HTTP or File Transfer Protocol (FTP), to transmit data of various content such as, for example, HTML formatted documents, plain text documents, graphic images, and XML documents for presentation to the user via the display 2325. Web pages formatted in accordance with HTML or XML may also be provided in accordance with the eXtensible Style Language (XSL) specification available from the World Wide Web Consortium. XSL is useful for separating style from content as well as for providing a common interface for sharing of web pages across applications. The web browser may also run or execute programs, such as Java applets including sequences of instructions provided in accordance with the Java programming language, or JavaScript. The web browser may be, for example, Internet Explorer® by Microsoft® Corporation, Netscape Navigator® by Netscape®, America Online® browser, or any other web browser. A thin client may utilize a two or more tiered client server model. In this model, the client may run a minimal set of services that provide functionality to interface with at least one server. A web browser may be a thin client. The server 2035 may run, for example, the Windows® NT network operating system available from Microsoft® Corporation of Redmond, Wash.
Instructions executed by the processor 2305 from the main memory 2345 may include, for example, application software instructions that cause the processor 2305 to perform operations as described herein. These application instructions may be implemented in the form of source code statements provided in accordance with, for example, the Visual C++® and Visual Basic® higher order programming languages, development kits for which are available from Microsoft® Corporation of Redmond, Wash. Application instructions may also include database scripts for accessing, storing, or selectively retrieving information contained in the database 2350. The database scripts may be contained in the storage device 2340 or may be stored using the database 2350. The database scripts may be implemented in the form of programming statements provided in accordance with, for example, SQL version 7.0 database management system query language, as well as the IBM DB2® system. Other database implementations are possible, including those available from Oracle® or Transact SQL in accordance with the ColdFusion® database management system.
Application software instructions may include a user interface portion, which may be a Graphical User Interface (GUI) portion, for generating interactive pages or display screens by which a user may provide data to and receive information from the computer system 2300 and the database 2350 using a human-machine interface such as, but not limited to, the display 2325. Interactive pages may include user dialog boxes for accepting user-entered information. In particular, the GUI portion may prompt the user to enter data by providing an interactive dialog box or message box instructing the user to enter particular data, or to select from among a multitude of options provided using a pull-down menu. The human-machine interface may also include a hardcopy-generating device such as a printer. A user may interact with the computer system 2300 via the graphical user interface provided by the GUI portion by using the pointing device 2320 and the data entry device 2310. The GUI portion may place the output of the computer system 2300 in a format for presentation to a user via the display 2325. In at least one embodiment, the GUI may be implemented as a sequence of Java instructions such as, for example, Java Swing® instructions. Java Swing® is part of the Java™ Foundation Classes (JFC) in the Java™ platform. The JFC encompasses a group of features to aid in the development of GUIs. Swing® provides all the components from buttons to split panes and tables. The Java™ classes and logic of the GUI may be implemented in Java™.
In particular, a user may select a particular data entry field of an interactive display page presented using the display 2325 by using the pointing device 2320 or the data entry device 2310 to select that field. Upon selecting a field, a user may then enter information into the data entry field using the data entry device 2310. After the user has entered data into the data entry field, the user may cause the GUI portion to input the user-entered information to the computer system 2300 using the pointing device 2320 to select a corresponding display icon or command button.
Thus, a client terminal (e.g., 2010a ) may send messages and receive data through the network(s) 2315 and the communications interface 2330. In at least one embodiment, a client terminal might transmit a requested code for an application program through the Internet, ISP, and/or the communication interface. In accordance with at least one embodiment, one such downloaded application provides for user interaction with the margin management service application 2040 using the interactive displays or interactive pages described herein. The received code may be executed by the processor 2305 as it is received, and/or stored in a non-volatile storage device for later execution. In this manner, computer system 2300 may obtain an application code in the form of a carrier wave.
The server 2035 may receive commands and data from the client terminals 2010 and output program code and data to the terminals 2010 using the network 2315. In at least one embodiment, the server 2035 may generate and transmit the requested data to the requesting user via HTML formatted or XML formatted pages, which may be provided as World Wide Web pages, using the network 2315. The network 2315 may be, for example, a network of interconnected networks such as the Internet, a LAN, a WAN, an intranet including any of these, and/or a PSTN. The communications interface 2330 may further include a web browser or thin client. A thin client is a client portion of an application designed to require little memory so that the bulk of the data processing occurs on a corresponding server. In at least one embodiment, a thin client may be Java-based. The web browser may be configured to display data and communicate with other computers via a network such as, for example, the Internet or an intranet. The web browser may provide a user with a way to navigate, via, for example, hyperlinks, which may be selected by the pointing device (such as a computer mouse), or as typed in by the user. The web browser uses a protocol such as, for example, HTTP or FTP, to transmit data of various content such as, for example, HTML formatted documents, plain text documents, graphic images, and XML documents for output presentation to the user via the display.
While the invention has been described with reference to the certain illustrated embodiments, the words that have been used herein are words of description, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described herein with reference to particular structures, acts, and materials, the invention is not to be limited to the particulars disclosed, but rather can be embodied in a wide variety of forms, some of which may be quite different from those of the disclosed embodiments, and extends to all equivalent structures, acts, and, materials, such as are within the scope of the appended claims.
