A rich user interface to visualize asset prices and define trading parameters

Abstract

Various user interfaces are disclosed. A polling user interface allows a user to forecast asset prices. A price forecast user interface overlays historical price data for an asset with an indication of a corresponding distribution of price forecasts for that asset (e.g., provided by a user via the polling user interface). A derivative definition user interface allows a user to define parameters for a derivative transaction associated with one or more assets. The derivative definition user interface also allows a user to request execution of a transaction (e.g., sending trade parameters to a trading platform). An order placement user interface allows a user to define and place orders for derivatives. The order placement user interface may also provide intra-trade updates regarding the processing of an order (e.g., notifications of executed fills, price action, etc.).

Description

[Technical field]

[0001] The described subject matter relates generally to user interfaces, and more particularly to information-dense user interfaces that use multiple scenario-based calculations to visualize asset pricing data as well as monitor and define transaction parameters. [Background technology]

[0002] Successfully predicting how the price of a particular asset will change over time can be highly profitable. Conversely, traders who rely on inaccurate predictions of asset prices may lose all or a significant percentage of their investment. However, the prices of many assets depend on many factors, and the accuracy and reliability of predictions vary widely. While some existing systems provide traders with access to price predictions, simply displaying the predictions makes it difficult to evaluate the predictions or understand the historical context of those predictions.

[0003] Understanding the potential outcomes of taking derivatives on an asset is perhaps an even more complex problem. Derivatives can be defined by multiple parameters, such as put price, spot price, upper knockout price and corresponding time frame (e.g., start and end time), lower knockout price and corresponding time frame (e.g., start and end time), strike price, expiry time, etc. The specific values ​​of these parameters result in a world of potential profit and loss scenarios, as well as the price of the derivative. Existing systems make it very difficult for traders to understand the world of scenarios or to place those scenarios in a historical context. Typically, the relevant information, if available, is scattered across multiple spreadsheets, applications, and databases, which traders must switch between and interpret to understand the risk-reward balance of a derivative transaction. Thus, using such systems effectively requires a lot of skill and experience (hence training time), and even when used effectively, there is a high tendency for human error resulting from traders not correctly drawing correlations between different data in a spreadsheet.

[0004] Thus, to use such systems effectively, a lot of skill and experience (hence training time) is required, and even when used effectively, there is a high tendency for human error resulting from traders not correctly drawing correlations between different data in the spreadsheets. This further highlights the problems with the existing system. Navigating large data sets in multiple spreadsheets on a single small screen can frustrate traders and also increases the risk that important correlations will be missed. These small screens also impose limitations on the user interface, due to the limited amount of screen space available for presenting information and user controls. Summary of the Invention

[0005] These and other problems may be addressed by a computing system having an information-dense user interface. In various embodiments, the user interface includes a historical data portion and a parameter definition portion. The historical data portion visualizes historical data related to prices of one or more assets, while the parameter definition portion allows a user to define parameters of derivatives of the one or more assets. The historical data portion, the parameter definition portion, or both may include one or more overlays / underlays that provide additional information about the assets or the defined derivatives. Thus, the user interface can simultaneously present a large amount of information on a single (potentially small) screen, allowing a user to quickly and intuitively understand the context of the derivatives and the potential impact of parameter changes on the derivatives.

[0006] In some embodiments, the user interface includes controls in a pre-trade view that allow a user to place orders against defined assets or derivatives. The orders may be sent to a trading platform to be filled. During filling, the user interface may transition to an intra-trade view that displays substantially real-time information regarding the filling of the submitted order. For example, as the order progresses, information (e.g., visual indicators) describing executed fills and price actions can be added to the user interface. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates a block diagram of a networked computing environment suitable for providing a trading application having an information-dense user interface according to one embodiment. [Diagram 2] FIG. 2 is a block diagram of the analysis server shown in FIG. 1 according to one embodiment. [Diagram 3]2 is a block diagram of one of the client devices shown in FIG. 1 according to one embodiment. [Figure 4A] 1 illustrates a first embodiment of an information-dense user interface that overlays a distribution of an asset's historical price data and price forecasts provided by other users. [Figure 4B] 1 illustrates a second embodiment of an information-dense user interface that overlays historical price data and price forecast distributions for an asset. [Figure 4C] 1 illustrates a first portion of an exemplary information-dense user interface that allows a user to enter a price prediction according to one embodiment. [Figure 4D] 4D illustrates a second portion of the exemplary information-dense user interface of FIG. 4C according to one embodiment. [Figure 5A] 1 illustrates an example of an information-dense user interface used to set parameters for a vanilla put trade, according to one embodiment. [Figure 5B] 1 illustrates an information-dense user interface used to set parameters for a callspread trade according to one embodiment. [Figure 5C] 1 illustrates an information-dense user interface used to set parameters for a 1x2x1 call fly trade, according to one embodiment. [Figure 5D] 1 illustrates an information-dense user interface used to set parameters for a call reverse knock-out (RKO) transaction, according to one embodiment. [Figure 5E] 1 illustrates an information-dense user interface used to set parameters for a call window knock-out (WKO) trade, according to one embodiment. [Figure 5F] 1 illustrates an information-dense user interface used to set parameters for a trade using multiple underlying assets, according to one embodiment. [Figure 6A]1 illustrates a smartphone version of an information-dense user interface including outlines showing possible outcomes of a put trade, according to one embodiment. [Figure 6B] 1 illustrates a smartphone version of an information-dense user interface with outlines showing possible outcomes of a put spread trade, according to one embodiment. [Figure 6C] 1 illustrates a smartphone version of an information-dense user interface with outlines showing possible outcomes of a WKO transaction, according to one embodiment. [Figure 7A] 1 illustrates an information-dense user interface for placing derivative orders prior to placing the order, according to one embodiment. [Figure 7B] 7B illustrates customizing the information-dense user interface of FIG. 7A using pop-up menus according to one embodiment. [Figure 7C] FIG. 7B illustrates the information-dense user interface of FIG. 7A after an order has been placed, according to one embodiment. [Figure 8] FIG. 5B illustrates a portion of a spreadsheet containing some of the data shown in the information-dense user interface of FIGS. 5A through 7C. [Figure 9] 1 is a flow chart of a method for generating an information-dense user interface that overlays a price forecast distribution on an asset's historical price data, according to one embodiment. [Figure 10] 1 is a flowchart of a method for updating parameters of a trade using an information-dense user interface according to one embodiment. [Figure 11] 1 is a flowchart of a method for placing one or more orders to execute derivatives and receiving intra-trade updates regarding the progress of the orders using an information dense user interface according to one embodiment. [Figure 12] 2 is a block diagram of an exemplary computer suitable for use in the networked computing environment of FIG. 1 according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The figures and the following description describe specific embodiments for purposes of illustration only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described. Wherever practicable, similar or similar reference numbers are used in the figures to indicate similar or similar functionality. When elements share a common numeral followed by another letter, this indicates that the elements are similar or similar. Unless the context dictates otherwise, reference to a numeral alone generally refers to any one or any combination of such elements.

