Patent ID: 12260459

DETAILED DESCRIPTION

The present disclosure relates generally to system components, processes and computer programs for verifiable order message handling for electronic auctions associated with an electronic trading system. An electronic trading system of the present disclosure may include one or more order sending entity systems and a computer platform configured to communicate with the order sending entity system(s) via one or more computer networks. The computer platform may receive one or more electronic order messages from among the entity system(s), where at least one message among the electronic order message(s) is an order of a predetermined order type (e.g., an issuer direct offering (IDO) order) that is eligible to participate in an electronic auction when one or more predetermined auction conditions are met. The predetermined order type may relate to sell order information associated with an entity having securities not previously registered for trading (e.g., transactions) on the electronic trading system represented by the computer platform (an example of an electronic exchange system), but which securities may be in the process of being registered with an appropriate regulatory authority (e.g., via a registration statement). The platform may also identify, from among the electronic order messages, one or more requests for participation in an electronic auction associated with the computer platform (e.g., an electronic exchange system), where the request(s) may include auction-only order information. At least one of the requests may include the order of the predetermined order type. The platform may also be configured to determine an auction price for the electronic auction, and determine whether the sell order information in the order of the predetermined order type meets at least one predetermined auction condition based on the auction price. When the sell order information meets the predetermined auction condition(s), the order is permitted to participate in the electronic auction, such that the order is executed in full in the electronic auction via an auction engine of the computer platform. When the sell order information does not meet the predetermined auction condition(s), the electronic auction may not be permitted to proceed and the order is canceled from participation in the electronic auction.

In some embodiments, aspects of the present disclosure are directed to the creation and handling of a new electronic order type (including a predetermined format in an electronic message) that may permit particular entities (e.g., entities that have securities not previously registered for trading on an electronic exchange system (e.g., a computer platform) to participate in an electronic auction, under predefined conditions, where participation by such entities is not permitted by existing systems (i.e., under any conditions)). Importantly, the present disclosure creates a mechanism (through the newly created particular order message) for such entities to participate (under verifiable conditions as determined by the platform itself). The verifiable conditions allow the platform to ensure that participation by such entities in an electronic auction may not cause the auction to be halted and/or canceled.

In some examples, the entity may have securities not previously registered for trading on an electronic exchange system (which may be represented by the computer platform of the present disclosure), but which securities may be in the process of being registered with an appropriate regulatory (e.g., governmental) authority, such as in a registration statement to be filed with the appropriate authority. In some examples, an IDO order may represent a limit order to sell that may be entered on behalf of an issuer that is offering new shares by selling those shares in an electronic auction for at least one primary direct listing security (e.g., to raise capital). The platform of the present disclosure may perform a number of verifications, both the order characteristics included in the IDO order message, as well as the entity sending the IDO order message. If the (incoming) IDO order message does not meet these verification(s), the order may be rejected. In some examples, the verifications may include one or more of the following, that: the order may only be sent from a designated broker dealer entity that is registered with the platform (e.g., the electronic exchange system), the order is for a limit on open, the order is a sell-only order, the order is priced at (or in some examples towards) a lower end of a filed price range (in the registration statement), and the order is sized and/or valued as indicated in the registration statement. As part of the order message handling, the platform of the present disclosure may control the processing of IDO orders such that the order may not be permitted to be subject to a cancel action or a cancel and replace action and that the IDO order may be included in any imbalance determinations for an electronic auction. Yet further, the order handling may include verifications in order to participate in an electronic auction, including that the auction price is within the filed price range of the IDO order (in the registration statement), that an IDO order is present in the electronic auction, and that the price of the auction should fully execute the IDO order. In some examples, the auction may be hard blocked if these verifications may not be confirmed. In some examples, the electronic auction may include an opening auction for one or more primary direct listing securities.

Aspects of the present disclosure, in some examples, relate to a technique for enabling an entity that is not previously registered for trading with an electronic exchange system, but has obtained regulatory approval (such as a registration statement) from a regulatory authority, to provide its shares (of securities) to the electronic exchange system the very first time the entity issues its shares, via an exchange-executed electronic auction. In the present disclosure, the electronic exchange system, subject to the entity obtaining regulatory approval, may be configured to facilitate a primary offering that does not involve an underwriter (where typically the exchange facilitates a secondary offering that involves an underwriter). In some examples, this technique provides entities the ability to have a public trading of securities (e.g., the ability for public trading and offering of securities directly on the electronic exchange). In other words, a conventional process for entities that are not previously registered for trading is through a secondary offering performed via an underwriter. In contrast, the approach of the present disclosure allows entities to offer securities directly through the electronic exchange publicly (i.e., as a primary offering). In the technique of the present invention, an entity may obtain regulatory approval (e.g., via a registration statement in the US). Once the regulatory approval is obtained, the technique of the present disclosure provides the ability to offer the securities directly on the electronic exchange system, which is defined as a direct listing.

Referring now toFIG.1, a functional block diagram of example electronic trading system100(system100herein) for verifiable electronic order message handling is shown. System100may include posting market platform102(platform102herein), one or more order sending entities104, one or more market maker (MM) entities106and, in some examples, one or more other entities108. In some examples, platform102may represent an electronic exchange system. Although not shown, platform102, order sending entity(s)104, MM entity(s)106and other entity(s)108may be communicatively coupled via one or more communication (e.g., wired and/or wireless) networks. The one or more networks may include, for example, a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, etc.) and/or a public network (e.g., the Internet).

