Omnibus Product Flow Overview

How Monark Omnibus works for distribution platforms, from onboarding through order placement, settlement and post-trade servicing.

Overview

Monark's Omnibus platform, also referred to as Evergreen Fund Omnibus (EFO), enables model portfolio platforms to allocate client capital to evergreen alternative funds through one API. Monark provides the order netting engine, transfer agent processing and investor-level sub-accounting. Your clients' shares are held as a nominee position in omnibus accounts at each fund's transfer agent. Depending on the custodian, those omnibus accounts are held by MMM Securities, Monark's broker-dealer subsidiary, or by the custodian itself.

Where MMM Securities holds the shares, cash also moves through it: the custodian sends cash to and receives cash from MMM Securities, which settles with the transfer agent. Otherwise, Monark does not hold or move cash, and cash settles directly between the custodian and the transfer agent. Either way, Monark tells each side exactly what is owed, and your integration is the same. Monark's Omnibus platform only supports funds or share classes that issue 1099 tax documents.

Order netting is enabled by Monark for each custodian, fund and share class. Ask Monark which of yours are enabled.

The lifecycle has four stages:

  1. Onboarding: connecting your platform, your custodians and the funds you offer
  2. Order Placement: submitting model-driven buy and sell orders
  3. Execution & Settlement: the netting queue, transfer agent processing and movement of cash
  4. Post-Settlement: positions, distributions, tax reporting and reconciliation

Steps that need action from your platform are marked Partner action.

Key Terms

TermMeaning
PartnerModel portfolio or distribution platform that submits orders to Monark for its clients' accounts. It collects each client's accreditation, eligibility and suitability information from the advisor in its UI
MonarkMonark's operations team and Omnibus platform, including MMM Securities, Monark's broker-dealer subsidiary
CustodianCustodian that holds your clients' accounts and cash. It funds purchases and receives redemption and distribution cash. The API calls it a Financial Institution
Transfer agent (TA)Firm that keeps each fund's shareholder records and processes subscriptions, redemptions and distributions
Omnibus accountAccount at the TA holding the combined shares of every client at one custodian, or of every participating custodian in the MMM Securities master omnibus, for each share class and distribution election
Custody modelWho holds a custodian's omnibus accounts at the TA: the custodian itself (custodian omnibus), or MMM Securities (MMM Securities master omnibus), with each participating custodian holding its own omnibus account at MMM Securities. See Custody Models
Sub-ledgerMonark's record of each client's positions, tax lots and cost basis beneath the omnibus accounts
Distribution electionCash (distributions paid out) or DRIP (distributions reinvested). Each fund share class has one omnibus account per election for every custodian, or one master account in MMM Securities' name for the MMM Securities master omnibus
Model orderOne rebalance order for a fund, covering many client accounts at one custodian
Netting queueWhere buys are netted against sells in the same fund, share class and custodian at NAV, before any order goes to the Fund/TA. An order is routed to it with routeInstruction: IntraCustodianNetting
Netting sessionThe netting queue's run for each fund and share class at the end of each business day, after that day's netting order cutoff. It prices fills at that day's NAV for a daily-NAV fund, or the last published NAV for a monthly-NAV fund
Cutoff dateMonark's order deadline for each fund dealing date. It always falls before the fund's own cutoff
NAVNet asset value per share, struck by the fund and used to price every order

Onboarding

Before your first order, Monark sets up your platform, each custodian you work with and the funds you plan to offer. Time to launch depends mostly on the custodians integration time frame.

Platform Setup