[0009] Example System 1 illustrates one embodiment of a networked computing environment 100 suitable for providing a trading app with an information-dense user interface. In the illustrated embodiment, networked computing environment 100 includes an analytical server 110, a market data data store 130, one or more client devices 140A, 140B, ..., 140N, and a trading platform 150, all connected via a network 170. In other embodiments, networked computing environment 100 includes different and / or additional elements. Furthermore, functionality may be distributed among the elements in ways different from that illustrated.

[0010] The analytical server 110 includes one or more computing devices that analyze market data to obtain metrics that drive an information-dense user interface. In one embodiment, the metrics used by the analytical server 110 include historical price data for one or more assets over one or more time periods. For example, the analytical server 110 may obtain the minimum, maximum, opening and closing prices of the assets for each day, week or other time period over a region of interest (e.g., last month, last six months, last year, last five years, etc.). Other metrics of interest, such as median or average prices during each time period, may be calculated. The analytical server 110 may also periodically poll a set of users (e.g., traders or financial analysts) for forecasts of prices of at least some of the assets for future periods (e.g., the next day or next week) and aggregate the forecasts for display in the user interface. Additionally, the analytical server 110 may pre-calculate pricing for one or more derivatives using a variety of different parameters to allow users to obtain desired derivatives. The pre-computation may include determining prices for multiple financial instruments and calculating various statistical measures for each instrument under different scenarios (e.g., payout ratios, evolution of sensitivities / Greeks, etc.). In one embodiment, analytical server 110 calculates pricing and statistical measures using a set of parameter values ​​and uses interpolation routines to provide pricing and statistical measures that have a higher information density than those calculated directly from the parameter values ​​in substantially real-time. Various embodiments of analytical server 110 are described in more detail below with reference to FIG. 2.

[0011] The market data datastore 130 includes one or more computer-readable media that store market data, including asset prices. While the market data datastore 130 is shown as a separate entity, the market data datastore may be part of the analytical server 110. Additionally, while the market data datastore 130 is shown as a single entity, the described functionality may be provided by multiple devices operating together (e.g., as a distributed database). In one embodiment, the market data includes information about each trade that occurs on one or more exchanges involving one or more assets tracked by the analytical server 110. The information about the trade may include the asset or assets traded, the price, a timestamp indicating when the trade occurred, and derived data such as volatility surfaces and discount curves. The information about the trade may include additional data such as an identifier for the buyer, an identifier for the seller, an identifier for the trading platform or exchange on which the trade occurred. The market data datastore 130 may receive market data (e.g., from an exchange or a computing system of the trading platform 150) in periodic batches (e.g., hourly or daily). Additionally or alternatively, the market data may be received in one or more continuous or semi-continuous data streams.

[0012] The client device 140 may be any computing device configured to interact with the analytical server 110. Although FIG. 1 shows three client devices 140 (a first client device 140A, a second client device 140B, and an Nth client device 140N), the networked computing environment may include any number of such devices. The client device 140 presents one or more user interfaces for displaying information about the assets generated by the analytical server 110. In various embodiments, the client device 140 provides one or more of a polling user interface, a price forecast distribution user interface, a derivative definition user interface, or an order placement user interface.

[0013] The polling user interface is provided to client devices associated with a subset of users designated to forecast asset prices and prompts those users to forecast one or more asset prices for a future period (e.g., the next day or the next week). The price forecast user interface displays historical price data for an asset overlaid with a display of a corresponding distribution of price forecasts for the asset (e.g., as provided by a user via the polling user interface). The derivative definition user interface allows a user to define parameters of a derivative transaction associated with one or more assets. The derivative definition user interface may also allow a user to request execution of a transaction (e.g., by sending transaction parameters to trading platform 150). Alternatively, the order placement user interface may allow a user to define and place an order for a derivative. The order placement user interface may also provide intra-trade updates regarding the processing of an order (e.g., notifications of executed fills and price actions). Various embodiments of client devices 140 and user interfaces are described in more detail below with reference to Figures 3 through 7C.

[0014] Trading platform 150 includes one or more computing devices that receive trade parameters (e.g., directly from client device 140 or via analytical server 110) to execute a defined trade. For example, a trader can use a user interface displayed on client device 140 to define parameters, such as an EURUSD put, RKO, or WKO, and use controls in the user interface to request that the trade be executed. Trading platform 150 can receive the request (including the defined parameters) from client device 140 and retrieve the requested derivatives. The trading platform can provide updates to client device 140 or analytical server 110 indicating progress or other metadata regarding order status (e.g., notifications of executed fills, time limits, and price action).