Order sending entity(s)104may be configured to post one or more orders on platform102from one or more market participants (e.g., traders). Order sending entity(s)104may be configured to post orders associated with one or more traders via one or more electronic order messages (i.e., electronic messages indicating an order) and to receive communications regarding orders (e.g., cancellations, executions, etc.) from platform102. An electronic order message may include one or more order characteristics such as, without being limited to, one or more securities associated with the order, an order type, whether the order is for a buy or sell, one or more entity characteristics of the trader, an amount for the order, and the like. In some examples, order sending entity(s)104may include at least one broker dealer. Order sending entity(s)104may comprise a server computer, a desktop computer, a laptop, a smartphone, a tablet or any other suitable computing device configured to capture, receive, store and/or disseminate any suitable data. In some examples, order sending entity(s)104may communicate with one or more market participant devices (associated with market participant(s). In some examples, market participant device(s) may comprise a server computer, a desktop computer, a laptop, a smartphone, tablet, or any other suitable computing device known in the art configured to capture, receive, store and/or disseminate any suitable data.

In some examples, order sending entity(s)104(and/or market participant device(s)) may include a computing device comprising a display device, a user interface and a communication interface for communication with interactive GUI(s)114. The user interface and the display may be one component (e.g., a touchscreen display), may be separate components (e.g., a display and a pointing device) and or any combination thereof. In some examples, order sending entity(s)104may include a client application for communication, such as a client application for communicating with interactive GUI(s)114.

In general, MM entity(s)106may be configured to maintain two-sided quotes in accordance with one or more predetermined business rules of platform102. In one non-limiting example, MM entity(s)106may include at least one designated MM (DMM). DMM(s) may be configured to maintain fair and orderly markets for one or more assigned securities. In some examples, DMM(s) may be configured to facilitate price discovery during market opens, closes and during periods of trading imbalances or instability. Interaction with DMM(s) may improve pricing, reduce volatility and add liquidity to orders being matched on platform102. In some examples, DMM(s) may be configured to manage one or more auctions (e.g., via physical interaction and/or for a completely automated auction (e.g., via algorithm quotes from DMM(s) and/or other market participants). MM entity(s)106may comprise a server computer, a desktop computer, a laptop, a smartphone, a tablet or any suitable other computing device configured to capture, receive, store and/or disseminate any suitable data.

In some examples, MM entity(s)106may include a computing device comprising a display device, a user interface and a communication interface for communication with interactive GUI(s)114. The user interface and the display may be one component (e.g., a touchscreen display), may be separate components (e.g., a display and a pointing device) and or any combination thereof. In some examples, MM entity(s)106may include a client application for communication, such as a client application for communicating with interactive GUI(s)114.

Other entity(s)108may include, without being limited to, one or more away market systems, one or more distribution platforms, and/or any other suitable remote entity that may desire to interact with platform102. Other entity(s)108may comprise a server computer, a desktop computer, a laptop, a smartphone, tablet, or any other suitable computing device known in the art configured to capture, receive, store and/or disseminate any suitable data. In some examples, other entity(s)108may include a computing device comprising a display device, a user interface and a communication interface for communication with interactive GUI(s)114. The user interface and the display may be one component (e.g., a touchscreen display), may be separate components (e.g., a display and a pointing device) and or any combination thereof. In some examples, other entity(s)108may include a client application for communication, such as a client application for communicating with interactive GUI(s)114.

Platform102may include one or more order/execution interfaces110, one or more MM interfaces112, one or more interactive GUIs114, order router/manager116, order verifier118, order book storage structure120, quote book storage structure122, data monitor124, order matching engine126, order and parameter storage136and transaction storage structure138. In some examples, platform102may include one or more of at least one optional clearing interface140and at least one administrator (admin) interface142.

Although not shown, platform102may include at least one processor (e.g., processing device602shown inFIG.6) and non-transitory memory (e.g., memory606shown inFIG.6) storing one or more routines and or algorithms for performing the functions of platform102described herein. An example implementation of one or more components of platform102is shown by computer system600(shown inFIG.6).

In some examples, components110-142of platform102may be embodied on a single computing device. In other examples, components110-142of platform102may be embodied on two or more computing devices distributed over several physical locations, connected by one or more wired and/or wireless links. It should be understood that platform102refers to a computing system having sufficient processing and memory capabilities to perform the specialized functions described herein.

In some examples, one or more of order sending entity(s)104, MM entity(s)106and other entity(s)108may be configured to communicate with platform102via one or more data feed interfaces (e.g., order/execution interface(s)110, MM interface(s)112). The data feed interface(s) may be specially configured as real-time connection(s). Thus, in operation, electronic messages may be transmitted to platform102via the real-time data feed interface(s). In some examples, the data feed may include secure (e.g., encrypted) data feeds.

In summary, platform102may be configured to interact with order sending entity(s)104, MM entity(s)106and other entity(s)108, for example, through one or more electronic communications such as electronic messages, interactive graphical user interface(s) (GUIs), such as interactive GUI(s)114), mobile application(s), etc. For example, platform102may receive order and/or quote indications via electronic messages from among respective order sending entity(s)104and/or MM entity(s)106. Platform102may be configured to parse received electronic messages, perform verification of one or more message characteristics (e.g., header information, sender information, data in the message itself) of the parsed messages and may route verified messages to at least one particular destination based on the message characteristics (e.g., to order book storage120, to continuous matching engine128, to auction engine130, to other entity(s)108).

Platform102may also be configured to generate and send one or more electronic messages and/or electronic indications (such as via interactive GUI(s)114) to one or more of order sending entity(s)104, MM entity(s)106and other entity(s)108. For example, platform102may send order rejection messages based on any errors identified during verification of message characteristics, order cancellation messages based on operation(s) of order matching engine126, auction advertisement messages for one or more upcoming auctions (performed by auction engine130), auction cancellation/halt messages for an auction, transaction indication messages based on operation(s) of order matching engine126, order routing messages to other entity(s)108, publication information associated with operations of order matching engine126(e.g., to one or more distribution platforms among other entity(s)108) and the like.

Yet further, platform102may be configured to perform one or more order matching operations via order matching engine126to generate one or more transactions. In general, platform102may be configured to perform continuous order matching (via continuous matching engine128) and order matching via one or more auctions (e.g., opening auctions, intra-day auctions, etc., via auction engine130). In some examples, the auction may include an opening auction including a direct listing auction.

In some examples, platform102may be configured to permit a predetermined order type (referred to herein as an issuer direct offering (IDO) order) having specific entity characteristics (i.e., an entity having securities not previously registered for transactions (e.g., trading) with platform102) and specific order characteristics (i.e., a sell limit order with sell order information that meets one or more predetermined auction conditions) to participate in the direct listing opening auction. In a non-limiting example, the securities that have not been previously registered may include cash equity securities. In general, embodiments of the present invention could be used with any suitable type of security, including, without being limited to, one or more of cash equities, futures, options, derivatives, fixed income (e.g., bonds) and debt.

Platform102may be configured to verify the message characteristics of incoming IDO order messages (e.g., for entity and auction condition characteristic(s)) in order to permit the IDO order to participate in the opening auction. Importantly, an IDO order message may be configured to include particular elements (e.g., flag(s), values and/or other indicators in the header and/or message body) that permit platform102to verify not only the inclusion of these elements but also that these elements match predefined entity characteristic(s) and predetermined auction condition(s)). Because platform102is able to verify these particular characteristics/conditions, platform102may permit orders for entities with previously unregistered securities to participate in the direct listing opening auction, under particular circumstances.

Importantly, existing systems lack the specific electronic message configuration, order type detection and verification mechanisms of the present disclosure. Thus, conventional systems simply do not permit entities with previously unregistered securities from participation in a direct listing opening auction. In contrast, the architecture of platform102itself, in combination with a new type of order message having a specific configuration permits platform102to verify particular entity characteristics and permit the IDO order to participate in the auction, under predetermined auction conditions. Accordingly, platform102provides the ability to permit orders with particular characteristics (e.g., IDO orders) to participate in an electronic opening auction, where orders from such entity(s) would ordinarily be excluded (e.g., restricted) from participation in the electronic auction. In this manner, system100of the present disclosure may increase the liquidity for the auction (e.g., by increasing the number of orders to be potentially matched), may increase the likelihood of generating matched orders and may decrease the likelihood of storing a number of unmatched orders responsive to the auction (thereby decreasing the number of unmatched orders that may need to be stored and further processed either internally or externally). Thus, platform102provides improved electronic message handling, improved auction process handling and improved overall efficiency of computer resources of platform102.

The solutions described herein utilize the power, speed and precision of a special purpose computer system configured precisely to execute the complex and computer-centric functions described herein. As a result, a mere generic computer will not suffice to carry out the features and functions described herein. Further, it is noted that the systems and methods described herein solve computer-centric problems specifically arising in the realm of computer networks so as to provide an improvement in the functioning of a computer, computer system and/or computer network, including the electronic message handling described herein.

Order/execution interface(s)110may be configured to interact with order sending entity(s)104, MM entity(s)106, other entity(s)108(e.g., away market entity(s), distribution platforms, etc.) and order matching engine126(e.g., in an order execution process). In some examples, order/execution interface(s)110may include an electronic device including hardware circuitry and/or an application on an electronic device. In some examples, order/execution interface(s)110may include at least one data feed interface, including, in some embodiments, security protection.

MM interface(s)112may be configured to interact with MM entity(s)106to capture market maker indications (e.g., bids and offers in assigned issues). The bids and offers may be configured to be stored in quote storage structure122. In some examples, MM interface(s)112may include an electronic device including hardware circuitry and/or an application on an electronic device. In some examples, MM interface(s)112may include at least one data feed interface, including, in some embodiments, security protection.

Although not shown, in some examples, platform102may include one or more further interfaces (e.g., an electronic device including hardware circuitry, an application on an electronic device) configured for interaction with other entity(s)108. For example, platform102may include a separate interface for interaction with away market entity(s) to capture quote and last sale information, which information may be stored in a storage structure (not shown). The away market quote and last sale information may be used to determine a market best bid and offer.

Interactive GUI(s)114may be configured to present one or more user input tools, one or more display tools (and in some examples one or more analysis tools) for interacting with platform102(e.g. with order and/or quote data associated with platform102), including in real-time and/or near real-time. For example, platform102may generate an interactive GUI for presentation on order sending entity(s)104via order/execution interface(s)110, for interacting with order data (e.g., to view orders submitted to platform, to view executed orders executed via order matching engine126, to modify and/or cancel existing orders submitted to platform102, to receive and/or interact with alert, status and/or error messages associated with one or more orders and the like).