Monark issues API keys for the sandbox (https://sandbox-api.monark-markets.com) and production. Keys go in the Authorization header; request one at [email protected].

Partner action: register a webhook (POST /primary/v1/webhook) with a delivery URL and a signing token. Monark sends every Omnibus order, model order, funding instruction and dividend event there. See Webhooks.

Custodian Setup

Each custodian that holds your clients' accounts is set up as a Financial Institution under your platform. For every share class you offer, its clients' shares are held in two omnibus accounts at the fund's TA, one Cash and one DRIP. Depending on the custodian's custody model, those accounts are in the custodian's name or in MMM Securities' name (see Custody Models).

Monark agrees on settlement file formats, delivery cadence and wire timing directly with each custodian. Its operations team gets Alts Desk access to view orders, positions and settlement files and to download reports.

Custody Models

MMM Securities master omnibusCustodian omnibus
Omnibus accounts at the TAOne Cash and one DRIP master account per share class, in MMM Securities' name. Each participating custodian holds its own omnibus account at MMM Securities beneath itOne Cash and one DRIP account per share class, in the custodian's name, for its clients only
Records each custodian's balanceMMM Securities, in the custodian's omnibus account on its own booksThe TA
CashMoves between the custodian and the TA through MMM Securities, using a clearing account the custodian opens at MMM SecuritiesMoves directly between the custodian and the TA
Funding instructionsMMM Securities' wire instructionsThe TA's wire instructions
Netting queueTwo tiers: orders net first within each participating custodian's omnibus account, then MMM Securities nets what remains across participating custodiansOrders net only within the custodian's own omnibus account, using Monark's netting engine under license to the custodian

The custody model doesn't change your endpoints, order fields, statuses or webhook event types, and every order is still placed for a client account at its custodian. What differs is where the cash goes: funding instructions carry MMM Securities' wire instructions, and dividends reference MMM Securities' master omnibus accounts.

MMM Securities sees only custodian-level data, such as each custodian's balances, orders and wires. Client-level records, including personal information, stay in Monark's sub-ledger and are not shared with MMM Securities.

Client Accounts

Partner action: create each client as a person (/primary/v2/person) or entity (/primary/v2/entity), then open an account (POST /primary/v2/account) under the right custodian's financialInstitutionId. Include the custodian's account number as externalAccountNumber.

  • Registration types: Individual, Joint, Retirement (Traditional, Roth, Rollover, SEP, SIMPLE and beneficiary IRAs) and Entity accounts
  • Accreditation: ask the advisor for it in your UI, and set it on every account before ordering with PUT /primary/v2/account/{id}/accreditation. Orders requiring accreditation are rejected if it is missing, more than 12 months old or NOT_APPLICABLE
  • Eligibility: ask the advisor for each client's qualified client or qualified purchaser status, and record it on the person (qualifiedStatus). Only offer a fund to clients who meet its eligibility flags
  • Non-US accounts: not supported. Do not submit orders for non-resident alien or foreign accounts

Fund Catalog

Fund data comes from the API. Show clients the following before they invest:

DataEndpointWhat to show clients
FundsGET /primary/v1/omnibus/fundDescription, asset class, structure, subscription and redemption cadence, redemption limit (% of NAV per window), distribution cadence, investor eligibility, tax form
Share classesGET /primary/v1/omnibus/share-classCUSIP, symbol, initial and subsequent minimums
FeesGET /primary/v1/omnibus/fee-structureManagement, performance and distribution fees and sales loads
NAVGET /primary/v1/omnibus/nav-reportNAV history by share class
DocumentsFund endpoints with includeDocuments=true, or GET /primary/v2/document?omnibusFundId=Prospectus, fact card and marketing documents

Fund fees are charged by the fund and do not change order amounts.

Monark sets a cutoff date for each share class's subscription and redemption dates, always ahead of the fund's own cutoff. Cutoff dates are shown in the Alts Desk and are set only by Monark.

Order Placement

Your platform submits orders through the API, one per client or as a model order covering a whole rebalance. Buys are in dollars and sells are in shares. No investor sets a price: every order executes at the fund's NAV.

Pre-Order Requirements

Each fund has order actions that must be completed before an order can proceed: prospectus and disclosure review, text acknowledgements, suitability questionnaires and, where required, signatures. Each action names who completes it (Partner, investor, advisor or co-owner).

Your platform collects these in its UI, in most cases from the advisor, and reports them to Monark. The custodian does not collect accreditation or suitability for Omnibus orders: Monark keeps your responses with each order and makes them available to the custodian.

Partner action:

  • Check what each client needs before ordering: GET /primary/v1/omnibus/order-action/requirements for one account, or POST /primary/v1/omnibus/order-action/requirements/batch for every account in a model order
  • Present each action to the right person and record completion with PUT /primary/v1/omnibus/order-action/requirements/{definitionId}/complete. Questionnaires are completed by submitting answers to POST /primary/v1/questionnaire-answer
  • Confirm the client has cash available at the custodian before submitting a buy, and keep it available until the order settles. Buys the custodian does not fund will not settle

An individual order created with open actions waits in PendingActions and is not sent to the TA until every action is complete. Model orders work differently: a line for an account with open actions is refused with 409 (RequiredOrderActionsIncomplete) when you add it, and the whole model order is rejected if any account has open actions when it is processed.

Sells are checked against the account's settled shares for that distribution election, less shares already committed to open sells. Sells that exceed them, including short sales, are rejected.

Submitting Orders

FieldNotes
referenceIdYour order reference. Must be unique across your platform
accountIdClient's Monark account
omnibusFundId, omnibusShareClassIdFund and share class being traded
sideBuy or Sell
notionalAmountBuys only, in USD
quantitySells only, in shares
distributionElectionCash or Drip. A client's Cash and DRIP holdings in the same share class are tracked as separate positions
taxLotElectionFIFO, LIFO, HCFO or LCFO: which lots a sell draws from
routeInstructionIntraCustodianNetting to go to the netting queue first, or TransferAgent. Defaults to TransferAgent. The older values OrderNetting and DirectToTa are still accepted. CrossCustodianNetting is reserved and not yet supported
unnettedOrderRouteNetting orders only. What happens to any part not netted: TransferAgent (default) or Cancel. See The Netting Queue, below
nettingTif, nettingTifDateNetting orders only. How long the order nets: Cutoff (default), EOD, EOM, EOQ or Custom with an optional nettingTifDate. Anything other than Cutoff requires unnettedOrderRoute: Cancel
modelIdOptional. Your model or rebalance identifier

Every submission gets an immediate response. Check the order's status as well as the HTTP code: many rejections are returned as 201 with status set to Rejected and a statusReasonCode. Monark also applies per-custodian limits on order size and daily volume, and rejects orders that exceed them.

Model Orders

For a rebalance, submit one model order for the fund and share class, with one line per client account. A model order covers accounts at one custodian (financialInstitutionId), so a rebalance spanning several custodians needs one model order per custodian.

A model order is submitted in three steps:

  1. Create it as a draft with POST /primary/v1/omnibus/model-order
  2. Add the client lines, in one or more batches of up to 10,000 lines in total, with POST /primary/v1/omnibus/model-order/investor-orders. Each batch is checked as it arrives, and a batch with a failing line is refused as a whole
  3. Submit it with POST /primary/v1/omnibus/model-order/complete and the total number of lines. The response is 202 with a status of Processing. Monark checks every line again, then sends OmnibusModelOrderCreated, or OmnibusModelOrderRejected if any line fails

Complete the draft the same day: drafts still open at 1:00 AM Eastern are cancelled.

Monark handles the model order as a single block:

  • Every client in the block gets the same execution price on each fill
  • Partial fills are shared pro rata. If 50% of a $100,000 block fills, a $40,000 client order fills $20,000 and a $60,000 client order fills $30,000
  • Each fill settles as its own child order and creates its own tax lot at that fill's price and date
  • A block routed to the netting queue nets as one order. Each fill is split across the client lines pro rata to their remaining balances, and every line follows the block's unnettedOrderRoute

Cancellations & Amendments

You can cancel an order (POST /primary/v1/omnibus/order/{id}/cancel) or change its amount or tax lot election (PUT /primary/v1/omnibus/order/{id}) until Monark's cutoff. After that it is final. A request made just after the cutoff may be accepted as Pending and then refused.

  • To change routing, cancel and resubmit
  • Orders routed to the netting queue can't be cancelled or amended unless they are still PendingActions (OrderNettingCancellationUnsupported, OrderNettingUpdateUnsupported). To limit how long a netting order waits, send unnettedOrderRoute: Cancel with a nettingTif
  • A model order can only be cancelled as a whole, with POST /primary/v1/omnibus/model-order/cancel. Its lines can't be cancelled or amended on their own, and model orders can't be amended. A draft is cancelled straight away; a model order that is Processing can't be cancelled
  • Partner action: show clients and advisors when an order can no longer be cancelled

Order Statuses

StatusMeaning
DraftA model order still taking lines. Cancelled with DraftExpired if not completed by 1:00 AM Eastern (model orders only)
ProcessingA completed model order being checked by Monark. The outcome is sent by webhook (model orders only)
ReceivedPassed Monark's checks and recorded. Not yet accepted for execution
PendingActionsWaiting on order actions (individual orders only)
PendingExecutionAccepted and waiting for Monark's cutoff or the netting queue. A partly netted order stays here until its remainder goes to the TA or expires
ExecutedSent to the TA in a trade file, awaiting the TA's confirmation. Nothing more is filled until then, though a netting order may already have netting fills
SettledConfirmed by the TA, or fully filled in the netting queue. Tax lots are created. A partly filled order also ends here, with a remaining quantity
CancelledCancelled before Monark's cutoff, or a netting order that reached its deadline with nothing filled (Execution:Expired)
RejectedFailed validation, eligibility or risk checks, or was rejected by the TA (Settlement:TaRejected). See statusReasonCode
FailedAn operational problem, such as no TA confirmation in time (Settlement:ConfirmationTimeout)

Individual orders send OmnibusOrder webhook events (OmnibusOrderAccepted, OmnibusOrderSent, OmnibusOrderSettled and so on). Model orders send only OmnibusModelOrder events for the block, except that each line also sends OmnibusOrderSettled or OmnibusOrderCancelled when a netting model order reaches its deadline; check each line with GET /primary/v1/omnibus/order/{id}. Each order carries its fills and settlement items. Fills in the netting queue don't send an event of their own, and an order that fills completely there moves to Settled without an OmnibusOrderSettled event, so read them from the order after each netting session.

Execution & Settlement

Orders are either netted in the netting queue, which nets orders against other orders at the same custodian (and, in the MMM Securities master omnibus, then across participating custodians), or sent to the fund's TA at Monark's cutoff. The custodian wires purchase money to the TA, and the TA wires redemption proceeds to the custodian. In the MMM Securities master omnibus these wires pass through MMM Securities; otherwise Monark never holds cash.

sequenceDiagram
    participant P as Partner
    participant M as Monark
    participant C as Custodian
    participant S as MMM Securities
    participant T as Transfer agent
    P->>M: Buy order
    M->>M: Hold until cutoff
    M->>C: Funding instruction for buys that were not netted
    alt MMM Securities master omnibus
        C->>S: Wire
        S->>T: Wire
    else Custodian omnibus
        C->>T: Wire
    end
    M->>T: Trade file
    T->>M: Confirmation at NAV
    M->>C: Settlement file
    M->>P: Order settled

Buys routed to the TA, and any part of a netting order that goes on to the TA, move through these steps. Sells follow the same path in reverse, with the TA wiring proceeds to the custodian, through MMM Securities in the MMM Securities master omnibus.

The Netting Queue

The netting queue runs one session at the end of each business day for each fund and share class, after that day's netting order cutoff. This applies to daily-NAV and monthly-NAV funds alike, whether or not the fund's subscription or redemption window is open. Orders submitted by the cutoff are included in that day's session. Where a share class has an enabled netting schedule, Monark's cutoff time for sending its orders to the TA is the same as its netting order cutoff time. TransferAgent orders can be submitted at any time.

  • Orders are netted against orders at the same custodian, in the same fund, share class and distribution election. In the MMM Securities master omnibus, what remains then nets across participating custodians. Cash and DRIP orders never net against each other
  • Orders are netted oldest first, by submission time. An order that waited in PendingActions takes its place from when its actions were completed
  • An order can fill in part, and against several other orders. Buys net on their effectiveNotionalAmount, after any order fee
  • Both sides of every fill in a session are priced at the same NAV, which depends on how often the fund strikes NAV:
    • Daily-NAV funds: the NAV the fund strikes for that business day. The price is not known when the order is placed, and the session waits for that day's NAV
    • Monthly-NAV funds: the last NAV the fund has published when the session runs. The price is known in advance
  • Netted orders never go to the TA. They settle at the custodian, which moves cash and shares between the two clients' accounts using Monark's settlement file. Each fill creates its own tax lot

The part of an order that is not netted is handled by its unnettedOrderRoute:

unnettedOrderRoutenettingTifWhat happens to the unnetted balance
TransferAgent (default)Cutoff onlyKeeps netting in each business day's session until Monark's next cutoff for its side, then goes to the TA with that cutoff's TransferAgent orders, at its fee-net amount with no second fee. An unnetted buy goes at the next subscription cutoff. An unnetted sell keeps netting until the cutoff for the fund's next redemption window, which can be weeks or months away
CancelCutoff, EOD, EOM, EOQ or CustomNets until its deadline, which is never later than Monark's next cutoff for its side, and is then cancelled. The order ends Settled if any of it filled, otherwise Cancelled, with statusReasonCode Execution:Expired

EOD, EOM and EOQ set the deadline to the last NYSE business day on or before the end of the current day, month or quarter. Custom does the same for nettingTifDate, and nets until Monark's cutoff if no date is sent. A deadline in the past is rejected.

A netting order for a custodian, fund and share class where Monark has not enabled netting is rejected with OrderNettingCapabilityMissing. Monark never sends it to the TA instead.

Purchases at the Transfer Agent

  1. At Monark's cutoff, Monark totals the buys that were not netted for each custodian and sends it a funding instruction with the exact amount to wire. For each share class and election, you receive an OmnibusOrderFundingInstruction webhook listing your orders and the wire instructions: MMM Securities' in the MMM Securities master omnibus, otherwise the TA's
  2. The custodian wires the cash to the TA, and Monark sends the TA one trade file. In the MMM Securities master omnibus, the custodian wires MMM Securities instead, which sends the TA one wire covering every custodian in that model. The wire and file amounts must match or the TA rejects the purchase
  3. The TA processes the purchase at NAV and confirms to Monark. Monark marks the orders Settled, creates tax lots at the TA's NAV and sends the custodian a settlement file
Fund cadenceMonark cutoffSettlement
Daily20:00 UTC on each dealing day (4:00 PM Eastern in summer, 3:00 PM in winter)As soon as T+1 after the order is sent to the TA
Weekly to annualBy default, 3 NYSE business days before the fund's cutoff, to leave time for the wireFund's subscription date

Monark may set an order fee for each custodian and share class. It applies to buys only: the order shows the feeAmount and the effectiveNotionalAmount that is invested.

Redemptions at the Transfer Agent

  1. At the redemption cutoff, Monark sends the TA a trade file for the sells that were not netted
  2. The TA processes the redemption, typically within 15 to 30 days, and wires proceeds to the custodian. In the MMM Securities master omnibus, the TA wires MMM Securities, which forwards each custodian's share
  3. Monark sends the custodian a per-client breakdown of the proceeds, tied to that wire
  • Gated redemptions: when a fund limits a window (for example, 5% of NAV per quarter), each client's sell fills pro rata. The order ends Settled with the unfilled shares shown as remainingQuantity

Settlement Files

After the 4:00 PM Eastern close, Monark sends each custodian a settlement file covering netted fills, buys it must fund and sells going to the TA. Model order fills appear as individual client orders. Some custodians also receive confirmations throughout the day.

The custodian reconciles the file against its own records. It raises any break, or any trade it does not recognize, with Monark Operations, who research and correct it.

In the MMM Securities master omnibus, Monark also sends each participating custodian a daily net amount to wire to or receive from MMM Securities for trades netted with other custodians, with the orders behind it.

Partner action: reflect fills, funding instructions and settlements in client and advisor views as webhook events arrive.

Post-Settlement

Monark's sub-ledger is the record of each client's shares, tax lots and cost basis beneath the omnibus accounts. Positions, distributions and tax data all come from it through the API. In the MMM Securities master omnibus, MMM Securities also records each participating custodian's total balance in that custodian's omnibus account on its books.

Positions & Valuations

GET /primary/v1/omnibus/positions returns each client's positions by fund, share class and distribution election. Add includeLots=true for tax lots.

  • Position: total shares, total cost basis and average cost per share
  • Lot: acquisition date, type (Subscription or DividendReinvestment) and cost basis per share. Only open lots are returned

The TA sends Monark each NAV as the fund strikes it, and a NAV can be revised. Use GET /primary/v1/omnibus/nav-report for the latest NAV and history to value positions.

Distributions

Clients are entitled to a distribution for lots acquired on or before the record date. A lot's acquisition date is when Monark records the TA's confirmation, not the order or dealing date.

  • Cash election: on the payable date, the TA wires the cash to the custodian. In the MMM Securities master omnibus, the TA wires MMM Securities, which forwards each custodian's share based on record-date balances. Monark calculates each client's share from record-date positions and sends the custodian the breakdown
  • DRIP election: the TA issues new shares at NAV into the DRIP omnibus account. Monark allocates them to clients as new tax lots, dated the payable date at the reinvestment NAV

Allocations are made per lot. Each one is available from GET /primary/v1/omnibus/dividends and arrives as its own OmnibusDividendCreated webhook, so sum them by accountId for a client's total. Monark splits each distribution pro rata, to the cent for cash and to 9 decimal places for DRIP shares, and assigns rounding remainders so the allocations add up exactly to the fund's total. If Monark's calculation does not match the TA's, Monark asks the custodian to hold the distribution until the difference is resolved.

Tax Reporting

Monark tracks every lot's acquisition date and cost basis, and relieves lots on each sell according to the order's tax lot election. Each fund's taxForm field shows whether it reports on Form 1099 or a K-1.

In mid-to-late January, Monark forwards the TA's final tax characterization file (qualified or ordinary dividend, return of capital) to each custodian, through MMM Securities in the MMM Securities master omnibus. The custodian uses it to issue 1099-DIVs. DRIP distributions are taxable even though no cash is paid out.

Reconciliation

Monark reconciles each time the TA sends a position file, and Monark Operations works with the relevant party to resolve any break.

LevelWhat is checked
Sub-ledger to TAClient positions in Monark's sub-ledger add up to the TA's balance for each omnibus account
MMM Securities to TA and bankIn the MMM Securities master omnibus, the participating custodians' omnibus accounts on MMM Securities' books add up to its master omnibus accounts at the TA, and its cash records match its bank account
Custodian to sub-ledgerThe custodian's client records match Monark's settlement files and positions

Partner action: use the positions and dividends endpoints as the source for client holdings, and raise any difference with Monark Operations.


Did this page help you?