[0015] Network 170 provides a communication channel through which other elements of networked computing environment 100 communicate. Network 170 may include any combination of local area and / or wide area networks using wired and / or wireless communication systems. In one embodiment, network 170 uses standard communication technologies and / or protocols. For example, network 170 may include communication links using technologies such as Ethernet, 802.11, Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of network protocols used to communicate over network 170 include multiprotocol label switching (MPLS), transmission control protocol / Internet protocol (TCP / IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over network 170 may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, some or all of the communication links of network 170 may be encrypted using one or more any suitable techniques.

[0016] 2 illustrates one embodiment of an analytical server 110. In the embodiment shown, the analytical server 110 includes an ingestion module 210, a polling module 220, a trade interface module 230, a pricing module 240, an implementation module 250, and an analytical data store 260. In other embodiments, the analytical server 110 includes different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different from that illustrated.

[0017] The ingestion module 210 retrieves data for one or more assets (e.g., from the market data datastore 130). The ingestion module 210 may retrieve raw asset price data, metrics calculated from the raw price data (e.g., maximum price, minimum price, opening price, and closing price), or both. If raw price data is retrieved, the ingestion module 210 may calculate some or all of the metrics. Additionally, the ingestion module 210 may create additional secondary metrics using metrics retrieved from external sources. For example, if the ingestion module 210 retrieves daily average prices from the market data datastore 130, the ingestion module 210 may calculate weekly and monthly average prices from the daily average prices. The ingestion module 210 may store a local copy of the retrieved data and any calculated metrics (e.g., in the analytical data store 260).

[0018] The polling module 220 generates a user interface that overlays historical price data of the asset with the price forecast distribution. In various embodiments, the polling module 220 periodically receives forecasts of the price of one or more assets in a future time period. For example, the polling module 220 can identify a set of client devices 140 belonging to users designated to provide forecasts of the price of one or more assets of interest. The same user may be prompted to provide forecasts for all of the assets of interest, or different users may be prompted for different assets. Users may be motivated to provide forecasts using gamification techniques, such as providing a leaderboard of users who provided the most accurate forecasts for a previous time period or multiple previous time periods (e.g., more recent time periods are weighted more than more recent time periods). Additionally, in some embodiments, the contribution of user-provided forecasts to the price forecast distribution may be weighted based on the accuracy of their previous forecasts.

[0019] In one embodiment, the polling module 220 sends a request to the client devices 140 in the set, which prompt the user to provide a prediction of the price of one or more of the covered assets for a future time period. The user can use various user interfaces and approaches to input the prediction. In one embodiment, the user is prompted to submit his prediction within an app running on the client device, and a corresponding interface for inputting the prediction is provided. For example, the user can input price estimates for the set of assets by placing a corresponding set of sliders in a window or entering them into a form. Alternatively, the polling module 220 can send the request via other channels, such as email or instant messenger. The user can be shown a chart showing the price of the asset in a previous time period (e.g., a candlestick chart showing the daily or weekly minimum, maximum, opening, and closing prices of the asset for the last week, last month, last six months, or last year, etc.) to help estimate the price for the future time period. In another embodiment, software running on the client device 140 prompts users to provide predictions, and the polling module 220 passively receives the submitted predictions.

[0020] Regardless of how the forecasts for an asset are obtained, the polling module 220 aggregates the forecasts to generate a distribution of expected prices for the asset over a corresponding time period. In one embodiment, the polling module 220 determines user interface data from the distribution of expected prices and historical device data. The user interface data can be provided to one or more client devices 140 to drive a price forecast user interface. Figures 4A-4C show example price forecast user interfaces that can be driven by data generated by the polling module 220.

[0021] In the embodiment shown in FIG. 4A, the price forecast user interface displays historical price metrics in a candlestick chart showing minimum, maximum, opening, and closing prices for a series of time periods. Other approaches to displaying historical price metrics may be used, such as line graphs, mouse-over or click-triggered popups, and overlays / underlays. The user may select the time range for which price metrics are displayed, and the time period may be dynamically adjusted accordingly. For example, if the time range is one month or less, daily price metrics may be displayed, if the time range displayed is between one month and one year, weekly price metrics may be displayed, and if the time range is more than one year, monthly price metrics may be displayed. The user may select the time range using any suitable user interface, such as single or multi-touch inputs to a graphical user interface (GUI) on a touch screen of the client device 140. The visual aspects of the candlestick (in the case of FIG. 4A, whether the body of the candlestick is filled with black or white) may indicate whether the price has risen or fallen during that period. In other embodiments, the historical metrics are displayed in different formats, such as line graphs with various interpolation schemes.

[0022] The historical distribution of price predictions can be represented in the user interface as an underlay or overlay. In FIG. 4A, the distribution is shown by the intensity of shading at different prices for each week. For the week starting September 17, the majority of users thought that the price would remain range-bound, and indeed it did remain range-bound (as shown by the strong shading around the actual price of the asset for that week). The following week, the majority of users thought that the price would stay roughly the same or go up a bit, but the price actually fell significantly. For the week starting October 1, the majority of users thought that the price would bounce back, but it did not. The following week, users were roughly evenly split on whether the price would fall further or bounce back. Actual price data for this week is not yet available, so it is not shown on the chart. Thus, the chart provides users with insight into how the price is changing, what other users think is likely to happen, and the accuracy of user predictions for the asset recently, all of which can help inform the choice of whether to buy or sell the asset during the current period. In some embodiments, users may be able to drill down into the price forecast distribution to gain additional insight (e.g., to see whether users who predict that prices will rebound have been historically more or less accurate than users who predict that prices will fall further).

[0023] To the right of the historical price data, user-submitted predictions of prices for the coming weekend may be displayed. Predictions may be generated algorithmically using price functions, previously submitted user predictions, or a combination of both. In the embodiment shown in FIG. 4A, the probability that the price will be in each of a series of ranges at the end of the current period (e.g., this week) is indicated by the shading intensity of the box next to the corresponding price on the y-axis. For example, the darkest colored box may indicate the most highly predicted price, while a lighter colored box may indicate a lower likelihood value. The box may also include a numerical value (e.g., a percentage) of the likelihood that the price will be the corresponding value at the end of the current period.

[0024] FIG. 4B shows an alternative embodiment of a price prediction user interface. In addition to the information displayed by the user interface shown in FIG. 4A, this embodiment also includes a display of predictions made by other users. The box immediately adjacent to the y-axis scale on the right indicates the probability of the price at the end of the current time period, similar to the boxes and numbers on the right of FIG. 4A. Inside the boxes showing the various price possibilities is a second set of boxes showing predictions of other users. These boxes can use shading, numbers, or both to indicate the number of other users who made the respective predictions (e.g., the numbers can indicate the percentage of users who selected the value or the raw numbers, and the shading can be darker for popular choices and less intense for unpopular choices).

[0025] 4C and 4D show a first and second portion of an exemplary price prediction user interface that includes information about a price prediction and a user's historical accuracy in making predictions. In the example shown in FIG. 4C, the price prediction user interface of FIG. 4B is shown on the left, providing the user with information about the asset's past prices and a current prediction of the price at the end of the current period (e.g., week). The price prediction user interface includes a chart of the user's "kudos," which is a score indicating how accurate the user's previous predictions were (e.g., higher kudos correspond to more accurate historical predictions and vice versa). In FIG. 4D, which may be displayed in conjunction with (e.g., below) some or all of the elements shown in FIG. 4C, the user is shown bars corresponding to a set of assets and the user's past performance in predicting prices for those assets. In one embodiment, the user can select a particular asset by clicking on the bar corresponding to that asset, and the user interface shown in FIG. 4C is updated to provide information about the selected asset.

[0026] Referring back to Figure 2, trading interface module 230 generates data to drive a user interface through which a user can define derivatives. Although several specific examples are described, the user interface is generally applicable to a wide range of derivatives and can be adapted to any type of derivative without departing from the disclosed principles. In one embodiment, trading interface module 230 receives an indication of the type of derivative a user wishes to define from client device 140 and generates / obtains data to drive the user interface.

[0027] In various embodiments, the user interface includes two portions: a historical data portion and a parameter definition portion. The historical data portion is similar to the user interface generated by the polling module 220 and shows the prices of the assets underlying the derivatives for a set of past periods (e.g., using candlestick charts). To drive this interface, the trading interface module 230 retrieves (e.g., from the analytical data store 260) price data for one or more assets underlying the type of derivative being defined. The parameter definition portion provides information about the currently defined derivative and provides controls that allow the user to modify one or more parameters of the derivative and see the effects of the modifications almost immediately. The trading interface module 230 can assign default values ​​to all parameters associated with a derivative of a selected type. The default parameters may be either global defaults (selected for all derivatives of that type), user defaults (default values ​​selected by or for the user defining the derivative), the most recent parameters used for derivatives of the same type, or parameters selected using any other suitable technique. For example, in one embodiment, some or all of the default parameters may be selected by a machine learning model (e.g., a neural network) trained to predict likely parameters given the user's profile, the user's past parameter selections, current market conditions, possible or actual results implied by the market, or any combination of the foregoing or other relevant factors. Alternatively, some or all of the initial parameter values ​​may be specified in a request received from the client device 140. For example, a user may specify the parameters using natural language input that is processed by a natural language processing engine on the client device 140 or the analytics server 110 to extract the parameters.

[0028] The trading interface module 230 passes an indication of the type of derivative and the initial parameters to the pricing module 240, which uses the initial parameters to calculate the price of the derivative. The pricing module 240 may also pre-calculate the price of the derivative using possible alternative values ​​of the parameters. What are considered possible alternative values ​​of the parameters may be determined by a set of rules, machine learning models, or a combination of both. For example, a rule may predict that the expiration of a derivative is likely to be an integer number of weeks from the current date, but unlikely to be 11 or 13 days from the current date, and therefore the pricing module 240 calculates a price for the derivative with an expiration of 1 week, 2 weeks, 3 weeks, etc. from the current date. Similarly, a machine learning model may be used to predict the parameter values ​​that a user is likely to select, given the user's past selections, the type of derivative, and current market conditions. In some embodiments, the pricing module 240 also calculates one or more other metrics of the derivative, such as delta, vega, gamma, and theta values, and provides the ability to resolve terms via mechanisms such as zero-cost structures.

[0029] The trading interface module 230 receives the prices generated by the pricing module 240 and provides them to the client device 140 along with other data used to drive the user interface (e.g., historical price data for the underlying assets, any default values ​​selected for the parameters, etc.). When the user interacts with the user interface to modify the value of one or more parameters, the client device 140 can provide the updated values ​​to the trading interface module 230. If the user selects a parameter value for which a price has not yet been calculated, the trading interface module 230 can provide the updated parameter value to the pricing module 240, which calculates and provides to the client device 140 a price for the derivative using the updated parameters. While the updated price is being calculated, the user interface can display an estimated price or price range (e.g., using linear extrapolation from parameter values ​​for which prices have already been calculated) and can provide an indication to the user that the currently displayed price is an estimated price. Similarly, the pricing module 240 can predict new parameter values ​​that the user is likely to select based on the updated parameter values. For example, if a user is gradually changing the expiration date to a later date, the pricing module 240 may proactively calculate a price for a later expiration date than was originally calculated.

[0030] The implementation module 250 interacts with the trading platform 150 to implement the defined derivative. In one embodiment, an order placement user interface is displayed on the client device 140. The implementation module 250 may provide a user interface having portions that are the same as or similar to the user interface provided by the trading interface module 230 to allow a user to define a desired derivative. In response to a user selection of a control (or controls) requesting implementation of the desired derivative, the implementation module 250 transmits instructions to the trading platform to place one or more orders to implement the desired derivative. In some embodiments, once implementation of the derivative is initiated, the order placement user interface may transition to an intra-trade configuration in which the progress of the one or more orders is displayed in substantially real-time.

[0031] Various embodiments of client device 140 and user interfaces are described in more detail below with reference to Figures 3 and 5A-7C.

[0032] In various embodiments, once the derivative parameters are set to the user's satisfaction, the user may obtain the derivative by selecting a control in a user interface to make a request directly to trading platform 150 or by sending a request to trading interface module 230, which in turn sends a request to trading platform 150. In some embodiments, trading interface module 230 may provide a notification to the user (e.g., via push notification, email, instant message, or the like) if certain criteria related to the derivative are met. For example, in an RKO or WKO derivative, if the current price is within a pre-specified threshold of the knock-out value, the user may be notified and may decide to exit immediately at a loss or hold on, risking even greater losses in exchange for the possibility that the price will not reach the knock-out price before the window expires. As another example, the user may be notified if the current price exceeds a pre-specified curve, such as 3 or 4 times the initial investment amount, so the user may decide whether to immediately exercise the option and make a sizable profit, or to wait and gamble for even greater profits.

[0033] The analytical data store 260 includes one or more computer-readable media that store data used by the analytical server 110. For example, the analytical data store 260 may include copies of historical price data, price forecasts, and derivative prices used to drive the various user interfaces provided by the analytical server 110. The analytical data store 260 may also include other data used by the analytical server 110, such as user profile data indicating user preferences (e.g., default parameters), historical data regarding derivatives defined by the user, one or more derivatives for which the user has been designated to provide price forecasts, etc. Although the analytical data store 260 is shown as a single entity within the analytical server 110, this functionality may be provided by multiple data stores, some or all of which may be physically separate from the analytical server 110 and accessed via the network 170.

[0034] 3 illustrates one embodiment of a client device 140 that may be used to interact with the analytical server 110. In the embodiment shown, the client device includes a trading app 310 and a local data store 320. In other embodiments, the client device 140 includes different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different from that illustrated.

[0035] The trading app 310 is software that executes on the client device 140 to enable interaction with the analytical server 110. The trading app 310 may include a communication module 312 and a rendering engine 314. The trading app 310 may include a communication module 312 and a rendering engine 314. The rendering engine 314 allows the client device 140 to display various user interfaces driven by data provided by the analytical server 110 and to determine whether additional data is needed to service a user request. The rendering engine 314 may interact with or be executed by one or more graphics processing units (GPUs) to generate the user interfaces. The local data store 320 includes one or more computer-readable media that store data used by the client device 140. For example, the local data store 320 may include cached copies of historical price data and derivatives price data received from the analytical server 110.

[0036] In various embodiments, a user can open the trading app 310 and select a user interface to launch from a menu. For example, a user can launch a polling user interface to provide a forecast of future prices for any asset for which the user has been designated to provide such forecasts. As another example, a user can launch a price forecast distribution user interface to select an asset and view historical price data and a price forecast distribution (such as the exemplary user interface shown in FIG. 4). As a further example, a user can launch a derivative definition user interface to explore derivative options and, if desired, obtain a derivative with selected parameters.

[0037] In one embodiment, a user initiates the derivative definition user interface by selecting a type of derivative to define, such as by selecting from a drop-down list (e.g., a list of favorites or recently defined derivative types) or by entering a possible partial definition of the type of derivative in a text box. In the latter case, natural language processing can be used to identify the type of derivative the user wants to define. Assuming that the relevant data is not already available at the client device 140 (e.g., not cached in the local data store 320), the communication module 312 sends a request to the analytic server 110 to identify one or more underlying assets and the type of derivative. The derivative pricing module 240 initially provides historical price data for one or more underlying assets, pricing data for the derivative using a default parameter set, and, optionally, pricing data for one or more additional parameter sets that are likely to be selected by the user. Additionally, the pricing module 240 can continue to generate and provide pricing data for the additional parameter sets to the communication module 312.

[0038] The rendering engine 314 causes the client device 140 to display the selected user interface. In the case of a derivatives definition user interface, instead of the pricing module 240 of the analytic server 110 determining the parameter values ​​that a user may select, the rendering engine 314 may make these determinations (using techniques the same or similar to those described above with reference to the pricing module 240 or approximations, such as Taylor expansion or interpolation techniques) and request the associated pricing data from the analytic server 110.

[0039] As previously described, the derivative definition user interface may include a history price portion and a parameter definition portion. The history price portion includes a chart (e.g., a candlestick chart or a line graph) of the historical prices of one or more underlying assets. The history price portion may also include a representation of the price forecast distribution generated by the polling module 220. The history data portion may further include additional overlays / underlays that convey other information, such as the prices of other assets, the occurrence of important events that may affect the price of the asset, or any other information that may be useful to a user to contextualize the historical price data. Examples of information conveyed by the overlays / underlays include the occurrence of important macroeconomic events, such as non-farm payroll releases, interest rate meetings, corporate earnings, or other economic or asset-specific releases; technical indicators, including moving averages, relative strength indexes, trading volumes, activity by customer segments, and the like; and derivative price information, such as market implied probabilities, percentile ranks of prices of at-the-money options, and the like.

[0040] The parameter definition portion provides a visual representation of the current parameter values ​​on a corresponding scale or axis. A user can modify the parameter values ​​by interacting with the corresponding visual representation, for example, by clicking or holding a finger on the representation and dragging it to a different position. The parameter definition portion can also include overlays / underlays that provide various information, such as contour lines representing the rate of return of various asset prices over time, vertical lines (or other indicators) of events expected to affect the price / return rate (e.g., dates when interest rate changes are expected to be announced, etc.), estimated probabilities of asset prices over time, etc. FIGS. 5A-5F illustrate using an exemplary parameter definition user interface to set parameters for various types of derivatives.

[0041] FIG. 5A illustrates the definition of a vanilla put option on the EURUSD currency pair. On the left side, the weekly values ​​of EURUSD for the past six months are shown. On the right side, the first horizontal line indicates the asset spot price (1.179), the second horizontal line indicates the put option's strike price (1.190), and the third horizontal line indicates the break-even price of the structure (1.197). The vertical lines indicate the put option's expiration time. The various lines can be visually distinguished using changes in one or more visual properties, such as color, dashing pattern, and thickness. For example, the put price may be indicated by a solid line of a first color (e.g., green), and the asset spot price may be indicated by a thinner or dashed line of the same or a different color (e.g., gray). The user can change the put price by dragging the corresponding line up or down, and the other parameter values ​​are automatically updated (e.g., the break-even point is automatically recalculated without additional user input, and the corresponding line is moved accordingly).

[0042] In the embodiment shown, the parameter definition portion has an overlay that displays dots for various combinations of price and expiration. The dots vary in various visual attributes, such as color and size. The size of the dots may correspond to each level of vanilla premium. The color of the dots may represent how cheap or expensive the option is compared to past history (e.g., green if the EURUSD 3-month, 1% otms call is in the 5th percentile compared to the past 2 years). Note that in this case, the skew is visible because the dots are larger on one side of the asset's spot or futures price than the other side (if the surface is bid for the call, it will be visually in front).

[0043] FIG. 5B shows a version of the user interface for defining the parameters of an EURUSD call spread. The upper and lower strike prices are represented by a pair of horizontal lines that may be visually distinguished (e.g., displayed in different colors), and the user can move both lines to different positions to change the corresponding values. Similarly, FIG. 5C adds a bit more complexity to represent the call fly, showing three vertical lines that the user can move to set each of the strike prices. As with FIG. 5A, when one of the vertical lines in FIG. 5B or FIG. 5C is moved, the affected parameter value is automatically updated, and the UI is updated accordingly.

[0044] 5D and 5E show versions of the user interface for Call RKO and Call WKO, respectively. Then there are two vertical lines: one that sets the expiry time and one that sets the end of the knockout window. There is also one (RKO) or two (WKO) vertical lines (dashed in this case) that indicate the knockout price. All of these lines can be rearranged to allow the user to adjust the derivative to their liking (affected parameters are updated automatically, as before). These examples provide a particularly powerful example of the power of the user interface. By displaying the historical price data of the underlying asset along with a visual representation of the knockout price and the length of the window, the user can better estimate the likelihood that the asset price will reach one of the knockout prices during the window. Furthermore, the user can continually manage the trade and restructure it if necessary.

[0045] FIG. 5F shows a version of the user interface where there are two underlying assets. The user can change the parameters associated with each underlying asset by repositioning the lines, and the affected parameter values ​​are automatically updated as in the other examples. In this case, the user interface includes an additional portion showing a two-dimensional surface representing the values ​​of both assets, plotting the historical prices of the asset pair moving around the surface, with higher opacity lines indicating more recent price levels. Thus, the user can better estimate the likelihood that the asset price combination is in a profitable area of ​​the surface (in this case, the lower right quadrant) based on the historical price momentum. In some embodiments, the implied probability of the asset price combination having a particular value on the target date can be displayed using an overlay.

[0046] Additional or alternative overlays / underlays can be included in the parameter definition portion of the user interface. For example, pixelated histograms of spot landing probabilities in each individual box (defined by date and spot range), payout ratios, Greeks evolution (e.g., theta decay), market implied probabilities, costs of alternative implementations, open commitments in comparable listed markets, scenario-based profit and loss (PnL) (e.g., stock market rises and falls in spot and volatility), expected events (e.g., dates when interest rate change announcements are scheduled or other events that may affect asset prices), etc. As another example, a payout contour may be overlaid on the parameter definition portion. The contour represents the multiple of the premium over various levels of spot and over time. As the user modifies the parameters, the contours can be automatically recalculated and updated. In one embodiment, contours for possible parameter sets may be pre-calculated (e.g., by the pricing module 240 of the analytic server 110) to reduce delays in the update process.

[0047] 6A-6C show an exemplary user interface displayed by a smartphone including a contour overlay. In FIG. 6A, the user interface is used to define a put. The contours show the relative investment returns if the put is exercised at various times and at various prices of the underlying asset. The contours corresponding to profits may be shown in one color (e.g., green), the contours corresponding to losses may be displayed in a different color (e.g., red), and the break-even contour may be displayed in a third color (e.g., yellow). Thus, the user can quickly and easily estimate the likelihood that the underlying asset will be in a profitable range at some point before expiration, and the degree of risk of loss associated with the put. In this case, it seems unlikely that the user will make a large profit with the put unless he or she expects a significant drop in the price of the underlying asset.

[0048] In FIG. 6B, the user interface is used to define a put spread, where the profitable underlying asset price range is expanded, as indicated by the green outlined area taking up a larger proportion of the user interface, thus allowing the user to intuitively compare put and put spread options.

[0049] In FIG. 6C, the user interface is used to define a call WKO. The contours show that if the user successfully manipulates the window, a win above the strike price at any time could potentially earn a profit many times the original investment. Furthermore, the user can adjust the knockout value or the length of the window, taking into account the displayed historical data, until the user is satisfied that the risk of hitting one of the knockout values ​​is sufficiently low. The user can also instantly see how these adjustments will affect the potential payout if the user successfully manipulates the window, allowing for an intuitive balance of risk and reward.

[0050] In the embodiment shown in Figures 6A-6C, the user interface also includes a lock button that can be used to lock the value of one or more parameters. When a parameter is locked, when the user adjusts the value of another parameter, the values ​​of the remaining unlocked parameters are automatically adjusted without further input from the user to maintain the value of the locked parameter. For example, a user can lock the price at zero for a no-cost collar strategy. When the strike price of one leg moves, the strike price of the other leg is automatically updated to keep the cost at zero.

[0051] 7A-7C show an exemplary order placement user interface. In the embodiment shown, the orders relate to EURUSD derivatives, but it should be understood that the principles shown can be used to define orders for a wide range of derivatives. In FIG. 7A, historical price data for the derivative is shown on the left side of the user interface. On the right side, contours showing the likelihood that the spot price will be in various ranges over time are displayed as overlays. Thus, the user can quickly obtain an intuitive estimate of the risk and reward associated with a trade using different parameters. The order placement user interface includes controls that allow the user to place an order using one or more execution methods (in the case of FIG. 7A, two methods are available: one using a dynamic hybrid algorithm and one using a risk transfer approach). The user can execute one of these methods by clicking or otherwise selecting the corresponding control.

[0052] 7B illustrates that the order placement user interface can be customized to include or omit various overlays and underlays. In the example shown, the user has selected to include both the Depth overlay and the Paid&Givens and Order Book underlays. It should be appreciated that a wide range of underlays and overlays can be defined in a modular manner to present the user with the information available in the user interface.

[0053] FIG. 7C illustrates the transition of the order placement user interface to an intra-trade mode after a user requests execution of a method to implement a defined derivative. As in FIG. 7A, the left side of the user interface displays historical price data for the derivative. The center portion of the user interface is an intra-trade portion that displays how the price has changed since execution was requested, and includes a visual indication of the executed execution and price action. The visual indication may be a geometric shape (e.g., a triangle) positioned at a position on the x-axis corresponding to the time the action occurred and at a position on the y-axis corresponding to the price at which the action was executed. The right side of the user interface continues to display projected / estimated probabilities of various values ​​of the derivative in the future, similar to FIG. 7A.

[0054] FIG. 8 illustrates the advantages of the user interface of FIGS. 5A-7C over conventional approaches. FIG. 8 illustrates a portion of a spreadsheet interface showing parameters for WKO and vanilla put options. The interface includes basic information such as strike and spot prices, option expiry, and knockout window value and expiry. However, it completely lacks the contextual information of historical price data, the additional information provided by various underlays and overlays, or the ability to intuitively visualize how various values ​​relate to each other. Furthermore, in contrast to the user interfaces of FIGS. 5A-7C, which can be comfortably displayed on a smartphone screen, the information cannot be comfortably displayed on a normal computer monitor without the need for scroll bars. In short, the disclosed user interface is a significant improvement over conventional systems by allowing a much larger amount of information to be intuitively displayed in a small amount of screen real estate.

[0055] Exemplary Methods FIG. 9 illustrates a method 900 for generating an information-dense user interface having historical price data for an asset overlaid with a price forecast distribution, according to one embodiment. The steps of FIG. 9 are illustrated from the perspective of the analytic server 110 performing the method 900; however, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform steps in parallel, in a different order, or perform different steps.

[0056] In the embodiment shown, method 900 begins with analytic server 110 retrieving (910) historical data for an asset. The historical data includes price data for the asset over a period of time, such as one month, six months, or one year. The time range is divided into multiple periods, such as days, weeks, or months. The historical data may include the maximum, minimum, start, and end prices of the asset for some or all of the periods in the time range. Alternatively, the historical data may be raw prices, and analytic server 110 may divide the historical data into buckets corresponding to predetermined periods and calculate the maximum, minimum, start, and end prices for each period.

[0057] The analytic server 110 retrieves (920) historical performance forecasts for the asset. The performance forecasts include forecasts of the asset's price for periods prior to those periods that the user made. The analytic server 110 also polls (930) the user for forecasts of the asset's future performance. The analytic server generates (940) a user interface that overlays the historical data with an indication of the distribution of past forecasts (e.g., in a candlestick plot as shown in FIGS. 4A-4C). The user interface may also show a probability distribution of future prices, a credit value for the user for correctly predicting future values, a credit value that may be lost if the user predicts incorrectly, a distribution of predictions made by other users, or any other combination of information useful to the user. The analytic server 110 provides (950) the user interface for display (e.g., at the client device 140). Thus, the user can compare the historical forecasts with the corresponding historical prices and evaluate how reliable the forecasts of future performance are.

[0058] Figure 10 illustrates a method (1000) for updating parameters of a trade using an information dense user interface, according to one embodiment. The steps of Figure 10 are illustrated from the perspective of an analytical server 110 performing the method 1000. However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform steps in parallel, in a different order, or perform different steps.

[0059] In the illustrated embodiment, the method 1000 begins with the analytic server 110 receiving (1010) an indication of a user input selecting a type of derivative to be defined. The user may select the type of derivative using the client device 140 which provides the selection to the analytic server 110 over the network 170. The analytic server 110 retrieves (1020) pre-calculated price data for the type of derivative. The pre-calculated price data may be data for the selected type of derivative with default parameters. The default parameters may be hard-coded, provided as preferences by the user, parameters previously used by the user for the same type of derivative, or may be determined using a model (e.g., a machine learning model) based on current market conditions, information about the user, or both. The analytic server 110 may periodically (e.g., hourly, daily, etc.) calculate prices for one or more types of derivatives with default parameters. In some embodiments, the analytic server 110 may calculate the terms and prices of the derivatives on the fly to resolve any parameters that have not been entered. For example, if the user does not enter a strike price, analytical server 110 may calculate the at-the-money strike price and the price accordingly. Analytic server 110 may also query or calculate all associated price data, such as price, sensitivity, contour information, etc.

[0060] The analytical server 110 provides a user interface for displaying (1030) using the pre-calculated price data. The user interface may include a visual representation of default parameters and prices determined from the price data (e.g., as shown in Figures 5A-6C). The analytical server 110 receives (1040) an indication of a user input updating one or more of the parameters of the derivative. For example, a user may move a line indicating a price or expiration in a user interface on the client device 140, and the client device 140 may send the updated parameter values ​​to the analytical server 110.

[0061] The analytical server 110 determines whether there is already pre-calculated price data for the derivatives with the updated parameters. If there is not, the analytical server 110 calculates (1050) additional price data using the updated parameters. The analytical server 110 provides (1060) an updated user interface for displaying the updated derivative prices. Alternatively, the analytical server 110 may proactively provide the client device 140 with additional pre-calculated price data for parameter values ​​that the user is likely to select. Thus, the client device 140 may not request additional pricing information when the user updates one or more parameters because the associated pricing data may already be available at the client device 140.

[0062] This process can be repeated, with the user continuing to update the parameters and receiving updated price data. Once the user is satisfied with the derivative parameters, the user may request to acquire the defined derivative (e.g., by selecting a button in a user interface) (1070). Analytical server 110 receives an indication of the user's intent to acquire the derivative from client device 140 and acquires (1070) the derivative (e.g., by placing an order with trading platform 150). Alternatively, client device 140 may place an order for the derivative directly with trading platform 150.

[0063] FIG. 11 illustrates a method 1100 for placing one or more orders to implement derivatives using an information dense user interface and receiving intra-trade updates regarding the progress of the orders, according to one embodiment. The steps of FIG. 11 are illustrated from the perspective of an analytical server 110 performing the method 1100. However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform steps in parallel, in a different order, or different steps.

[0064] In the illustrated embodiment, method 1100 begins with analytical server 110 receiving (1110) an indication of a type of derivative and corresponding parameters. For example, a user may define a desired derivative and obtain price data for the desired derivative using an approach similar to that described with reference to Figure 10. Prices for the derivatives may be displayed (1120) in a user interface.

[0065] The analytical server 110 receives user input selecting an execution method (1130). For example, the user may click or otherwise select a button to implement the desired execution method. As shown in FIG. 7A, the user interface may include buttons (or other controls) for selecting among multiple possible execution methods. Upon selection of an execution method, the analytical server 110 sends instructions to the trading platform 150 to implement the selected execution method by placing one or more orders (1140). The user interface may be updated to display the status of the submitted order (1150) (e.g., as shown in FIG. 7C, visual indicators of executed execution and price action of the submitted order may be displayed in the user interface). Once the order is completed, the user interface may be updated accordingly to indicate that the derivative has been executed and to update the user on any resulting profits or losses.

[0066] Computing System Architecture 12 is a block diagram of an exemplary computer 1200 suitable for use as an analytical server 110, a client device 140, or a trading platform 150, or the like. The exemplary computer 1200 includes at least one processor 1202 coupled to a chipset 1204. The chipset 1204 includes a memory controller hub 1220 and an input / output (I / O) controller hub 1222. The memory 1206 and the graphics adapter 1212 are coupled to the memory controller hub 1220, and the display 1218 is coupled to the graphics adapter 1212. The storage device 1208, the keyboard 1210, the pointing device 1214, and the network adapter 1216 are coupled to the I / O controller hub 1222. Other embodiments of the computer 1200 have different architectures.

[0067] In the embodiment shown in Figure 12, storage device 1208 is a non-transitory computer-readable storage medium such as a hard drive, a compact disc read only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 1206 holds instructions and data used by processor 1202. Pointing device 1214 may be a mouse, a trackball, a touch screen, or other type of pointing device, and may be used in combination with keyboard 1210 (which may be an on-screen keyboard) to input data into computer system 1200. Graphics adapter 1212 displays images and other information on display 1218. Network adapter 1216 couples computer system 1200 to one or more computer networks, such as network 170.

[0068] The types of computers used by the entities of Figures 1-3 may vary depending on the embodiment and the processing power required by the entities. For example, market data datastore 130 may include multiple blade servers working together to provide the described functionality. Additionally, the computers may lack some of the components discussed above, such as keyboard 1210, graphics adapter 1212, and display 1218.

[0069] Additional Considerations The above description focuses on the technical details of an information dense user interface for efficiently presenting various information to a user. It does not focus on or represent how particular embodiments may be implemented in compliance with relevant regulatory requirements. Particular embodiments take into account and comply with relevant financial and other regulations of the jurisdictions in which the user interface is used.

[0070] Some portions of the above description describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. While these operations have been described functionally, computationally, or logically, they will be understood to be performed by computer programs that include instructions for execution by a processor or equivalent electrical circuitry, microcode, or the like. Moreover, without loss of generality, it is sometimes convenient to refer to these arrangements of functional operations as modules.

[0071] As used herein, a reference to "one embodiment" or "embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. In various places in this specification, the appearance of the phrase "in one embodiment" does not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is done merely for convenience. This description should be understood to mean that one or more of the element or component are present, unless it is clear that something else is meant.

[0072] When values ​​are described as "about" or "substantially" (or derivatives thereof), such values ​​should be interpreted with an accuracy of + / - 10%, unless a different meaning is clear from the context. From the example, "about 10" should be understood to mean "in the range of 9 to 11".

[0073] As used herein, the terms "comprises," "comprises," "includes," "including," "has," "having," or any other variations thereof are intended to include a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive "or" and not an exclusive "or." For example, a condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0074] Upon reading this disclosure, those skilled in the art will recognize additional alternative structural and functional designs of systems and processes for providing information-dense user interfaces. Thus, while specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise structures and components disclosed. The scope of protection should be limited only by the scope of the following claims.