In one non-limiting example, platform102may be further configured to generate an administrator-specific interactive GUI for presentation of user interaction tool(s), display tool(s) and analysis tools, for interaction by at least one administrator (not shown) with various aspects of platform102in real-time and/or near real-time (e.g., via optional administrator interface(s)142). In some examples, an administrator-specific interactive GUI may permit an administrator interact with auction(s) (via communication with auction engine130), to interact with pre-auction procedures (e.g., via pre-auction manager132) and to analyze data (such as order data, quote data, away market data, transaction imbalance data and the like).

In another non-limiting example, platform102may be further configured to generate a DMM-specific interactive GUI for presentation of user interaction tool(s), display tool(s) and analysis tools on at least one of MM entity(s)106via MM interface(s)112, for interaction with various aspects of platform102in real-time and/or near real-time. The DMM-specific interactive GUI may permit DMM(s), for example, to view (and in some examples interact with) order data, to view and/or interact with quote data, to interact with auction(s) (via communication with auction engine130), to interact with pre-auction procedures (e.g., via pre-auction manager132) and to analyze data (such as order data, quote data, away market data, transaction imbalance data and the like) to interact with order matching engine126(e.g., to facilitate price discovery during various periods such as market opening and/or closing periods, transaction imbalance periods, instability periods, etc.).

In general, platform102may provide one or more operational tools for interaction with various aspects of platform, including in real-time and/or near real-time, by one or more authorized users (e.g., an administrator, a DMM and the like). The operational tool(s) may include, without being limited to, one or more of an interactive GUI, a command line interface and the like.

Order router/manager116may be configured to receive electronic order messages (including for IDO order(s)), determine order characteristics of the received messages (e.g., order type, sender, etc.). Order router/manager116may also be configured to verify one or more characteristics of the orders, via communication with order verifier118. In some examples, order router/manager116may be configured determine whether entity characteristics (for a sender) match predefined entity characteristics for on indicated IDO order message. In some examples, order router/manager116may also analyze message characteristics, such as to insure that an indicated order message is not missing any information, is a valid order message and the like. Order router/manager116may be further configured to generate one or more messages to one or more entities (e.g., order sending entity(s)104) such as when an order message is rejected. Order router/manager116may be further configured to route verified order message(s) to a destination (e.g., order book storage structure120, continuous matching engine128, other entity(s)108), based on the order characteristics. An example of order router/manager116is described further below with respect toFIG.2.

Order verifier118may be configured to verify one or more characteristics of order messages (including for IDO order(s)). In some examples, order verifier118may verify one or more entity characteristics indicated in an order message. In some examples, order verifier118may perform one or more risk checks on order messages. In some examples, order verifier118may communicate with order router/manager116and auction engine130. In some examples order verifier118may interact with auction engine130to verify order characteristics, for example, as part of an auction allocation process. An example of order verifier118is described further below with respect toFIG.2.

Order book storage structure120may be configured to store one or more orders (e.g., buy and sell orders, including IDO order(s)) received from among order sending entity(s)104. Storage structure120may include any suitable storage structure (e.g., order allocation data structure228shown inFIG.2) suitable for storing and retrieving order data in a computationally efficient and timely manner.

Quote book storage structure122may be configured to store one or more quotes (e.g., bids and offers) received from among MM entity(s)106. Storage structure122may include any suitable storage structure, including any time and/or priority data structures suitable for storing and retrieving quote data in a computationally efficient and timely manner.

Data monitor124may be configured to continually monitor data (e.g., in real-time and/or near real-time), from one or more data sources that may be useful for performing one or more order matching operations by order matching engine126. In some examples, data monitor124may monitor data from among other entity(s)108, such as quote and last sale information from one or more away market entities, which may be useful for determining an up-to-date market best bid and offer.

Storage structure136may be configured to store one or more pre-defined order and order matching parameters and rules that may be used by order matching engine126in matching orders and executing transactions. Storage structure136may include any suitable storage structure, including at least one data structure suitable for storing and retrieving order and matching parameter(s)/rule(s) in a computationally efficient and timely manner.

Transaction storage structure138may be configured to store one or more transactions (e.g., trades) received from order matching engine126(e.g., responsive to one or more order matching processes among continuous matching engine128and auction engine130). Storage structure138may include any suitable storage structure, including at least one data structure suitable for storing and retrieving transaction data in a computationally efficient and timely manner.

Optional clearing interface(s)140may be configured to interact with one or more clearing and settlement entities (e.g., an example of other entity(s)108) for providing clearing and settlement services for securities transactions generated by platform102. In some examples, optional clearing interface(s)140may include an electronic device including hardware circuitry and/or an application on an electronic device. In some examples, optional clearing interface(s)140may include at least one data feed interface, including, in some embodiments, security protection.

Optional administrator interface(s)142may be configured to interact with one or more administrators (not shown) for interaction with various aspects of platform102in real-time and/or near real-time. In some examples, optional administrator interface(s)142may include an electronic device including hardware circuitry and/or an application on an electronic device. In some examples, optional administrator interface(s)142may include at least one data feed interface, including, in some embodiments, security protection.

Order matching engine126may include continuous matching engine128, auction engine130, pre-auction manager132and auction scheduler134. In general, order matching engine126may be configured to validate, match and process all orders and quotes on platform102. In some examples, order matching engine may128route orders to other entity(s)108(e.g., an away market entity) under one or more predefined conditions.

Continuous matching engine128may be configured to immediately execute incoming marketable orders (that meet particular order characteristics) against orders in order book storage structure120in a continuous matching process. Any matched orders may form transactions that may be stored in transaction storage structure138.

Auction engine130may be configured to perform one or more auction processes during one or more designated auction periods. In general, order matching engine126may activate auction engine130at an onset of an auction period (e.g., via one or more indications from auction scheduler134). Auction engine130may initiate an order auction process, which may include queuing orders (including orders among those stored in order book storage structure120) that are eligible to participate in the scheduled auction. Auction engine130may also verify that orders are indeed eligible for participation. Auction engine130may then perform an order matching process for the designated auction period, subject to any predefined auction conditions, and based on a reference price determined for the auction as well as any order imbalances. Matched auction orders may be executed, and resulting transactions may be stored in transaction storage structure138. In some examples, any remaining unmatched orders at the end of the auction may be released to continuous matching engine128for execution against its orders in order book storage structure120. In some examples, auction engine130may be configured to perform an opening auction process for direct limit orders including at least one IDO order. In some examples, the electronic auction process may be performed completely electronically by an electronic decision maker (i.e., without any user input). In some examples, one or more auctions may include interaction with one or more DMMs among MM entity(s)106(e.g., via interactive GUI(s)114). In some examples, the continuous matching process and order auction process(s) may execute concurrently, but are logically separate processes. An example of auction engine130is described further below with respect toFIG.3.

Pre-auction manager132may be configured to perform one or more pre-auction routines (e.g., via rules stored in storage structure136) during at least one pre-auction period. For example, the upcoming auction may be broadcast in the marketplace (e.g., to order sending entity(s)104, other entity(s)108). The broadcasts may include one or more pre-opening indications. In some examples, the pre-opening indication(s) may indicate at least one security to be included in the auction and a price range within which an auction price is anticipated to occur, without publicly disclosing details of orders that may be eligible for the auction. In some examples, the pre-opening indication(s) may provide information that may be related to an indication reference price for a security (e.g., information related to a security's last official closing price, a security's offering price, a security's last reported sale price on a securities market, a security's most recent transaction price, a lowest price of an auction price range, etc.). In some examples, as new orders are received by platform102and existing orders may be canceled and/or modified during the pre-auction period, pre-auction manager132, via auction engine130, may continuously calculate and disseminate an updated auction imbalance indication.

Auction scheduler134may be configured to store information related to one or more auction periods (e.g., an opening auction period, a closing auction period, at least one intra-day auction period, etc.). In some examples, auction scheduler134may also be configured to store information relating to one or more pre-auction periods. In some examples, auction scheduler134may prompt initiation and/or termination of one or more of pre-auction process(s) by pre-auction manager132and auction process(s) by auction engine130based on the stored pre-auction/auction period information.

