Efficient use of computing resources through conversion and comparison of trade data into musical composition representations and metric trees

Abstract

The trading data processing and monitoring system receives trading activity, converts it into a musical composition representation, transforms that representation into a metric tree, and then performs analysis, resulting in accelerated speed, more accurate onset detection, and more efficient use of computing resources. This is achieved by focusing on the information contained hierarchically in the metric tree rather than the tree structure when comparing and matching trading patterns, such as potential market manipulation, market change signals, or synthetically created trades, or the likelihood that a series of trading activities will lead to market price movements of one or more financial assets contrary to plan. The analysis system further weights the identified signals and determines a score reflecting the likelihood of trading irregularities. If the score does not meet a pre-set threshold, corresponding action is taken.

Description

[Technical field]

[0001] Cross-references to related applications This application is a continuation-in-part of U.S. patent application Ser. No. 16 / 373,625, filed April 2, 2019, entitled "EFFICIENT USE OF COMPUTING RESOURCES VIA CONVERTING AND COMPARING TRADE DATA TO MUSICAL WORK REPRESENTATIONS AND METRIC TREES" and a continuation-in-part of U.S. patent application Ser. No. 14 / 975,720, filed December 19, 2015, which claims priority to U.S. provisional patent application Ser. No. 62 / 094,287, filed December 19, 2014. Applicants hereby incorporate the following application numbers: 16 / 373,625, 14 / 975,720, and 62 / 094,287, by reference in their entireties.

[0002] FIELD OF THEINVENTION The present invention relates generally to the field of artificial intelligence. In particular, the present invention is directed to efficient use of computing resources through the transformation and comparison of trade data to musical composition representations and metric trees. [Background technology]

[0003] 2. Background of the Invention One of the trading disciplines employed to evaluate investments and identify trading opportunities is technical analysis, which assumes that past trading activity and price changes of a security can be valuable indicators of the future price movement of the security. Technical analysis focuses on the statistical analysis of price trends and patterns found on charts. However, technical analysis can be time-consuming, and the task of drawing graphics and measuring vectors on the graphics can take minutes, or even seconds, or more. Known methods of technical analysis cannot identify signals or warnings of the necessities in a timely manner, given that high-frequency trading (HFT) program trading platforms trade large numbers of orders in fractions of a second. High-frequency trading has data speeds that operate at nanosecond speeds, and a thousand trades can occur within a 100 millisecond period. Therefore, technical analysis is not sufficient to meet the timeliness requirements. Online analytical processing (OLAP) for pattern recognition is required by the U.S. Securities and Exchange Commission and financial industry regulators, stock exchanges, electronic marketplaces, high-frequency trading, and serious market participants seeking to make the best-executed trades. The amount of computer resources required to meet timeliness requirements is significant and taxing.

[0004] Additionally, known methods for analyzing financial instruments and / or market trends for investment decisions and time series forecasting are prone to errors for both Type I (false positive) and Type II (false negative) errors. This is due to the lack of pattern recognition accuracy in known methods. Pattern recognition accuracy depends on the veracity of the data. However, timestamps of trade messages (such as sending, modifying, or canceling a trade order, receiving order confirmations, etc.) are not accurate due to unsynchronized clocks. Clock synchronization refers to techniques used to adjust a common concept of time between processes. Currently, Financial Industry Regulatory Authority (FINRA) rules require a ±50 ms tolerance for National Institute of Standards and Technology (NIST) atomic clock synchronization and a 1 ms timestamp granularity for electronic trading messages. Known methods could not handle this timestamp tolerance and caused errors.

[0005] Moreover, known market monitoring and research techniques rely on humans to compare graphs and charts, leading to highly subjective assessments. Thus, these known techniques lack sufficient objectivity.

[0006] Additionally, analysis of trade data involves using known techniques of data visualization to graphically measure vectors. However, these techniques for processing and reviewing graphical representations of large amounts of trade data require significant computer resources. Due to the increasing volume of trade data, the cost of storing compressed trade data is also quite high.

[0007] Additionally, confidentiality and secure delivery and retrieval of trade data are a priority. Current approaches struggle to provide market data to all market participants simultaneously in a confidential and secure manner, impacting market access.

[0008] Furthermore, due to the complexity and fragmentation of capital markets, current technological tools are inadequate to aggregate or disaggregate trade data in a way that allows for meaningful identification of interconnectedness across markets and asset classes.

[0009] And while large financial institutions and high-frequency trading firms have the AI ​​and supercomputers to power their market monitoring / research methods, these companies work in silos rather than collaboration, stifling the exchange of best practices within the industry and raising fairness concerns for those without access to such technology. This further hampers the collective ability to deal with sudden market accidents and stress. Summary of the Invention [Means for solving the problem]

[0010] Disclosure Summary In an aspect, a system for processing and monitoring trade data, the system comprising a computing device having at least one processor, is configured to perform the steps of: receiving data representing a set of trade activity; receiving a plurality of user inputs from a plurality of user client devices, where each user input of the plurality of user inputs further comprises identifying a datum of a set trade activity representing; and identifying a trade irregularity associated with the plurality of data representing the trade activity; converting the plurality of user inputs into training data, the plurality of data representing the set of trade activity, and generating a classifier as a function of the training data, the classifier receiving the representation of the set of trade activity as an input and an output of a trade irregularity.

[0011] In another aspect, a method for processing and monitoring trade data includes: receiving, by a computing device, data representing a series of trade activity; receiving, by the computing device, a plurality of user inputs from a plurality of user client devices, where each user input of the plurality of user inputs updates an identification of a datum of a set of trade activity representing the plurality of data representing the trade activity and an identification of a trade irregularity associated with the series of trade activity; converting, by the computing device, the plurality of data representing the series of trade activity, the plurality of user inputs into training data; and generating, by the computing device, a classifier as a function of the training data. The classifier receives the representation of the series of trade activity as an input and an output of a trade irregularity.

[0012] These and other aspects and features of non-limiting embodiments of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific non-limiting embodiments of the invention in conjunction with the accompanying drawings. The present invention provides, for example, the following: (Item 1) 1. A system for processing and monitoring trade data, comprising a computing device having at least one processor, configured to perform the following steps: receiving a plurality of data representing a set of trading activities; receiving a plurality of user inputs from a plurality of user client devices, where each user input of the plurality of user inputs represents a set of trading activities of a plurality of data representing the trading activity further including an identification of at least one datum, and an identification of a trading irregularity associated with the set of trading activities; Converting a plurality of data representing a set of trading activities and a plurality of user inputs into training data; and It generates a classifier as a function of training data, where the classifier receives a set of trading activities as input and output related to the classifier trading irregularity. (Item 2) 2. The system of claim 1, wherein the plurality of data representing a set of trading activities and a plurality of user inputs is converted into training data, further comprising: Categorize each user input and datum into a genre of trading activity, and Transform multiple data sets representing trading activities and multiple user inputs as a function of classification into training data. (Item 3) The method of item 2, wherein the genre further comprises a previously identified genre and further comprises modifying the previously identified genre. (Item 4) 3. The system of claim 2, wherein generating further comprises generating a classifier using training data associated with a single genre. (Item 5) 2. The system according to item 1, wherein the conversion further comprises: using a machine learning process to discover at least one hidden model among a set of multiple trading activities; and A plurality of sequences of trading activities are transformed into training data using a plurality of user identities and at least one hidden model. (Item 6) 6. The system according to item 5, wherein the conversion further comprises: Retrieving a plurality of saved trade activity models; and simulating at least one model trade using the plurality of stored models; Calculate the results of at least one model trade, and Determining the fit of a hidden model as a function of outcome. (Item 7) 7. The system of item 6, wherein the calculation includes: Determine the datums that represent trade size and market time boundaries, and Backtest at least one model trade based on the datum. (Item 8) 2. The system of claim 1, wherein the computing device is further configured to: Receive the current set of trading activities, and Use the classifier to classify the current set of trading activities. (Item 9) The system according to item 1 may further comprise: The classifier further comprises a trade pattern classifier; The current set of trading activity is associated with trades occurring on the first trading desk, and The computing device is further configured to: categorizing the set of current trade activity into a pattern of trades occurring at a second trade desk, where the first trade desk is different from the second trade desk; Identify possible trade desk hopping scenarios as a function of classification. (Item 10) 7. The system of claim 6, wherein the computing device is further configured to convert the set of current trade activities into a metric tree, wherein the classifier is configured to identify matching trees in the training data. (Item 11) 1. A method for a trade data processing and monitoring system, comprising: receiving a plurality of data representing a set of trading activities; receiving a plurality of user inputs from a plurality of user client devices, where each user input of the plurality of user inputs further includes an identification of at least one datum, representing a set of trading activities of the plurality of data representative of the trading activity, and an identification of a trading irregularity associated with the set of trading activities; Converting a plurality of data representing a set of trading activities and a plurality of user inputs into training data; and It generates a classifier as a function of training data, where the classifier receives a set of trading activities as input and output related to trading irregularities. (Item 12) The method according to item 11, wherein the plurality of data representing a set of trading activities and a plurality of user inputs is converted into training data, further comprising: Categorize each user input and datum into a genre of trading activity, and Transform multiple data sets representing trading activities and multiple user inputs as a function of classification into training data. (Item 13) The method of method 12, wherein the genre further comprises a previously identified genre and further comprises modifying the previously identified genre. (Item 14) Item 13. The method of item 12, wherein generating further comprises generating the classifier using training data associated with a single genre. (Item 15) The method according to item 11, wherein the conversion further comprises: using a machine learning process to discover at least one hidden model among a set of multiple trading activities; and A plurality of sequences of trading activities are transformed into training data using a plurality of user identities and at least one hidden model. (Item 16) 17. The method according to item 16, wherein the conversion further comprises: Retrieving a plurality of saved trade activity models; and simulating at least one model trade using the hidden model and / or the plurality of stored models; Calculate the results of at least one model trade, and Determining the fit of a hidden model as a function of outcome. (Item 17) The method according to item 16, wherein the calculation comprises: Determine the datums that represent trade size and market time boundaries, and Backtest at least one model trade based on the datum. (Item 18) The method according to item 11 further comprises: Receive the current sequence of trading activity, and Use the classifier to classify the current set of trading activities. (Item 19) The method according to item 18 herein comprises the steps of: The classifier further comprises a trade pattern classifier; The current set of trading activity is associated with trades occurring on the first trading desk, and The computing device is further configured to: categorizing the set of current trade activity into a pattern of trades occurring at a second trade desk, where the first trade desk is different from the second trade desk; Identify possible trade desk hopping scenarios as a function of classification. (Item 20) The method of claim 16 further includes converting the set of current trade activities into a metric tree, where the classifier is configured to identify matching trees in the training data. (Item 21) A system for processing and monitoring trade data, comprising a computing device having at least one processor, configured to perform the following: Receiving data representing a set of trading activities; Transforming data representing a set of trading activities into a representation of a musical composition; and converting the musical piece representation into a metric tree, where the notes of the musical piece representation are recorded in labeled leaf nodes of the metric tree, and the labeled leaf nodes are connected to unlabeled internal nodes; and Set the initial default value for the score representing the probability of trading irregularity, and comparing the metric tree to a plurality of trigger trees stored in a lesson database, where each trigger tree of the plurality of trigger trees represents a trade irregularity; and Using a nearest neighbor algorithm, identification of at least one trigger tree of the plurality of trigger trees that exhibits at least a closest match to the metric tree is performed, where the use of a nearest neighbor algorithm further includes: We use the match values ​​to calculate the tree-to-tree distance, where the distance from a trigger tree to a metric tree is the average chance of finding a labeled leaf from a trigger tree that is connected to an unlabeled internal node in the metric tree, and Identify at least the trigger tree that has the smallest distance to the metric tree, and modifying the score to represent an increased probability of trading irregularity as a function of the identification of at least one trigger tree; Comparing the score to a pre-defined threshold, and With the review system, it takes corresponding actions as a result of the comparison. (Item 22) 22. The system according to item 21, wherein the conversion includes: Representing trading activities in a set as notes and trading non-activities as rests in the musical composition representation, where each note represents a trading order in the set of trading activities; Each note representing a purchase order is placed on the high note of the musical piece. placing each note representing a sales order on a bass clef of the musical composition representation, setting the pitch of each note of the musical composition representation according to a price value and a length of time that the corresponding trade order remains open; setting the tempo of the musical composition representation according to the average speed at which trade orders are filled; and Set the time signature of your musical expression according to a combination of trade instrument type, venue, and market conditions of your trade activity. (Item 23) 22. The system according to item 21, wherein the conversion comprises: Each note in the musical composition representation is transformed by a data processor into a leaf node of the metric tree, which includes: Setting, by the data processor, determines the level of a leaf node in the metric tree according to the duration of a corresponding note in the musical piece representation; using a data processor to organize the plurality of nodes in the metric tree into an appropriate order according to a time ordering of notes of the musical composition representation; Parsing the metric tree into a number of tracks, each track consisting of the smallest discrete trade unit of a set of trading activity; and We use a partially labeled tree comparison method to aggregate tracks into dimensions, where each dimension is a group of multiple individual trading units. (Item 24) 22. The system of claim 21, wherein each trigger tree of the plurality of trigger trees includes data representing a pattern selected from the group consisting of: potential market manipulation, a market change signal, a synthetically created trade, and a series of trading activities likely to result in market price movements of one or more financial assets. (Item 25) 22. The system according to item 21, wherein the comparison further comprises: The calculation of the average probability of finding a labeled leaf in the descendants of an unlabeled internal node in the metric tree is performed recursively until no matching trigger tree is found and the sequence of trade activity for the period matches. (Item 26) 22. The system of claim 21, wherein the computing device is further configured to store data representing the set of trading activities using time-locked cryptographic protection. (Item 27) 1. A computer-implemented method for processing and monitoring electronic trade data, comprising: Executed by a data processor, receiving data representing a set of trading activities; Executed by a data processor, converting data representing the set of trading activities into a representation of the musical composition; and a step of converting the musical piece representation into a metric tree, the musical piece representation having notes recorded in labeled leaf nodes of the metric tree, the labeled leaf nodes being connected to unlabeled internal nodes; and Set the initial default value for the score representing the probability of trading irregularity, and comparing the metric tree to a plurality of trigger trees stored in a lesson database, where each trigger tree of the plurality of trigger trees represents a trade irregularity; and Using a nearest neighbor algorithm, identification of at least one trigger tree of the plurality of trigger trees that exhibits at least a closest match to the metric tree is performed, where the use of a nearest neighbor algorithm further includes: We use the match values ​​to calculate the tree-to-tree distance, where the distance from a trigger tree to a metric tree is the average chance of finding a labeled leaf from a trigger tree that is connected to an unlabeled internal node in the metric tree, and Identify at least the trigger tree that has the smallest distance to the metric tree, and modifying the score to represent an increased probability of trading irregularity as a function of the identification of at least one trigger tree; Comparing the score to a pre-defined threshold, and (Item 28) 28. The method according to claim 27, wherein the transformation includes: Representing trading activities in a set as notes and trading non-activities as rests in the musical composition representation, where each note represents a trading order in the set of trading activities; Each note representing a purchase order is placed on the high note of the musical piece. placing each note representing a sales order on a bass clef of the musical composition representation, setting the pitch of each note of the musical composition representation according to a price value and a length of time that the corresponding trade order remains open; setting the tempo of the musical composition representation according to the average speed at which trade orders are filled; and Set the time signature of your musical expression according to a combination of trade instrument type, venue, and market conditions of your trade activity. (Item 29) 28. The method according to item 27, wherein the conversion comprises: Each note in the musical composition representation is transformed by a data processor into a leaf node of the metric tree, which includes: Setting, by the data processor, determines the level of a leaf node in the metric tree according to the duration of a corresponding note in the musical piece representation; using a data processor to organize the plurality of nodes in the metric tree into an appropriate order according to a time ordering of notes of the musical composition representation; Parsing the metric tree into a number of tracks, each track consisting of the smallest discrete trade unit of a set of trading activity; and We use a partially labeled tree comparison method to aggregate tracks into dimensions, where each dimension is a group of multiple individual trading units. (Item 30) 27. The method of claim 26, wherein each trigger tree of the plurality of trigger trees comprises receiving data representing a pattern selected from the group consisting of: potential market manipulation, a market change signal, a synthetically created trade, and a sequence of trading activity likely to result in movement in the market price of one or more financial assets. (Item 31) 28. The method according to item 27, wherein the comparison further comprises: The calculation of the average probability of finding a labeled leaf in the descendants of an unlabeled internal node in the metric tree is performed recursively until no matching trigger tree is found, and a set of trading activities for the period match. (Item 32) The method of claim 27 further includes storing the data representing the set of trade activities using time-locked cryptographic protection. (Item 33) A non-transitory computer readable medium containing computer readable program code embodied therein, the program instructions being executable by at least one processor. and at least one processor performs operations that include: Executed by a data processor, receiving data representing a set of trading activities; Executed by a data processor, converting data representing the set of trading activities into a representation of the musical composition; and a step of converting the musical piece representation into a metric tree, the musical piece representation having notes recorded in labeled leaf nodes of the metric tree, the labeled leaf nodes being connected to unlabeled internal nodes; and Set the initial default value for the score representing the probability of trading irregularity, and comparing the metric tree to a plurality of trigger trees stored in a lesson database, where each trigger tree of the plurality of trigger trees represents a trade irregularity; and performing identification of at least one trigger tree of the plurality of trigger trees that exhibits at least a closest match to the metric tree using a nearest neighbor algorithm, where using a nearest neighbor algorithm further includes: We use the match values ​​to calculate the tree-to-tree distance, where the distance from a trigger tree to a metric tree is the average chance of finding a labeled leaf from a trigger tree that is connected to an unlabeled internal node in the metric tree, and Identify at least the trigger tree that has the smallest distance to the metric tree, and modifying the score to represent an increased probability of trading irregularity as a function of the identification of at least one trigger tree; Comparing the score to a pre-defined threshold, and With the review system, it takes corresponding actions as a result of the comparison. (Item 34) Item 34. The medium according to item 33, wherein the conversion comprises: Representing trading activities in a set as notes and trading non-activities as rests in the musical composition representation, where each note represents a trading order in the set of trading activities; Each note representing a purchase order is placed on the high note of the musical piece. placing each note representing a sales order on a bass clef of the musical composition representation, setting the pitch of each note of the musical composition representation according to a price value and a length of time that the corresponding trade order remains open; setting the tempo of the musical composition representation according to the average speed at which trade orders are filled; and Set the time signature of your musical expression according to a combination of trade instrument type, venue, and market conditions of your trade activity. (Item 35) Item 34. The medium according to item 33, wherein the conversion comprises: Each note in the musical composition representation is transformed by a data processor into a leaf node of the metric tree, which includes: The setting is performed by the data processor to determine the level of a leaf node in the metric tree according to the duration of a corresponding note in the musical piece representation; using a data processor to organize the plurality of nodes in the metric tree into an appropriate order according to a time ordering of notes of the musical composition representation; Parsing the metric tree into a number of tracks, each track consisting of the smallest discrete trade unit of a set of trading activity; and We use a partially labeled tree comparison method to aggregate tracks into dimensions, where each dimension is a group of multiple individual trading units. (Item 36) The medium described in item 33, wherein each trigger tree of the plurality of trigger trees includes data representing a pattern selected from the group consisting of: potential market manipulation, a market change signal, a synthetically created trade, and a series of trading activities likely to result in market price movements of one or more financial assets. (Item 37) Item 34. The medium according to item 33, wherein the comparison further comprises: The calculation of the average probability of finding a labeled leaf in the descendants of an unlabeled internal node in the metric tree is performed recursively until no matching trigger tree is found, and a set of trading activities for the period matches. (Item 38) Item 34. The medium of item 33 configured to store data representing a set of trade activities using time-locked cryptographic protection. [Brief description of the drawings]

[0013] For the purpose of illustrating the invention, the drawings show aspects of one or more embodiments of the invention. It should be understood, however, that the invention is not limited to the precise arrangements and dexterity shown in the drawings.