Claims

1. 1. A method for defining parameters of a derivative in an information dense user interface, comprising: providing a display of the information-dense user interface, the information-dense user interface including a historical data portion and a parameter definition portion, the historical data portion representing historical price data for the derivative, the parameter definition portion including a visual representation of the parameters of the derivative arranged to indicate default values ​​for the parameters of the derivative, the parameter definition portion further including an overlay or underlay including contours, each contour indicating a corresponding rate of return in relation to a premium for the derivative on a vertical axis against time on a horizontal axis; receiving a user input that moves a first one of the visual representations corresponding to a first one of the parameters from an initial position to an updated position, the initial position indicating a default value of the first parameter and the updated position indicating an updated value of the first parameter; using the updated value of the first parameter to determine updated values ​​of one or more additional parameters of the derivative, wherein determining the updated values ​​includes: obtaining pre-calculated values ​​of the one or more additional parameters relative to an expected value of the first parameter; interpolating updated values ​​of the one or more additional parameters relative to the updated value of the first parameter using the pre-calculated values; and determining an updated contour using the updated value of the first parameter and the updated values ​​of the one or more additional parameters; updating the information-dense user interface to include updated values ​​of one or more additional parameters of the derivative and the updated contour; A method comprising:

2. 2. The method of claim 1, wherein the corresponding result of the contour is a multiple of the premium of the derivative and the corresponding price is a put price of the derivative.

