CA2922112C - Electronic trading system and method for mutual funds - Google Patents

Abstract

Data messages representative of orders for mutual funds are received via a network from market participant terminals. Each data message contains a mutual-fund identifier, an indication of a number of units, and a market-participant identifier. Pending orders are generated from the data messages. Each pending order contains a market- participant identifier, an indication of a number of units, and a mutual fund manufacturer identifier obtained from a mutual-fund identifier extracted from the particular data message. Pending orders are accumulated for an indeterminate amount of time in a batch. An indication of price is received for each of the mutual funds from a respective mutual fund manufacturer system. For each accumulated pending order, a total price is calculated based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order. Filled orders are outputted to a settlement and clearing system.

Description

Electronic Trading System and Method for Mutual Funds Field This disclosure relates to electronic trading systems and related methods.
Background [00021 Known trading systems for mutual funds are often separate and distinct from systems used for other types of financial instruments and interests. This is due to differing regulations and differing technologies used. One of the many drawbacks of such trading systems is that additional technical knowledge and maintenance are required from the end users.
[00031 In an example known equity marketplace, dealers submit orders on behalf of one or more retail end-investors through their front-office systems. Positions are aggregated and registered at a clearing and settlement service in the name of the dealer. The dealer's back-office maintains individual investor's positions and manages entitlements and tax reporting.
Mutual funds, on the other hand, are typically processed through a separate fund transaction processing system, where an individual purchase/redemption instruction is routed from the investment advisor on behalf of each end-investor to the fund issuer. As there is no secondary trading in mutual funds, all orders are fulfilled directly from the fund treasury.
[00041 The fund maintains a registry of all beneficial owners and manages entitlements and tax reporting. As such, most dealers have separate front-office systems for managing equities from managing mutual funds without sufficient integration between the two, which can make transacting in mutual funds a very manual and laborious process far a dealer that mainly works with equities.
[00051 As such, widespread and efficient electronic trading of mutual funds is hampered.

Date Recue/Date Received 2022-05-13 Summary [0006] According to one aspect of the present invention, method in an electronic trading system includes receiving data messages via a network, the data messages representative of orders for mutual funds from market participant terminals. Each data message contains a mutual-fund identifier, an indication of a number of units, and a market-participant identifier.
The method further includes generating pending orders from the data messages.
Each pending order contains a market-participant identifier extracted from a particular data message, an indication of a number of units extracted from the particular data message, and a mutual fund manufacturer identifier obtained from a mutual-fund identifier extracted from the particular data message. The method further includes accumulating the pending orders for an indeterminate amount of time in a batch of accumulated pending orders, receiving an indication of price for each of the mutual funds from a respective mutual fund manufacturer system, and for each accumulated pending order, calculating a total price based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order. The method further includes outputting filled orders to a settlement and clearing system.
[0007] The method can further include querying a database to obtain a mutual fund manufacturer identifier using a mutual-fund identifier as a query key.
[0008] The method can further include generating a pending order from a received data message without matching price or time of the received data message with any booked order.
[0009] Each data message can omit a price.
[0010] The method can further include reporting a market-participant identifier of a filled order to a mutual fund manufacturer system identified from the filled order.
[0011] The method can further include receiving other data messages via the network, the other data messages representative of other orders for at least one equity instrument, and executing trades based on the other orders in parallel to accumulating the pending orders for

2 the mutual funds, the execution of trades based on the other orders bypassing the accumulating.
[0012] The method can further include generating at least one integrated and heterogeneous market data feed containing data from the filled orders for the mutual funds and containing other data from other filled orders for at least one equity instrument.
[0013] The method can further include performing an exception process, the exception process obtaining a suitable previous indication of price for use as an unreceived or erroneous indication of price or cancelling orders for the respective mutual fund.
[0014] According to another aspect of the present invention, an electronic trading system includes an order processing engine configured to receive data messages via a network. The data messages are representative of orders for mutual funds from market participant terminals.
Each data message contains a mutual-fund identifier, an indication of a number of units, and a market-participant identifier. The order processing engine is further configured to generate pending orders. Each pending order contains a market-participant identifier extracted from a particular data message, an indication of a number of units extracted from the particular data message, and a mutual fund manufacturer identifier obtained from a mutual-fund identifier extracted from the particular data message. The system further includes an order accumulator coupled to the order processing engine and configured to receive pending orders from the order processing engine. The order accumulator is configured to store pending orders for an indeterminate amount of time in a batch of accumulated pending orders. The system further includes an order resolver coupled to the order accumulator. The order resolver is configured to receive an indication of price for each of the mutual funds from a respective mutual fund manufacturer system. The order resolver is further configured to fetch accumulated pending orders from the order accumulator and, for each accumulated pending order, calculate a total price based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order. The order resolver is further configured to output filled orders to a settlement and clearing system.

3 [0015] The order processing engine can be further configured to query a database to obtain a mutual fund manufacturer identifier using a mutual-fund identifier as a query key.
[0016] The order processing engine can be further configured to generate a pending order from a received data message without matching price or time of the received data message with any booked order.
[0017] Each data message can omit a price.
[0018] The order resolver can be further configured to report a market-participant identifier of a filled order to a mutual fund manufacturer system identified from the filled order.
[0019] The order processing engine can be further configured to receive other data messages via the network, the other data messages representative of other orders for at least one equity instrument. The order processing engine can be further configured to match the other orders for execution of trades in parallel to the order accumulator accumulating the pending orders for the mutual funds, the execution of trades based on the other orders bypassing at least the order accumulator.
[0020] The order resolver can be further configured to output data from the filled orders for the mutual funds to a market data system that is configured to generate at least one integrated and heterogeneous market data feed containing data from the filled orders for the mutual funds and containing other data from other filled orders for at least one equity instrument.
[0021] The order resolver can be configured to perform an exception process, the exception process obtaining a suitable previous indication of price for use as an unreceived or erroneous indication of price or cancelling orders for the respective mutual fund.

4 =
Brief Description of the Drawings [0022] The drawings illustrate, by way of example only, embodiments of the present disclosure.
[0023] FIG. 1 is a diagram of an overall system.
[0024] FIG. 2 is a flowchart of a method for electronic trading.
[0025] FIG. 3 is a diagram of an electronic trading system.
[0026] FIG. 4 is a diagram of data structures.
[0027] FIG. 5 is a flowchart of an exception process.
[0028] FIG. 6 is a diagram showing relative timing of the method for electronic trading.
Detailed Description [0029] The present invention provides an integrated platform for purchase/redemption of mutual funds together with trading of other financial instruments, such as equities. Mutual fund orders are configured in a manner similar to orders for other financial instruments, such as equities, and are identified and processed according to the techniques described herein. This advantageously allows one trading system to process mutual funds in addition to one or more other financial instruments, despite the significant financial and technical differences in processing purchase/redemption of mutual funds. Market data feeds can be similarly integrated. In view of the invention, market participants need not maintain separate and distinct systems for mutual funds and other financial instruments. Further, computer processing and memory efficiencies can be gained by using one system.
[0030] FIG. 1 shows a system according to the present invention. The system includes one or more mutual fund manufacturer systems 10, one or more admin terminals 12, a plurality of market participant terminals 14, one or more portfolio management systems 16, one or more smart order routers and/or order management systems 18, a settlement and clearing system 20, and an electronic trading system 22, and a market data system 24 mutually connected via a network 26. The system can further include other components, such as electronic message gateways (not shown) and similar.
[0031] The network 26 can include any number and type of computer networks, such as a local area network (LAN), wide-area network (WAN), virtual private network (VPN), a wireless network, an intranet, and the Internet. The network 26 operates to communicatively couple the components 10¨ 24, while isolating domains of such components 10 ¨ 24 from one another, where appropriate, and restricting communications between domains.
[0032] Each of the mutual fund manufacturer systems 10 can include servers, data stores, or other types of computers within a mutual fund manufacturer's domain and under the control of a mutual fund manufacturer.
[0033] An admin terminal 12 can be connected to a mutual fund manufacturer system 10 to manage and control the system 10, such as to trigger the transmission of data from the mutual fund manufacturer system 10 to the trading system 22.
[0034] The market participant terminals 14 are connected to respective portfolio management systems 16, which are configured to place orders initiated by market participant terminals 14 via the smart order routers and order management systems 18 for execution at the trading system 22. Data messages inbound to the trading system 22 represent orders for financial instruments and interests by market participants in control of the terminals 14, such as dealers and brokers who buy and sell such instruments and interests on behalf of investors.
Examples of financial instruments and interests are discussed below, and notably at least include mutual funds.
[0035] The terminals 12, 14 can be electronic devices, such as desktop computers, smart phones, tablet computers, and similar devices that have at least one processor configured to execute instructions stored in memory.
[0036] The settlement and clearing system 20 is connected to the trading system 22 and receives data indicative of filled orders from the trading system 22. The settlement and clearing system 20 handles the financial transactions behind the exchange of financial instruments and interests facilitated by the trading system 22. The settlement and clearing system 20 can include servers, data stores, or other types of computers within one or more settlement and clearing domains under the control of one or more settlement and clearing entity.
[0037] The trading system 22 includes servers, data stores, or other types of computers within a trading system domain controlled by an exchange or other entity. The trading system 22 is configured to receive data messages representative of orders for mutual funds from market participant terminals 14, accumulate such orders, and then fill the orders based on price data received from the manufacturer systems, such as net asset value (NAV) price. The trading system 22 is also configured to process orders received from market participant terminals 14 for other financial instruments and interests, in a conventional manner.
Advantageously, the trading system 22 can process data representative of orders for instruments and interests that are subject to only primary trading (i.e., mutual funds) and also process data representative of orders for instruments and interests that are subject to primary and secondary trading (e.g., equities, exchange-traded funds, etc.). As will be discussed, a set of universal techniques are used, so that one trading system 22 can handle such disparate types of data.
[0038] The market data system 24 is configured to output one or more market data feeds containing mutual fund data integrated with equity data. Both equities and mutual funds may be identified by their mutual-fund identifiers (e.g., symbol) and may further include last trade data, such as last traded price and volume. Mutual fund data may further include attributes, such as maximum/minimum volume thresholds accepted for purchase/redemption. An example of a market data feed is shown below in Table 1.
[0039] Table 1:
Symbol Last Trade Min/Max Volume Price Volume (or NA for not applicable) ABC $251.49 10000 NA

, QRS-M $150.00 500 100/NA
XYZ $85.44 1000 NA
[0040] In the illustrative example of Table 1, the feed contains mutual fund data integrated with normal equity data. The indicator or tag for a mutual fund, in this example, is "-M".
[0041] The portfolio management systems 16 and market participant terminals 14 can be configured to consume the market data feeds provided by the market data system 24. Such configuration can include identifying the mutual-fund indicator or tag in the feed and displaying information for mutual funds with the indicator, tag, or some other indication to market participants. Advantageously, market data is provided in integrated but heterogeneous feeds, in a network efficient and computationally efficient manner, with end points decoding the feeds according to their needs.
[0042] FIG. 2 shows a flowchart of a method performed by the trading system 22.
[0043] At step 30 a data message is received at the trading system 22 from one of the market participant terminals 14.
[0044] If the data message does not contain a mutual-fund identifier, such as a preassigned symbol for the fund similar to a stock symbol, as determined by the trading system 22 inspecting the data message at step 32, then the data message is treated as an order for another kind of financial instrument or interest. The trading system 22 performs matching and trade processing normally for such financial instrument or interest, at step 34.
[0045] If the data message contains a mutual-fund identifier, then the message is determined to also contain data that includes an indication of a number of units ordered and a market-participant identifier identifying the source of the order. Notably, the data message specifies a number of units (volume) of a mutual fund, rather than financial information such as a total spend or a price of the fund. The data message may include a limit price that triggers cancelation of the order after determination of a NAV price that contravenes the limit. At step 36, the trading system 22 extracts data from the data message and uses it to generate a pending order that contains the market-participant identifier, the indication of the number of units, and a mutual fund manufacturer identifier. The mutual fund manufacturer identifier can be obtained by the trading system 22 a database to obtain a mutual fund manufacturer identifier using the mutual-fund identifier as a query key, where such database stores relationships of mutual-fund identifiers to mutual fund manufacturer identifiers. Generating a pending order is performed without matching price or time of the respective data message with a corresponding booked order. Rather, each order is automatically generated identifying the correct mutual fund manufacturer irrespective of the price, which is not yet known.
[0046] At step 37, it is determined whether a minimum volume threshold applies and whether a maximum volume threshold applies. For each such threshold that applies, the threshold is checked and any pending order violating the threshold is rejected, via step 39. That is, if a pending order has a volume that exceeds a maximum volume threshold for the ordered fund, then the pending order is rejected. Likewise, if a pending order has a volume that is less than a minimum volume threshold for the ordered fund, then the pending order is rejected.
Such thresholds may be set by fund manufacturers to introduce volume discounts or tiered pricing using volume as a proxy for the type of client submitting the instruction.
[0047] At step 38, the pending order is accumulated by the trading system 22 and stored in a batch with other pending orders for an indeterminate amount of time, which can be based on a configured end time (e.g., periodic, time-of-day, etc.). Accumulating orders involves collecting and storing orders for a time and is distinct from aggregating orders, which instead groups orders based on another characteristic. The present invention does not aggregate orders or processed orders in aggregation. Rather, each order is processed individually after a group of orders are accumulated over a period of time.
[0048] Step 40 determines whether the accumulated orders are to be resolved based on the configured end time. In one example, the configured end time is 6:00 PM of each trading day. Before the configured end time, step 40 returns the method to step 30 to wait to receive more data messages. On or after the configured end time, step 40 resolves the accumulated orders by advancing to step 42.
[0049] At step 42, the trading system 22 receives an indication of price for each of the mutual funds identified in the pending orders from the respective mutual fund manufacturer systems 10. The trading system 22 can query the respective mutual fund manufacturer systems for price data. Alternatively, the trading system 22 can wait for such data to be delivered.
The price data can be representative of NAV prices.
[0050] Reception of suitable price data is checked for by an exception process (FIG. 5). The exception process includes checking that the price data meets basic requirements (e.g., exists, is well formed, and is complete).
[0051] At step 43, for each accumulated pending order that specifies a limit price, the limit price is compared to the obtained NAV price and the accumulated pending order is cancelled, via step 39, if the limit price is contravened.
[0052] Next, at step 44, the trading system 22 calculates a total price based on the relevant received indication of price and the number of units specified in each accumulated pending order to generate a filled order. All accumulated pending orders that were not cancelled at step 43 are processed in this manner.
[0053] Filled orders are then transmitted to the settlement and clearing system 20, at step 46.
[0054] In addition, the method may include, at step 48, reporting a market-participant identifier of a filled order to the respective mutual fund manufacturer system 10 identified from the filled order, so that the mutual fund manufacturer system 10 can process any commission due to the market participant.
[0055] The method repeats each trading day.
[0056] FIG. 3 shows components of the electronic trading system 22.

, , [0057] The trading system 22 includes an order processing engine 60, a database 62, an order accumulator 64, and an order resolver 66. Each of the components 60 ¨64 can include a combination of hardware processors and memory and programmatic instructions to implement the discussed functionality. Functionality of the components 60¨ 64 can be combined into fewer components or further separated into more components, with the components 60 ¨64 being illustrative and not limiting.
[0058] The order processing engine 60 is configured to receive data messages via a network 26 from market participant terminals. Each data message is representative of an order for a financial instrument or interest, including mutual funds. In the case of mutual funds, a data message contains a mutual-fund identifier, an indication of a number of units, and a market-participant identifier. Because the system operates on a unit-basis, such a data message can omit a price, a total amount to spend, and similar information. A data message can include a limit price.
[0059] The order processing engine 60 can be configured to perform matching and trade processing normally for financial instruments and interests other than mutual funds. That is, an incoming order for an equity instrument (e.g., a stock) can be matched to another order to create a trade, which is then executed. Such processing is performed by the order processing engine 60 in parallel to processing of mutual fund order and thus bypasses the order accumulator 64 and order resolver 66. The order processing engine 60 can be configured to differentiate orders for mutual funds from other financial instruments and interests by detecting a mutual-fund indicator or tag in data messages, such mutual-fund indicator being within the mutual-fund identifier (e.g., symbol) or as an attribute of orders contained in the data messages.
[0060] The order processing engine 60 is further configured to generate pending orders for mutual funds based on received data messages. Each pending order contains a market-participant identifier extracted from a particular data message and an indication of a number of units extracted from the particular data message. Each pending order further includes a mutual fund manufacturer identifier obtained by using the mutual-fund identifier extracted from the particular data message as a key to query the database 62, which stores relationships of mutual-fund identifiers to mutual fund manufacturer identifiers.
[0061] The order processing engine 60 can implement minimum and maximum volume (unit) thresholds, discussed above, to reject pending orders that contravene any such threshold(s) set for a particular fund.
[0062] The order accumulator 64 is coupled to the order processing engine 60 and is configured to receive pending orders from the order processing engine 60. The order accumulator 641s configured to store pending orders for an indeterminate amount of time in a batch of accumulated pending orders 70.
[0063] The order resolver 66 is coupled to the order accumulator 64. The order resolver 66 is configured to receive an indication of price for each of the mutual funds identified in the accumulated pending orders 70 from the respective mutual fund manufacturer systems 10 and to execute an exception process (FIG. 5) to ensure that suitable price data is available. The order resolver 66 is further configured to fetch accumulated pending orders 70 from the order accumulator 64. For each accumulated pending order, the order resolver 66 calculates a total price based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order. Calculation of total price can include multiplying a NAV price received from the manufacturer by the number of units ordered. The order resolver 66 can also be configured to cancel any order that does not meet its limit price, if any. Operation of the order resolver 66 can be limited by a resolve condition 68 that must be met before generation of filled orders. The resolve condition can be a time-based condition, such as a particular time of day for each trading day. For example, the resolve condition 68 can specify 6:00 PM of every trading day, so that operation of the order resolver 66 is triggered at that time. The order resolver 66 is further configured to output filled orders or settlement records to the settlement and clearing system 20.
[0064] Settlement records are also transmitted to the fund manufacturer systems 10 to ensure the required number of units for each respective fund are either created and settled or received and retired. This information can also be used as one of the inputs into the NAV
calculation for the next business day. Settlement records are also transmitted to the market participants. Settlement records can also transmitted to the market data system 24 for output in one or more market data feeds.
[0065] FIG. 4 shows data structures according to the present invention. A
message data structure 80 includes fields for mutual-fund identifier 82, number of units 84, and market-participant identifier 86. The data structure 80 can form the basis for data messages representing orders. A fund/manufacturer correlation data structure 90 includes fields for mutual fund manufacturer identifier 92 and mutual-fund identifier 82. The data structure 90 can form the basis of the fund/manufacturer relationships stored in the database 62. An order data structure 100 describes a transaction between two parties and includes fields for mutual fund manufacturer identifier 92, mutual-fund identifier 82, number of units 84, and market-participant identifier 86. The order data structure 100 can be used to store pending and filled orders.
[0066] FIG. 5 shows a flowchart for an exception process used when receiving price data (e.g., NAVs) from manufacturer systems 10.
[0067] The exception process includes, for each mutual fund identifier (e.g., symbol), checking that data purporting to being price data has been received (step 100) and checking that such data is well-formed (step 102), which can include checking that the message or file containing the data lacks fundamental errors and that the data itself has characteristics of accepted price data (e.g., a monetary value). The data is also checked for currency (step 104), which can include verifying that one or more dates in the data match the current date. Further, a logic check (step 106) may be implemented as another check to ensure that the data lacks other errors. The logic check may include mathematical limits for valid prices (e.g., >0), sensible limits for valid prices (e.g., disallow price moves greater than +1-50%), and similar.
[0068] If any of the checks at steps 100¨ 106 fail, then it is determined that the received price data, if any, is invalid and a notification is generated, at step 108.
The notification can indicate which check failed. At step 110, the notification is transmitted to the manufacturer system 10 that sent the price data.
[0069] Without valid price data for the current trading day, the process repeats, via step 112, until valid price data is received or until a timeout expires. The timeout can be set to a specific time of the trading day (e.g., 11:00 PM), a specific time of the next day (e.g., 8:00 AM), a specific duration after market close (e.g., within 3 hours after close), or similar.
[0070] If the timeout expires, it is determined the no valid price data for the current day was received. Step 114 then determines whether valid price data is available for a preceding trading day, such as the immediately preceding trading day. If available, then price data for the preceding trading day is selected as the price data for the current day, at step 116. This provides tolerance to errors in transmitting the price data without unduly compromising the ability to execute trades. In other examples of the exception process, valid price data of a trading day earlier than the immediately preceding trading day can be used if valid price data for the immediately preceding trading day is unavailable.
[0071] If no valid price data is available for the specified preceding trading day(s), then, at step 118, the orders for the current day for the respective mutual fund identifier (e.g., symbol) are cancelled.
[0072] If all of the checks at steps 100¨ 106 pass, then the received price data is considered valid and is selected as the price data for the current trading day, at step 120.
[0073] FIG. 6 shows a flowchart diagram illustrating the components of the system that perform each action and showing the timing of each action. The process applies to purchase and redemption of fund units, though the clearing and settlement process 168 will vary depending on whether purchase or redemption is performed.
[0074] During a given trading day, purchase/redemption instructions 150 are generated by the market participant terminals 14 and portfolio management systems 16 and transmitted as orders to the trading system 22. The trading system accumulates orders 152 until the end of the trading day. At the end of the trading day, manufacturer systems 10 transmit 154 NAVs via the network for the trading day to the trading system 22 which receives 156 the NAVs. The trading system 22 resolves 158 the orders, as discussed above, and transmits 160 respective settlement records via the network. The market participant terminals and systems 14, 16, manufacturer systems 10, and settlement and clearing system 20 respectively receive 162, 164, 166 the settlement records or variations thereof. During the next one or more subsequent days, the settlement and clearing system 20, along with one or more transfer agents, custodians, and/or clearing brokers, perform a settlement and clearing process 168 to financially complete each order according to the settlement records. The settlement and clearing system 20 transmits an execution report upon completion, which is receptively received 172, 174 by the manufacturer systems 10 and the market participant terminals and systems 14, 16. The manufacturer systems 10 receiving execution reports 172 can include receiving settlement funds to custodial accounts. The market participants receiving execution reports 174 can include receiving or delivering units, depending on whether units were bought or sold.
[0075] The techniques described above can be implemented in an electronic marketplace or trading system for issuing, trading, holding, transferring, buying, selling, or participating in other types of exchange for one or more financial instrument or interest.
Electronic marketplaces and trading systems include one or more electronic networked order books, venues, trading venues, securities trading venues, marketplaces, exchanges, private equity exchanges, public securities exchanges, order books (e.g., dark books, lit books, etc.) within an exchange, alternative trading systems, and/or other markets, alone or in combination.
Advantageously, the one or more financial instrument or interest include mutual funds, as discussed herein, and may further include exchange-traded funds (ETFs), securities, debt, shares, stocks, derivatives, and similar or other type of financial product, instrument, or interest. That is, a system according to the present invention processes mutual fund orders, as discussed, and can be additionally configured to process orders/trades for other financial instruments or interests. The techniques discussed herein can be applied to various computerized trading systems, including those operating in various marketplaces.

[0076] While the foregoing provides certain non-limiting example embodiments, it should be understood that combinations, subsets, and variations of the foregoing are contemplated.
The monopoly sought is defined by the claims.

Claims (16)

Claims

1. A method in an electronic trading system, the method comprising:
receiving data messages via a network, the data messages representative of orders for mutual funds from market participant terminals, each data message containing a mutual-fund identifier, an indication of a number of units, and a market-participant identifier;
generating pending orders from the data messages, each pending order containing a market-participant identifier extracted from a particular data message, an indication of a number of units extracted from the particular data message, and a mutual fund manufacturer identifier obtained from a mutual-fund identifier extracted from the particular data message;
accumulating the pending orders for an indeterminate amount of time in a batch of accumulated pending orders;
receiving an indication of price for each of the mutual funds from a respective mutual fund manufacturer system; and for each accumulated pending order, calculating a total price based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order, and outputting filled orders to a settlement and clearing system.

2. The method of claim 1, further comprising querying a database to obtain a mutual fund manufacturer identifier using a mutual-fund identifier as a query key.

3. The method of claim 1 or 2, further comprising generating a pending order from a received data message without matching price or time of the received data message with any booked order.

4. The method of any one of claims 1 to 3, wherein each data message omits a price.

5. The method of any one of claims 1 to 4, further comprising reporting a market-participant identifier of a filled order to a mutual fund manufacturer system identified from the filled order.

6. The method of any one of claims Ito 5, further comprising receiving other data messages via the network, the other data messages representative of other orders for at least one equity instrument, and executing trades based on the other orders in parallel to accumulating the pending orders for the mutual funds, the execution of trades based on the other orders bypassing the accumulating.

7. The method of any one of claims Ito 6, further comprising generating at least one integrated and heterogeneous market data feed containing data from the filled orders for the mutual funds and containing other data from other filled orders for at least one equity instrument.

8. The method of any one of claims Ito 7, further comprising performing an exception process, the exception process obtaining a suitable previous indication of price for use as an unreceived or erroneous indication of price or cancelling orders for the respective mutual fund.

9. An electronic trading system comprising:
an order processing engine configured to receive data messages via a network, the data messages representative of orders for mutual funds from market participant terminals, each data message containing a mutual-fund identifier, an indication of a number of units, and a market-participant identifier;
the order processing engine further configured to generate pending orders, each pending order containing a market-participant identifier extracted from a particular data message, an indication of a number of units extracted from the particular data message, and a mutual fund manufacturer identifier obtained from a mutual-fund identifier extracted from the particular data message;
an order accumulator coupled to the order processing engine and configured to receive pending orders from the order processing engine, the order accumulator configured to store pending orders for an indeterminate amount of time in a batch of accumulated pending orders; and an order resolver coupled to the order accumulator, the order resolver configured to receive an indication of price for each of the mutual funds from a respective mutual fund manufacturer system, the order resolver further configured to fetch accumulated pending orders from the order accumulator and, for each accumulated pending order, calculate a total price based on a respective received indication of price and the number of units specified in the accumulated pending order to generate a filled order, the order resolver further configured to output filled orders to a settlement and clearing system.

10. The system of claim 9, wherein the order processing engine is further configured to query a database to obtain a mutual fund manufacturer identifier using a mutual-fund identifier as a query key.

11. The system of claim 9 or 10, wherein the order processing engine is further configured to generate a pending order from a received data message without matching price or time of the received data message with any booked order.

12. The system of any one of claims 9 to 11, wherein each data message omits a price.

13. The system of any one of claims 9 to 12, wherein the order resolver is further configured to report a market-participant identifier of a filled order to a mutual fund manufacturer system identified from the filled order.

14. The system of any one of claims 9 to 13, wherein the order processing engine is further configured to receive other data messages via the network, the other data messages representative of other orders for at least one equity instrument, the order processing engine further configured to match the other orders for execution of trades in parallel to the order accumulator accumulating the pending orders for the mutual funds, the execution of trades based on the other orders bypassing at least the order accumulator.

15. The system of any one of claims 9 to 14, wherein the order resolver is further configured to output data from the filled orders for the mutual funds to a market data system that is configured to generate at least one integrated and heterogeneous market data feed containing data from the filled orders for the mutual funds and containing other data from other filled orders for at least one equity instrument.

16. The system of any one of claims 9 to 15, wherein the order resolver is configured to perform an exception process, the exception process obtaining a suitable previous indication of price for use as an unreceived or erroneous indication of price or cancelling orders for the respective mutual fund.