Although embodiments of the present disclosure describe auctions in the context of an opening auction, it is understood that auctions of present disclosure could also be scheduled at different times during the trading day (including, in some examples, a closing auction). Although embodiments of the present disclosure describes auctions specific to direct listing auctions, it is understood that the present disclosure is not limited to direct listing auctions, and that embodiments of the present disclosure could be used in any type of financial instrument market center environment (e.g., cash equities, futures, options, derivatives, fixed income (e.g., bonds), debt, etc.).

It is understood that system100represents an exemplary embodiment of the present disclosure and that system100may be configured with more or fewer components than shown, may combine two or more components, or may have a different configuration or arrangement of the components. For example, although continuous matching engine128and auction engine130are illustrated as separate components, in some examples, continuous matching engine128and auction engine130may be combined into one component.

Referring now toFIG.2, a functional block diagram of example verifiable order message handling system200is shown, according to an aspect of the present disclosure. Verifiable order message handling system200(also referred to herein as system200) may include order manager202and order verifier204. In some examples, order manager202represents an example of order router/manager116and order verifier204represents an example of order verifier118(shown inFIG.1). For completeness, system200is shown in communication with order book storage206.

Order manager202may include message parser208, order type detector210, message/order parameter(s) storage structure218, order analyzer212, outgoing message generator214and message router216. In summary, order manager202may be configured to receive one or more incoming electronic order messages230(including messages indicating IDO order(s)), may analyze and verify characteristic(s) of messages230, may generate one or more outgoing messages (in some examples) and may route verified messages (in some examples) to at least one destination.

Message parser208may be configured to parse incoming electronic order message(s)230(e.g., received via order/execution interface(s)110ofFIG.1). In general, an order message230may include a message header having a predetermined format and a message body. Message parser208may parse each order message230to identify and extract one or more predetermined elements in the message header (e.g., an element in a predetermined position, a flag set in in a predetermined position and the like) associated with message characteristic(s). In some examples, message parser208may parse information in the message body to extract one or more message characteristics (e.g., an order amount, a buy or sell indication, other conditions). For example, message parser may identify and extract keywords (e.g., “buy”, “sell”, etc.), predetermined phrases, etc. in the message body, via one or more text-parsing algorithms (e.g., keyword matching, natural language processing based on one or more rules, and the like). The extracted elements (e.g., message characteristic(s)) in the header and/or message body from an order message230may be provided to order type detector210.

Order type detector210may be configured to determine an order type (e.g., IDO order, limit on open (LOO) order limit order, market order, etc.), indicated in each order message230, based on the extracted elements received from message parser208. In some examples, order type detector210may determine the order type by comparing one or more of the extracted elements to predetermined order type parameters stored in storage structure218. For example, a direct listing order type may be indicated by a direct listing flag. As another example, an IDO order type may be indicated based on inclusion of a predefined value in a particular header element. Order type detector may provide the identified order type and the extracted elements (e.g., message characteristic(s) to order analyzer212.

Order analyzer212may be configured to analyze the message characteristics for an order message230to determine whether it meets one or more predetermined conditions specific to the identified order type. For example, order analyzer212may compare one or more of the extracted elements to one or more predefined order type characteristics stored in storage structure218, to confirm (for example) that the order type is not missing any of one or more predefined order type characteristics, that information in the extracted elements (e.g., a buy amount for a security, a sell amount for a security, a security indicated in the order, an order action (e.g., create, modify, cancel), etc.) match predetermined order type conditions (e.g., a permissible range of an amount, a permissible buy, a permissible sell, a permissible security, and the like). In general, order analyzer may determine whether any suitable characteristic indicated in the extracted element(s) meets a suitable predefined order type characteristic to confirm that the order is indeed a valid (permissible) order type.

Order analyzer212may also be configured to verify one or more characteristics of order message230, via communication with order verifier204. Order verifier204may include risk check evaluator220, entity validator222, risk check parameter storage structure224and entity characteristic storage structure226. In summary, order verifier204may perform one or more of risk checks and sender validation of the message characteristic(s). Order verifier204may communication an indication of verification (or lack of verification) to order manager202and/or via communication(s)236with an auction engine (e.g., auction engine130ofFIG.1). Order verifier204may perform at least one type of verification based on a request from order manager202and/or auction engine130(via auction engine communication(s)238).

Referring further to order verifier204, order verifier204may include risk check evaluator220, entity validator222, risk check parameter storage structure224and entity characteristic storage structure226.

Risk check evaluator220may be configured to perform one or more risk checks on the message characteristic(s) based on one or more predefined risk check parameters stored in storage structure224. In a non-limiting example, the risk checks may include one or more of a single order maximum notional value risk check, a single order maximum quantity risk check and a gross credit limit check. In some examples, the risk check(s) may be optional.

Entity validator222may be configured to verify one or more entity characteristics of an order message230. In some examples, entity validator222may compare a market participant identifier (MPID) extracted from message230to one or more predefined MPIDs stored in storage structure226. In some examples, the entity validator may be used (e.g., by order manager202) to determine whether an IDO order type indicated in an order message230is sent from a designated broker dealer that is registered with platform102, based on comparing the MPID in the order message230to predefined MPIDs stored in storage structure226. In general, entity validator222may compare any suitable entity characteristic indicated in the order message230(e.g., the market participant itself, a location of the market participant, a location of the order sending entity and the like) to one or more predefined entity characteristics to validate an entity associated with the order message230.

Storage structure224may be configured to store one or more risk check parameters (and in some examples one or more rules) that may be used by risk check evaluator220for performing one or more risk checks on order message characteristic(s). Storage structure224may include any suitable storage structure for storing and retrieving predefined risk check parameter(s)/rules in a computationally efficient and timely manner.

Storage structure226may be configured to store one or more pre-defined entity characteristic(s) (and in some examples one or more rules) that may be used by entity validator222for performing one or more entity validations on entity characteristics. Storage structure226may include any suitable storage structure for storing and retrieving predefined entity characteristic(s)/rules in a computationally efficient and timely manner.

Next, a summary of IDO order characteristics and auction conditions are described. An IDO order may be defined as a limit order to sell that is entered on behalf of an issuer that is selling shares in an opening (core) auction for a primary direct listing security (e.g., to raise capital). An IDO order may include particular entity characteristic(s) including that the IDO order is associated with an entity having securities not previously registered with a regulatory (e.g., governmental) authority and listed on at least one. registered exchange (e.g., a US registered exchange), and therefore not previously eligible to trade on platform102, and that the IDO order is sent from a designated broker dealer that is registered with platform102. Order characteristics for an IDO order may include that the order: is designated as a limit order, is a sell side order, is not subject to particular actions (e.g., a cancel action, a cancel and replace action or a modification action), is priced at (or in some examples towards) a lower boundary of a filed price range (e.g., a primary direct listing auction price range), and is sized and valued as indicated in the filing. In addition, an IDO order may include the following auction condition(s): an IDO order is present in the auction, the IDO order is to be executed in full within the auction (e.g., based on a price of the auction), and the primary direct listing security (for the IDO order) is opened at or within an auction price range of the primary direct listing auction (e.g., a price of the auction is within the filed range. Yet further, order book storage206may permit one IDO order to be stored (e.g., the number of IDO orders may be limited to one). For example, one IDO order may be entered on behalf of an issuer, by one member organization (e.g., a designated broker dealer).

In general, an IDO order may allow an entity that has not previously had its securities registered, to list its securities on platform102at the time of effectiveness of a registration statement pursuant to which the entity itself will sell shares in an opening auction. The IDO order may permit a primary direct listing that could be effected if (i) the auction price would be within the price range specified by the entity in its effective registration statement, and (ii) the full quantity of the IDO order (e.g., the shares that the entity seeks to sell in the primary direct listing) can be sold within that price range. In this manner, the IDO order permits orders from particular entities to be included in an auction, under particular order and auction conditions, where such orders were not previously permitted to be included in an auction.

Referring back to order analyzer212of order manager202(inFIG.2), order analyzer may analyze the specific order characteristics for IDO orders noted above, together with verification of the entity characteristics (and in some examples, also one or more risk check indications (from order verifier204). Based on analysis and verification, order analyzer212may determine whether the indicated IDO order is a valid order or whether the order should be rejected.

Based on the order analysis and verification (for any order type including IDO orders), order analyzer212may determine whether to generate an outgoing message to one or more entities (e.g., an order rejection message, e.g., an order acceptance message, etc.) and/or whether to route the order message230to at least one destination. For example, order analyzer212may determine that an order message is to be rejected, thus no order message routing may be performed. Instead, order analyzer212may prompt outgoing message generator214to generate a rejection message (e.g., as message232) to an order sending entity (e.g., order sending entity(s)104). As another example, order analyzer212may determine that no outgoing message needs to be generated, and that the order message230itself (e.g., as message232) is to be routed to other entity(s)108such as an away market). As yet a further example, order analyzer212may determine that both an outgoing message (e.g., an acceptance message of an order) should be generated and sent (e.g., as message232) to order sending entity(s)104and that the order message itself should be routed (e.g., as orders234or as orders236). It is understood that the above examples are exemplary and that embodiments of the present disclosure may be used with any other possible examples of outgoing message generation and/or order message routing. In some examples order analyzer212may include a verification indication (e.g., a flag, a value, etc.) in order message(s)230that have been analyzed and verified.

Outgoing message generator214(also referred to herein as generator214) may be configured, in some examples, to receive an indication from order analyzer212to generate an outgoing message for one or more entities. In some examples, the message generation indication may include an indication of a message type to be included (e.g., order confirmed, order rejected, order modified, etc.) and may include an indication of at least one recipient for the message. Generator214may be configured to look up an electronic address for the indicated recipient, and may create the electronic message in one or more suitable electronic formats for a particular recipient entity. Generator214may be configured provide any generated outgoing messages to message router216.

Message router216may be configured to route one or more of verified order messages and outgoing messages to at least one destination. For example, message router216may route at least one verified order and/or outgoing message232to one or more entities (such as entity(s)104, entity(s)108, etc.). As another example, message router216may route at least one verified order message234to continuous matching engine126). As yet another example, message router216may route at least one verified order message236to order book storage206.

An important aspect of system200is its ability to analyze/verify incoming order messages)230in real-time (and/or near real-time) and to also route order and/or outgoing messages (e.g., messages232-236) to one or more destinations in real time (and/or near real-time). Of significance, the order information in incoming message(s)230is time-sensitive. Any delays in transmitting message(s)230to their destination may cause any further processing (e.g., order matching internally and/or externally) to become based on stale data, leading to inaccurate transactions. Moreover, any delays in transmitting outgoing message(s)232(such as messages related to a status of an order in platform102based on order analysis/verification) may cause a delay in the destination entity(s) ability to respond to the outgoing message232(such as resubmit an order with one or more corrects, cancel an order, adjust an order, submit a new order, etc.). In some examples, a delay in an outgoing message232may be such that it is impossible for the destination entity to respond to the message (e.g., an auction has ended). Accordingly, it is critical that system200is configured to continually and in real-time (and/or near real-time) perform the order analysis, verification, feedback (through outgoing messaging) and routing operations described herein.