[0014] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary system including components for at least processing and analysis of real-time and / or historical trading order data and / or processed trades according to some embodiments.

[0015] [Diagram 2] FIG. 2 illustrates a computing environment according to some embodiments.

[0016] [Diagram 3] FIG. 3 is a flow chart illustrating a method for processing and sequencing real-time or historical trading data and / or processed trades performed by a data processor according to some embodiments.

[0017] [Figure 4]FIG. 4 shows an example of a user interface or display window for trade activity.

[0018] [Diagram 5] Figure 5 shows an example of a user interface or window panel with various tabs of tuning controls for simulating market dynamics and for replicating the Depth of Market book.

[0019] [Figure 6] FIG. 6 illustrates a method for converting, composing, or decomposing real-time trading order data or processed trades into a metric tree according to some embodiments.

[0020] [Figure 7] FIG. 7 is a flow chart illustrating a method for providing trade analysis performed by the analysis system in accordance with some embodiments.

[0021] [Figure 8] FIG. 8 is a flow chart illustrating in more detail the analysis performed by the detection engine according to some embodiments.

[0022] [Figure 9] FIG. 9 is a flow chart illustrating a pattern recognition process for comparing trade order data and / or processed trades with Complex Event Processing (CEP) data according to some embodiments.

[0023] [Figure 10] FIG. 10 illustrates a table of example triggers in a lesson database according to some embodiments.

[0024] [Figure 11] FIG. 11 is a flowchart illustrating a process performed by a backstop guarantee component according to some embodiments.

[0025] [Figure 12] FIG. 12 illustrates an example of identification of synthetically created trades by basic control components according to some embodiments.

[0026] [Figure 13] FIG. 13 is a flow chart illustrating how parameters and boundaries are calculated and defined by the model and logic components according to some embodiments.

[0027] [Figure 14] FIG. 14 illustrates an exemplary framework and algorithm for use in an analysis system according to some embodiments of the present invention.

[0028] [Figure 15] FIG. 15 illustrates a method for determining reasonably expected short-term demand (RENTD) according to some embodiments.

[0029] [Figure 16] FIG. 16 illustrates an exemplary method for creating an inventory plan to guide an entity's management of risk mitigating hedging and liquidity management activities according to some embodiments.

[0030] [Figure 17] FIG. 17 is a flow chart illustrating an example method for crowd computing processing in accordance with some embodiments.

[0031] [Figure 18] FIG. 18 is a flow chart illustrating a method for reconstructing trade events performed by a trade reconstruction component of a review system according to some embodiments.

[0032] [Figure 19] FIG. 19 is a flow chart illustrating a method for assimilating market dynamics and backtesting performed by a trading order replay simulator according to some embodiments.

[0033] [Figure 20] FIG. 20 illustrates an example of a user interface implemented by the trade reconstructor component.

[0034] [Figure 21] FIG. 21 is a flowchart illustrating a method implemented by a case management component according to some embodiments; and

[0035] [Figure 22] FIG. 22 is a block diagram of computer system components that may include one or more components for implementing various embodiments of the invention.

[0036] The drawings are not necessarily to scale and may be illustrated by phantom lines, diagrammatic representations, fragmentary views, etc. In certain cases, details and / or reference characters that are not necessary for the understanding of the embodiment or that make other details difficult to perceive may be omitted. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] Detailed Description The following description is provided to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles of the present specification may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments shown, but is intended to be accorded the widest scope consistent with the principles and features described herein.

[0038] References herein to "one embodiment," "embodiment," "exemplary embodiment," "or a "preferred embodiment" refer to at least one embodiment of the invention in which a particular feature or structure or characteristic described in connection with that embodiment is included. The appearances of the phrase "in one embodiment" in various places in the specification do not necessarily all refer to the same embodiment, nor to separate or alternative embodiments that are mutually exclusive from other embodiments. Also, various features that may be exhibited by some embodiments but not other embodiments are described. Additionally, various requirements that may be requirements for some embodiments but not other embodiments are described. In general, features described in one embodiment may be suitable for use in other embodiments as would be apparent to one skilled in the art. The appearance of "and / or" means at least one of the first element / feature and the second element / feature.

[0039] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart diagrams or block diagrams may represent a module, segment, or portion of code, including one or more executable instructions for implementing a specified local function. Also, in some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously or may be executed in reverse order depending on the functionality involved in the blocks. Also, it should be noted that each block in the block diagrams or flowchart diagrams, or combinations of blocks in the block diagrams or flowchart diagrams, may be implemented as a special-purpose hardware-based system that performs a particular function or act, or may be based on a combination of special-purpose hardware and computer instructions.

[0040] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural unless the context clearly dictates otherwise. It is further understood that as used in this specification, the terms "comprise" and / or "comprise" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0041] Embodiments of the present invention provide: more accurate detection of onset signals at accelerated rates while using fewer computer resources; more tolerant asynchronously clocked pattern recognition methods; a more objective and quantifiable approach for trade control monitoring and investment research across capital markets and asset classes; improved data compression and information security obfuscation protection methods that allow for a significant reduction in storage requirements while preserving the broad spectrum and confidentiality of information; simplified methods for meaningfully aggregating or disaggregating financial records allowing for a more robust trade event reconstruction and order book replay process; and shared best practices and business intelligence developed by crowd computing and other components that are used to guide and fine-tune the parameters and filtering mechanisms used to monitor and manage trading activity, identify patterns of irregularities, and detect and investigate potential fraudulent activity.

[0042] FIG. 1 illustrates a system 0XX0100 including components for processing and analyzing real-time trading order data and / or processed trades according to some embodiments. The system 0XX0100 includes a data processor 1XX1101 for processing, compressing and sequencing processed trade data real-time or historical trade orders using a metric tree approach and using an audio control component with tuning and information security control. The system 0XX0100 also includes an analysis system 2XX0100 for analyzing trading activity using hybrid techniques based on rules and pattern recognition techniques. The system further includes a review system 3XX0140 for reconstructing trades and market events for the purpose of detecting and investigating patterns of irregularities or potential fraudulent activity.

