Rebalancing Guide

Rebalancing means comparing each client's holdings with your model's target weights and trading the difference. Monark Omnibus is built to make evergreen funds as seamless a part of that routine as any other holding: one API, one model order per fund, and the same rebalance you already run. What it can't change is the funds themselves. They price and trade on their own schedule, so an evergreen sleeve moves in days and weeks rather than minutes. The table below sets out where that differs from an ETF or mutual fund.

Decide how the evergreen sleeve rebalances when you build the model, not when the drift shows up. Three settings need an answer up front, and each has to fit the fund's own schedule:

• Drift bands: set them wider than for a liquid sleeve. NAV lag, share class minimums and dealing dates make an exact target weight impossible to hold
• Cadence: rebalance evergreen positions on each fund's dealing and redemption schedule rather than on the model's own calendar
• Partial fills: a redemption window may be pro-rated, so plan for a sell that fills in part and a remainder you resubmit in a later window

The rest of this guide covers the options behind each of those choices.

How Evergreen Funds Differ

Evergreen funds trade on the fund's schedule, not the market's. A model that rebalances them like ETFs will hold uninvested cash longer, sell more slowly and drift further than expected.

Orders routed to the netting queue (routeInstruction: IntraCustodianNetting) can fill between dealing dates. The queue runs a session at the end of each business day and nets buys against sells from other clients at the same custodian, in the same fund, share class and distribution election. Fills are priced at that day's NAV for a daily-NAV fund, or at the last published NAV for a monthly-NAV fund. A netted sell does not wait for a redemption window or count against the fund's gate. Monark enables netting for each custodian, fund and share class. Other orders go to the fund's transfer agent (TA) at Monark's cutoff.

Buying

A buy is committed at Monark's cutoff and invested on the fund's next dealing date. Until then, the client's cash must remain locked in the client's custodial account.

• Cutoff dates: Monark sets them per share class and shows them in the Alts Desk. An order placed after a cutoff goes into the next dealing date
• Minimums: each share class has an initialMinimumInvestment for a client's first buy and a subsequentMinimumInvestment for later ones. Small accounts or small model weights can fall below them. Decide whether to skip, defer or combine those buys before submitting
• Order fees: Monark may set an order fee for each custodian and share class, charged on buys only. Only the effectiveNotionalAmount is invested, so allow for the fee when converting a target weight to a dollar amount
• Eligibility: leave out clients who don't meet the fund's accreditation or qualified client/purchaser requirements

Selling

Sells leave the fund only in redemption windows, may fill only in part and pay out weeks later. Treat evergreen positions as the slowest leg of any rebalance.

• Redemption windows: each fund's redemptionCadence sets how often it redeems (monthly to annual). Sells submitted before Monark's redemption cutoff go to the TA for that window
• Gating: redemptionValue describes, as text, how much of the fund's NAV it will redeem per window, for example 5% per quarter. It may be a range. If requests exceed the limit, every client's sell fills pro rata. After the window, check filledQuantity and remainingQuantity on each order and resubmit any remainder in a later window if still needed
• Proceeds: the TA typically takes 15 to 30 days to process a redemption, then wires proceeds to the custodian, through MMM Securities if the custodian is in the MMM Securities master omnibus. Fund new buys from other cash rather than waiting on these proceeds
• Sellable shares: sells are checked against the account's settled shares for that distribution election, less shares already committed to open sells. Short sales are rejected

Sizing Orders

Size buys in dollars and sells in shares, using the latest NAV as your estimate. The actual price is usually set on the dealing date, so fills will differ slightly from the target. A netted fill on a monthly-NAV fund is the exception: it prices at the last published NAV.

• Valuing positions: multiply each position's totalQuantity by the newest NAV from GET /primary/v1/omnibus/nav-report for that share class. NAV reflects the fund's last valuation and can lag public markets
• Sells: shares to sell = dollar amount to sell ÷ latest NAV. Orders take up to 6 decimal places, while DRIP lots can hold up to 9, so round sells down to 6 places to stay within the client's sellable shares
• Open orders: count pending buys as committed cash and pending sells as committed shares. Check open orders (GET /primary/v1/omnibus/order filtered by accountId and statuses) before generating new trades, so the model does not order twice
• Drift bands: NAV lag, minimums and dealing schedules make exact targets hard to hold. Consider wider drift bands for evergreen sleeves, and rebalancing them on each fund's dealing schedule rather than daily

Building Model Orders

Split each rebalance into model orders (POST /primary/v1/omnibus/model-order), each with one line per client account. Every client in a model order gets the same price, and each model order carries these settings once for all its lines:

1. Check requirements for every account at once with POST /primary/v1/omnibus/order-action/requirements/batch. Resolve open actions first, or leave those accounts out and add them to a later order. A batch of lines that includes an account with an open action is refused as a whole with 409 RequiredOrderActionsIncomplete
2. Submit in three steps: create the model order as a draft, add the client lines in one or more batches with POST /primary/v1/omnibus/model-order/investor-orders, then submit it with POST /primary/v1/omnibus/model-order/complete and the total number of lines. Use a unique referenceId for the model order and for each line, and tag it with your modelId. A duplicate referenceId is rejected, so retrying a timed-out request with the same references won't create a second order or add a line twice. Complete it the same day, because drafts are cancelled overnight
3. Track the model order through OmnibusModelOrder webhook events. Monark checks every line again after you complete it, and sends OmnibusModelOrderCreated, or OmnibusModelOrderRejected if any line fails. Client lines don't send their own events, so check each one with GET /primary/v1/omnibus/order/{id}

• Partial fills: if a block fills only in part, as in a gated redemption, every client's line fills by the same percentage and ends Settled, with the unfilled shares in remainingQuantity
• Cancelling: cancel the whole block with POST /primary/v1/omnibus/model-order/cancel until Monark's cutoff. Individual lines can't be cancelled or amended, so to change one client's trade, cancel the block and resubmit it. A block routed to the netting queue can't be cancelled once submitted
• Netting queue: a block routed to the netting queue nets as one order, and each fill is split across its lines pro rata. Any part that is not netted goes to the TA at Monark's cutoff, or, with unnettedOrderRoute: Cancel, is cancelled at the block's nettingTif deadline so you can resubmit it

Distributions & Tax Lots

Distributions change holdings between rebalances. DRIP elections add shares, and Cash elections leave uninvested cash at the custodian.

• DRIP: the TA issues new shares at NAV on the payable date, and Monark adds them as new lots. Over time the evergreen sleeve drifts overweight
• Cash: the TA wires the cash to the custodian on the payable date, through MMM Securities if the custodian is in the MMM Securities master omnibus. It stays uninvested until your model deploys it. OmnibusDividendCreated webhooks arrive once per lot when allocations are final; sum them by accountId for each client's total
• Choosing an election: the election is part of the position. A buy with a different election opens a separate position, and a sell must name the election of the shares it draws from
• Record dates: only lots acquired on or before the record date receive a distribution. A lot's acquisition date is when Monark records the TA's confirmation, so a buy confirmed after the record date misses it

Each fill and each DRIP reinvestment creates its own tax lot. The taxLotElection on a sell picks which lots it draws from:

Each fund's taxForm shows whether clients receive a Form 1099 or a K-1. Tax-sensitive models may want to account for that when choosing funds.