Storage structure218may be configured to store one or more predefined message and/or order parameters (and in some examples one or more rules) that may be used by one or more of message parser208, order type detector210, order analyzer212and outgoing message generator214for performing one or more operations on incoming electronic order messages230. Storage structure218may include any suitable storage structure for storing and retrieving predefined message/order parameters/rules in a computationally efficient and timely manner.

For completeness, an example of order book storage206is also shown inFIG.2. Order book storage206represents an example or order book storage structure120(FIG.1). In some examples, order book storage206may include at least one order allocation data structure228. In some examples, orders in order messages236may be entered into order allocation data structure228according to ranking such that within each price level, orders may be organized according to various order types. For example, Table 1 below shows a non-limiting example ranking that may be implemented. In Table 1, one or more types of displayed orders may have a higher priority in data structure228, with other orders decreasing in priority (e.g., one or more types of non-displayed orders, one or more types of auction orders), such that one or more types of directed orders may have a lower priority.

TABLE 1Example order book rankingPriorityOrder typeHigher PriorityParticular type(s) of displayed ordersParticular types of non-displayed ordersParticular types of auction ordersLower PriorityParticular types of directed orders

In some examples, the type(s) of auction orders that may be included in data structure228may include auction only orders, such as limit or market orders to be traded in an auction. Non-limiting examples of auction only orders may include one or more of market on open (MOO) orders (e.g., market orders to be matched during an opening or reopening auction), limit on open (LOO) orders (e.g., limit orders to be matched during an opening or reopening auction), market on close (MOC) orders (e.g., market orders to be matched during a closing auction), limit on close (LOC) orders (e.g., limit orders to be matched during a closing auction), and IDO orders.

In some examples, order book storage206may be configured to store at least one IDO order under one or more predefined conditions. For example, order book storage206may store an IDO order (received among order message(s)236) on data structure228when an IDO order does not already exist on data structure228(that has already been entered on behalf of the issuer by one member entity). Otherwise, order book storage206may reject the IDO order.

In some examples, one or more auction-only type orders may be designated for an opening or reopening auction before a core trading session begins (e.g., for a core opening auction) or during a halt or a pause (e.g., for a trading halt auction). In some examples, any quantity of these designated orders that are not matched in a designated auction may be cancelled.

It is understood that system200represents an exemplary embodiment of the present disclosure and that system200may be configured with more or fewer components than shown, may combine two or more components, or may have a different configuration or arrangement of the components.

Referring now toFIG.3, a functional block diagram of example auction engine300is shown, according to an example of the present disclosure. Auction engine300may represent an example of auction engine130(FIG.1). Auction engine300may include auction order allocator302, auction order verifier304, auction controller306, one or more auction process routines308and storage structures312-318that may be in communication via a control and data bus320. In some examples, auction engine300may be configured to communicate with optional GUI interface310, to receive inputs from and/or provide outputs to optional interactive GUI334. In some examples, auction engine300may be configured to perform electronic auction processing without any user input. In some examples, one or more of components302-310may operate in parallel during an auction period. Storage structures312-318may include any suitable data structure for storing and retrieving data and/or information in a computationally efficient and timely manner.

Auction order allocator302may be configured to obtain potential orders322that may be indicated for at least one auction, for example, from order book storage structure120(and/or order book storage206). In some examples, potential orders322to be allocated may be determined once an auction price332has been determined (e.g., via auction process routine(s)308and/or via one or more user indications from optional interactive GUI334). In some examples, the potential orders322to be allocated may be based on the type of auction (e.g., an opening auction, a trading halt auction, a closing auction). In some examples, the allocation may include comparing potential orders322to one or auction conditions (e.g., based on the specific order type, such as an IDO order) and including potential orders322that meet the auction condition(s) in the allocation (for participation in the auction). In some examples, exclusion of a potential order322that does not meet the auction condition(s) may cause the particular order to be excluded from the auction (e.g., to cancel participation in the auction). In some examples, exclusion of a potential order322may cause the auction itself to be canceled. In some examples, the allocation may include ranking approved orders for the auction (among potential orders322) by order type and allocating an individual auction price for each particular order (e.g., based on order type) for the auction.

In a non-limiting example, the allocation may include ranking and allocating an individual auction price for MOO orders, market orders, displayed limit and LOO orders, and at least one IDO (sell) order that is priced at or lower than an execution price. In some examples, one or more buy DMM orders (e.g., that meet predefined auction condition(s)) may also be included in the allocation. In some examples, allocated orders may be stored in auction order storage structure312according to their respective ranking and allocated individual auction prices.

Auction order verifier304, in some examples, may perform one or more risk check evaluations of potential orders322(e.g., via communication(s)324with order verifier204). In some examples, auction order verifier304may operate in parallel with auction order allocator302to allocate and verify auction orders among potential orders322.