3. 2. The method of claim 1 , wherein the first visual representation includes a substantially horizontal line, the first parameter is a price associated with the derivative, and moving the first visual representation includes moving the substantially horizontal line from a first y-coordinate corresponding to a first value of the price to a second y-coordinate corresponding to a second value of the price.

4. The method of claim 3 , wherein the price associated with the derivative is one of a put price, a spot price, an upper knockout price, a lower knockout price, and a strike price.

5. 2. The method of claim 1 , wherein the first visual representation includes a substantially vertical line, the first parameter is a time associated with the derivative, and moving the first visual representation includes moving the substantially vertical line from a first x-coordinate corresponding to a first time to a second x-coordinate corresponding to a second time.

6. 6. The method of claim 5, wherein the time associated with the derivative is one of an expiration time, a start time of a lower knockout price, an end time of the lower knockout price, a start time of an upper knockout price, and an end time of an upper knockout price.

7. 7. The method of claim 1, further comprising placing one or more orders to implement the derivative.

8. 7. The method of claim 1, further comprising receiving an indication that a user has selected a lock control in the information-dense user interface to lock the value of a locked parameter of the additional parameter, and wherein determining updated values ​​for one or more additional parameters of the derivative comprises calculating updated values ​​for other parameters of the additional parameter without changing the value of the locked parameter.