[0043] With reference to FIG. 1, components of the system 0XX0100, including but not limited to the data processor 1XX1101, may be implemented as a computing device and / or software and / or hardware modules operating on one or more computing devices. The computing device may include any computing device described in this disclosure, including but not limited to the microcontrollers, microprocessors, digital signal processors (DSPs) and / or systems on chips (SoCs) described in this disclosure. The computing device may include, be contained in, or communicate with a mobile device, such as a mobile phone or smartphone. The computing device may include a single computing device operating independently or may include two or more computing devices operating in parallel, sequentially. The two or more computing devices may be included together in a single computing device or two or more computing devices. The computing device may interface or communicate with one or more additional devices, which will be described later, via a network interface device. The network interface device may be utilized to connect the computing device to one or more diverse networks, and one or more devices. Examples of network interface devices include, but are not limited to, a network interface card (e.g., a mobile network interface card, a local area network (LAN) card), a modem, and any combination thereof. Examples of networks include wide area networks (such as the Internet, corporate networks, etc.), local area networks (networks associated with an office, building, campus, or other relatively small geographic space), telephone networks, data networks associated with a telephone / voice provider (e.g., a mobile communications provider's data and / or voice network), and any direct connection between two computing devices and any combination thereof.The network may use wired or wireless communication modes. In general, any network topology may be used. Information (data, software, etc.) may be communicated between computers and / or computing devices. Computing devices include, for example, but are not limited to, a computing device or cluster of computing devices at a first location and a computing device or cluster of computing devices at a second location. Computing devices may include one or more computing devices specialized for data storage, security, traffic distribution for load balancing, etc. Computing devices may distribute one or more computing tasks among multiple computing devices of computing devices, as described below, and may operate in parallel, serial, redundant, or any other manner used to distribute tasks or memory among computing devices. Computing devices may be implemented using a "shared-nothing" architecture where data is cached at the workers. In an embodiment, this may enable scalability of the system 0XX0100 and / or the computing devices.

[0044] The computing device and / or modules and / or components introduced in this disclosure may be designed and / or configured to perform the method steps, or sequences of method steps, in any order and with any iterations, in any embodiment described in this disclosure. For instance, the computing device and / or modules may be configured to repeatedly perform a single step or sequence until a desired result or command result is achieved. The iteration of a step or sequence of steps may be performed by repeating the process, recursively repeating the process using the output of a previous iteration as input to a subsequent iteration, aggregating the input and / or output of the iteration, decreasing or decreasing one or more variables, such as global variables, and / or dividing a large processing task into a sequence of processes that iteratively process the steps. The computing device and / or modules may perform the steps or sequences described in this disclosure in parallel, e.g., performing a step two or more times simultaneously using two or more parallel threads, processor cores, etc. The division of tasks between parallel threads and processes may be performed according to a protocol suitable for dividing tasks between iterations. Those skilled in the art will recognize, upon reviewing this disclosure in its entirety, the various ways in which steps, sequences of steps, processing tasks, and / or data may be subdivided, shared, or otherwise processed using iterative, recursive, and / or parallel processing.

[0045] The data processing device 1XX1101 receives multiple inputs via a gateway 5AX1307. In some embodiments, the inputs include, but are not limited to: processed trade or trade order streams 4AA0130, inventory positions and trade books 4BA0132, market data 5XA0131, reference data 5XB0131, output from a voice and electronic communications monitoring system 5DA9999, and various news feeds 5DB9999. The data processor 1XX1101 includes a data transformation composer 1AX1101, a sequencer 1BX1101, a compression component 1CX9999, an information security component 1DX9999, and an output and storage management component 1EX1304. The data processing device 1XX1101 and its components are described below with reference to Figures 3-6.

[0046] The analysis system 2XX0100 receives as input the rules or control list 2JA0113 and the control plan 2JB0301, and data from other data components in the system 2XX0100. The analysis system 2XX0100 uses a set of advanced filter criteria 2JC1207 and includes: a basic control component 2AX0101, a detection engine 2BX0104, a pattern recognition component 2CX0904, a model and logic component 2DX0105, a backstop guarantee component 2EX0106, and a crowd computing component 2FX0107. The analysis system 2XX0100 and its components are further described below with reference to Figure 7-17.

[0047] The review system 3XX0140 includes: a trade event reconstruction component 3AX1206, an order book replay simulator 3BX0415, and a case management component 3CX0140. The review system 3XX0140 and its components are described below with reference to Figures 18-21.

[0048] The components of the system 0XX0100 are configured to communicate through various communication channels 5BX1307. The analysis system 2XX0100 and the review system 3XX0140 have access to the audit trail database 3TX0121, the lesson database 2TX0120, and the flag / quarantine database 2TX0122. Through the gateway 5AX1307, the data processing unit 1XX1101 further communicates with: broker or dealer systems 4XX1311, supervisory systems 6XX9999, self-regulatory organizations (SROs) and other trading platforms 5XX9999, voice and electronic communications monitoring systems 5DX9999, and clearing and settlement systems 5DX9999 (e.g. the clearing and settlement system of the central depository company). A broker-dealer's system 4XX1311 may include an order management system and / or an execution management system (OMS / EMS) 4AX0211, while a market maker interacts with a pricing and quotation system 4CX9999 and a portfolio management system / investment book of record (PMS / IBOR) 4BX0132. A broker-dealer system 4XX1311 consists of both manual trading by traders 4DX0505 and algorithmic trading by machines 4EX99999.

[0049] In some embodiments, the data processor 1XX1101 structures the financial data into an audio representation or metric tree, with tuning, compression, encryption, and other features. It distributes and shares market data between self-regulatory organizations and other market participants, such as other trading platforms 5XX9999 and broker / dealer systems 4XX1311. It also prepares data for analysis by the analysis system 2XX0100, and for review by the review system 3XX0140, and for trade reporting, and data management, and the like.

[0050] In some embodiments, the analysis system 2XX0100 uses a hybrid of rule-based and pattern recognition methods to: implement risk and compliance controls; conduct research and market surveillance, understand the firm's trading activity, and monitor market behavior, among others.

[0051] In some embodiments, the review system 3XX0140 serves as an output and interface and is implemented by: a trade event reconstruction component 3AX0416 that reviews sequences of trade events; an order book replay simulator 3BX0415 that simulates market dynamics and backtests and evaluates scenarios; and a case management component 3CX0140 that manages cases (from alerts generated from the analysis system 2XX0100) and monitors for timely and proper closure of identified issues, documents audit trails in an audit trail database 3TX0121, and finds lessons and feedback through a crowd computing component 2FX0107 to support custom inspections and fine-tuning of controls and drive continuous improvement actions.

[0052] FIG. 2 illustrates a computing environment 0XA1300 according to some embodiments. The computing environment 0XA1300 includes components for processing, compressing, sequencing trade data, reconstructing market events, monitoring trading activity, and identifying and investigating potential fraudulent activity. The computing environment 0XA1300 is comprised of high-performance computing components, such as those typically found in cluster architectures. The components include, but are not limited to, computer cluster and login nodes 0XO1306, administrative nodes and network switches 0XN1308, system health modules, circuit breaker modules, security and privacy modules (including encryption servers and key management devices), and business continuity planning (BCP) controller modules. The module 0XB0109 includes a processor 0XC1306, memory 0XD1301, power management 0XE0109, and load tenant task executor components 0XF0109. The computing environment 0XA1300 further includes various components forming a communication infrastructure 0XG1307 through which the components communicate, such as connection paths, I / O switch interfaces, and high bandwidth fabrics 0XH0109. The computing environment 0XA1300 further includes storage, such as a parallel file system 0XK1304, data storage 0XL1304, and disaster recovery archive library 0XM1304. Other computing components, such as an analytical cube 0XQ1305, can be configured to communicate with components in the computing environment 0XA1300. The computer system 0XA1300 resides behind a firewall 0XP1300 for secure communication with external devices 0XZ1311. A display 0XR1310 can be further coupled to the computing component 0XQ1305.In some embodiments, the computing environment 0XA1300 accelerates the performance of the delivered computing results while requiring fewer computing resources (particularly the graphics processing unit GPU, central processing unit CPU, memory, reduced power consumption, and significantly reduced data storage) because it no longer requires a lot of image processing and analysis, it has less complex calculations, and it uses other advanced techniques, as further described below.

[0053] Data Processor

[0054] FIG. 3 illustrates a method for the data processor 1XX1101 to process and sequence real-time or historical trade data and / or processed trades, according to some embodiments. Unlike conventional approaches that require clock synchronization accuracy before sequencing data, which otherwise causes a large impact on the shape of the plotted chart, and as a result many inaccuracies in measuring vectors graphically. Some embodiments of the present invention, at least through a method that values ​​information hierarchically rather than on a tree structure, are more tolerant to clock synchronization issues with respect to input data, with reference to FIG. 9 below. In block 1BA0201, the data processor 1XX1101 receives as input a stream of market data 5XA0131, and possibly also past processed trade records or a current trade order stream 4AA0130, including pricing information via a protocol or gateway 5AX1307. Market Data 5XA0131 may include, but is not limited to, order confirmations, order execution, order confirmations, open orders, basic market data or level 1 data (e.g., market orders, bid price, bid size, price, ask, size, last price, last size, etc.), volume information, additional market data or level 2 data (e.g., market data related to order books and depth of market, the highest bid price that a trader would be willing to pay to buy a security [including 5 or 10 prices depending on the market]), bid size (e.g., the number of securities available at each of the highest bid prices), the lowest asking price at which a trader is willing to sell a security, the number of securities available at each of the asking prices / lower prices, next best bid, trade quotes, open interest (e.g., the number of buy market orders before the stock market opens), changes in open interest, associated exchange trade position (EFRP) volume, the number of securities available for sale, the number of securities seeking to buy at each offer and bid price, information about cancelled, unlisted, incomplete, or unexecuted orders, and calculated market data. (e.g. imbalances and indices) and other price information.Market Data 5XA0131 may also include an aggregation of various elements of market data, such as an aggregate of trade volume information. Market Data 5XA0131 may be publicly available or may not be publicly available. Market Data 5XA0131 may be provided or generated from a variety of sources. For example, sources of market data include, but are not limited to: back-end order management systems, order fulfillment systems, stock exchanges, stock exchange matching engines (which process buy / sell orders and apply different rules for different exchanges), stock trading venues (such as Alternative Display Facilities [ADF]), electronic communications networks [ECNs] for matching buy and sell orders (e.g., used to connect brokers to individual traders to process orders), securities information processors [SIPs] (which carry trade and order information under a Consolidated Tape Associated Plan [CTA] or Unlisted Trade Privilege Plan [UTP]), and trade or transaction reporting services (e.g., the U.S. Financial Industry Regulatory Authority's Trade Reporting and Compliance Engine [TRACE]). Recipients of market data 5XA0131 may include a variety of stakeholders, some of which use the market data for various purposes upon receipt. These recipients include, but are not limited to: institutional traders, brokerage firms, high frequency traders, retail investors, individual traders, stock exchanges (as they often consume data from other trading venues), alternative trading systems (ATS or "dark pools"), analysts, industry regulators, market data providers, or market data vendors. Market data may be transmitted immediately after generation and, whenever possible, continuously in accordance with the integration rules in an integrated stream. Sources of market data operate data services implemented with "transmission rules" based on the continuous transmission of market data.

[0055] The data processor 1XX1101 may receive market data 5XA0131 from multiple different marketplace data sources, both local and international sources aggregated across asset classes, into a consolidated stream of order book status. The market data 5XA0131 may be provided in the form of raw data and communicated as network packets. In some embodiments, the market data 5XA0131 may also be provided as formatted or unformatted data, applying media files or formats. The market data 5XA0131 information may further be provided in a variety of formats, such as Extensible Markup Language (XML), Microsoft Excel Spreadsheet (XLS), Comma Separated Values ​​(CSV), Text File (TXT), Extensible Business Reporting Language (XBRL), and the like. Similar to the market data 5XA0131, the company's historical processed trade records or current trade order stream 4AA0130 includes bid and ask prices, and volume information. Traders at a broker or dealer firm 4DX0505 (see Figure 1) enter orders into an Order Management System (OMS) or Execution Management System (EMS) 4AX0211. The Order Management / Execution Management System 4AX0211 records the details of the trades including information such as time, price, order size, specifications of buy and sell orders, and creates a trade blotter accordingly. A trade blotter is a record of trades and details of trades made over a period of time. The purpose of a trade blotter is to carefully document trades so that they can be reviewed and confirmed by traders and brokerage firms. Trade order streams 4AA0130 may be live feeds running in parallel with the Order Management / Execution Management System 4AX0211 including orders, cancellations, or amendments to trades initiated from various 4DX0505 trading desks, order feeds from algorithmic trading systems 4EX9999, or order feeds from market maker pricing / quoting systems 4CX9999, both local and international and cross asset classes.A market maker is a company that is prepared to buy and sell certain stocks on a regular and ongoing basis at publicly quoted prices. Most often, you will hear about market makers in the context of Nasdaq and other "over-the-counter" (OTC) markets. Market makers that are prepared to buy and sell stocks listed on exchanges such as the New York Stock Exchange are called tertiary market makers. Many over-the-counter stocks have multiple market makers.

[0056] In block 1BB9999, the sequencer 1BX1101 checks the quality of the incoming data to ensure that the input data flow contains basic data elements. If the sequencer 1BX1101 determines that the input data fails the quality requirements, the data is rejected. Otherwise, the data is accepted (block 1AA1153). Data points in the incoming data are converted into musical notes, or metric tree presentations, as described further below with reference to FIG. 6. In this exemplary embodiment, the trading orders from the trading order stream 4AA0130 model the temporal and hierarchical structure of a musical piece. Like a musical piece, the trading order stream 4AA0130 contains activity (notes) and inactivity (rests). In music, the notes placed on the staff convey the tone or pitch of the note, and the type of note (whole note, half note, quarter note, etc.) conveys the duration of the note. Musical staves contain two types: treble clef (:( ) for higher tones, and bass clef ($ ) for lower tones. In this exemplary embodiment, trade orders are represented using notes on a musical staff. The notes represent trade orders. An arrangement of notes in the treble clef represents a buy order, and an arrangement of notes in the bass clef represents a sell order. The pitch of the notes represents the price value and the period for which the trade order will remain open (e.g., an ascending staff represents a trading desk with a bullish view, while a descending note represents a trading desk with a bearish view). In music, a piece is divided into measures (or "bars"), and the period of a measure is defined by a meter or beat. The total duration of notes and rests within a measure is the same as the beat. The tempo or beat in music represents the average speed at which a trade order is filled. The beat of a measure represents the combination of financial instrument type, venue, and market conditions for the trade order. The rhythm of a musical representation may be explicitly encoded or implicitly represented under a pitch class representation method. A musical "pitch class" is a set of pitches that are a whole octave apart (e.g., C pitches in all octaves).In Figure 6, 1AX1150 staff notation and 1AX1151 diagram show an example of pitch classes and their tonal correspondence. The example shows a chromatic scale of 12 tones of equal temperament (i.e., all pairs of adjacent pitches are separated by the same interval) above C, with only one full octave ascending (indicated by only sharps (♯)). The trading order pattern represented as music in the above manner is then converted into a metric tree by the data conversion composer component 1BX1101. As an example of a pitch class representation, the melody representation 1AX1152 is converted into a metric tree 1AX1153 as shown in Figure 6. The level of a leaf in the tree 1AX1153 determines the duration of the notes it represents. The left-to-right order of the tree nodes represents the time order of the notes of the melody.

[0057] Returning to Figure 3, in block 1BC1101, the sequencer 1BX1101 captures the temporal and hierarchical structure and metric trees, as well as metadata, according to trade sequence priority (e.g., a typical price / time priority where orders are automatically sorted according to price and time input criteria, or a size and time priority where size priority is ranked first in order). Capital market trading activity is dynamic with many co-streams of activity, similar to many voices playing polyphonic music at the same time. To represent multiple activity streams as polyphonic music, each "voice" or stream is inserted into the same tree in the manner described above, with the voices appearing to overlap. Buy orders are represented with a treble clef and sell orders with a bass clef, so there are typically at least two layers in the representation, with the number of overlay layers increasing as trade volume increases.

[0058] Figure 6 further illustrates an example of a polyphonic melody representation 1BX1154. The melody representation 1BX1154 may be transformed as two monophonic trees 1BX1155 and 1BX1156, with a first tree 1BX1155 representing the upper voice in the treble clef and a second tree 1BX1156 representing the lower voice in the bass clef. The node labels in trees 1BX1155 and 1BX1156 represent the pitch class per node. Alternatively, both voices are represented by the same tree 1BX1157. In tree 1BX1157, each node contains all notes played at a particular time, its depth conditioned by the note with the shortest duration. The node labels in tree 1BX1157 represent a set of pitch classes, rather than a single pitch class, as in trees 1BX1155 and 1BX1156. A node that represents only a music break symbol has an empty set.

[0059] Optionally, bottom-up label propagation can be implemented to remove irrelevant information (noise) that makes classification or identification of key features of the melody (signal) more difficult. As shown in Tree 1BX1158, node labels are propagated from bottom to top based on the node's position in the tree.

[0060] Returning to Figure 3, in block 1BD 1158, sequencer element 1BX 1101 aggregates the polyphonic data (block 1BE 1158) and / or displays them (block 3AX 1206). Alternatively, the polyphonic data is broken down (block 1BF 1158) into mono tracks and / or coordinated for display (block 3AX 1206) and analysis at a lower level of dimension or the smallest individual trading unit. As used herein, the term "individual unit" or "trading desk" refers to each individual unit engaged in the coordinated implementation of a revenue generating strategy and involved in the execution of targeted trading activities. This may include (a) each unit being a "trading desk," which may be the smallest unit of organization used by an entity to structure and control its risk-taking activities and employees, (b) each organizational unit used to aggregate risk-taking activities and structure and control employees for one or more trading units, (c) any managing or reporting division, group, subgroup, or other intermediate unit of the organization used to manage one or more individual trading units, (d) collectively all trading operations, and (e) any other organizational unit designated by a regulator with respect to a particular financial entity. Multiple individual units may be grouped together to form a "dimension."

[0061] FIG. 4 shows an example of a user interface or display window 3KS9908 for trade activity. In some embodiments, the user interface 3KS9908 is part of the trade reconstruction component 3AX1206 and the order book replay simulator 3BX0415 and is used with the composer 1AX1101 and sequencer 1BX1101 to: compile in-house or market trade activity into "tracks", aggregate or decompose the "tracks" into up or down or up or down "dimensions", and play, edit, record, and save. An audio "track" or "midi [MIDI] track" is for playing a recording or piece of sound or music, and each track has a corresponding channel on an audio mixer console. Similarly, financial instruments are distributed through various channels (e.g., retirement and insurance channels, discount brokerages like Charles Schwab, financial institution channels (hedge funds, proprietary trading firms), etc.). There may be multiple trading desks in a trade operation. Some focus on foreign exchange (FX), interest rates, the equity market, the debt market, or U.S. Treasury and / or agency products. Trading desks may be organized into groups and subgroups, such as countries, or large cap stocks / thinly traded penny stocks, value vs. growth strategies, or algorithmic desks vs. human traders. Again, each "track" refers to the smallest "individual trading unit," and the aggregated discrete units used here form the "dimensions."

[0062] Examples of User Interface 3KS9908 include: a consolidated view of all tracks 3KS9901, replay in a lower dimension 3KS9902 (e.g. the "target" to play is a ticker symbol), trade data broken down into "discrete trading units" 3KS9903 (e.g. trade data for a particular trading desk), display of Sync Time 3KS9906, button 3KS9907 to switch between audio spectrum display and traditional chart display, control button to dim other tracks to adjust the effect of a particular track ("Solo mode") 3KS9904, and changing the display of targets 3KS9905 to "stereo" mode to view and compare buy / sell side activity. User Interface 3KS9908 provides an easy way (e.g. drag and drop) to meaningfully aggregate or disaggregate financial records using reverb or other tuning or simulation methods, recreate depth of market books, and assimilate and represent market dynamics. Complex calculations such as asset pricing and payoffs are avoided, as well as deciphering correlations between rollups and the underlying dimensions, thereby saving compute and processing resources.

[0063] Returning to Figure 3, at block 1DA9999, the information security component 1DX9999 obfuscates confidential or sensitive data and personally identifiable information. Trading strategies are often proprietary secrets, and both the firm's own trading data and data about how the firm trades on behalf of its clients must be properly protected, as hackers could use stolen trading data to exploit illegal front-running and other trading strategies. Therefore, trading data must be encrypted and obfuscated accordingly. Obfuscation involves changing the format of data so that it cannot be easily read or accessed. As mentioned above, converting trading data into a musical format enables new obfuscation methods to mask or hide information.

[0064] FIG. 5 shows an example of a user interface or window panel 3KS9000 with various tabs of tuning controls for market dynamics assimilation, and replicating depth of market book. In some embodiments, the user interface 3KS9000 is part of the trade reconstruction component 3AX1206 and the order book replay simulator 3BX0415 and is used with the data transformation composer 1AX1101 and sequencer 1BX1101 to assimilate market dynamics and replicate depth of book and other market interactions by mixing different "effects". Traditional approaches rely on internal database queries to hopefully find outlier data points or use human "eyeball testing" to confirm similarities between graphs and charts. However, these traditional technology methods yield inaccurate and subjective results. In contrast, the trade reconstruction component 3AX1206 and the order book replay simulator 3BX0415 provide a highly configurable way to assimilate different market environments and "what if" scenarios. As shown in Figure 5, the user interface 3KS9000 includes a tuning console with Long / Short and Original / Effect tuning features 3KS9001, which represent the relative strength of the bid / ask prices and change the steepness of the price curve. In addition, the preset view 3KS9002 displays the National Best Bid and Offer (NBBO) along with the highest price present in the venue [BBO] and a mouse "double click" expander view with venue specific details. The tuning console 3KS9000 also includes tabs 3KS9001 that show other tuning effects such as: Treble / Mid / Bass - representing alternative trading systems (dark pools) / System Internalizers (SI) / stock exchange activity, faders representing the relative activity or interaction between the banking sector and shadow banking, increasing loudness to obfuscate, and adjusting left / right balance to simulate the relative activity or interaction between the buy / sell sides.The user interface 3KS9000 also includes a simulator 3KL9999, which contains: an instrumental sampler 3KM9999 of tradable objects (stocks, bonds, commodities, etc.), triggers and genres related to lessons, potential market manipulation and synthetically created trades, etc. (see Figures 9-11 and 17, and further described below).

[0065] Using the user interface 3KS9000 shown in FIG. 5, data is obfuscated by increasing loudness, which introduces background noise. In this exemplary embodiment, the data itself is not altered; instead, the "loudness" distorts the dynamic range, linearity, and frequency response to "mask" the data signal in the guise of noise frequency. By rendering the data incompatible, the depth of market book and trade volume details are less transparent than before, but the best bid price information remains unchanged. Other obfuscation techniques can also be used, including but not limited to: "introducing random noise" (mashing newly generated noisy data into existing good data), or "separating and scrambling" to make deciphering the details more complex, through simplifying the data (e.g. removing trading desk data fields), or by utilizing "aggregation at roll-up level" (e.g. showing market-wide trade statistics but not disclosing the traceable trading strategies of individual companies). To reverse the obfuscation, the person who obfuscated the information must share the techniques used, or trial and error or reverse engineering methods are applied. You can also use the tuning features of Trading Order Book Replay Simulator 3BX0415 to introduce noise or randomness that resists pattern recognition techniques. See Figure 3, information in the data can be separated using the decomposition analysis function and the Simulator 3BX0415 can be used to scramble the signal to increase the difficulty of data theft. Information can also be aggregated through the information aggregation function to simplify the content. Thus, lower dimensional information is hidden. Any combination of these obfuscation techniques can be used according to security protection requirements.

[0066] Returning to Figure 3, at block 1CA9999, compression component 1CX9999 compresses the data stream at a compression ratio that provides a compression ratio greater than the data storage ratio. Uncompressed or compressed file formats can be used, including, but not limited to: Pulse Code Modulation (PCM), Waveform Audio (WAV), Audio Interchange File Format (AIFF), MPEG-1 Audio Layer 3 (MP3), Advanced Audio Coding (AAC), Free Lossless Audio Codec (FLAC), and Apple's Lossless Audio Codec (ALAC). In some embodiments, a transmitting entity, such as an electronic stock exchange system 5XX9999 (see Figure 1), such as a trading entity in communication with the stock exchange system 5XX9999, utilizes an audio codec in the compression and encryption.

[0067] In block 1DB9999, information security component 1DX9999 encodes and encrypts the compressed data with a time-locked audio codec. Time-locked encryption is a method of encrypting data so that it can be decrypted after a specific deadline. To promote fair availability of market data 5XA0131 to market participants, time-locked encryption prevents premature decryption of protected data. In an exemplary embodiment, only the decryption key is needed to access the data. An independent time-enabled trusted third party (TTP) can be used, such as the National Institute of Standards and Technology atomic clock. The sender of the encrypted data uses a secret share to split the key between the data receiver and the trusted third party. In a secret share, each member of the group is assigned a share of the key. The key can only be reconstructed if enough shares are combined. Individual shares are useless on their own. The trusted third party also receives a representation of if it can decrypt the contents. For decryption, the receiver connects to the trusted third party, and the two use secure multi-party computation to generate the decryption key. In secure multi-party computation, the recipient and a trusted third party jointly compute a function over an input (a share of a key) while keeping the input private. The multi-party computation can include an embedded current time value and a representation of when decryption of the content is permitted. Advantages of time-locked encryption include: (a) the recipient already has the encrypted content and the trusted third party does not need to store it, (b) the entirety of the decryption key is never released to a single entity, so theft from one entity cannot compromise the key, and (c) the decryption time can be kept private from the trusted third party if desired. A new key and a new time limit can be periodically updated to avoid reuse of the decryption key.Additionally, methods of eradication techniques may be used to delete data as soon as it has been transmitted or used (such as overwriting data with the goal of completely destroying all electronic data present on digital media).

[0068] In block 1EA 1304, the output and storage management component 1EX 1304 stores the encrypted and compressed data. In an exemplary embodiment, depending on data loss prevention and business continuity planning policies and available budget, the data is stored in a designated top-level parallel file system 0XK 1304 or second-tier storage 0XL 1304, and the archive data is periodically separated and purged within a disaster recovery archive library 0XM 1304 (see Figure 2). Data Loss Prevention (DLP) is a software product that allows administrators to classify and protect sensitive or important information using business rules to prevent unauthorized end users from accidentally or maliciously sharing the data. Business continuity planning is the process of creating a system of prevention and recovery to address potential threats. Optionally, the encrypted and compressed data can be streamed through some protocol or gateway to another system or a third-party system (block 1EB9999).

[0069] Block 1EC9999 validates the external access format and other requirements for the encrypted and compressed data. Example formats include, but are not limited to: JSON, CVS, XBRL, or XML. Block 1AB9999 can convert the data between musical notation, metric tree representations, traditional financial data formats, or other desired formats, as needed, before compressing it. The encrypted and compressed data can then be shared (Block 1ED9999).

[0070] In block 1EE9999, upon receiving data from a third party, the data is decoded with an audio codec by information security component 1DX9999 (block 1DC9999) and decompressed by compression component 1CX9999 (block 1CB9999).

[0071] As further described below with reference to Figure 18, when pulling the timeline of events during the trade reconstruction process (block 3AX1206), block 1AC9999 provides links to related reference data 5XB0131, output from voice and electronic communications 5DA9999, news feeds 5DB9999, and other market event records that are tagged with the corresponding trade order stream 4AA0130 or market maker pricing record system 4CX9999 for the same period, as applicable.

[0072] Analysis System

[0073] 7 illustrates a method of providing trade analysis performed by an analysis system 2XX100 according to some embodiments. The analysis system 2XX100 receives output from a data processing device 1XX1101. Alternatively, the analysis system 2XX100 receives the trading order stream 4AA0130 and reference data 5XB0131 directly from an order management / execution control system 4AX0211. Alternatively, the analysis system 2XX100 receives quotes, orders, and trade information from a market maker quoting system 4CX9999, which replaces the trading order stream 4AA0130. Other input data sources may be used as an alternative to the trade order stream 4AA0130, including, but not limited to, data from the U.S. Securities and Exchange Commission's Market Information Data Analysis System (MIDAS) 6XX9999 or the U.S. Financial Industry Regulatory Authority's "Order Audit Trail System" (OATS) or Combined Audit Trail (CAT) system, data residing on self-regulatory organizations (SROs) or other trading platforms (such as the New York Stock Exchange [NYSE] or Nasdaq [NASDAQ] stock exchanges 5XX9999), and clearing house systems, such as the Depository Trust and Clearing Corporation [DTCC] (5CX9999).

[0074] In block 2AX0101, the base control process 2AX0101 reviews the trade instruction against a control list or predefined rules 2JA0113. In some embodiments, the control list or predefined rules 2JA0113 are desk or trader specific. For example, the business policy 2JB0301 may prohibit certain order types, leverage, or derivatives depending on the nature of the trading desk and the trade limits set for different traders. If a control violation is found, the base control process 2AX0101 rejects the trade order or the trade is flagged or quarantined, which is stored in the flag / quarantine database 2TX0122.

[0075] In block 2BX0104, for trade orders that pass through the basic control process, the detection engine 2BX0104 examines the trade orders to determine which series of trade orders or processing trades match a pattern of irregularity, indicating potential market manipulation, or other onset signals stored in the trade database 2TX0120. If the trades match a pattern of irregularity, the detection engine 2BX0104 flags the matter in the flag / quarantine database 2TX0122 for management action. In block 2DX0105, the detection engine 2BX0104 further applies more stringent checks or filtering processes using the model and logic component 2DX0105 and advanced filtering criteria 2JC1207. Thus, the detection engine 2BX0104 applies a hybrid approach that combines pre-configured detection algorithms and pattern recognition techniques for effective detection and identification of abnormal or undesirable trading activity (e.g., conflicts of interest with clients).

[0076] FIG. 8 illustrates in more detail the analysis performed by the detection engine 2BX0104 according to some embodiments. In block 2BA0801, the detection engine 2BX0104 sets an initial score for the trade order at the start of the process performed by the detection engine 2BX0104. The initial score is set according to the management plan 2JB0301, in particular the risk appetite statement. The initial score can be customized to a particular trading desk or trading group, for example, to reflect different risk exposures to different trade operations. The initial score can be adjusted using a due diligence fit method, as described below with reference to FIG. 17. The customized due diligence method puts things in context and ensures that it is fit for purpose to tighten or relax the respective controls (e.g., the order is initiated by a trader on a monitored list, or is based on a different market environment, the nature of the trade with the client or counterparty, the characteristics of the traded product, and the characteristics of the risk, liquidity conditions, and inventory portfolio consideration factors). Various parameters in the advanced filtering criteria 2JC1207 used by the detection engine 2BX0104 for comparison may be configured via a customization process and are further described below with reference to FIG. 17. In block 2BE0206, trading activities with scores that meet the set thresholds may be considered normal or desirable (or considered reasonable in the context of U.S. Volcker compliance). Those trading activities with scores that do not meet the set thresholds may be considered trading irregularities or undesirable (or do not meet certain exemption criteria in the context of U.S. Volcker compliance) and may be flagged or quarantined in the flag / quarantine database 2TX0122.

[0077] The detection engine 2BX0104 leverages the results of the Models and Logic 2DX0105 calculations to objectively run multiple rule-based processes in parallel. Through a review of factors such as the frequency of trading a particular instrument at a particular venue, the score of the trade order being processed is skewed to reflect whether it is more likely or less likely to be irregular. If the trade is not a frequently traded instrument or venue of the trading desk 4DX0505, the Models and Logic component 2CX0105, described further below, is used to perform ABC analysis (block 2DD0805) to explore and identify the value category of the trade. In block 2BB0812, the score is adjusted accordingly to reflect that the trade is more likely to be flagged or quarantined, taking into account any updated filtering criteria 2JC1207. ABC analysis is the analysis of different items with different importance and which should be treated or controlled differently. The most frequently traded instruments and venues are assigned the highest values, and the least frequently traded instruments and venues are assigned the lowest values.

[0078] Detection engine 2BX0104 determines whether market making or underwriting traders are likely to have active inventory that exceeds the Reasonable Expected Short-Term Demand Forecast (RENTD), or whether the risk of mitigating hedges exceeds the hedge exposure limit, or whether financial transactions exceed the funding needs of the liquidity management inventory plan. Reasonably expected short-term demand and inventory plans are calculated to consider whether trading activity is outside of the "reasonable" range or market time. Reasonably expected short-term demand and inventory plans are described below with reference to Figures 15 and 16. If trading orders cause excesses that exceed limits or timing irregularities, detection engine 2BX0104 determines whether the trading activity is related to a sudden market disruption, (e.g., a rapid change in market volatility calculated by some frameworks and algorithms). Excesses during sudden market disruptions may qualify for exemptions under the U.S. Volcker Rule if certain mitigating risk hedges meet the trade exemption requirements. Had there been no sudden market disruption, that particular trade would not only have been considered a high-risk proprietary trade, and thereby the appropriate skewing of the score (block 2BB0812), but would have been flagged or quarantined for administrative action. It may also pose unnecessary risk to the bank if the bank enters into a non-customer short selling trade in anticipation of a sales order from a client; therefore, the score should be adjusted appropriately. If the trade does not exceed the limit, the detection engine 2BX0104 determines whether the trade has exceeded the life of the hedge (i.e., the duration of the hedge protection, as further discussed below with reference to Figure 16), another trigger of concern that the life of the hedge trade activity should be flagged or quarantined for administrative action.

[0079] In an exemplary embodiment, if the trade is not a customer transaction, and if the risk and market price have moved per the pattern recognition process, the score is adjusted accordingly (block 2BB0812) based on the magnitude of the move, the larger the move, the more likely the trade order will be flagged or isolated for irregularity concerns. "Market price moved" refers to an act that creates a buying or selling momentum effect in the market. Risk measures per the framework and algorithm are used to gauge market conditions, and the entity may change hedging trading instruments and / or volumes to adjust to the move. Regardless of whether the trade is a customer transaction, if the trade order has a disproportionately large daily trading volume with non-customers, the score is adjusted based on the magnitude of the imbalance (block 2BB0812), the larger this imbalance, the higher the likelihood of a potential conflict with a customer (block 2BD0814).

[0080] In another embodiment, the score of a trade order being processed is skewed through a review of factors such as agency trades on behalf of clients while trade size or trade timing is inconsistent (block 2BB0812). The greater the deviation, the more likely it is to be suspected of front-running or other unethical behavior if other symptoms appear. These symptoms include, but are not limited to, when a bank wants to escape fiduciary responsibilities, flipping the switch of a “client” account to “counterparty” and then flipping the switch back to “client” in order to qualify for some exemption and dodge regulatory scrutiny. Another symptom is when the market maker’s risk profile exceeds a certain threshold (i.e., the risk characteristics of a position taken in the context of a type of market making) based on a calculation by the Models and Logic component 2DX0105 (block 2BC0811). The score is adjusted based on the magnitude of the change (block 2BB0812).

[0081] In another embodiment, if the trade is related to a risk mitigating hedge, the detection engine 2BX0104 determines whether the trade purchases a credit default swap [also known as a CDS], but the company's inventory position 4BA0132 (from a Portfolio Management System (PMS) or Investment Book of Record (IBOR) 4BX0132) indicates that the company has no related underlying positions (i.e., buying a "naked" credit default swap, which is a high-risk proprietary bet). The purpose of a credit default swap is hedge protection. But if the company holds no related underlying positions, there is nothing to protect against. Thus, a naked credit default swap does not qualify for the risk mitigating hedge exemption requirements under the U.S. Volcker Rule or the risky nature of such trading activity would distort the score, and require appropriate generating an alert or escalating the issue (block 2BB0812).

[0082] In another embodiment, if the trade is related to underwriting, the detection engine (Block 2BG0706) determines whether the trade is a bond swap, an option, a short sale, or if the trade activity exceeds the respective underwriting period or if the bank is a syndicate member of the corresponding underwriting lot. If the trade is a bond swap, the trade may only qualify under the market exemption, but does not meet the underwriting exemption requirements of the U.S. Volcker Regulation. If the trade order is an option and it is placed during a period of falling markets, the trade may only qualify under the underwriting exemption risk mitigation hedge exemption of the U.S. Volcker Regulation. If the trade is a short sale, the detection engine 2BX0104 examines the underwriting logbook 2DB0421 (see FIG. 15) to determine whether there is a price limit for the particular underwriting lot. If the short sale order is placed during a market decline, the trade may only qualify for the underwriting exemption risk mitigation hedge exemption of the U.S. Volcker Regulation. If the trade order exceeds the underwriting period as stated in the underwriting logbook 2DB0421 and the bank is not a syndicate member of the respective underwriting lot but exceeds the non-member threshold set by the relevant underwriting agreement, then the trade order will not meet the parameters and will warrant a distortion of the score (block 2BB0812) and may lead to the generation of an alert (block 2BF0207) or escalation of the issue.

[0083] In another embodiment, a "toxicity or profit analyzer" may be implemented in combination with a scoring and filtering approach according to an embodiment of the present invention to holistically track and respond to "toxic" order flow. Toxic order flow occurs in scenarios where trades anticipate losses above a threshold or worsen the maximum drawdown rate or Sharpe ratio [Sharpe]. The mechanisms of onset signal detection, modeling investment strategies, and the ability to generate timely and meaningful alerts can also be directed toward trade analysis to monitor market liquidity, best execution, or pursuit of alpha opportunities. An embodiment of the detection engine 2BX0104 is not driven solely by a set of predefined rules. Instead, the detection engine 2BX0104 uses a hybrid approach that includes both a set of rules and a pattern recognition process to identify erratic trading activity.

[0084] FIG. 9 illustrates a pattern recognition process that compares Complex Event Processing (CEP) lessons with trade order data or processed trades according to some embodiments. Once the trade patterns are converted into metric trees by the data processor 1XX1101, the trade reconstruction component 3AX1206 of the review system 3XX0140 populates the corpus or Complex Event Processing lessons, which are then stored in the lesson database 2TX0120, as further described below and with reference to FIG. 18. Market manipulation often involves a series of transactions rather than a single transaction. This includes deceptive price movements and the appearance of fictitious market forces on a financial instrument, where profits are unfairly realized from trading in the opposite direction to a false or misleading market environment, and may be prohibited conduct under U.S. or international securities regulations. Potential market manipulation typically involves characteristics that resemble a combination of the following "triggers": (a) Continuous alpha trades with large cumulative losses; (b) unusual trading volume (rigged-up volume accompanied by a sudden drop in price); (c) inexplicable run-ups, run-downs, or spikes in prices; (d) Suspected artificial pricing just before the market closes; (e) Inconsistency in trading style with rapid reversals in direction; (f) frequent buying and selling between bank holding companies (BHCs) or their affiliates; (g) dealing with concentrated groups of dealers; (h) suspected price speculation on or around the date of an initial public offering (IPO); (i) Irregular activity in infrequently traded small-cap assets (for small cap stocks that generally do not have high volume, a sudden large number of shares being traded could be a sign of unfair trading (market manipulation)), (j) accumulated large positions of a size greater than their constituent percentage of the supply; (k) A series of heavy sell orders dominating a long position; (l) offloading substantial non-performing assets to the retail sector; (m) Retailers rarely square their pump positions, (n) erosion of market liquidity due to an increase in perceived liquidity; (o) Squeezing and questionable off-street finance corners; (p) markets flooded with devalued collateral; (q) Many margin calls in case of selling; (r) Suspicious setting prices using long calls, with synthetic calls; (s) algorithm deployment errors or trading glitches due to control offences; (t) the risk of fluctuations in market prices, volatility and / or instability; (u) tight two-way price quotes with a high volume of cancelled transactions; (v) Substantial orders issued in revision of estimates.

[0085] A single "trigger" as described above does not constitute a violation. However, the legitimacy of trading activity may be challenged if it occurs in a sequence similar to the set of triggers in the trading database 2BX1104, examples of which are listed in Table 1 and shown in Figure 10.

[0086] As shown in Figure 10, the segmentation and grouping of trading styles or patterns helps to speed up the comparison process in the comparative analysis described below, and avoids the need to compare with all lessons in the lesson database 2TX0120. The segmentation and grouping of trading styles or patterns represents market change signals and is suitable for reconfiguring, customizing, and updating the control list 2JA0113 and advanced filtering criteria 2JC1201. Historical cases can be used as complex event processing lessons stored in the lesson database 2TX0120 to train the analysis system 2XX0100 through the crowd computing component (block 2FX0107), as described below, and improve the ability of the detection engine 2BX0104 to recognize potential market manipulation, market change signals, the possibility that a synthetically created trade or a series of trading activities will result in market price movements of one or more financial assets against the plan, or other signals.

[0087] Referring to Figure 9, a matching process is performed to compare the "track" with the "triggers" stored in the lesson database 2TX0120. When the pattern of the track resembles the pattern of the trigger (block 2CM1105), a trigger counter is updated (block 2CN1104). The score of the trade order is adjusted for this trigger. The trade order can then be scrutinized as needed by the crowd computing component 2FX0107. It is also determined whether the track resembles the set of triggers in the lesson database 2TX0120 (block 2CO1104). If so, it is determined whether the similarity indicates a market change signal (described below with reference to Figure 19) or indicates risk and market price has moved for the detection engine process described above (Figure 8), or is recognized as a synthetically created trade (described below with reference to Figure 11).

[0088] A monophonic approach, a polyphonic approach, or a combination of monophonic and polyphonic approaches can be used to compare the trading data with the lesson database 2TX0120. For the monophonic approach, the pattern recognition component 2CX0904 performs a trading normalization process (block 2CA1101) where the trading data is parsed and separated into the lowest dimensions. For example, cancelled trading orders and bid / ask orders are parsed and separated into "tracks". Then, pitch and rhythm are encoded (blocks 2CB1101 and 2CC1101) using the tuning function of the data conversion composer 1AX1101 to spot any anomalous activity in "solo" mode (see Figure 4, block 2CE1104). Simpler patterns, such as the payoff curve shown in Figure 12, may be removed from the "tracks" and "triggers" (block 2CD1101). The melodic matching process (block 2CF1104) compares the stripped out "tracks" with "triggers" stored in the lesson database 2TX0120. These "triggers" can be simple payoff patterns: long, short, covered calls, protective puts, butterfly spreads, or strangles (see Figure 12). Although the monophonic approach is relatively slower than the polyphonic approach, the monophonic approach allows more detailed information to be presented as evidence. Also, the "triggers" help form the basis for determining whether a combination of trades may become a synthetically created trade, which is reviewed by the backstop guarantee component 2EX0106.

[0089] As for the polyphonic approach, the pattern recognition component 2CX0904 captures the temporal and hierarchical structure in transforming the trade information into a metric tree using the data transformation composer 1AX1101 (block 2CH1101). A case is labeled "systemic" if the number of cases of the same genre exceeds a set threshold (block 2CI1101). Machine learning methods are used in the similarity analysis (block 2CJ1104) to look for similarities between the trade data in the lesson database 2TX0120 and the "polyphonic" triggers or lessons. Such a similarity analysis is faster than traditional approaches because the size of the metric tree structure is smaller, saving processing and other computing resources. The accuracy of the similarity analysis depends in part on the quality of the polyphonic triggers or lessons. Thus, the training set can be constructed to minimize overfitting or underfitting of the model. Alternatively, once the metric tree has been constructed (block 1AA1153, see Figure 6), it can perform the comparison (block 2CL1104) using a propagation or partially labeled tree approach (block 2CK1104), which places more importance on the information hierarchically contained in the tree than on the tree structure.In some embodiments, the partially labeled tree approach involves: (1) calculating the average probability of finding a labeled leaf of a descendant of an unlabeled internal node; (2) recursively calculating until no trade activity / metric tree similar to the trigger stored in the lesson database 2TX0120 is found within the corresponding time period (i.e., no match, thus passing the pattern recognition 2CX0904 checkpoint); (3) using nearest neighbor rules or other classification protocols or algorithms to measure the distance between the lessons in the lesson database 2TX0120 and other metric trees in the lessons stored in the lesson database 2TX0120; (4) organizing the lessons in the lesson database into genres (see Figure 17 below) and using the trigger counter 2CN1104 to identify the set of lessons that can be matched, which uses the distance, genre, and trigger counter to identify lessons that match the metric tree. The trigger counter is used to identify the subset of lessons that can be matched with the metric tree. For example, referring to Table 1, when trigger "j" is matched, the trigger counter for "j" is updated. The matching process can determine from the updated trigger counter of "j" that lessons (i) and (vi) are likely matches. The matching process then compares only the remaining lessons with the subset of lessons compared to the comparisons described above to optimize the matching process. The score of the trade activity is adjusted by increasing the weighting each time it matches a lesson trigger. For example, referring again to Table 1, the score is adjusted for the match that triggers "b" in lesson (i). As the matching process subsequently matches triggers "e", "n", and "o", the score is adjusted by increasing the weighting, i.e., to reflect the increased likelihood of irregularity in the trade match of "o" having the most weighting.

[0090] Continuing to refer to FIG. 9, the nearest neighbor rule or other classification process and / or classifier may be implemented using a classification algorithm and / or classifier creation process. A classification algorithm, as used in this disclosure, is defined as a process in which a computing device derives a model, called a "classifier," from training data to classify inputs into categories or bins of data. Classification can be performed using linear classifiers, including but not limited to logistic regression, naive Bayes classifiers, nearest neighbor classifiers, K-nearest neighbor classifiers, support vector machines, least squares support vector machines, Fisher's linear discriminant, quadratic classifiers, decision trees, boosted trees, random forest classifiers, learning vector quantization, and / or neural network-based classifiers.

[0091] As a non-limiting example, still referring to FIG. 9. The computing device may be configured to classify or generate a classifier using the K-Nearest Neighbor (KNN) algorithm. The "K-Nearest Neighbor" algorithm used in this disclosure includes classification methods that utilize feature similarity to analyze how close out-of-sample features are to training data, classifying input data into one or more clusters or / and feature categories. This may be done by representing both the training data and the input data in vector form, using one or more vector similarity measures to identify classifications in the training data, and determining the classification of the input data. The "K-Nearest Neighbor" algorithm includes: specifying a K value or selecting the input training data that is most similar to a particular sample; determining the most common classifier for entries in the database; and specifying a K value or number that classifies the known sample. This may be done recursively, or iteratively, which may generate a classifier that is used to classify the input data as further samples. For example, an initial set of samples may be run to cover initial heuristics or "first guesses" with outputs and / or relationships that are seeded. As a non-limiting example, using expert input received according to any process described herein. As a non-limiting example, an initial heuristic might include ranking associations between the input and elements of the training data. The heuristic might include selecting the top associations and / or a number of training data elements.

[0092] With continued reference to FIG. 9, a K-nearest neighbors algorithm may be generated that operates by calculating the proximity between two or more elements of data and identifying the k-closest training data elements to the element being analyzed according to such distance and / or proximity calculation. For example, the K-nearest neighbors algorithm may generate a first vector output including the data input clusters, generate a second vector output including the input data, and calculate the distance between the first and second vector outputs using any suitable criterion, such as cosine similarity, Euclidean distance measure, etc. Each vector output may be represented, without limitation, as an n-tuple of values, where n is at least two values. Each value in the n-tuple of values ​​represents: a measurement or other quantitative value, or attribute, associated with a particular category of data. Examples of which are provided in more detail below: The vectors may be represented, without limitation, in an n-dimensional space with an axis per category of values ​​represented by the n-tuple of values, such that the vector has a geometric direction that characterizes the relative amounts of the attributes in the n-tuple compared to one another. Two vectors are considered equivalent if their orientations, and / or the amount of relative values, are the same when compared to one another within each vector. Thus, as a non-limiting example, a vector represented as [5,10,15] may be treated as equivalent for purposes of this disclosure as a vector represented as [1,2,3]. Vectors may be more similar if their orientations are more similar, and more different if their orientations are more dissimilar. However, vector similarity may alternatively or additionally be determined using an average of the similarities between similar attributes, or other measures of similarity appropriate for any n-tuple value, or an aggregation of numerical similarity measures for purposes of the loss functions described below. The vectors described herein may be scaled so that each vector represents each attribute along an equivalent scale of values. Each vector may be "normalized" or divided by a "length" attribute, an example of which would be a length attribute derived using the Pythagorean norm. [ka] , where ai is the attribute number i in the vector. Scaling and / or normalization serves to make vector comparison independent of the absolute amount of attributes while still maintaining the dependency on attribute similarity. This can be advantageous, for example, when cases represented in the training data are represented by different amounts of samples, resulting in proportionally equivalent vectors with different values.

[0093] The K-nearest neighbors algorithm and / or other proximity-based classification algorithms may alternatively or additionally employ other standard and / or distance calculations between any two data structures, including, as a non-limiting example, distances calculated as described herein between trees, such as metric trees.

[0094] The partially labeled tree comparison algorithm is based on the assumption that the match value between a labeled leaf and an unlabeled internal node is the average value of the probability of finding that leaf in the descendants of that internal node. This comparison method does not require laboriously inserting or deleting nodes, but it only measures the probability of finding a matching label, which means that the hierarchical information contained in the tree is more important than the structure of the tree. In this exemplary embodiment, if we consider two trading sequences that play at different tempos, perfect clock synchronization is similar to the fact that the two trading sequences must change the two tracks to the same tempo before their similarity can be measured. The two tracks can have the same tempo (e.g., "long, long, short, long, short, and short" structural connections), or the relative distance between cross levels of the temporal hierarchical structure, etc. Thus, the "jiggling" process of inserting or deleting nodes in a fully labeled tree is only relevant if it is related to the "tree structure" (i.e., the "shape" of the plotted chart on which "technical analysis" relies, which causes a lot of inaccuracies when measuring vectors graphically; for example, changes in shape affect the angles of linear vectors). However, it fails, as it does not focus on measuring or highlighting information "hierarchically". In the "partially labeled tree" approach, the match value is considered as distance, and according to the nearest neighbor rule, the melody classification of the trade activity closest to the query is taken as the corpus lesson stored in the lesson database 2TX0120. This results in more accurate results and more insightful discoveries than the traditional method (block 2CG0904), with less errors and higher clock synchronization tolerance. Also, the analysis runs faster than the traditional method, further saving processing and other computing resources.

[0095] In some embodiments, the selection between the monophonic and polyphonic approaches is manually selected by a user, in other embodiments the selection is performed automatically without user intervention, where the quickest path method, least error in use, and most suitable method for the purpose is selected, as described in FIG. 17 below with reference to FIG.

[0096] 11 illustrates a process performed by the backstop assurance component 2EX0106 according to some embodiments. The backstop assurance component 2EX0106 performs gatekeeping of trade activity that was not detected by the base control component 2AX0101 and the detection engine 2BX0104. These activities indicate significant risk or significant violations, such as synthetically created trades that bypass controls, or potential impacts due to lack of action for cases of temporary tolerance or delay.

[0097] The backstop assurance component 2EX0106 reviews trade activity in multiple parallel processes. In the first process, using the output from the model and logic component 2DX0105, the backstop assurance component 2EX0106 determines whether the aggregate risk matches any of the predefined criteria 2DA0906, i.e., results in an "out of parameters" condition (block 2EF0906). If the aggregate risk does not match any of the predefined criteria, the backstop assurance component 2EX0106 determines that there are no "red flags" based on these criteria. If the aggregate risk does match any of the predefined criteria, the backstop assurance component 2EX0106 determines that the trade activity poses a significant exposure, a significant conflict of interest, or a safety and soundness threat to the entity. In response, it flags the trade as having a "materiality" concern (block 2EG0909). In this exemplary embodiment, the predetermined criteria include, but are not limited to: whether individual non-bank counterparty exposures exceed a threshold, whether the bank's common equity Tier 1 / Tier 2 capital is within a threshold, whether related party exposures are less than single or connected party trades, whether related party transactions or write-offs exceed a threshold, whether net exposures of a particular asset class or commodity exceed a threshold. Each threshold shown here takes into account the validity of exemptions configured by the user and associated with the trade order. The model and logic component 2DX0105 continues to run the numbers on these measurements, and thus whenever the next trade activity may trigger a potential external parameter situation, the case is escalated for management consideration with respect to possible stop loss or other actions (block 2EE0212). This inventive feature addresses an industry-wide problem that despite entities having risk models to identify large exposures, the entities do not have robust control mechanisms to stop losses in time to avoid the consequences of exposure.

[0098] In the second process, (block 2EA0901) the backstop guarantee component 2EX0106 examines a set of trade activity in the corresponding time period that has been identified by the pattern recognition process (block 2CX0904) as a synthetically created target trade (see Figure 9 above). Figure 12 illustrates the identification of synthetically created trades that resemble payoffs in trade orders or processed trade data that would otherwise be restricted or have the effect of bypassing the control of the detection engine 2BX0104 by the basic control component 2AX0101 according to several methods. A synthetically created trade is a financial instrument that is artificially created by simulating another instrument that has the combined characteristics of a collection of other assets. For example, as shown in Chart A, if a trader is attempting to generate payoffs on a short put for legitimate trading purposes but a put option is not available in the market, the trader may legitimately use financial engineering techniques to hold a long position in a security and combine it with a corresponding short call option at a particular strike price for the same time period to achieve the same effect. There are other payoff replicas, including but not limited to: puts (Chart B), calls (Chart C), short calls (Chart D), butterfly spreads (Chart E), strangles (Chart F), etc. Charts A through F illustrate an options model that is known in the art and will not be described further here, the Black-Scholes put-call parity formula.

[0099] Returning to Figure 11, if the trade order and sequence of recent trade activity are determined to be synthetically created trades (block 2EA0901), the monophonic and polyphonic hybrid partial label tree approach (described above with reference to Figures 6 and 9) propagates the equivalent trade pattern. To determine whether the synthetically created trades are abusive, the backstop guarantee component 2EX0106 sends the equivalent trade pattern for review to the basic control component 2AX0101 and the detection engine 2BX0104 (block 2EB0902), which determine whether they have the same effect as an attempt to circumvent the controls set by the basic control component (block 2EC0902). If they have an abusive effect, the trade order is flagged by the backstop guarantee component (block 2ED0910).

[0100] For example, a dealer is seeking a position to profit if bond prices fall. The dealer simultaneously enters into a reverse repurchase agreement and a sale of the collateral. The dealer borrows and sells the bonds, lending the proceeds of the sale to the reverse repurchase agreement. At the end of the repurchase period, the dealer's loan is repaid at the agreed upon interest, and the dealer buys back the bonds in the open market and delivers them to the reverse repurchase agreement. Such example activity requires pattern recognition in a trade order and a series of trading activities in a corresponding period. If a trade order and a series of trading activities in a corresponding period do not have the effect of a synthetic short sale, the backstop guarantee component 2EX0106 determines whether the trading activity has the effect of a total return swap, or a synthetic forward. A total return swap involves an agreement in which one party makes payments based on a set rate and the other party makes payments based on the return of an underlying asset (usually an equity index, a loan, or a bond). A synthetic forward involves a single investor holding both a long call option and a short put option simultaneously. If the trading activity does not have the effect of a total return swap or synthetic forward, the trade would be legitimate in the context of U.S. Volcker Rule compliance. If the trading activity has the effect of a total return swap or synthetic forward, the effect is input to the base control component 2AX0101 and the detection engine 2BX0104, which returns an adjusted score to take into account the "effect."

[0101] In the third process, once a trade receives an approved temporary tolerance via the case management system 3CX0140, the trade is further subjected to follow-up monitoring (block 2EH0908) and flagged as a concern that needs to be further evaluated to determine whether aggregate risk exists (i.e., bypass of controls, blocks 2EC0902 and 2EC0910). Temporary tolerances may be granted under certain conditions, such as when excesses must be squared within a certain time period. Follow-up monitoring ensures that the conditions are met appropriately in the set timeframe. The case management system 3CX0140 closely monitors and prioritizes temporary tolerances and unclosed cases of delinquency. The backstop assurance component 2EX0106 ensures that the cumulative effect of such tolerance or delinquent status does not cause unintended consequences or other problems that may be uncontrollable or difficult to control, and prevents abusers from exploiting the temporary tolerance process. The model and logic component 2DX0105 periodically maintains the count and reports on temporary tolerances, or how much risk is hidden in case of overdue. Trade irregularities are then flagged and sent to the case management component 3CX0140 for further processing (block 3CX0140).

[0102] FIG. 13 illustrates how parameters and bounds are defined by the model and logic component 2DX0105 according to some embodiments. The model and logic component 2DX0105 starts with a set of assumptions. In this exemplary embodiment, the assumptions are derived from the management plan 2JB0301. The assumptions may include, but are not limited to: market, client / counterparty, instructions, risk, liquidity, and inventory (see FIG. 14). The model and logic component 2DX0105 receives results and findings from the pattern recognition component 2CX0904. In block 2DH0304, the Models and Logic component 2DX0105 performs data mining of data from the Pattern Recognition component 2CX0904, as well as from other sources (such as: Market Data 5XA0131, Reference Data 5XB0131, Voice and Electronic Communications Monitoring System 5DX9999, and News Feed 5DB9999, and Audit Trail Database 3TX0121) to discover relevant business intelligence that enhances the framework and algorithms (described below with reference to Figure 14-16). This insight is used to justify changes to the model and logic, and inputs this insight into the Crowd Computing component 2FX0107, which may lead to further adjustments. Using the framework and algorithms (blocks 2DI0304 and 2DJ9999), the Models and Logic component 2DX0105 calculates results for backtesting and "what if" evaluations in combination with the Simulator 2BX0415. The results of the evaluation are used to define a set of parameters and boundaries and what ifs considered when "out of reach" (block 2DG0320), as further described below with reference to Figure 19. The parameters and boundaries are used to define or update control lists or rules 2JA0113 used by the basic control component 2AX0101 and advanced filter criteria 2JC1207 used by the detection engine 2BX0104 and backstop assurance component 2EX0106.The detection engine 2BX0104 and the backstop assurance component 2EX0106 guide the analysis system 2XX0100 in detecting trade irregularities or undesirables, monitoring trade behavior, identifying and investigating potential trade fraud. Suspicious trade orders are detected and then sent to the case management component 3CX0140 and the order book replay simulator 3BX0415 for further processing. The detection engine 2BX0104 and the backstop assurance component 2EX0106 take the calculation results from the model and logic component 2DX0105 and use them in composing the inventory plan (block 2DC0701) and the reasonably expected short-term demand (block 2DB0703) (taking into account the observed reality) and in calculating the total and aggregate risk exposure (block 2DA0906) (as explained above with reference to Figures 8 and 11). The results from the Models and Logic component 2DX0105 are further used by the Detection Engine in calculating the Market Maker's Risk Profile (block 2DF0811), looking for inconsistencies in trade size / market timing (block 2DE0810) and performing ABC analysis 2DD0805 (see Figure 8 above). The Order Book Replay Simulator 3BX0415 also utilizes the calculations and results of the Models and Logic component 2DX0105, including the set parameters and boundaries, hypothetical Profit and Loss (P&L), Sharpe Ratio, Drawdown Percentage, etc. (described below with reference to Figure 19).

[0103] FIG. 14 illustrates an exemplary framework and algorithms for use in the analysis system 2XX0100 according to some embodiments of the present invention. The framework and algorithms are used to measure multiple factors, such as market micro-structure, customers / counterparties, instruments, risk, liquidity, capital, inventory, and other considerations to determine appropriate parameters for filtering criteria 2JC1207. The framework and algorithms define what, when, and where irregularities may exist and set appropriate parameters to guide related controls. Financial institutions typically have many performance measures, such as risk, liquidity, capital, etc. These measures are prepared by different departments in silos. The framework illustrated in FIG. 14 creates the equivalent of a balanced scorecard, with appropriate focus on differences in external markets, customer and counterparty relationships (such as dispute avoidance), responsible use of financial instruments, maintenance of sufficient liquidity, risk, capital, and inventory of securities.

[0104] FIG. 15 illustrates a method for determining reasonably expected short-term demand (RENTD) according to some embodiments. Trading desk inventory should be designed to not exceed reasonably expected short-term demand of customers on an ongoing basis, such as based on historical demand and consideration of market factors. In addition, reasonably expected short-term demand should measure the reasonableness of market timing and order size of a firm's securities inventory to meet the firm's market making and underwriting plans. For market making activities, two approaches may be used. One approach is based on a recursive planning model, and the other approach is based on an event-driven model. Due to the deterministic aspects of capital markets that follow historical forecasts, a recursive planning model may be used. In the recursive planning model approach, an economic order quantity (EOQ) model is applied to the inventory of financial instruments to determine a "reasonable" inventory for reasonably expected short-term demand. The economic order quantity may be considered as the quantity that minimizes the total holding cost and order cost of the inventory, balancing the trade-off between the two. Variables considered include unit cost, order quantity, optimal order quantity, annual demand quantity, fixed cost per order, and annual holding cost per unit.

[0105] As shown in Figure 15, in the implementation of the recursive planning model, the model and logic component 2DX0105 uses a transaction cost analyzer (TCA ) to calculate the acquisition cost of a transaction (block 2DB0401), which is the difference between the price of a particular transaction if executed at the price prevailing at the time the portfolio manager decides to buy or sell and the actual price. The transaction price, including: fees, taxes, and other costs, i.e., slippage. It also calculates the holding cost (block 2DB0402), which depends on the entity's cost burden for holding various risky assets (bank capital adequacy requirements, cost of raising capital or debt to carry inventory). In this exemplary embodiment, the total acquisition (setting) cost = cost of placing an order (S) * demand (R) / economic order size (Q). In market making, the acquisition cost is generally called the "expected transaction cost" [ka] Many factors affect expected transaction costs, including, but not limited to, the competitiveness of market makers and trading platforms, tick size (the movement of the minimum price of the traded instrument), market fragmentation, and the cost of the bid / ask spread (the amount by which the ask price exceeds the bid price). In one exemplary embodiment, either a linear model or a square root model may be used to calculate acquisition costs, such as: [ka] Alternatively, an entity may use a different model that it believes best represents the costs of the entity's trading desk, such as: order capture costs, execution costs, record keeping costs, exchange costs, hedging costs, and costs associated with the facilitation process, and maintaining equilibrium bid / ask spreads. Any model used may be customized using input parameters, including configurable parameters and assumptions applicable to a particular trading desk.

[0106] In this exemplary embodiment, the holding cost is expressed as a fraction of the unit cost of the economic order quantity (C) or as the price of the security of the trade. If the market maker relies on its own capital, the cost of carrying inventory is the opportunity cost of capital (funding cost) with an adjustment to reflect the market maker's risk aversion. Preferably, an additional risk premium is included to allow the market maker's capital to take into account borrowing costs when debt financing (when expected returns on a risky asset exceed known returns on a risk-free asset). As with the computing acquisition costs, the models used can be customized using input parameters, including configurable parameters and assumptions applicable to a particular trading desk.

[0107] Once acquisition and holding costs are calculated, the tradeoff between these two costs is optimized to determine a reasonable inventory (block 2DB0403). In this exemplary embodiment, the tradeoff is optimized to minimize inventory costs. Graph A of FIG. 15 illustrates the tradeoff between acquisition and holding costs. The graph shows holding cost curve 2DB0440, acquisition (placement or order) curve 2DB0441, and total cost curve 2DB0442. The larger the market maker's inventory, the higher the average cost of capital and the wider the bid / ask spread. Thus, holding cost curve 2DB0440 slopes upwards with respect to reorder quantity. Acquisition cost curve 2DB0441 slopes downwards with respect to reorder quantity due to economies of scale. Economic order quantity (2DB0443) is set to optimize the tradeoff between holding and acquisition costs 2DB0440 through 2DB0441 to produce the minimum inventory cost. Here, the length of the recurring order cycle is equal to the periodic demand divided by the economic order quantity, the normal consumption during the lead time, plus a safety buffer. The length of the "order cycle" refers to the time interval between successive reordering actions. It is the time to replenish inventory if the inventory level reaches the reorder point. Otherwise, there may not be enough lead time to obtain inventory before it runs out. Companies may want to include a "safety buffer" rather than run out of inventory. Stylized facts are empirical findings that have a consistency that is qualitatively accepted as true, within a constructed margin of error based on observed reality. Stylized facts are incorporated in the economic order quantity calculation (block 2DB0404). In block 2DB0405, the replenishment cycle and reorder point are calculated using the economic order quantity formula.

[0108] Some of the stochastic or event-driven aspects of capital markets do not follow the historical expectations or statistical characteristics of economic order quantities described above. For these activities, an event-driven approach can be used. In the event-driven model approach, this illustrative embodiment uses the Grossman Miller model to determine what is a "reasonable" inventory of reasonably expected short-term demand. In the Grossman Miller model, market liquidity is modeled as being determined by immediacy demand and supply. Typically, the number of market makers adjusts to equate immediacy demand and supply. This determines the equilibrium level of market liquidity. Alternatively, the calculation of a reasonably expected short-term demand forecast might use "market timing" forecasting methods such as conditional expectations, Bayesian estimation, Kalman filtering, martingale measures, or a combination of these models, instead of or in conjunction with the Grossman Miller model.

[0109] In applying the Grossman-Miller model, two categories of market players are assumed: market fundamentalists (informed) and chartists (uninformed). Core market makers may be considered as market fundamentalists while other participants in the market may be considered as chartists. An entity or trading desk decides on the number of market fundamentalists based on its own experience and competitive position in a particular market. The Grossman-Miller model is based on M = σ 2 v σ 2 u Define / A: M = number of core market makers; σ 2 v = observed variance in the asset payoff, σ 2 u = the observed variance in the noise trader's stock, and A = Expected Sharpe Ratio from the trade. Market prices move quickly and frequently, in microseconds, especially in equity, derivatives, and commodity markets. History is often a poor predictor of the future in these markets. 2DB0703 Reasonably Expected Short-Term Demand / Inventory Forecast calculations measure demand at a certain fair price and when the associated trading activity is considered "reasonable". Under the US Volcker Rule, price fluctuations (i.e., delta market value) are a concern for inventory returns. Through the observation and scanning of orders in the market data feed 5XA0131, the framework and algorithms (see Figure 14) are able to identify order imbalances (situations resulting from an excess of buy or sell orders for a particular security on the trading exchange) and liquidity shocks or constraints occurring in the market. In some cases, these indicators may be included in an entity's market data subscription. The standard deviation of noise trader stocks (σ u ), the observed standard deviation of the asset payoff (σ v ), and the expected Sharpe Ratio (A) available from the trading desk, to calculate a reasonably expected short-term demand forecast, we use the Grossman-Miller inverse selection model to calculate the depth of market as: λ = A (σ v / σ u ) (Block 2DB0411). Depth of market refers to the size of the order required to move the market price by a certain amount. The Sharpe ratio is a measure for calculating risk-adjusted returns, which is the average return earned above the risk-free rate per unit of volatility or total risk. Using the depth of market (λ), it is possible to extract other parameters including: the observed mean (μ) and variance (σ) of the asset's payoffs 2 v ), and Chartist stock (σ u ) standard deviation. The capital market, consisting of two types of players, market fundamentalists and chartists, is entered next (block 2DB0412). Market fundamentalists trade periodically with chartists, and the amount of demand from chartist players is calculated as [ka] forms a rational basis for what is "reasonable" and available for market makers to trade.

[0110] Chartist inventory is used to gauge fair price with rational market timing (block 2DB0413). A market maker's trading profit is a function of the expected squared Sharpe ratio from a trade, from which a "fair price" can be calculated: P = (σ v / M) * u - μ, or alternatively [ka] ,where: M = number of core market makers; σ 2 v = observed variance in the asset payoff, σ 2 u = observed variance in noise trader's stock, A = expected Sharpe ratio from the trade, μ = the observed mean of the observed asset payoffs, and [ka]

[0111] These optimal price points are then substituted as rational market timing to measure whether market makers are facilitating or providing liquidity to the market with reasonable bid / ask spreads. By applying the Grossman-Miller model and / or alternative models to compare the prevailing average and fair prices multiplied by the expected market maker price stabilizing effect, the 2DB0703 Reasonably Expected Short-Term Demand Forecast calculation can predict or determine what is a "rational" market for a banking firm or trading desk to have:

change

[0112] For reasonably expected short-term demand forecasts, the Model and Logic component 2DX0105 captures and registers key parameters in the logbook for each underwriting job (block 2DB0421). The US Volcker rule requires new underwriting lots to be registered in order to associate or link related trade activity with a specific lot. Updates to registered lots must be recorded in the audit trail database 3TX0121 and supported by appropriate justification. The Model and Logic component 2DX0105 also enters sales targets corresponding to underwriting lots for various sales teams (block 2DB0422). Examples of entering sales targets by underwriting lot include, but are not limited to: mutual fund distributions, retirement plans and endowment funds, high net worth investors, and retail sales desks. In the process of pricing assets in the market, road shows or solicitation campaigns may be performed by banking corporations or sales desks to gauge market returns on the investment. Institutional investors may provide their Indications of Interest (IOI) regarding for commitments to purchase a certain number of shares from an underwriting lot at various prices. From this information, the Model and Logic Component for Reasonably Expected Short-Term Demand Forecasting 2DX0105 might predict how much non-IOI customers from different sales channels will purchase. The Model and Logic Component for Reasonably Expected Short-Term Demand Forecasting 2DX0105 models the underwriting sales targets (block 2DB0423) and validates the sales targets using the "what if" scenarios and backtesting features of the simulator 3BX0415. The success or completion of an underwriting obligation is often a function of a variety of factors, including: market sentiment, the marketing strength of the entity or sales team to lock in a significant commitment, and the effectiveness of the solicitation campaign. The Model and Logic Component 2DX0105 puts these factors into a forecasting algorithmic model for the Reasonably Expected Short-Term Demand calculation.Historical data can be matched to correlate sales effort, market conditions, and sales efficiency, and cross-referenced by algorithms to validate sales goals.

[0113] In this exemplary embodiment, the allocation that the banking entity commits to underwrite, with or without a greenshoe option, is the forecast or expected share of transactions that will be in the bank's inventory portfolio. Adjustments can be made to accommodate changes in market sentiment, competing products with similar risk and return attributes, and customer risk appetite. You can then set the timing (i.e. underwriting period) and inventory figures in your securities inventory plan, set parameters and boundaries for what constitutes a "reasonable" range of transactions and market times, and also what you consider to be "out of reach" see Figure 19.

[0114] FIG. 16 illustrates an exemplary method for creating an inventory plan to guide a company's risk mitigation hedging and liquidity management activities, according to some embodiments. Risk mitigation hedging and liquidity management are not technically a category of "customer demand" in the context of reasonably anticipated short-term demand for compliance with the U.S. Volcker Rule, but are activities necessary for trading operations. However, these activities impact the amount of inventory an entity should have to manage solvency and risk exposure and are considered in the creation of an inventory plan. An inventory plan is a document that summarizes reasonably anticipated short-term demand outputs, assumptions, changes in plans over time, and associated rationale for changes. Banking entities can use inventory plans to demonstrate to regulators the rationality in establishing the basis for the banking entity's inventory levels. For risk mitigation hedging categories, the risk being hedged is registered in this category (Block 2DC0310) and the expected exposure and life of the hedge are entered (Block 2DC0311). The Model and Logic component 2DX0105 calculates the expected delta hedge position for the linear hedge position (block 2DC0313) and performs correlation analysis with nonlinear hedges or receives pre-calculated inputs from internal or external sources (block 2DC0312). Based on the expected delta hedge position, it can adjust the composition of the portfolio to stay in compliance, if necessary (block 2DC0316). The Model and Logic component 2DX0105 for inventory planning forecasting then models and validates the expected delta hedge position or nonlinear hedge using the simulator's 3BX0415 "what if" and backtesting features.

[0115] For the Liquidity Management category, the Model and Logic component 2DX0105 for inventory planning forecasting calculates or receives the Liquidity Replenishment Rate (LCR) and statistical funding needs of financial institution positions, from internal or external sources (block 2DC0314). It determines the product specific contingency financial liquidity premia (block 2DC0315) and adjusts the portfolio composition as required to achieve the liquidity management plan (block 2DC0316). The adjusted portfolio composition is fed back to the Model and Logic component 2DX0105, which modifies the inventory plan or updates the advanced filtering criteria 2JC1207 via the Crowd Computing component 2FX0107, as required, see Figure 17.

[0116] Returning to Figure 7, after the detection engine 2BX0104 examines the trading activity, any trading activity outside of acceptable parameters is filtered out. The scoring methodology used is based on the magnitude of the resulting impact of the associated trades, and the system user may scrutinize certain traders, tradable objects or targets, or certain trading patterns or some triggers within a pattern by tightening or loosening the filtering mechanism, skewing the respective scores (see Figure 8). The scoring process performed by the detection engine 2BX0104 is particularly useful for addressing trading orders that are in a "gray" area (e.g., a particular trade or order may appear legitimate and comply with desk-specific controls 2JA0113, but the combined series of trades may signify anomalous trading activity or the aggregate risk level may exceed a predefined threshold deemed "significant and requiring appropriate management attention"). Once a trading order or series of trades is identified as not meeting the threshold, the trader 4DX0505 associated with the trading order may be scrutinized in the crowd computing process 2FX0107 described below (Figure 17). The identified traders, and the reason why the trade activity is flagged or quarantined, are stored in the Flag / Quarantine database 2TX0122. Once the trade passes the checkpoint in the Detection Engine 2BX0104, it is subjected to further review by the Backstop Guarantee component (block 2EX0106). If the score meets certain customizable thresholds, an alert is generated or the trade instructions and / or trade records are tagged with escalation notifications and sent to the Case Management component 3CX0140. Copies of trade orders and / or processed trade records tagged with alerts and escalation notifications are stored in the Flag / Quarantine database 2TX0122. Alternatively, administrators have the discretion to withhold trade orders from further processing in the Order Management / Execution Management system 4AX0211 by quarantining the tagged trades stored in the 2TX0122 database.

[0117] The analysis system 2XX0100 can be fine-tuned by a crowd computing component 2FX0107. The process of the case management system 3CX0140 and re-learning false positives and false negatives can be used to continually fine-tune the filtering algorithms in the analysis system 2XX0100.

[0118] FIG. 17 illustrates an exemplary method for a crowd computing component according to some embodiments. An exemplary embodiment leverages collective intelligence from a network of users (i.e., a "crowd") to monitor market behavior, fight fraud, learn exceptions, and customize various processes executed by the analytics system 2XX0100. The crowd computing component 2FX0107 continuously fine-tunes filtering rules in an active learning loop. The crowd computing component 2FX0107 receives inputs from internal and external sources, including data and metadata from within the analytics system 2XX0100 (e.g., lesson database 2TX0120, audit trail database 3TX0121, flag / quarantine database 2TX0122, etc.) and from sources outside the analytics system 2XX0100. These inputs are processed and used to update the rules / control lists 2JA0113 and advanced filtering criteria 2JC1207. The Crowd Compute component 2FX0107 further fine-tunes the filtering scores used by the detection engine 2BX0104 and the backstop assurance process 2EX0106. Users can customize how each pattern and new rule affects the score table, region or desk-by-desk, to determine the best use for their organization. Users can also share best practices they discover 2FS1209 with other Crowd users.

[0119] As a non-limiting example, a device and / or system component, such as a non-limiting order book replay simulator, may receive a plurality of data representative of a set of trading activity according to any process and / or process steps representative of a set of trading activity as described above. A computing device and / or component receives a plurality of user inputs from a plurality of user client devices, where each user input of the plurality of user inputs further includes an identification of at least a datum representing the set of trading activity, where the plurality of data representative of the trading activity and an identification of a trading irregularity associated with the set of trading activity. The identified trading irregularity may include any trading irregularity as described in this disclosure.

[0120] Still referring to FIG. 17, a plurality of data representing a series of trade activities may be converted by a computing device and / or component into training data. As used in this disclosure, "training data" is data that includes correlations that a machine learning process, such as a nearest neighbor classifier, may use to model relationships between two or more categories of data elements. For example, and by way of non-limiting example, the training data may include a plurality of data entries, with each entry representing a set of data elements that have been associated, recorded, received, and / or generated together. Data elements may be correlated by shared presence in a particular data entry, by proximity within a given data entry, and the like. By way of non-limiting example, such data entries may be created following identification of user input as described above. The plurality of data entries in the training data may exhibit one or more trends in correlations between categories of data elements. For instance, and without limitation, higher values ​​of a first data element belonging to a first category of data elements tend to correlate with higher values ​​of a second data element belonging to a second category of data elements, indicating a proportional or other mathematical relationship that may link values ​​belonging to the two categories. Multiple categories of data elements may be associated in the training data according to various correlations. Correlations indicate causal and / or predictive links between categories of data elements and may be modeled as relationships, such as mathematical relationships through machine learning processes, as described in more detail below. The training data may be formatted or organized by categories of data elements by associating the data elements with one or more descriptors that correspond to the categories of the data elements. As a non-limiting example, the training data may include data entered in a standardized format by a person or process that enters designated data elements into designated fields in a form, which may be mapped to one or more category descriptors. Elements of the training data may be linked to category descriptors by tags, tokens, or other data elements.For instance, and without limitation, the training data may be in a format that links the location of data to categories, such as a fixed-length format, a comma-separated values ​​format, and / or a self-describing format such as Extensible Markup Language or Extensible Business Reporting Language, allowing a process or device to discover the category of the data. Alternatively or additionally, the training data may include elements in the form of musical compositions and / or metric trees, for instance including tree representations of musical compositions and metrics of trade activity data, as described above.

[0121] Alternatively or additionally, the training data may contain one or more elements that are not classified, i.e., they may not contain a format or descriptor for some elements of the data or may not have a data schema (i.e., unstructured data). Machine learning algorithms and / or other processes may sort the training data according to one or more classifications, for instance using natural language processing algorithms, tokenization, finding correlation values ​​in raw data, structured query languages ​​[NoSQL], object-oriented programming, and schemaless or schema-independent multi-model databases. Categories may be generated using correlation or other processing algorithms. As a non-limiting example, in a corpus of text, phrases that make up a number "n" of noun-like compounds modified by other nouns may be identified according to the statistically significant prevalence of n-grams that contain such words in a particular order. N-grams are classified as elements of language like "words" that are tracked similarly to single words, generating new categories as a result of the statistical analysis. Similarly, data entries containing textual data, such as a person's name, may be identified by reference to a terminology, dictionary, or other list of terms and automatically associated with a descriptor or specific format by machine learning algorithms and / or ad-hoc classification by the data entry. The ability to automatically classify data entries may allow the same training data to be applied to two or more different machine learning algorithms described in this disclosure. As non-limiting illustrative examples, boosting, bootstrap aggregation, and stacking are "meta-algorithmic" machine learning approaches that combine several machine learning techniques into a single predictive model to reduce bias through boosting, reduce variance through bootstrap aggregation, or boost predictive power through stacked alias ensembles. Boosting is a two-stage approach that first generates a set of average performing models using a subset of the original data and then "boosts" their performance by combining them using a specific function included as a majority voting function to reduce bias in the model.Bootstrap aggregation generates additional data for training from the original data set, for example in combination with repetition to generate a multiset of the same cardinality / size as the original data, and by increasing the size of the training set, the variance of the model is reduced. Stacking introduces a meta-level rather than just an empirical formula for the weighting function, as it applies multiple models to the original data, and it increases predictive power based on using a different model or approach to estimate the inputs along with the output of each model to determine which model produces the best results. Training data used in a computing device as described in this disclosure may associate any input data described in this disclosure with any output data described in this disclosure. As a non-limiting illustrative example, training data may associate inputs representing patterns and / or sets of trading activity with outputs representing irregularities in trading.

[0122] In this exemplary embodiment, the case management system 3CX0140, via the simulator 3BX0415, determines whether the flagged alert is a false alarm, affirms the genuine case, and seeks management approval for temporary allowances, modifications, and remedial actions. Examples include, but are not limited to, modifications: amend trade order, cancel trade order, management plan 2JB0301, control list 2JA0113, and advanced filtering criteria 2JC1201. This may be performed without limitation as part of the generation of training data. For instance, and without limitation, converting the plurality of data representing the set of trading activities and the plurality of user inputs into training data may include classifying each user input and data into a genre of trading activity previously identified. The classification may be performed without limitation using a classification algorithm and / or classifier described in this disclosure. The computing device and / or case management system 3CX0140 may convert the plurality of data representing the plurality of trading activities and the plurality of user inputs into training data as a function of the classification, for instance, by creating one or more sets of training data for one or more genres. As such, further classification may occur within each genre, as described in further detail below. Processes such as genre classification and / or identification may be used as filters to exclude entries for inclusion in the training data. As a non-limiting example, the computing device and / or case management system 3CX0140 may receive from at least one of a plurality of user client devices: a set of trade activities exhibiting a predetermined pattern indicative of false positives and / or false negatives, a set of trade activities matching a pattern indicative of false positives and / or false negatives, and a set of trade activities shown in the training data.As a further non-limiting example, the process of converting the data to training data may include classifying the set of trading activities into genres that identify false positives as defined above, and including the set of trading activities in the training data as shown. The computing device and / or components of the system may identify, without limitation, genres that represent new genres by performing a classification process that classifies a particular pattern into a genre when determining that the classifier does not classify the pattern being analyzed into an existing genre and generates a new genre that matches the pattern. The generating may also include, without limitation, receiving a user identification of a new genre, identifying a cluster of patterns that are close to the existing genre under a distance metric, or identifying a pattern that is close to the pattern under analysis. The new genre may be modified using any process for modification of an existing genre. The conversion to training data may include matching a set of trading activities from a set of multiple trading activities to a stored pattern using a nearest neighbor algorithm, where the matching may be performed using any process described herein for matching a pattern of trading activities to other patterns. Additional processes may include, without limitation, simulation, backtesting, and / or relationship detection, as described in more detail below with reference to FIG. 19. As a non-limiting example, and as described in more detail below with reference to FIG. 19, a computing device and / or a component of a device or system 0XX0100 may be configured to detect hidden models or simulate at least model trading, for example, using elements of training data. Patterns of trading activity can be identified, analyzed, and converted into training data, as described in more detail below with reference to FIG.

[0123] Alternatively or additionally, the crowd computing component and / or other components of the system may classify and / or match the pattern being analyzed to a current genre. For example, in block 2FA1202, the crowd computing component 2FX0107 searches for similar cases in the lesson database 2TX0120 and organizes the cases into genres. For example, classification into genres may be used to classify cases into database entries or to generate queries to database entries. Genres include, but are not limited to: positive cases, false positives, false negatives, and various types of trading patterns, such as market manipulation, market change signals, synthetically created trades, and the likelihood that a set of trading activities will result in market price fluctuations for one or more financial assets. The crowd computing component 2FX0107 may determine (block 2FB1208) whether the cases are in the same genre, in which case it may use classification and / or database lookup as described above. As part of the active learning process, the analysis system 2XX0100 may associate trader identifiers with trading patterns identified through the pattern recognition process of the detection engine 2BX0104 (described above with reference to Figure 9). This may be accomplished, without limitation, by identifying training data associated with a particular trading desk and generating a trade pattern classifier that classifies sets of trading data to a particular trading desk. The analysis system 2XX0100 may use the patterns associated with a particular trader identifier to compare consistency in trading style to patterns detected from similar trading desks. This may be useful to determine whether cases of the same genre indicate possible repeated irregularities by a potentially rogue trader, regardless of the trading desk the trader may be "hopping" to within the network (i.e., systemic concern, block 2FC1203). If so, behaviors associated with patterns of trading activity that skew the scores may be scrutinized and the advanced filtering criteria 2JC1207 may be updated.The fraudulent trading detection methods described above may provide further advantages when coupled with rapid detection of patterns enabled by other factors described herein, such as, without limitation, matching to genres prior to matching a pattern, and / or representations and matching processes using metric trees. Such features may thwart attempts by fraudulent traders to bypass controls, for example by cancelling trades each time they are checked and then substituting bets using different financial instruments or synthetic trade combinations, or by hopping across trading desks to avoid detection.

[0124] Still referring to FIG. 17, the computing device and / or module may generate a classifier that receives as input a representation of the set of trade activity and associated trade irregularities as a function of the training data as described in this disclosure, and output, this may be accomplished using the classification algorithms and / or classifiers described above, including but not limited to the classification processes and / or classifiers described above, and see FIG. 9. As a non-limiting example, the classifier and / or classification algorithm may include a nearest neighbor classifier or algorithm. The nearest neighbor classifier and / or classification algorithm may be configured to calculate the distance between the trees using the match values, as described above. For instance, the distance from the metric tree to the multiple trigger trees may be calculated as the average probability of finding a labeled leaf from the tree of the training data for a leaf node connected to an unlabeled internal node of the metric tree. The classification includes non-limitingly identifying the matching tree with the smallest distance to the metric tree. In an embodiment, the current set of trades may be classified and / or matched to a genre as described above for instance, and then classification of the current set of trade activity may proceed within that genre to identify specific trade irregularities, or similar. As a non-limiting example, here, if the current trading activity pattern falls into a genre associated with false positives as described above, the system 0XX0100 may indicate that the current trading activity pattern is not likely associated with trading irregularity and / or it may reduce the irregularity and / or risk score as described above, where the classifier further includes a trade pattern classifier. The trade pattern classifier is used to identify possible desk hopping scenarios, defined as a trader engaging in the identified patterns, who may have moved from one trading desk to another in an attempt to evade detection. Identification of the scenario trade desk hopping scenario may enable detection of such behavior without requiring identification of the trader or the trader's personally identifying information.As a non-limiting example, here, when a current set of trading activity is associated with an identifier for a first trade desk, the system 0XX0100 may classify the current set of trading activity into a trading pattern occurring at a second trade desk, where the first trading desk differs from the second trading desk, and identify possible scenarios of trade desk hopping scenarios as a function of the classification.

[0125] 17, the methods described above may be performed by a centralized hub and / or cluster of proximate machines, which then transmits and / or distributes the training data and / or models to local machines, where such localized machines may utilize such models to quickly detect trade irregularities. In an embodiment, this may allow slower or resource intensive processes (e.g., processes for aggregating and analyzing training data and / or converting training data into data structures including, but not limited to, representations of musical compositions, metric trees, etc.) to be performed on dedicated resources, while allowing computing devices more local to the occurrence of a particular trade activity pattern to analyze that training pattern locally, thus requiring less memory usage and less computational comparison of the training pattern against the models, data structures, and / or training data, as described above.

[0126] In an embodiment, and with further reference to FIG. 17, classifying and / or matching a current set of trading activity into genres, followed by classification within genres, may have the advantage of identifying trading irregularities more quickly and efficiently. This is because classification into genres may impose fewer points of comparison and fewer accuracy criteria compared to more fine-tuned matching. Also, classifying into specific patterns of trading irregularities, initially using training data within genres to place a current set of trading activity into genres and subsequent classification, and / or a genre-specific classifier may require a much smaller number of computational cycles for classification compared to the entire class database. This advantage may be further added by the use of additional data structures and processes described in this disclosure, including, without limitation, metric tree, kernel, nearest neighbor, and / or random forest / decision tree methods. Additionally, the combination of genre matching and / or classification with other classification methods described herein may produce synergistic results. Too much data may be a weakness of the traditional K-nearest neighbor algorithm, as it is difficult to manage the exponential increase in the number of decision points. By setting up corpora and grouping them into genres, the system can focus on matching only relevant subsets, rather than the entire population.

[0127] When enough experience is accumulated with cases of the same genre (block 2FB1208), the crowd computing component 2FX0107 prompts the user to change the control or filter. The amount of accumulated experience that is considered "sufficient" depends on the genre and is configurable. The user can mine data or use automated mining or crawling methods across the analysis system 2XX0100 and review system 3XX0140 to justify the change and determine whether the risk associated with the change is acceptable (block 2FD1211). The amount of risk that is considered acceptable is configurable and can be based on business-level and strategic-level considerations. By mining data on how the approvers reviewed various cases in the case management system 3CX0140 and the justification of the mining approvals stored in the audit trail database 3TX0121, the approvers' field experience is aggregated and becomes an insight that is continuously fed back to the analysis system 2XX0100. In this way, the analysis system 2XX0100 learns and re-learns from false positive or negative cases.

[0128] If the risk is not acceptable (block 2FD1211), management may decide that the management plan 2JB0301 requires appropriate revision. Management also has the discretion to freeze traders' system access (block 2FF9999) or certain algorithmic trades ("circuit breaking", block 2FG9999) as necessary due to urgent and significant risk events that are not acceptable according to the management plan / policy. If the risk is acceptable at the strategic level but not acceptable for other reasons (e.g., different control rules in different countries / regions) (block 2FH1212), then customized changes are implemented. Optionally, the acceptable risk level can be overridden, in which case (block 2FI1213), the parameters of the model and logic component 2DX0105 are adjusted. Through the crowd computing component 2FX0107, data results can be mined through the model and logic component 2DX0105 to substantiate the changes. When setting the initial scores in the 2BX0104 detection engine (Figure 8), the control personnel can custom skew the scores of trades submitted by a particular trader or trading algorithm and / or discourage the use of a particular financial instrument / exchange venue for a certain period of time by skew the ABC analysis and / or scrutinize the related trading activity (block 2FJ0802) by skew the scores corresponding to certain "triggers" / "patterns" (Figure 10). The approval grid and empowerment levels in the case management system 3CX0140 (more on this later) can be modified (blocks 2FK1211 and 2FL1211). The approval grid used by the case management component 3CX0140 can be modified. For example, if the crowd computing component 2FX0107 determines that "flags" of a certain nature are being repeatedly approved, it can give appropriate authority to junior approvers and ease management's involvement in operational details. Similarly, if junior approvers make repeated mistakes in approving cases, the empowerment level can be reverted back to senior management.Any control in the detection engine 2BX0104 and the backstop assurance component 2EX0106 can be turned on or off (blocks 2FM1211 and 2FN1211). New controls can be defined and added at will. The control list 2JA0113 or advanced filtering criteria 2JC1207 can be updated per the approved action in the 3CX0140 case management system (block 2FO1211). Other customized changes can also be implemented to train the system 0XX0100. In addition to utilizing knowledge from domain experts, the crowd computing component 2FX0107 trains the system 0XX0100 through simulation of "what if" scenarios and recording lessons by the simulator 3BX0415. The user can record lessons on the changes in the lesson database 2TX0120 and the corresponding impact of the changes (block 2FP1206). Using machine learning - reinforcement learning models, lessons 2TX0120 and accumulated cases in the lesson database are used to train the 0XX0100 system and improve the accuracy of the analysis system 2XX0100 (block 2FQ1206). Training the computer involves comparing the training set (new lessons) with the untrained nearest neighbor rule, using simulator 3BX0415, see Figure 9 above. If the new lessons do not reduce the amount of false positives or negatives, one might consider the lessons useless. Otherwise, the new lessons will help improve the accuracy of pattern onset detection and fit.

[0129] Each entity may have its own experience or expertise with a particular market, financial instrument, and / or counterparty with which it trades. The definition of "sufficient" experience may vary from entity to entity. Factors include, but are not limited to, experience in risk management, domain knowledge of supply and demand changes, and understanding of regional differences in behavior. If an entity lacks sufficient experience, the Crowd Computing component 2FX0107 displays rules or best practices recommended by the crowd through the Notification and Share feature (block 2FR1209). In this way, the Crowd Computing component 2FX0107 provides users with the option to adopt, adjust, or not adopt a particular system logic set by other entities in the network. Users can compare the recommended rules or best practices with their own company's case (block 2FT1210). By using the backtesting functionality via simulator 3BX0415, and as further explained with reference to Figure 19, the backtesting results help determine whether the crowd best practices are suitable for use “as is” (block 2FU1209) or with appropriate adjustments or customizations (blocks 2FH1212, 2FJ0802, 2FL1211, 2FN1211, and 2FO1211). The crowd best practices may be evaluated to determine whether the risks are acceptable at a strategic level (block 2FD1211). If not, the management plan 2JB0301 may be revised accordingly (block 2FE1211).

[0130] Customizing the effectiveness criteria and feedback of analytical components in this manner can be useful for financial institutions with multiple regional trading desks and / or multiple algorithmic trades across geographic locations and asset classes, as well as for central office and cross-team working. Instead of central office guiding all of the order routing and trade execution movements, which often slows decision making, it can create a lot of unnecessary back and forth that slows decision making and creates the risk of missing the best market timing for trades or mitigating hedging opportunities in a dynamic electronic trading environment. The embodiments described in this disclosure allow appropriate discretion to be given to local trading desks (4DX0505) and / or algorithmic trades (4EX9999), while allowing central office (4XX1311) to adjust their overall macro strategies and analyze long-term directions to respond to the market.

[0131] Additionally, customizing the analytical component's validity criteria and feedback in this manner can reduce false positives and false negatives. Over time, this allows for a high level of customization, allowing for more accurate identification of "reasonable" and "out of reach" conditions. The crowd computing component 2FX0107 may also discover cases that indicate possible stress scenarios, threats to financial stability, or crisis situations that may alert an entity to potentially re-forecast reasonably expected short-term demand 2DB0703 or reconsider inventory planning 2DC0701 to consider possible hedging protections.

[0132] Optionally, activate a "Reasonably Expected Short-Term Demand Under Pressure" trigger via crowd computing component 2FX0107 and simulator 3BX0415 described below, where the inputs and parameters of the Reasonably Expected Short-Term Demand calculation are analyzed against actual market conditions to assess market dynamics in real time (e.g., view the distribution of toxic assets on a macro level, determine who is ready to provide liquidity to the market, and who is under pressure in the event of a market crash). This allows for more timely intervention between the industry and regulators. In one exemplary embodiment, through crowd computing component 2FX0107, stakeholders can collectively determine the appropriate time to declare a situation called "Reasonably Expected Short-Term Demand Under Pressure," which is a situation in which a timely injection of liquidity into the market is essential to prevent a financial sector taxpayer bailout.

[0133] Review System

[0134] The review system 3XX0140 includes three components: a trade event reconstruction component 3AX1206, an order book replay simulator 3BX0415, and a case management component 3CX0140 (see FIG. 1). FIG. 21 illustrates a method implemented by the case management component 3CX0140 according to some embodiments. The case management component 3CX0140 receives and displays a queue (block 3CA0141) of alerts stored in the flag / quarantine database 2TX0122 from the analysis system 2XX0100. In block 3CM1210, the case management component 3CX0140 also displays the alerts as part of the management dashboard. Through the management dashboard, users can view key performance indicators (e.g., number of open cases, number of high priority cases that need to be escalated for attention due to issues of materiality or systemic concern, and turnaround time for closed cases that may be currently under scrutiny by a "target" or "trader"). In block 3CN1208, the user can further review closed flagged or overdue cases (i.e. timeliness and standard turnaround times for closing cases are monitored and tracked by the case management component 3CX0140) to ensure previously closed cases are resolved and addressed, and it can log the results to the management dashboard. The user can further reopen closed "flags" and return closed cases to the re-investigated alert queue (block 3CB0140). The user can further escalate and follow up on long open / unclosed cases, so that critical concerns, systemic concerns, or long open cases are prioritized for review (block 3CO0140).In an exemplary embodiment, in reviewing closed or delinquent cases, compliance and control personnel can obtain from the management dashboard a list of trader identifiers with the most repeated violations or flagged or quarantined trades for appropriate follow-up and investigation or individual performance review. Specific activities of traders with specific identifiers can be scrutinized and their scores skewed accordingly by the crowd computing component 2FX0107. In investigating open flags (block 3CB0140), the case management component 3CX0140 identifies false negative cases via a correlation process via the simulator 3BX0415 (i.e. "undetected surprise" / Type II errors). By identifying and processing these false negative cases, the case management component 3CX0140 minimizes the recurrence of false negatives by sharing the false negatives via the crowd computing component 2FX0107 and reflecting the false negative cases in reasonably expected short-term demand / inventory planning.

[0135] Upon investigating a case on the alert queue (block 3CB0140), the review system 3XX0140 reconstructs the trade events and replays the order book. FIG. 18 illustrates a method of reconstructing trade events performed by the trade reconstruction component 3AX1206 of the review system 3XX0140, according to some embodiments. The trade event reconstruction component 3AX1206 receives data from the data processing device 1XX1101 via a communication channel 5BX1307. In the trade event reconstruction component 3AX1206, the user selects a period or a previously recorded lesson in the lesson database 2TX0120 (block 3AB9999), selects one or more target trade records from the lesson database 2TX0120 (block 3AC9999), and replays these trade records (block 3AD9999). A target may be, but is not limited to: a particular stock symbol, the Committee on Uniform Security Identification Procedure (CUSIP) for Debt Instruments, a hybrid instrument (e.g., trust preferred securities [TruPS]), any tradable object, an entire asset class, or transactions traded in a particular geographic region, or the smallest discrete unit of a particular trader or trading desk (a single "track" in musical terms), or a mix-and-match of "dimensions."

[0136] FIG. 20 shows an example of a user interface 3KS1206 implemented by the trade event reconstruction component 3AX1206. With reference to both FIG. 18 and 20, the trade event reconstruction component 3AX1206 displays the retrieved records in an initial window 3KF9991 (block 3AF9999) that allows the user to break down, drill down, or "track" aggregations (rollups) (block 3AG9999), and display lower and upper dimensions (block 3AH9999). The 3KS1206 user interface allows the user to zoom in and out or other similar functionality to expand on the activity (block 3AI9999), zoom in on the activity (e.g., play the activity in microseconds, milliseconds, or "tick-by-tick"), or view activity over a longer period of time (block 3AJ9999). The Trade Event Reconstruction component 3AX1206 displays in the second window 3KE9992 a blotter for a particular trade (i.e., a record of a particular trade and details of transactions made during a period), which is updated with the changes in the first window 3KF9991 (block 3AK9999), as well as key statistics for the period: high, low, and volume weighted average price (VWAP) (block 3AE9999). In the third window (block 3KM9993), the Trade Event Reconstruction component 3AX1206 displays "Depth of Market Book" information about bids and offers below the highest price (NBBO) that exists in the entire United States (blocks 3AL9999 and 3AM9999). The user can drill down to see a particular trading venue (e.g., stock exchange, best bid and offer) at a particular time (blocks 3AN9999 and 3AO9999). Users can pull an event timeline that consists of information from market event records (block 3AP9999).Market event records include: outputs from voice or electronic communication monitoring systems 5DA9999 and news feeds 5DB9999, as well as audit trails in the audit trail database 3TX0121 corresponding to selected periods of trade activity, tagging reference data 5XB0131 with code links, and tagging other market event records with corresponding trade orders and pricing records as appropriate (e.g., music format files and data stream prefixes). The trade event reconstruction component 3AX1206 displays the event log files for the relevant timeline in a fourth display window 3KQ9994 (block 3AQ9999), which acts like a "file explorer", and overlays the first display 3XF9991 (block 3AR9999), showing arrows and log references, and the fifth display 3KR9995. The user can mouse over or click to view a particular event record. The User Interface 3KS1206 provides control buttons 3KS9996 for various functions (blocks 3AS1206): stop, pause, rewind to start playing the trade sequence, cut, or edit. Referring to Figure 21, the reconstructed trade events can be recorded in a lesson database 2TX0120 referenced by the analysis system 2XX0100, and the case management component 3CX0140 can configure the corpora and record and / or turn off or on the complex event processing lesson 3CJ1102. The controls can further include a toggle to change the first display 3KF9991 to show either an audio spectrum or a traditional chart view. The details of the trade orders (audit trail) are displayed in 3KQ9997. These functions allow to interact with the order book replay simulator 3BX0415, the case management component 3CX0140, and the crowd computing component 2FX0107.

[0137] FIG. 19 illustrates a method for replaying an order book, according to some embodiments, implemented by an order book replay simulator 3BX0415. The simulator 3BX0415 replays the order book, assimilating market dynamics, observing possible market interactions to perform backtesting, and evaluating different "what if" scenarios. The simulator 3BX0415 assimilates market dynamics, via reconstructing its own trades 3AX01206 with reference to FIG. 18, and by combining historical or hypothetical trade records in the market (block 3BD9999). The simulator 3BX0415 uses lessons from the lesson database 2TX0120 (block 3BA9999) or obtains trade records over a specific period of time to establish a basis for simulating the market. Alternatively, the simulator 3BX0415 uses the data processor's 1XX1101 aggregation (propagation) function to stack tracks to replicate certain interactions between market participants and introduce background tracks representing a hypothetical market (block 3BB9999). Considering possible market change signals via the pattern recognition component 2CX0904, the simulator 3BX0415 can modify the simulated market via tuning and configuration techniques of the data processor 1XX1101 available in the Tune control panel 3KS9000 (Figure 5) (block 3BC9999). Examples of tuning include, but are not limited to, "reverb", which represents the depth of the market, and "high / mid / low": representing the activity of "dark pools" (i.e., trading venues that give investors the opportunity to place orders and make trades without publicly revealing their intentions while searching for buyers and sellers), and systematic internalizers (i.e., investment firms that trade on their own accounts in an organized, frequently systematic and substantially, manner in executing customer orders outside the trading venue), and stock exchanges (i.e., stock exchanges that show different bids and offers on different stocks, the opposite of dark pools).Additionally, "faders" represent the relative activity and interaction of the banking sector and shadow banking, and also increase the loudness or introduce random noise to obfuscate the lessons stored in the lesson database 2TX0120. Crowd Computing 2FX0107 allows customization of control filters to be applied in the simulated environment. Next, the firm's trades, background tracks representing the simulated market, frameworks from Models and Logic 2DX0105 (e.g. maker-taker models, price / time / size priorities), and applicable filtering controls are assimilated for the assessment of market dynamics (block 3BD9999).

[0138] Simulator 3BX0415 validates the assimilation model against any "out of reach" situations (block 3BE0415). Non-exclusive "out of reach" situations include, for example, price discrepancies between the company's trades and the model, or unrealistic volatility in a particular market (i.e., opposite and far away from the range of reasonably expected short-term demand previously set). If no "out of reach" situations are found, backtesting is performed (block 3BF0415). If an "out of reach" situation is found, the model is again re-customized before backtesting as previously described, see Figure 17.

[0139] In block 3BF0415, backtesting refers to the process of applying a trading strategy (e.g., a series of own trades) or analytical method to historical data or a simulated environment to see how accurately the strategy or method predicts actual results and / or observe how the strategy interacts with other market participants (block 3BG1205). Backtesting simulations are also useful for evaluating the performance of trading algorithms 4EX9999. The simulator 2BX0415, via the models and logic component 2DX0105, calculates hypothetical profit and loss (P&L), Sharpe ratios, drawdown percentages, etc. based on backtests to evaluate trading strategies. The simulator 2BX0415 can also be informed by the models and logic component 2DX0105 to apply baseline or various stress scenarios, and to simulate multiple "what if" scenarios (3BJ9999). These "what if" scenarios help in evaluating the best trading algorithms for different market conditions so there is timely switching of trading strategies when the pattern recognition component 2CX0904 picks up or detects the desired market change signal.

[0140] The simulator 3BX0415 uses the backtest results to access correlations against outputs from the voice and electronic communications monitoring system 5DA9999 and various news feeds 5DB9999. The interactions observed from the backtest results include, but are not limited to, own trades that cause bias in the market mechanism (e.g., tricking the market into believing falsehoods or violating the efficient market hypothesis), have an effect that changes the value of a tradable object (moving the market price) or have no effect. If the trade event does not cause a bias in the market mechanism (block 3BH9999), the trade event is flagged as a false positive. In that case, the simulator 3BX0415 determines whether the trade event has an effect that changes the value of the target (block 3BI9999). If not, the trade event is flagged as a false positive. Otherwise, the simulator positively confirms that the case has been legitimately flagged / quarantined by the 2XX0100 analysis system, or it may flag the transaction event as a false negative if it was not previously flagged by the 2XX0100 analysis system. Positive cases, false positives, and false negatives are reported to the case management component 3CX0140.

[0141] Again, the simulator 3BX0415 continues backtesting with other "what if" scenarios by recalibrating the simulated "model" and customizing the use case, lesson, or genre (block 3BJ9999). The "what if" options are evaluated (block 3BK9999) to arrive at the optimal risk-reward outcome for the trading algorithm. Alternatively, the "what if" options are used to preclude or eliminate irrational investments or "out of reach" conditions, thus providing evidence to support or confirm the potential misconduct and / or trading activity flagged as irrational. In this case, a correlation is established for the potential unfair trading or market manipulation, and the trading case is recorded in the lesson database 2TX0120 or exported to a third party for further action via the case management component 3CX0140 (see FIG. 21, in particular, block 3CJ1102).

[0142] FIG. 19 is still referred to, the system 0XX0100 and / or computing device, and / or modules included in the system may employ additional machine learning processes to detect additional patterns and / or models of potential irregular trade activities in data describing the trade activities and / or training data described in this disclosure. The additional machine learning may include, but is not limited to, using supervised and / or unsupervised machine learning processes and / or methods to discover at least a hidden model of a set of multiple trade activities, and converting the multiple trade activities into training data with multiple user identities and at least the hidden model, i.e., the hidden model can be used as a new stored pattern or to form a new genre of stored patterns. The unsupervised machine learning process may include, but is not limited to, a partially observed Markov decision process (POMDP). The partially observed Markov decision process may include a generalized Markov decision process that models the decision process of an agent that cannot detect the underlying state of a system having dynamics determined by a Markov decision process. A partially observed Markov decision process agent may maintain a probability distribution over a set of system states that may be calculated and updated based on observations, observed characteristics, and the Markov decision process. Repeated interactions with the environment and the system result in periodic recalculation of the probability distribution of the states, resulting in improved predictive accuracy of the model. As a result, the partially observed Markov decision process may discover unknown relationships between data elements in the training data and / or trade data sets, which in turn may be used as additional and / or update existing models used by the system.In an embodiment, a partially observed Markov decision process is used that may include: detecting previously identified semantics of model trades; operating a model recognition engine to generate and synthesize the insertion of newly generated nodes that are sequenced into tracks and aggregated into dimensions (bootstrap aggregation); and operating a dialog management component, via a user client device, to enable tracking of trade paths of the model other than the most likely path; interacting with the user to suggest alternative or new genre categories of elements of the training data. Although a partially observed Markov decision process is described as an exemplary process for hidden model discovery, alternative processes such as partially observable stochastic games (POGS) with Nash equilibrium may be employed instead. Also, as previously mentioned, boosting, bootstrap aggregation, and stacking are "meta-algorithmic" machine learning approaches that combine multiple machine learning techniques into a single predictive model to reduce bias, reduce clutter, and improve predictive power. Iterative learning, unlearning, and relearning of relevant context, conditions, and relevant models (through boosting, bootstrap aggregation, stacking, partially observed Markov decision processes, partially observable stochastic games, deep learning, and other machine learning approaches) can help enable trading desks and algorithmic trading to become more resilient and smarter as markets move.

[0143] Still referring to FIG. 19, the hidden patterns may generally be tested and / or evaluated for validity and / or usefulness, and / or in one or more contexts, using simulation methods as described above and / or as further detailed herein. For example, and without limitation, such a process may include obtaining a plurality of stored trade activity models, simulating at least one model trade using the hidden model and / or the plurality of stored models, calculating at least the outcome of the trade, and determining the suitability of the hidden model as a function of the outcome. The plurality of stored models may be obtained to simulate a particular market situation. For instance, the plurality of stored models may represent patterns of trade activity detected together in the trade activity data collected, analyzed, and / or stored according to the processes, process steps, and / or combinations as described in this disclosure. The patterns may be grouped according to one or more market and / or activity-based contexts. For example, various previously existing scenarios may be simulated to include the newly identified hidden patterns as patterns of trade activity. The outcomes of the hidden pattern may be simulated, measured, and compared to a threshold, where insufficiently positive outcomes, including, but not limited to, money-losing outcomes and / or outcomes that are minimally profitable, may be used to reject the hidden pattern as a pattern for use in training data (e.g., under the assumption that trading patterns that do not produce financial profits are unlikely to be repeated frequently by traders acting in self-interest). Such outcome tests may be performed generally or per context, where if the outcome fails a threshold for a particular context, the pattern is rejected for that context, and the pattern may be used as training data in contexts where the threshold is met.Also, classification of current trading patterns against patterns in training data can then be performed against a set of training data that matches a context that matches the current trading pattern, and the contexts can be organized according to genres such that classification into genres obtains trading patterns in relevant contexts. The contexts used for such results and / or simulation testing can be identified using: classification of hidden patterns, and / or related and / or co-occurring data, into genres and / or contexts. Results can be determined and / or measured using any suitable method, including but not limited to reasonably anticipated short-term demand / inventory planning, Grossman-Miller, economic order quantities or similar, examples of which are described further in this disclosure. Contexts and / or genres may include any factors that affect trading patterns, including the type of securities traded, market conditions, type of institutions represented, or similar.

[0144] The effectiveness of classification, simulation, and backtesting in this way may help improve detection accuracy in trade research and monitoring of "known" cases (i.e., creating a testing hypothesis, designing an experiment, and checking whether the outcome is within the range of known possibilities). Such a process may also help discover and prepare for unexpected market scenarios (such as "known and unknowable things" such as flash crashes). A better understanding of how flash crashes occur is highly beneficial, given that the consequences of a crash event can be devastating if not detected in a timely manner. To reduce the amount of false negatives, unknowns, or hidden models, it may be highly beneficial to better understand the causes of flash crashes, determine effective early warning signals for detecting potential crashes, and select the most effective and appropriate risk hedges for different crash scenarios. Thus, machine learning approaches such as those described above may serve an important purpose in promoting the safety and soundness of the global financial system.

[0145] Returning to Figure 21, the case management component 3CX0140 makes further remarks regarding the findings in the audit trail database 3TX0121 and closes the flags of any false alarms (block 3CC0210). All false positives and false negatives (Type I and Type II errors) are fed back to the crowd computing component 2FX0107. The case management component 3CX0140 reviews the confirmed cases (block 3CD0140), identifies corrective actions (block 3CE0140), and approves the corrective actions (block 3CF0213). Corrective actions may include, but are not limited to, modifying filtering mechanisms in the analysis system 2XX0100 or enabling temporary tolerance for the situation. Securities management of information is implemented to maintain the privacy and confidentiality of individual traders and trading strategies. For example, designated approvers are only allowed to view and process flagged / quarantined trade orders in their assigned queues, such as trade desks or regions or jurisdictions, according to the approval grid referencing Figure 17, and traders are only tagged using a unique trader identifier. The case management component 3CX0140 generates reminders of the expiration of approved temporary tolerance cases (block 3CG0907). Referring to Figure 11 above, the backstop assurance component 2EX0106 ensures that the cumulative effect of tolerance cases does not inadvertently cause cascading or other issues that could result in uncontrollable or difficult to control outcomes, or prevent abuse of the temporary tolerance process to bypass detection.

[0146] The Case Management component 3CX0140 applies the changes according to the approved corrective actions and documents the corrective actions taken in the Audit Trail database 3TX0121 (block 3CH1211). The Case Management component 3CX0140 monitors and tracks the timeliness in completing the required changes and closes the case (block 3CI0140). The status of overdue or long open cases may be displayed in the Management Dashboard. The monitoring process should use the simulator 3BX0415 for backtesting and consider based on the backtest results whether further changes to the corrective / improvement actions need to be made or further investigation is required until the number of outliers or exceptions falls below the set threshold (block 3CL0213). Once fully satisfied, the Case Management component 3CX0140 closes the flag. Lessons learned are recorded in the Lessons database 2TX0120 (block 3CJ1102). Stakeholders, such as regulators, are appropriately notified (block 3CK9999). False positives, false negatives, and lessons learned are fed into the crowd computing component 2FX0107 as described above with reference to Figure 17.

[0147] FIG. 22 is a block diagram of components of a computer system, one or more of which may be used to implement various embodiments of the present invention. The components of the computer system 2200 include, without limitation: one or more processors or processing units 2206, memory 2201, and bus 2209, which couple various system components (including memory 2201) to the processor 2206. The bus 2209 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using various bus architectures. The memory 2201 may include computer readable media in the form of a volatile memory, such as a random access memory (RAM) 2202 or a cache memory 2203, or a non-volatile storage medium 2204. The memory 2201 may include at least one program product having a set of at least one program code module 2205 configured to perform the functions of an exemplary embodiment of the present invention when executed by the processor 2206. The computer system 2200 can also communicate with one or more external devices 2211, such as a display 2210, via an input / output switch interface 2207. The computer system 2200 can communicate with one or more networks via a network adapter 2208.

[0148] The invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

[0149] Additionally, the present invention provides program code for use in or in connection with a computer or any instruction execution system, which may take the form of a computer program product accessible from a computer use medium or computer readable storage medium. For purposes of this description, a computer use medium or computer readable storage medium may be any device that can contain, store, communicate, propagate or transport a program in connection with or for use in an instruction execution system, apparatus or device. The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device), or a propagation medium. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read only memory (ROM), rigid magnetic disks, optical disks, etc. Current examples of optical disks include compact disks with read only memory (CD-ROM), compact disks - read / write (CD-R / W), and digital video disks (DVD). As used herein, a computer-readable storage medium should not be construed as being a transitory signal, per se, such as: radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through an optical cable), or electrical signals transmitted over wires.

[0150] A data processing system suitable for storing and / or executing program code includes at least one processor coupled directly or indirectly through a system bus to memory elements which may include local memory used during the actual execution of the program code, bulk storage, and cache memory, and / or a cache memory that provides temporary storage for at least some of the program code to reduce the number of times the code must be retrieved from bulk storage during execution.

[0151] Input / output devices or I / O devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I / O controllers.

[0152] Network adapters may also be coupled to a system to couple the data processing system to other data processing systems or remote printers, or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the network adapters available today.

[0153] conclusion

[0154] An embodiment of an improved system for detecting and analyzing trade data is described above. In some embodiments, as described above with reference to FIG. 6, data points in trade activity are converted into a musical piece representation. The musical piece representation is converted into a metric tree. This results in a data structure of smaller size than traditional technical analysis using vectors, reducing storage resource requirements. As the amount of trade data increases, the amount of storage resource savings also increases. The comparison process is performed using a metric tree, as described above with reference to FIG. 9-10, to analyze trends in tradable financial instruments or markets, thus avoiding reliance on plot charts and measuring graphical vectors, as in traditional methods. Furthermore, the smaller size of the metric tree allows the comparison process to be performed more quickly and in a timely manner than traditional technical analysis. Furthermore, the smaller size of the metric tree allows the comparison process to be performed more quickly and in a timely manner than traditional technical analysis. This reduces the latency of the comparison process and allows for timely identification of signals and warnings that are important for regulators (such as: the Securities and Exchange Commission in the United States, the Financial Industry Regulatory Authority), electronic markets (such as stock exchanges), high frequency trading, and serious market participants that seek to achieve the best trade execution. Using a smaller metric tree structure in the comparison process and the complex event processing model of the 2TX0120 model database, the complex event processing model avoids the complex calculations of traditional technical analysis techniques (see Figures 9-10), thus reducing the computing resource requirements. Complex event processing models in some embodiments include hypothetical "what if" scenarios, allowing the practice of forward-looking analysis to prevent undesirable outcomes (such as potentially causing market manipulation or conflicts with customers) before implementation, rather than relying solely on historical data sets. The comparison process can process large volumes of trade data with real-time, pre-trade, or trade order analysis that cannot reasonably be achieved with human oversight.

[0155] In some embodiments, once a metric tree is constructed, the comparison process can be performed using a propagation or partially labeled tree approach that places more emphasis on the information contained in a hierarchical structure rather than a tree structure, resulting in more accurate results, fewer errors, and greater tolerance for clock synchronization.

[0156] Additionally, audio compression techniques can be leveraged to achieve greater compression of the metric tree than under traditional financial data compression approaches. In some embodiments, increased flexibility over various coding methods for lossless or lossy data compression is achieved. Lossy methods can achieve greater compression ratios than common financial data compression approaches. In some embodiments, the use of a metric tree representation optimizes the tradeoff between acceptable quality loss and increased transmission speed and reduced storage size. Audio codecs can be further leveraged to obfuscate and encrypt data in the metric tree for data protection and other purposes.

[0157] In some embodiments, the compressed data is encrypted with a time-locked audio codec to prevent early access and promote fair availability of market data to market participants.

[0158] In some embodiments, the system 0XX0100 quantifies the trade data into a score and uses the feedback via the crowd computing component 2FX0107 to improve the accuracy of pattern recognition.

[0159] In some embodiments, feedback from crowd sources, via the crowd computing component 2FX0107 and simulator 3BX0415, is leveraged to improve the lesson database 2TX0120 and accumulated case lessons used to train the system 0XX0100, as well as improve the accuracy of the analysis system 2XX0100. Parameters, lists, and filtering criteria used in the analysis system 2XX0100, including reasonably expected short-term demand and inventory planning, can also be fine-tuned. A "Reasonably expected short-term demand under pressure" trigger can be triggered via the crowd computing component 2FX0107, which analyzes inputs and parameters of reasonably expected short-term demand / inventory planning calculations by different users of the 0XX0100 platform against actual market conditions to evaluate market dynamics in real time via the 3BX0415 simulator, allowing for more timely intervention that cannot reasonably be realized if the calculations are performed by humans.

[0160] In some embodiments, the trade reconstruction component and trading order book replay simulator provide an objective correlation of trade events with facts in the market event timeline. Trading activity that may or may not have the effect of changing the value of the underlying financial instrument may be objectively identified as a suspicious case. Thus, avoiding the use of traditional methods that rely on subjective human comparison of charts and graphics to identify suspicious cases.

[0161] In some embodiments, the user interface uses reverb or other tuning or simulation methods to mimic and replicate a depth of market book, assimilating and representing market dynamics, providing an easy way to meaningfully aggregate or disaggregate financial records. Complicated calculations such as asset pricing and payoffs, and deciphering correlations between rollups and underlying dimensions are avoided, thus saving computing and processing resources.

[0162] Although the present invention has been described according to the illustrated embodiments, one of ordinary skill in the art will readily recognize that there may be variations in the embodiments, and these variations will be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims

1. 1. A system for processing and monitoring trade data, the system comprising a computing device, the computing device having at least one processor; The computing device comprises: receiving a plurality of data representing a set of trading activities; receiving a plurality of user inputs from a plurality of user client devices, each user input of the plurality of user inputs further comprising: an identification of at least one datum representing a set of trading activity of a plurality of data representing trading activity; and an identification of a trading irregularity associated with the set of trading activity; converting the plurality of data representing a set of trading activities and the plurality of user inputs into training data, the converting to training data comprising: converting the plurality of data representing a set of trading activities into a musical piece representation, the musical piece representation including musical notes and rests, the musical notes representing trading activities and the rests representing non-trading activities; and converting the musical piece representation into a metric tree; generating a classifier as a function of the training data, the classifier receiving a plurality of metric trees as inputs and outputs related to trade irregularities; 23. A system configured to perform the steps including:

2. Transforming the plurality of data representing a set of trading activity and the plurality of user inputs into training data includes: Categorizing each user input and datum into a genre of trading activity; converting the plurality of data representing a set of trading activity and the plurality of user inputs into training data as a function of the classifying. The system of claim 1 further comprising:

3. The system of claim 2 , wherein the genre further comprises a previously identified genre, the system further comprising modifying the previously identified genre.

4. The system of claim 2 , wherein generating the classifier further comprises generating a classifier using training data associated with a single genre.

5. To convert, discovering at least one hidden model among a plurality of sets of trading activity using a machine learning process; converting the plurality of sets of trading activity into training data using the plurality of user inputs and the at least one hidden model; The system of claim 1 further comprising:

6. To convert, Obtaining a plurality of stored models of trading activity; and simulating at least one model trade using the plurality of stored models; calculating results of the at least one model trade; determining the fitness of the hidden model as a function of the result; The system of claim 5 further comprising:

7. To calculate, determining a datum representing trade size and market time boundaries; backtesting the at least one model trade based on the datum; and The system of claim 6 , comprising:

8. The computing device comprises: Receiving a current set of trading activities; classifying the current set of trading activities using the classifier; The system of claim 1 , further configured to:

9. the classifier further comprises a trade pattern classifier; the current set of trade activity is associated with a pattern of trades occurring at the first trade desk; The computing device comprises: categorizing the current set of trade activity into a pattern of trades occurring at a second trade desk, the first trade desk being different from the second trade desk; and identifying possible trade desk hopping scenarios as a function of said classifying; The system of claim 1 configured to:

10. 10. The system of claim 8, wherein the computing device is further configured to convert the current set of trade activity into a metric tree, and the classifier is configured to identify matching trees in the training data.

11. 1. A method for processing and monitoring trade data, the method comprising: receiving a plurality of data representing a set of trading activities; Receiving a plurality of user inputs from a plurality of user client devices, each user input of the plurality of user inputs comprising an identification of at least one datum representing a set of trading activity of a plurality of data representing trading activity and a data item associated with the set of trading activity. and further comprising identifying trade irregularities associated with the converting the plurality of data representing a set of trading activities and the plurality of user inputs into training data, the converting to training data comprising: converting the plurality of data representing a set of trading activities into a musical piece representation, the musical piece representation including musical notes and rests, the musical notes representing trading activities and the rests representing non-trading activities; and converting the musical piece representation into a metric tree; generating a classifier as a function of the training data, the classifier receiving a plurality of metric trees as inputs and outputs related to trade irregularities; A method comprising:

12. Transforming the plurality of data representing a set of trading activity and the plurality of user inputs into training data includes: Categorizing each user input and datum into a genre of trading activity; converting the plurality of data representing a set of trading activity and the plurality of user inputs into training data as a function of the classifying. The method of claim 11 further comprising:

13. The method of claim 12 , wherein the genre further comprises a previously identified genre, the method further comprising modifying the previously identified genre.

14. The method of claim 12 , wherein generating the classifier further comprises generating a classifier using training data associated with a single genre.

15. To convert, Discovering at least one hidden model among a plurality of sets of trading activity using a machine learning process; converting the plurality of sets of trading activity into training data using the plurality of user inputs and the at least one hidden model; The method of claim 11 further comprising:

16. To convert, Obtaining a plurality of stored models of trading activity; and simulating at least one model trade using the hidden model and / or the plurality of stored models; calculating results of the at least one model trade; determining the fitness of the hidden model as a function of the result; 20. The method of claim 15 further comprising:

17. To calculate, determining a datum representing trade size and market time boundaries; backtesting the at least one model trade based on the datum; 17. The method of claim 16, comprising:

18. The method comprises: Receiving a current set of trading activities; classifying the current set of trading activities using the classifier; The method of claim 11 further comprising:

19. the classifier further comprises a trade pattern classifier; the current set of trade activity is associated with a pattern of trades occurring at the first trade desk; The method comprises: categorizing the current set of trade activity into a pattern of trades occurring at a second trade desk, the first trade desk being different from the second trade desk; and identifying possible trade desk hopping scenarios as a function of said classifying; 20. The method of claim 18, further comprising:

20. 20. The method of claim 18, further comprising converting the current set of trade activity into a metric tree, the classifier being configured to identify matching trees in the training data.

21. 1. A system for processing and monitoring trade data, the system comprising a computing device, the computing device having at least one processor; The computing device comprises: Receiving data representing a set of trading activities; converting the data representing a set of trading activities into a musical composition representation; converting a musical piece representation into a metric tree, wherein notes of the musical piece representation are recorded in labeled leaf nodes of the metric tree, the labeled leaf nodes being connected to unlabeled internal nodes; setting an initial default value for a score representing the probability of trade irregularity; comparing the metric tree to a plurality of trigger trees stored in a lesson database, each trigger tree of the plurality of trigger trees representing a trade irregularity; identifying at least one trigger tree among the plurality of trigger trees that exhibits at least a closest match to the metric tree using a nearest neighbor algorithm, the nearest neighbor algorithm comprising: calculating a distance between trees using a match value, where the distance from a trigger tree of the plurality of trigger trees to the metric tree is an average chance of finding a labeled leaf from the trigger tree at a leaf node connected to an unlabeled internal node of the metric tree; identifying at least one trigger tree having a minimum distance to the metric tree; and modifying a score to represent an increased probability of trading irregularity as a function of the identification of the at least one trigger tree; comparing said score with a pre-established threshold; performing a corresponding action by a review system as a result of said comparing; A system configured to:

22. The converting step comprises: representing trading activity in the set as notes and representing non-trading activity as rest in the musical composition representation, each note representing a trading order in the set of trading activity; placing notes representing purchase orders on a high-pitched clef of said musical composition representation; placing notes representing sales orders on a bass clef of said musical composition representation; setting the pitch of each note of said musical composition representation according to a price value and a length of time that a corresponding trading order will remain open; setting a tempo of the musical composition representation according to an average rate at which trading orders are filled; setting the time signature of the musical expression according to a combination of market conditions of the type of trade instrument and the venue and trade activity of said set; 22. The system of claim 21, comprising:

23. The converting step comprises: said at least one processor converting each note in said musical piece representation into a leaf node of said metric tree; said at least one processor setting a level of said leaf node in said metric tree according to a duration of a corresponding note in said musical composition representation; said at least one processor ordering the nodes in the metric tree according to a time ordering of notes in the musical composition representation; parsing the metric tree into a plurality of tracks, each track including a smallest discrete trade unit of a set of trading activity; aggregating the tracks into dimensions using a partially labeled tree comparison method, each dimension being an organized grouping of a plurality of discrete trade units; 22. The system of claim 21, comprising:

24. 22. The system of claim 21, wherein each trigger tree of the plurality of trigger trees includes data representing a pattern selected from the group consisting of potential market manipulation, market change signals, synthetically created trades, and a probability that a set of trading activity will result in a movement in the market price of one or more financial assets.

25. 22. The system of claim 21, wherein comparing further comprises recursively performing an average of the likelihood of finding a labeled leaf in a descendant of an unlabeled internal node in the metric tree until no matching trigger tree is found that describes trade activity having a time span that matches a time span of the data representing a series of trade activity.

26. 22. The system of claim 21, wherein the computing device is further configured to store the data representing a set of trade activities with time-locked cryptographic protection.

27. 1. A computer-implemented method for processing and monitoring electronic trading data, comprising: a data processor receiving data representing a set of trading activities; said data processor converting said data representative of said set of trading activities into a representation of a musical composition; said data processor converting said musical piece representation into a metric tree, wherein notes of said musical piece representation are recorded in labeled leaf nodes of said metric tree, said labeled leaf nodes being connected to unlabeled internal nodes; setting an initial default value for a score representing the probability of trade irregularity; comparing the metric tree to a plurality of trigger trees stored in a lesson database, each trigger tree of the plurality of trigger trees being a trade and, identifying at least one trigger tree among a plurality of trigger trees that exhibits at least a closest match to the metric tree using a nearest neighbor algorithm, the nearest neighbor algorithm comprising: calculating a distance between trees using a match value, the distance from one of the plurality of trigger trees to the metric tree being the average chance of finding a labeled leaf from the trigger tree at a leaf node connected to an unlabeled internal node of the metric tree; identifying at least one trigger tree having a minimum distance to the metric tree; and modifying a score to represent an increased probability of trading irregularity as a function of the identification of the at least one trigger tree; comparing the score to a pre-established threshold; performing a corresponding action by a review system as a result of said comparing; 23. A computer-implemented method comprising:

28. The converting step comprises: representing trading activity in the set as notes and representing non-trading activity as rest in the musical composition representation, each note representing a trading order in the set of trading activity; placing notes representing purchase orders on a high-pitched clef of said musical composition representation; placing notes representing sales orders on a bass clef of said musical composition representation; setting the pitch of each note of said musical composition representation according to a price value and a length of time that a corresponding trading order will remain open; setting a tempo of the musical composition representation according to an average rate at which trading orders are filled; setting the time signature of the musical expression according to a combination of market conditions of the type of trade instrument and the venue and trade activity of said set; 30. The computer-implemented method of claim 27, comprising:

29. The converting step comprises: said data processor converting each note in said musical piece representation into a leaf node of said metric tree; said data processor setting a level of said leaf node in said metric tree according to a duration of a corresponding note in said musical piece representation; said data processor ordering the nodes in the metric tree according to a time ordering of notes in the representation of the musical piece; parsing the metric tree into a plurality of tracks, each track including a smallest discrete trade unit of a set of trading activity; aggregating the tracks into dimensions using a partially labeled tree comparison method, each dimension being an organized grouping of a plurality of discrete trade units; 30. The computer-implemented method of claim 27, comprising:

30. 30. The computer-implemented method of claim 27, wherein each trigger tree of the plurality of trigger trees includes data representing a pattern selected from the group consisting of potential market manipulation, market change signals, synthetically created trades, and a probability that a set of trading activity will result in a movement in the market price of one or more financial assets.

31. 28. The computer-implemented method of claim 27, wherein comparing further comprises recursively performing calculating an average of the likelihood of finding a labeled leaf in a descendant of an unlabeled internal node in the metric tree until no matching trigger tree is found that describes trade activity having a time span that matches a time span of the data representing a series of trade activity.

32. 30. The computer-implemented method of claim 27, further comprising storing the data representing a set of trade activities with time-locked cryptographic protection.

33. A non-transitory computer readable medium comprising computer readable program code, the program code being executable by at least one processor to cause the at least one processor to perform operations, the operations comprising: a data processor receiving data representing a set of trading activities; said data processor converting said data representative of said set of trading activities into a representation of a musical composition; said data processor converting said musical piece representation into a metric tree, wherein notes of said musical piece representation are recorded in labeled leaf nodes of said metric tree, said labeled leaf nodes being connected to unlabeled internal nodes; setting an initial default value for a score representing the probability of trade irregularity; comparing the metric tree to a plurality of trigger trees stored in a lesson database, each trigger tree of the plurality of trigger trees representing a trade irregularity; identifying at least one trigger tree among a plurality of trigger trees that exhibits at least a closest match to the metric tree using a nearest neighbor algorithm, the nearest neighbor algorithm comprising: calculating a distance between trees using a match value, the distance from one of the plurality of trigger trees to the metric tree being the average chance of finding a labeled leaf from the trigger tree at a leaf node connected to an unlabeled internal node of the metric tree; identifying at least one trigger tree having a minimum distance to the metric tree; and modifying a score to represent an increased probability of trading irregularity as a function of the identification of the at least one trigger tree; comparing the score to a pre-established threshold; performing a corresponding action by a review system as a result of said comparing; A non-transitory computer readable medium,

34. The converting step comprises: representing trading activity in the set as notes and representing non-trading activity as rest in the musical composition representation, each note representing a trading order in the set of trading activity; placing notes representing purchase orders on a high-pitched clef of said musical composition representation; placing notes representing sales orders on a bass clef of said musical composition representation; setting the pitch of each note of said musical composition representation according to a price value and a length of time that a corresponding trading order will remain open; setting a tempo of the musical composition representation according to an average rate at which trading orders are filled; setting the time signature of the musical expression according to a combination of market conditions of the type of trade instrument and the venue and trade activity of said set; The medium of claim 33, comprising:

35. The converting step comprises: said data processor converting each note in said musical piece representation into a leaf node of said metric tree; said data processor setting a level of said leaf node in said metric tree according to a duration of a corresponding note in said musical piece representation; said data processor ordering the nodes in the metric tree according to a time ordering of notes in the representation of the musical piece; parsing the metric tree into a plurality of tracks, each track including a smallest discrete trade unit of a set of trading activity; aggregating the tracks into dimensions using a partially labeled tree comparison method, each dimension being an organized grouping of a plurality of discrete trade units; The medium of claim 33, comprising:

36. 34. The medium of claim 33, wherein each trigger tree of the plurality of trigger trees includes data representing a pattern selected from the group consisting of potential market manipulation, market change signals, synthetically created trades, and the probability that a set of trading activity will result in a movement in the market price of one or more financial assets.

37. 34. The medium of claim 33, wherein comparing further comprises recursively performing calculating an average of the likelihood of finding a labeled leaf in a descendant of an unlabeled internal node in the metric tree until no matching trigger tree is found that describes trade activity having a time span that matches a time span of the data representing a series of trade activity.

38. 34. The medium of claim 33, wherein the medium is further configured to store the data representing a set of trade activities with time-locked cryptographic protection.

Images