Auction controller306may be configured to communicate with auction scheduler134(FIG.1) to obtain indications of one or more of at least one pre-auction period, an auction start time, an auction end time, an auction duration and the like. Auction controller306may also be configured to communicate, in some examples, with optional GUI interface310, to receive user input from at least one authorized user (via optional interactive GUI334) which user inputs may also be used to control one or more operations of auction engine300. In general, auction controller306may be configured to control one or more operations of one or more among auction order allocator302, auction order verifier304, auction process routine(s)308, optional interactive GUI334(in some examples), and storage structures312-318. In some examples, auction controller306may control operations among components302and306-318based on indications from auction scheduling communication(s)326, including activating one or more components of auction engine300and/or terminating operation of one or more components of auction engine300(including, in some examples, halting and/or canceling an auction).

Auction process routine(s)308may be configured to perform one or more operations related to initiation of an auction, order matching throughout the auction, and termination of an auction over an auction period. In general, auction process routine(s)308may use an order imbalance328(that may vary throughout the auction), reference price330and auction price332(e.g., that may be determined prior to the auction) to perform the order matching of the auction orders (stored in storage structure312) during the auction. In general, reference price330refers to a single price published in advance of the electronic auction (which price desirably would be the lower end of the range of the registration statement for an IDO order). Auction price332(also referred to herein as an execution price) refers to the actual price at which the electronic auction would be conducted. In some examples, auction process routine(s)308may also use one or more auction parameters and/or auction conditions (stored in storage structure314) to perform order matching during the auction. In a non-limiting example, the auction parameter(s) (stored in storage structure314) may include one or more of an auction order maximum quantity (which may depend on order type), a primary listing auction price range (e.g., for securities indicated as a primary direct listing), an IDO quantity (e.g., defining a quantity the IDO order should equal, a zero value indicating that IDO order(s) may be rejected) and an IDO broker dealer (indicting the broker dealer permitted to enter the IDO order). In some examples, an IDO order may be guaranteed to participate in a direct listing auction at auction price332. If the limit price of the IDO order is equal to auction price332, the IDO Order may be provided priority at that price.

Responsive to order matching during the auction, auction process routine(s)308may generate one or more matched orders and/or one or more unmatched orders, which may be stored in respective storage structures316and318. In some examples, one or more unmatched orders may be released to continuous matching engine128(e.g., upon termination of the auction). For example, unexecuted portions of orders not designated for ‘auction only’ may be released to continuous matching engine128. In some examples, one or more unmatched orders (stored in storage structure318) may be cancelled (e.g., via auction controller306and/or via user input from optional interactive GUI334, such as based on the order type). In some examples, any matched order(s) (stored in storage structure316) may be transferred, upon termination of the auction to transaction storage structure138(FIG.1).

In some examples, auction process routine(s)308may be configured to determine an opening order imbalance as well as any order imbalances throughout the auction (referred to generally as order imbalance328). In some examples, order imbalance328may include a determination of a side of an imbalance (e.g., buy or sell), to determine the side with a greater ‘has to go’ quantity. In some examples, a buy side ‘has to go’ quantity may be determined as a sum of an aggregated size of all eligible buy orders priced above the reference price and all buy MOO and market orders. In some examples, a sell side ‘has to go’ quantity may be determined as a sum of aggregated size of all eligible sell/sell short/sell short exempt orders priced below the reference price, a (sell) IDO order priced at or below the reference price and all sell/sell short/sell short exempt MOO and market orders. In some examples, if the buy side ‘has to go’ quantity is the same as the sell side ‘has to go’ quantity, then the side of the imbalance may be set to ‘none’ and a total imbalance quantity may be set to zero.

In some examples, a total imbalance quantity may also be determined. For example, if there is an imbalance side, a total imbalance quantity may represent a difference between the ‘has to go’ quantity on the side of the imbalance and a total quantity of all orders eligible to participate in the auction that is marketable at the reference price (both at priced and better priced) on the opposite side.

In some examples, optional interactive GUI334(via optional GUI interface310) may interact with auction engine300, so that at least one authorized user (e.g., an administrator, a DMM (e.g., among MM entity(s)106), and the like) may interact with (e.g., provide at least some management of) an auction performed by auction engine300. In general, an authorized user may include any user permitted (e.g., based on one or more predefined user credentials) to interact with auction engine300, such as an administrator, a DMM, a MM and the like.

In a non-limiting example, an authorized user may determine auction price332for a core opening auction and/or a trading halt auction, for example by interaction with information stored on platform102via user input, display and/or analysis tools of optional interactive GUI334. In some examples, if an imbalance is indicated, the authorized user may select an auction price332at which all better-priced orders on the side of the imbalance can be satisfied. In some examples, the authorized user may not cause a direct listing auction for a primary direct listing to be conducted by auction engine300when the auction price332would be below a lowest price or above a highest price of the primary direct listing auction price range or there may be insufficient buy interest to satisfy both the IDO order and all better priced sell orders in full.

In one non-limiting example, an authorized user may provide DMM participant allocation to auction engine300, via optional interactive GUI334. For example, at-priced DMM orders may be included as part of allocated orders for an auction (e.g., in storage structure312), for example, based on a time of entry and any other orders or interest that may join a position among the allocated orders. In some examples, a parity allocation to a DMM participant may be allocated according to a price-time priority ranking (e.g., among the auction orders). In some examples, both at-priced DMM orders that do not receive an allocation and that lock other unexecuted orders and buy and sell better-priced DMM orders may be cancelled after the auction processing period concludes.

It is understood that auction engine300represents an exemplary embodiment of the present disclosure and that auction engine300may be configured with more or fewer components than shown, may combine two or more components, or may have a different configuration or arrangement of the components.

Some portions of the present disclosure describe embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are used to convey the substance of this disclosure effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are to be understood as being implemented as data structures, computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, at times, it may be convenient to refer to these arrangements of operations as modules or algorithms. The described operations and their associated modules may be embodied in specialized software, firmware, specially-configured hardware or any combinations thereof.

Platform102(and/or system200or auction engine300) may be configured with more or less components to conduct the methods described herein with reference toFIGS.4and5. In particular,FIG.4is a flowchart diagram illustrating an example method for verifiable order message handling of incoming order messages, including messages that may be suitable for an electronic auction, according to an aspect of the present disclosure; andFIG.5is a flowchart diagram illustrating an example method for performing an electronic auction with verified order data, according to an aspect of the present disclosure. As illustrated inFIGS.4and5, the methods shown may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, the methods shown inFIGS.4and5may be performed by one or more specialized processing components associated with components110-142of system100ofFIG.1(as well as components ofFIGS.2and/or3). It is understood that methods shown inFIGS.4and5represents a non-limiting example of handling electronic order messages and performing electronic auctions related to IDO orders. The methods may also be implemented to handle any other type of electronic messages anticipated by the present disclosure.

Referring next toFIG.4, a flowchart diagram of an example method400for verifiable order message handling of incoming order messages. At step402, order router/manager116(order manger202) may receive one or more incoming electronic order messages (e.g., via order/execution interface(s)110) from among order sending entity(s)104. At step404, order router/manager116(order manger202) may parse the incoming order messages to identify and extract one or more message characteristics. At step406, order router/manager116(order manger202) may identify an order type in each message based on the identified message characteristic(s) (step404), for example, based on one or more predefined stored message type parameters.

At step408, order router/manager116(order manger202) may determine whether the order type indicates an IDO order (i.e., an auction only sell order having one or more entity characteristics). When it is determined, at step410that the order type indicates an IDO order, step410may proceed to step412. When it is determined that the order type does not indicate an IDO order, step410may proceed to step416.

At step412, order router/manager116(order manger202), via order verifier118(204) may determine whether order characteristics and entity characteristic(s) indicated among the (extracted) message characteristics matches predefined order characteristics and at least one predefined entity characteristic. For example, the predefined order characteristics may include that the IDO order is a limit on open, that the IDO order is priced at a lower end of the filed price range and that the IDO order is sized and valued as indicated in the filing (registration). For example, step412may include comparing an MPID extracted from the order message to one or more predefined MPIDs, to determine whether an indicated IDO order is sent from a designated broker dealer that is registered with platform102(entity characteristics), based on the MPID comparison. At step414, it is determined whether the IDO order matches the predefined order and entity characteristic(s). When it is determined, that the IDO order matches the predefined order and entity characteristic(s), step414may proceed to optional step416.

