Orders
A description of Monark EFO's Order processing system, including Order Netting.
Buy and Sell Orders
Monark EFO refers to Subscriptions as BUY Orders and Redemptions as SELL Orders. BUY Orders are processed in dollars, and SELL Orders are processed in shares. The BUY/ SELL terminology permeates throughout the rest of our API documentation.
Creating Orders
When creating Orders, there are a few requirements that must be met:
BUYOrders must be denominated in dollars, up to two decimal places. Monark supports fractional shares, and we calculate the fractional number of shares allocated to each Order once we receive the NAV and settlement file from the Fund/TA.SELLOrders must be denominated in shares, up to 6 decimal places. Prior to anySELLOrder being accepted, the system validates the share count against the Account's settled balance on Monark's sub-accounting ledger. Positions cannot be sold short. AnySELLOrder that would result in a short Position will be rejected.- There are no limit Orders. Orders are NAV-driven. Orders netted on the Netting Queue are priced at the fund's end-of-day NAV for the netting session's business day for daily-NAV funds, or at the last published NAV for monthly-NAV funds. Both sides of a netted match settle at the same NAV.
- A
CASH/DRIPelection is required onBUYOrders. This determines which Omnibus account the Order routes to. For Model Orders, the Child Orders will inherit theCASH/DRIPelection set at the Model Order level.
Order Routing
Orders submitted to EFO follow one of two routing paths, elected at Order submission with routeInstruction: TransferAgent (Direct to TA, the default) or IntraCustodianNetting (the Netting Queue). The legacy values DirectToTa and OrderNetting are still accepted. CrossCustodianNetting is reserved for Omnibus V2 and is not yet supported.
Direct to TA
Orders routed directly to the Transfer Agent are aggregated into a single trade file per omnibus account and submitted at the fund's subscription or redemption cadence (typically daily, monthly, or quarterly). Monark manages the cutoff calendar per our integrations with the TAs, and EFO's cutoff will always precede the fund's cutoff. This provides us time to reconcile against Custodians before trade files or wires åre transmitted to the TA.
- For
BUYOrders, on the Fund's cutoff date Monark delivers a wire request to the Custodian specifying exactly how much cash is owed to the fund, along with the wire instructions Monark holds for the Custodian (MMM Securities' for Custodians in the MMM Securities master omnibus) and the underlying Orders. Please see our Custodian Wire Request wehbook for an example of what the wire request payload looks like. EFO will simultaneously submit a Subscription Order to the TA on behalf of the omnibus account. - For
SELLOrders, EFO submits the redemption file to the TA at the fund's cutoff, and the TA processes the redemption, subject to any fund-level gating. Orders are marked as settled once the Transfer Agent returns a confirmation file, at which point tax lots are created at the NAV at which the TA processed the Order. Then, Custodians will receive:- (1) the per-investor breakdown of the redemption proceeds from Monark, and
- (2) the wire with the redemption proceeds from the TA (or from MMM Securities, for Custodians in the MMM Securities master omnibus).
Netting Queue
Alternatively, Orders can be routed to Monark's Netting Queue, where BUY and SELL Orders from the same Custodian, in the same fund, share class, and dividend election, are netted against each other at the fund's NAV (end-of-day NAV for daily-NAV funds, last published NAV for monthly-NAV funds) on a time-priority basis. Netted Orders settle at the Custodian without ever being routed to the Transfer Agent. Monark enables netting for each Custodian, fund, and share class; a netting Order where it is not enabled is rejected (OrderNettingCapabilityMissing) rather than routed to the TA.
Order netting is a core design feature of the platform. At the end of each business day, incoming Subscription (BUY ) Orders are netted against incoming Redemption (SELL ) Orders, oldest first. An Order can be partially filled, and filled against several Orders. The residual that is not netted is handled by the Order's unnettedOrderRoute:
TransferAgent(default): the residual keeps netting until EFO's next cutoff for that side, then is passed up to the Fund with the Direct to TA Orders as a single omnibus-level Subscription or Redemption. An unnettedBUYgoes to the Fund at the next subscription cutoff; an unnettedSELLkeeps netting each business day until the cutoff for the Fund's next redemption window.Cancel: the residual nets until the Order'snettingTifdeadline (Cutoff,EOD,EOM,EOQ, or aCustomdate), and is then cancelled.
Because redemptions are satisfied with incoming subscription flow rather than fund-level liquidity, netting reduces cash drag, eases pressure on redemption gates, lets managers keep capital fully deployed, and increases the likelihood that a redemption is filled in full rather than prorated.
Trading Hours
Orders routed directly to the Transfer Agent can be created on a 24/7 basis. There are no "trading hours" associated with creating these Orders. Netting Queue Orders can also be created at any time. The Netting Queue runs one session at the end of each business day for each fund and share class, after a daily netting Order cutoff; Orders submitted after the cutoff join the next session.
Cash Movement
How cash moves depends on the Custodian's custody model. In the custodian omnibus model, Monark EFO does not touch cash: Custodians wire subscription proceeds directly to the Transfer Agents, and Transfer Agents wire redemption proceeds and cash dividends directly to Custodians. In the MMM Securities master omnibus, these wires pass through MMM Securities LLC, Monark's broker-dealer subsidiary: Custodians wire subscription cash to MMM Securities, which sends the Transfer Agent one aggregated wire, and the Transfer Agent wires redemption proceeds and cash dividends to MMM Securities, which forwards each Custodian's share while Monark sends the per-investor breakdown. MMM Securities also withholds any early redemption fee from redemption proceeds and forwards it to the Transfer Agent. In both models, Monark's role is to instruct and reconcile: wire instructions are set up for each Custodian, optionally per fund, share class and election, and delivered via API, and every wire is tied to a corresponding trade file so that cash and share records always tie out. For Orders netted on the Netting Queue, cash movement is handled directly by the Custodian, who re-ledgers cash and shares internally based on netting activity communicated by Monark EFO.
Individual Orders vs. Model Orders
EFO processes two categories of order flow: Individual Orders and Model Orders. Submitting and managing Individual and Model Orders requires leveraging two different sets of API endpoints, both of which are linked below.
Individual Orders
Individual Orders are those submitted by an Investor or Advisor directly, outside of a model rebalance. They are submitted, routed, filled, and settled independently. See here for our API reference on managing Individual Orders.
When an Individual Order is submitted, the API returns a real-time confirmation or error response synchronously. On acceptance, EFO assigns a unique Monark Order ID (id), used for all downstream references. BUY Orders are submitted with a notionalAmount (dollars, USD), and SELL Orders are submitted with a quantity (shares). Each Order also carries the account, fund (omnibusFundId), share class (omnibusShareClassId), distributionElection (Cash/Drip, required on BUY Orders), taxLotElection (e.g., FIFO), and routing election (routeInstruction: Direct to TA or Netting Queue).
Each fill against an Order is reported in the fills array of the order object, including the executionPrice and tradeDate. Each fill generates its own tax lot (Position) at the fill price and fill date. Running filledQuantity, remainingQuantity, and settledNotionalAmount counters are maintained on the Order object, so API Clients can track execution state directly.
Individual Orders routed Direct to TA can be updated or cancelled at any time before they are batched to the Transfer Agent. Netting Queue Orders can only be updated or cancelled while they are PendingActions; one with no outstanding actions goes straight to the Netting Queue and can't be changed. Use unnettedOrderRoute Cancel with a nettingTif to limit how long they net. Cancellations are asynchronous: a cancellation API response with status Pending does not mean the Order is cancelled. The Order is only cancelled once the OmnibusOrderCancelled webhook is received. See our webhooks section for further detail on canceling Orders.
Model Orders
Model Orders originate from model portfolio rebalances that span numerous underlying client accounts. For example, a model platform rebalancing hundreds of advisory accounts into or out of a particular fund, triggered by market movement, would route their Order to the Model Orders endpoint.
API Clients first create the Parent Order as a draft for one fund, share class, side, and Custodian, then add the Child Orders (one per account) to it in one or more batches, and finally complete it. Monark checks each batch as it arrives, checks every Child Order again once the Parent Order is completed, and then creates each Child Order as an individual order linked to the Parent through modelOrderId (and tagged with the Parent's modelId, if supplied). If any Child Order fails a check at that point, the whole Parent Order is rejected. The outcome is delivered by webhook. Drafts that are not completed are cancelled overnight. See here for our API documentation on managing Model Orders.
The defining requirement of Model Order processing is fairness: every Child Order within the Model Order must be treated identically. Two rules enforce it:
- Same execution price. All Child Orders within a Parent Order are filled at the same price.
- Pro-rated fills. When a Parent Order is only partially executed, whether a partial fill on the Netting Queue or a cutback on a gated redemption, every Child Order receives the same pro-rated fill percentage as the Parent.
For example, a redemption cutback:
- Parent Model
SELLOrder ABC is submitted for 10 shares, linked to Child Order 1 (4 shares) and Child Order 2 (6 shares) - The Fund's repurchase offer is oversubscribed, and the Fund prorates redemptions at 50%. The Parent Order is partially filled for 5 shares (10 shares * 50%)
- Child Order 1 settles a partial fill of 2 shares (50% x 4)
- Child Order 2 settles a partial fill of 3 shares (50% x 6)
- Both Child fills settle at the same NAV, and each generates its own tax lot.
The same math applies to BUY Orders, denominated in dollars, partially netted on the Netting Queue: the same $10 Parent Order filled for $5 (50%) settles a $4 Child at $2 and a $6 Child at $3.
In other words, each Child Order receives exactly the same fill percentage as the Parent Order, ensuring that all Orders within the Model Order are treated fairly.
Settlement and downstream treatment of Child Orders:
- Each Child fill settles independently, with its own tax lot at the fill price and fill date.
- On the settlement webhook, each Child fill is presented as a completed Order with its pro-rated allocation from the Parent block. Custodians receive fills at the Child Order level, not at the Model Order level.
- Positions are generated as a result of Child Orders being filled, and can be retrieved through the Positions endpoint.
- Record date attribution for dividend eligibility is evaluated per fill (lot), by settlement date. If a Parent Order spans a distribution's record date, Child fills that settle on or before the record date are eligible for the distribution, and Child fills that settle after are not. Settlement date, not match date or submission date, governs dividend eligibility. Think of Child fills as 1:1 with lots.
Cancelling Model Orders:
- Individual orders linked to a Model Order are not cancelled or updated through the Individual Order endpoint. Use the Model Order cancellation endpoint, which cancels the whole Parent Order. Model Orders cannot be updated: cancel and resubmit instead. A draft Parent Order is cancelled immediately, and a Parent Order that is still being processed after completion cannot be cancelled.
- Cancelling a Parent Order before any Child fill has occurred cancels the entire Parent.
Once any Child fill has occurred, partial or full, the filled Children Orders are final. - Model Orders routed to the Netting Queue cannot be cancelled once submitted.
Model Orders on the Netting Queue: the Parent Order nets as one block. Each fill is priced at that netting session's NAV and split across the Child Orders pro rata to their remaining balances, so every Child receives the same price on each fill. A Parent Order can fill across several sessions, and each fill generates its own tax lot. The Parent's unnettedOrderRoute and nettingTif apply to every Child: by default the unnetted residual goes to the TA at EFO's cutoff, and with Cancel and a nettingTif such as EOD it is cancelled at the deadline, so the model platform can resubmit it as a new Parent Order.
Rounding & Correction Accounts
Rounding on the EFO platform is two-sided. BUY Orders produce rounding on the share side, and SELL Orders produce rounding on the dollar side. In both cases, residuals are rounded down and accrue to the correction account attached to the omnibus account, ensuring that the sum of the individual sub-account allocations, plus the correction account, always ties exactly to the omnibus-level amount processed by the Transfer Agent. EFO rounds dollar amounts down to 2 decimal places, and share amounts down to 6 decimal places.
BUY Orders: Share Rounding
BUY Orders are denominated in dollars, so the dollar side of a subscription is exact by construction. Investors buy exact dollar amounts, and Custodians wire the exact aggregate to the TA (through MMM Securities, for Custodians in the MMM Securities master omnibus). Rounding on subscriptions occurs on the share side. When the Transfer Agent processes the omnibus subscription, it issues shares into the omnibus account at NAV. EFO then allocates shares to each investor, with the investor's subscription dollars divided by the processed NAV, rounded down to six decimal places, with share residuals accruing to the correction account. Each investor's tax lot is created for the allocated share quantity, at the NAV at which the TA processed the subscription.
For example, Fund 123 processes Subscription Orders at a NAV of $3.00. Custodian ABC's omnibus account Subscribes $30.00 across three investors, meaning that at the Custodian level the Omnibus Account receives 10.000000 shares.
| Investor | BUY Amount | Raw Shares ($ ÷ NAV) | Allocated Shares |
|---|---|---|---|
| Investor A | $10.00 | 3.333333333... | 3.333333 |
| Investor B | $10.00 | 3.333333333... | 3.333333 |
| Investor C | $10.00 | 3.333333333... | 3.333333 |
| Correction Account | - | - | 0.000001 |
| TOTALS | $30.00 | 9.999999999... | 10.000000 |
The Custodian wires $30.00 to the TA, and the TA issues 10.000000 shares into the omnibus account ($30.00 ÷ $3.00). EFO allocates 9.999999 shares across the three investors and accrues the remaining 0.000001 shares to the correction account. This ensures that the sum of the individual allocations plus the correction account ties exactly to the 10.000000 shares issued by the TA.
SELL Orders: Cash Rounding
When SELL Orders settle, the Transfer Agent processes the redemption at NAV and wires the aggregate proceeds directly to the Custodian at the omnibus account level. This is processed as a single wire per omnibus account, per redemption cycle. In the MMM Securities master omnibus, the wire goes to MMM Securities, which forwards each Custodian's share. Upon receiving the TA's trade file confirmation, EFO calculates the per-investor breakdown of the proceeds, ties the breakdown to the wire received from the TA, and delivers the breakdown to the Custodian for downstream lot-level allocation.
Because SELL Orders are share-denominated and investors can hold fractional share positions, per-investor proceeds for redemptions routinely include fractions of a penny. EFO applies the same rounding rules to redemption proceeds as it does to CASH distributions:
Per-investor cash proceeds are rounded down to two decimal places. Monark does not deal in fractional pennies, any investor whose proceeds amount to less than one cent receives nothing, with the full amount accruing to the correction account.
All rounding residuals accrue to the correction account attached to the omnibus account, ensuring that the sum of the individual allocations, plus the correction account, always ties exactly to the wire received from the TA.
On prorated redemptions (cutbacks), the prorated share fills themselves are rounded down to six decimal places, with share residuals accruing to the correction account.
For example, Fund 123 processes a quarterly redemption at a NAV of $10.00. Custodian ABC's omnibus account redeems 10.000000 shares across three investors, meaning that the omnibus account receives $100.00 at the omnibus level.
| Investor | Shares Sold | Raw Cash Proceeds | Allocated |
|---|---|---|---|
| Investor A | 3.333333 | $33.3333330 | $33.33 |
| Investor B | 3.333333 | $33.3333330 | $33.33 |
| Investor C | 3.333334 | $33.3333340 | $33.33 |
| Correction Account | - | - | $0.01 |
| TOTALS | 10.000000 | - | $100.00 |
The TA wires $100.00 to the Custodian (10.000000 shares × $10.00). EFO allocates $99.99 across the three investors and accrues the remaining $0.01 to the correction account, ensuring that the sum of the individual allocations plus the correction account ties exactly to the $100.00 received from the TA.
Order Status and Webhooks
Order state transitions are surfaced to API Clients in real time via webhooks. Orders progress through statuses including Received, PendingActions (the order is created but required order actions remain outstanding), PendingExecution (accepted downstream for execution, including Orders waiting in or partially filled on the Netting Queue), Executed (sent to the Transfer Agent), Settled, Rejected, Cancelled, and Failed. Rejections and failures populate statusReasonCode and reason message fields when available.
Model Orders start in two statuses of their own: Draft, while Child Orders are being added, and Processing, after the Model Order is completed and while Monark checks it. A Model Order then moves to Received, or ends Rejected or Failed.
Please see our webhook documentation for Individual Order Events and Model Order Events for further detail on Order statuses and real time notifications.
Updated 27 days ago