9. The method of claim 8 , wherein the locked parameter is a cost to acquire the derivative.

10. 1. A method for implementing derivatives using an information dense user interface, comprising: providing a display of the information-dense user interface, the information-dense user interface including a parameter definition portion and one or more controls for initiating one or more execution methods, the parameter definition portion including a visual representation of parameters of the derivative that is movable in response to user input defining values ​​of the parameters of the derivative, the parameter definition portion further including an overlay or underlay including contours, each contour showing a corresponding rate of return in relation to a premium of the derivative on a vertical axis against time on a horizontal axis; receiving user input via the one or more controls requesting initiation of a selected one of the one or more execution methods; submitting one or more orders to a trading platform to execute the selected execution method; A method comprising:

11. The method of claim 10 , wherein the user interface further includes a historical data portion representing historical price data for the derivative.

12. 11. The method of claim 10, wherein the first visual representation includes a substantially horizontal line, the first parameter is a price associated with the derivative, and moving the first visual representation includes moving the substantially horizontal line from a first y-coordinate corresponding to the first price to a second y-coordinate corresponding to a second price.

13. 13. The method of claim 12, wherein the price associated with the derivative is one of a put price, a spot price, an upper knockout price, a lower knockout price, and a strike price.

14. 11. The method of claim 10, wherein the first visual representation includes a substantially vertical line, the first parameter is a time associated with the derivative, and moving the first visual representation includes moving the substantially vertical line from a first x-coordinate corresponding to a first time to a second x-coordinate corresponding to a second time.