At optional step416, order verifier118(204) may perform a verification of one or more order messages (including, in some examples of an IDO order). In some examples, the verification may include one or more risk check evaluations. In some examples, order router/manager116(order manger202) may perform one or more verifications of the message characteristic(s) (e.g., that the order message is missing information (e.g., is incomplete), includes incorrect information, does not match information to be included for a particular order type, that an order action for an order type is permissible, and the like).

At optional step418, order router/manager116(order manger202) may generate one or more outgoing messages to one or more entity(s) (e.g., order sending entity(s)104, other entity(s)108, etc.), based on analysis of the order messages in steps402-416. For example, an outgoing message may indicate rejection of an order, acceptance of an order, acceptance to modify an order, transfer of an order to an away market and the like.

At optional step420, order router/manager116(order manger202) may add one or more indicators to an order message responsive to verification of the message characteristic(s). In some examples, the verification indication(s) may be used by internal and/or downstream components to ensure that processing of orders is not disrupted due to any errors in the order message.

At step422, order router/manager116(order manger202) may route verified order message(s) and/or outgoing message(s) (including any IDO orders) to one or more destinations, based on the analysis and verification in steps402-418. In some examples, the destination(s) may include one or more of order book storage structure120(206), continuous matching engine128, order sending entity(s)104, MM entity(s)106, other entity(s)108).

When it is determined, at step414, that the IDO order does not match the predefined entity characteristic(s), step414may proceed to step424. At step424, the IDO order may be rejected. At step426, a rejection message for the IDO order may be generate. Step426may proceed to step422and the rejected IDO order message may be sent to an appropriate destination (e.g., order sending entity(s)104).

At step428, when a verified IDO order exist, order router/manager116(order manger202) may route the IDO order to order book storage structure120(206). Order book storage structure120(206) may store the IDO order under one or more predefined conditions. For example, the IDO order may not be stored, when an IDO order already exists on order book storage structure120(206). In this case, the IDO order may be rejected.

Referring next toFIG.5, a flowchart diagram of an example method500for performing an electronic auction with verified order data. At step502, auction engine130(300) may receive one or more auction participation requests. The participation requests may include one or more potential orders stored in order book storage structure120(206) that may be suitable for an electronic auction. At step504, an auction price may be determined for an electronic auction. In some examples, the auction price may be determined automatically by auction engine130(300). In some examples, the auction price may be determined based on user input from at least one authorized user (e.g., an administrator, a DMM, etc.) (e.g., via interactive GUI334).

At step506, auction engine130(300) may allocate one or more orders among the auction participation requests for a particular auction, based on the auction price. For example, the orders may be ranked and priced based on the auction price. In some examples, one or more order characteristics of the participation requests (potential orders) may be compared against one or more auction condition(s) to determine whether the participation requests are eligible for the auction. In some examples, ineligible participation requests may be excluded from the auction.

At step508, auction engine130(300) may identify whether at least one order of a predefined order type (i.e., an IDO order) is included among the auction participation requests. When it is determined, at step510, that an IDO order is not included, the auction may be canceled (at step512). When it is determined, at step510, that an IDO order is included, step510may proceed to step514.

At step514, auction engine130(300) may compare sell order information in the IDO order to predetermined auction condition(s) (e.g., the auction price should fully execute the IDO order). When it is determined, at step516, that the auction condition(s) for the IDO order are not met, the auction may be canceled (at step518).

When it is determined, at step516, that the auction condition(s) for the IDO order are met, step516may proceed to step520. At step520, auction engine130(300) may permit the IDO order to participate in the auction (i.e., the auction is permitted to proceed with the IDO order).

At optional step522, auction engine130(300) may perform a verification of one or more of the allocated orders (including, in some examples, the IDO order). In some examples, the verification may include one or more risk check evaluations (e.g., via order verifier118(204)). In some examples, unverifiable orders may be excluded from the auction.

At step524, auction engine130(300) may perform an auction process such that the IDO order is executed fully in the auction. In some examples, the auction process may include matching one or more orders among the allocated orders based on one or more order imbalances over an auction period.

At step526, auction engine130(300) may generate at least one matched order responsive to the auction. At optional step528, auction engine130(300) may generate at least one unmatched order responsive to the auction.

Referring next toFIGS.7A-10B, examples of interactive GUIs for authorized users that may be part of platform102(FIG.1) are described, according to aspects of the present disclosure. More particularly,FIGS.7A and7Bare screenshots of example DMM GUI700for interaction with platform102via a DMM (e.g., an example of an authorized user);FIGS.8A-8Eare screenshots of example administrator GUI800for interaction with platform102via an administrator (e.g., another example of an authorized user);FIGS.9A and9Bare screenshots of example pop-up window900of administrator GUI800; andFIGS.10A and10Bare screenshots of example pop-up window1000of administrator GUI800. Although exemplary sections/windows are depicted inFIGS.7A-10B, alternative configurations for the sections/windows are envisioned. For example, each interactive GUI (e.g., GUIs700and800) may include more or fewer sections, windows, webpages and/or tabs. Additionally, the sections/windows may be reorganized and displayed to optimize GUI space and efficient utilization of pertinent information.

Referring toFIGS.7A and7B, example screenshots of DMM GUI700are shown.FIG.7Aillustrates first portion702of DMM GUI700andFIG.7Billustrates second portion708of DMM GUI700. Together, first portion702and second portion708illustrate various regions (704,710,712,714and716) for a DMM to review and/or interact with various securities, to provide at least some management of an auction (e.g., performed by auction engine130).

Securities selection region704(also referred to as region704), in first portion702, may include one or more selectable security elements (e.g., nineteen security elements as shownFIG.7A) including, in some examples, security elements in a pre-open state and/or an open state. For each security element in region704, GUI700may include the most up-to-date security information (as available). In some examples, the security information displayed in the security element (if any) may depend on one or more predefined conditions and/or predefined events. For example, a security element may not show security information except for predefined condition(s) and/or predefined event(s). In this manner, GUI700may provide an improved user interface, where the arrangement and display of information allows the user to better identify and focus on particular information of interest. InFIGS.7A and7B, an example of GUI700for selection of security element706(e.g., security element ‘BX’) is shown.

As shown inFIG.7B, second portion708of GUI700may include option menu region710, template region712, imbalance region716and message window716. Option menu region710may display one or more selectable options (an ‘Update’ option is illustrated) that may be available for a currently opened template (in template region712). Template region712may include user display and/or input tools (e.g., textual input tools), that may depend upon an option selected in option menu region710, for allowing a DMM to view and/or interact with the most up-to-date (i.e., current) bids and/or offers for a particular security element (e.g., ‘BX’). InFIG.7B, an opening auction template is shown in template region712. In general, template region712may include one ore selectable templates, such as (without being limited to) an opening auction template, a quoting template, a closing auction template, an indications template and the like. Imbalance region714may provide the most up-to-date (i.e., current) imbalance information associated with a particular security element (e.g., ‘BX’). Message window716may display one or more relevant messages for the DMM to action.

Referring toFIGS.8A-8E, example screenshots of administrator (admin) GUI800are shown.FIGS.8A and8Billustrates respective first user-selection portion802and second user selection portion808of admin GUI800.FIGS.8C-8Eprovide respective security information portions812,816and820. Together, portions802,808,812,816and820of admin GUI800provide interactive management tools for an administrator to select one or more securities, filter tools to filter securities presented in display regions814,818and822, and facilitate an opening auction (e.g., to provide at least some management of an auction that may be performed by auction engine130).

Referring toFIGS.8A and8B, first user-selection portion802and second user-selection portion808include user-selection tools804for selecting a security (also referred to as a symbol), filtering securities shown in display regions814,818and822based on one or more selected filter criteria, managing a security, and facilitating an opening auction, such as (without being limited to) text input boxes and/or drop down selection tools. First user-selection portion802may also include additional user tools806, such as (without being limited to) search, reset and additional options. Second user-selection portion808may also include additional user tools810, such as bulk update, display and setting options.

