Create an aggregate Model Order as a draft. The Individual Orders, representing the underlying Child Orders, are added to the draft afterwards. Monark handles pro-rated settlement, ensuring that all investors within the Model Order are treated fairly during downstream processing at the Transfer Agent or Matching Queue. As such, we require the Child Order breakdown to be submitted for every Model Order.

A Model Order is submitted in three steps:

1. POST /primary/v1/omnibus/model-order (this endpoint) creates the Model Order with a status of Draft and returns 201 with its id. The request carries the Model Order's fund, share class, side, Financial Institution and elections, but no Child Orders.
2. POST /primary/v1/omnibus/model-order/investor-orders, with modelOrderId and an orders list, adds a batch of Child Orders and returns 200 with the receivedOrderCount so far. Call it once per batch. Each batch is validated as it arrives, and a batch with an invalid Child Order is refused as a whole, with nothing added and the Model Order still in Draft.
3. POST /primary/v1/omnibus/model-order/complete, with modelOrderId and totalOrderCount, submits the Model Order and returns 202 with a status of Processing. totalOrderCount must equal the number of Child Orders received, or the request is refused with 409 (OrderCountMismatch). Monark validates every Child Order again, then moves the Model Order to Received and sends OmnibusModelOrderCreated, or to Rejected or Failed with OmnibusModelOrderRejected or OmnibusModelOrderFailed.

Drafts that are not completed by 1:00 AM Eastern are cancelled with a statusReasonCode of DraftExpired. See Model Orders for the full flow, with examples.

Order Structure Example:

• Model Order: BUY, $100 (calculated by Monark)
  • Child Order: BUY, $10
  • Child Order: BUY, $50
  • Child Order: BUY, $40

Use this endpoint when a model rebalancer submits a single aggregate block for a particular fund/share class. Add the underlying Orders with the investor-orders endpoint.

Notes:

• The Model Order referenceId must be unique per API client.
• A Model Order must contain at least 1 and no more than 10,000 Child Orders, across all batches.
• referenceId values for Child Orders must be unique per API client, and can't be reused on another open Model Order.
• For SELL Model Orders: a batch is refused, or the Model Order is rejected in its entirety when it is completed, if any Child Order, once fully filled and settled, would result in a negative share balance for the associated Investor.
• For BUY Orders: custodians are responsible for checking to ensure that Investors associated with Child Orders have sufficient cash to fund their BUY Order.
• Child Orders will inherit the taxLotElection and distributionElection method set at the Model Order level.
• Each account can appear only once in the Model Order, across all batches.
• The Model Order's Financial Institution must have access to the Registered Fund in order to process Model Orders into the Fund.
• An Omnibus Account must already exist at the Transfer Agent for the fund, share class, and distribution election, held by the financial institution or, in the MMM Securities master omnibus, by MMM Securities.
• Model Order individual orders are created as linked child orders and cannot be amended or cancelled through the Individual Order endpoints.