15. 15. The method of claim 14, wherein the time associated with the derivative is one of an expiration time, a start time of a lower knockout price, an end time of the lower knockout price, a start time of an upper knockout price, and an end time of the upper knockout price.

16. 16. The method of any one of claims 10-15, wherein the user interface includes an intra-trade portion that indicates the progress of the one or more orders.

17. 17. The method of claim 16, wherein the intra-trade portion includes one or more visual indications of executed contracts or price action.

18. 18. The method of claim 17, wherein the visual indication comprises a geometric shape positioned at a position on an x-axis corresponding to a time when a fill action occurred and at a position on a y-axis corresponding to a price at which the fill action was executed.

19. 1. A method for generating an information-dense user interface with historical price data and price forecast distributions for an asset, comprising: retrieving historical price data for said asset; retrieving a historical performance forecast for said asset; polling a set of users to provide a forecast of future performance of said asset; receiving a forecast of future performance of the asset from at least a portion of the set of users; providing a display of the information-dense user interface, the information-dense user interface including a visual representation of the asset's historical prices over time overlaid with an indication of a first distribution of the historical performance forecasts and an indication of a second distribution of received forecasts of the asset's future performance; A method comprising:

20. 20. The method of claim 19, wherein the indication of the first distribution of historical performance forecasts includes a set of geometric shapes, each geometric shape arranged according to a corresponding price range and having a visual property corresponding to a number of users who predicted the asset price to be within the corresponding price range.

21. 21. The method of claim 20, wherein each geometric shape has an x-axis position indicating a time range and a y-axis position indicating a price forecast, and the visual property is shading intensity.

22. 22. The method of any one of claims 19 to 21, wherein the received indication of the second distribution of predictions of future performance of the asset includes a set of geometric shapes, each geometric shape arranged according to a corresponding price range and having a visual property corresponding to the number of users who predicted that the asset price will be within the corresponding price range.

23. 23. The method of claim 22, wherein each geometric shape has a y-axis position that indicates a price prediction, and the visual property is shading intensity.

Images