Referring toFIGS.8C-8E, display regions812,816and820may include respective security information portions814,818and822. Regions814,818and822may display information on one or more securities in accordance with user-selection tools804ofFIGS.8A and8B. In some examples, a user may first view a number of securities (symbols) shown in display regions812,816and820(FIGS.8C-8E). The user may create one or more filter criteria using user-selections tools804(FIGS.8A and8B), to reduce the number of securities (symbols) displayed in display regions812,816and820based on the selected filter criteria.

Referring toFIGS.9A and9B, pop-up window900of admin GUI800is shown. Pop-up window900may be generated upon selection of ‘symbol state’ among user-selection tools804(FIG.8A). Pop-up window900may include first portion902and second portion910shown in respectiveFIGS.9A and9B. Pop-up window900illustrates a first window that may be used by an administrator to approve the running of an opening auction. In general, pop-up window900may provide an administrator with the ability to select a state for a security (also referred to as a symbol) review parameters for the security, select actions for a security and submit information to initiate an opening auction.

Pop-up window900may include tab region904for user-selection of one or more tabs associated with pop-up window900. InFIG.9A, a ‘Settings’ tab in tab region904has been selected. Other tabs in tab region904may provide information on MM sender MPIDs and one or more DMM symbol (security) subscriptions.

Pop-up window900may include drop-down user-selection region906for selecting a state for the security. In one embodiment, one of the states that may be selected may include ‘Other.’ Selection of the ‘other’ state in region906may be associated with an opening auction. Pop-up window900may also include display region908, action selection region912, search region914and setting region916.

Display region908(shown in first portion902and second portion910) may provide information on one or more parameters associated with a security. For example, display region908may provide the administrator with the ability to review whether a security is eligible for an opening auction. Action selection region912may include one or more user input tools for selecting at least one action for a security. Search region914may include one or more user input tools for searching for information associated with a security. Setting region916may include one or more user tools for displaying or hiding empty properties (shown in display region908).

Pop-up window900may also include submission/reset buttons918, for user input to submit the security (when ‘Other’ is selected in region906) for an opening auction (when the ‘submit’ button is selected) or to reset information in pop-up window900(when the ‘reset’ button is selected). Selection of the ‘submit’ button (among buttons918) may generate pop-up window1000(FIGS.10A and10B).

Pop-up window1000represents a second window that may be used by an administrator to approve the running of an opening auction. In other words, pop-up window900(FIGS.9A and9B) may provide the administrator the ability to manage different operations and actions with a security (including initiating approval for an opening auction). Pop-up window1000(FIGS.10A and10B) may provide the administrator the ability to further review auction information and approve the running (activation) of the opening auction.

Referring toFIGS.10A and10B, pop-up window1000of admin GUI800is shown. Pop-up window1000may include first portion1002and second portion1010shown in respectiveFIGS.10A and10B. Pop-up window1000may include drop-down user-selection region1004for selecting a state for the security. Pop-up window1000may also include display region1006, auction activation button1008, search region1012and setting region1014.

Display region1006(shown in first portion1002and second portion1010) may provide information on one or more parameters associated with an auction. Auction activation button1008may be selected by an administrator to activate the running of an opening auction. Search region1012and setting region1014are similar to respective search region914and setting region916. In some examples, once the administrator has activated the running of an opening auction (via auction activation button1008inFIG.10A), the opening auction may proceed subject to facilitation by a DMM, such as for an opening auction for direct listings involving IDO order(s). In some examples, pop-up windows900and1000may be used by a DMM, rather than an administrator, for facilitating a direct listing auction involving IDO order(s).

Systems and methods of the present disclosure may include and/or may be implemented by one or more specialized computers including specialized hardware and/or software components. For purposes of this disclosure, a specialized computer may be a programmable machine capable of performing arithmetic and/or logical operations and specially programmed to perform the functions described herein. In some embodiments, computers may comprise processors, memories, data storage devices, and/or other commonly known or novel components. These components may be connected physically or through a network or wireless links. Computers may also comprise of software which may direct the operations of the aforementioned components. Computers may be referred to as servers, personal computers (PCs), mobile devices, and other terms for computing/communication devices. For purposes of this disclosure, those terms used herein are interchangeable, and any special purpose computer particularly configured for performing the described functions may be used.

Computers may be linked to one another via one or more networks. A network may be any plurality of completely or partially interconnected computers wherein some or all of the computers are able to communicate with one another. It will be understood by those of ordinary skill that connections between computers may be wired in some cases (e.g., via wired TCP connection or other wired connection) or may be wireless (e.g., via a WiFi network connection). Any connection through which at least two computers may exchange data can be the basis of a network. Furthermore, separate networks may be able to be interconnected such that one or more computers within one network may communicate with one or more computers in another network. In such a case, the plurality of separate networks may optionally be considered to be a single network.

The term “computer” shall refer to any electronic device or devices, including those having capabilities to be utilized in connection with an electronic exchange system, such as any device capable of receiving, transmitting, processing and/or using data and information. The computer may comprise a server, a processor, a microprocessor, a personal computer, such as a laptop, palm PC, desktop or workstation, a network server, a mainframe, an electronic wired or wireless device, such as for example, an on-site computing device specially configured for a particular entity, a telephone, a cellular telephone, a personal digital assistant, a smartphone, an interactive television, such as for example, a television adapted to be connected to the Internet or an electronic device adapted for use with a television, an electronic pager or any other computing and/or communication device.

The term “network” shall refer to any type of network or networks, including those capable of being utilized in connection with the systems and methods described herein, such as, for example, any public and/or private networks, including, for instance, the internet, an intranet, or an extranet, any wired or wireless networks or combinations thereof.

The term “computer-readable storage medium” should be taken to include a single medium or multiple media that store one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present disclosure.

FIG.6illustrates a functional block diagram of a machine in the example form of computer system600within which a set of instructions for causing the machine to perform any one or more of the methodologies, processes or functions discussed herein may be executed. In some examples, the machine may be connected (e.g., networked) to other machines as described above. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be any special-purpose machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine for performing the functions describe herein. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. In some examples, one or more of components110-142of platform102, order sending entity(s)104, MM entity(s)106and/or distribution entity(s)108, one or more components202-206of system200and/or one more components302-318of auction engine300may be implemented by a specialized machine, particularly programmed to perform certain functions, such as the example machine shown inFIG.6(or a combination of two or more of such machines).

Example computer system600may include processing device602, memory606, data storage device610and communication interface612, which may communicate with each other via data and control bus618. In some examples, computer system600may also include display device614and/or user interface616.

Processing device602may include, without being limited to, a microprocessor, a central processing unit, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and/or a network processor. Processing device602may be configured to execute processing logic604for performing the operations described herein. Processing device602may include a special-purpose processing device specially programmed with processing logic604to perform the operations described herein.

Memory606may include, for example, without being limited to, at least one of a read-only memory (ROM), a random access memory (RAM), a flash memory, a dynamic RAM (DRAM) and a static RAM (SRAM), storing computer-readable instructions608executable by processing device602. Memory606may include a non-transitory computer readable storage medium storing computer-readable instructions608executable by processing device602for performing the operations described herein. For example, computer-readable instructions608may include operations performed by components110-142of platform102(FIG.1), components202-206of system200(FIG.2) and/or components302-318of auction engine300(FIG.3), including operations shown inFIGS.4and5. Although one memory device606is illustrated inFIG.6, in some examples, computer system600may include two or more memory devices (e.g., dynamic memory and static memory).

Computer system600may include communication interface device612, for direct communication with other computers (including wired and/or wireless communication) and/or for communication with a network. In some examples, computer system600may include display device614(e.g., a liquid crystal display (LCD), a touch sensitive display, etc.). In some examples, computer system600may include user interface616(e.g., an alphanumeric input device, a cursor control device, etc.).

In some examples, computer system600may include data storage device610storing instructions (e.g., software) for performing any one or more of the functions described herein. Data storage device610may include a non-transitory computer-readable storage medium, including, without being limited to, solid-state memories, optical media and magnetic media.

While the present disclosure has been discussed in terms of certain embodiments, it should be qualified that the present disclosure is not so limited. The embodiments are explained herein by way of example, but there are numerous modifications, variations and other embodiments that may be employed that would still be within the scope of the present disclosure.