Subscriptions (Buy Orders)

A subscription into an evergreen fund is a Buy order for one account. Buy orders are placed in dollars. The number of shares the account receives is determined later, when the fund strikes the NAV that the order fills at.

This guide covers the single-account order flow used by self-directed platforms and by advisors placing one order at a time. To invest many accounts in one submission, see Model Orders.

Endpoints used

Before you begin

• The account exists and is eligible for the fund. See Accounts & Eligibility.
• The user has chosen a share class. See Fund Detail.
• Requirements for this account, advisor, fund, share class, and side evaluate to allSatisfied: true. See Pre-Order Requirements.

Workflow

1. Collect the amount and elections on an order ticket, and validate the amount against the share class minimums.
2. Confirm that pre-order requirements are satisfied.
3. Show a review step that restates exactly what will be submitted.
4. Submit the order with a unique referenceId. An IdempotencyKey header is optional.
5. Branch on the status of the response: confirm, collect outstanding actions, or show the rejection.
6. Track the order until it settles.

Order ticket

Distribution election. Cash pays the fund's distributions out in cash. Drip reinvests them into additional shares. The election is part of the identity of the resulting position: an account that holds the same share class under both elections has two separate positions.

Tax lot election. This sets the order in which tax lots are relieved when shares are later sold. See Redemptions (Sell Orders) for what each method means. Platforms that apply a firm-wide or account-level default can set it without asking the user.

Validate the amount

Check for an existing holding with GET /primary/v1/omnibus/positions?accountId={accountId}&omnibusShareClassId={shareClassId}.

Review step

Restate the order before the user commits to it: fund, share class, account, amount, distribution election, and tax lot method. Repeat the share estimate, labelled as an estimate, and remind the user of the fund's subscription and redemption schedule.

Submit the order

POST /primary/v1/omnibus/order
IdempotencyKey: 6f1c1a0e-7d1b-4f57-9d0a-2f3b8a1c9e44

{
  "referenceId": "ORD-2026-000184",
  "accountId": "b2d4e6f8-0000-4000-8000-000000000021",
  "financialAdvisorId": "c3e5a7b9-0000-4000-8000-000000000031",
  "omnibusFundId": "d4f6b8c0-0000-4000-8000-0000000000f1",
  "omnibusShareClassId": "e5a7c9d1-0000-4000-8000-0000000000c1",
  "side": "Buy",
  "notionalAmount": 25000,
  "currency": "USD",
  "distributionElection": "Drip",
  "taxLotElection": "FIFO"
}

A referenceId that you can trace back to your own order management system makes reconciliation straightforward: you can look an order up with GET /primary/v1/omnibus/order?referenceId={referenceId} even if you never received the response to the original request.

Route to the netting queue

Send routeInstruction: IntraCustodianNetting to net the order against opposite orders from the same custodian, in the same fund, share class and distribution election, at the fund's NAV. Monark enables netting for each custodian, fund and share class. Where it isn't enabled, the order is rejected with OrderNettingCapabilityMissing rather than sent to the transfer agent. The older values OrderNetting and DirectToTa are still accepted and are returned as sent, and CrossCustodianNetting is not yet supported.

{
  "routeInstruction": "IntraCustodianNetting",
  "unnettedOrderRoute": "Cancel",
  "nettingTif": "EOM"
}

A netting order can fill in part, across several daily netting sessions, and against several other orders. Each fill is priced at that day's NAV for a daily-NAV fund, or at the last published NAV for a monthly-NAV fund, and creates its own tax lot. A netting order can be changed or cancelled only while it is PendingActions. One with no outstanding actions goes straight to the netting queue and can't be changed or cancelled, so use unnettedOrderRoute: Cancel and a nettingTif to limit how long it waits. See the Omnibus Product Flow Overview for how netting sessions work.

Interpret the response

{
  "id": "0ed24676-0000-4000-8000-0000000000e1",
  "externalId": "01a0b58aa55207f9d70f",
  "referenceId": "ORD-2026-000184",
  "status": "Received",
  "submittedAtUtc": "2026-09-18T17:22:37.516Z",
  "requestedRouteInstruction": null,
  "routeInstruction": "TransferAgent",
  "statusReasonCode": null,
  "message": null,
  "fieldErrors": []
}

The create endpoint returns this body for 201, 403, 404, 409 and 503. Request-validation 400s return a validation problem with an errors map instead. Branch on status first. requestedRouteInstruction is the route you sent, or null if you omitted it, and routeInstruction is the route Monark applied. fieldErrors is currently always empty.

Other statuses can be returned. Treat any status you do not recognise as "submitted, pending confirmation" and rely on order tracking.

A rejected order:

{
  "id": "0ed24676-0000-4000-8000-0000000000e2",
  "referenceId": "ORD-2026-000184",
  "status": "Rejected",
  "statusReasonCode": "FinancialInstitutionFundAccessDenied",
  "message": "The investor's financial institution does not have access to the omnibus fund.",
  "fieldErrors": []
}

Important: A rejection can be returned with HTTP 201. Do not treat a 2xx response as an accepted order. Orders rejected with 201 are retained, and are returned by the order endpoints with a status of Rejected. Rejections returned with a 4xx code are not stored. Neither sends a webhook.

Complete order actions

An order returned as PendingActions is not processed until its actions are complete. This is uncommon when pre-order requirements were satisfied first, but your integration should handle it.

1. List the actions with GET /primary/v1/omnibus/order-action/order/{orderId}.
2. Present each action whose status is Pending. Order actions carry the same name, type, responsibleParty, actionText, markdownText, and dataId fields as pre-order requirements, so you can reuse the same components.
3. Complete each one with PUT /primary/v1/omnibus/order-action/{id}/complete. Each call returns 204 No Content. For a Questionnaire action, submit the answers first (see Pre-Order Requirements), then call complete. Completing an action that is not Pending returns 400.

When every action is Complete, the order moves to Received and is submitted, and any order fee is recalculated at that point. It becomes PendingExecution when OmnibusOrderAccepted arrives. PUT /primary/v1/omnibus/order-action/order/{orderId}/complete-all completes every action in one call. Use it only where the user has reviewed every action.

Track the order

GET /primary/v1/omnibus/order/{id}

An order appears in the account's positions only after it reaches Settled, except that each fill in the netting queue updates the position as it happens. Until then, show it as an open order. See Portfolio & Positions.

Note: Funding for a subscription moves through the account's custodian, which wires the amount after Monark's cutoff. If the custodian is in the MMM Securities master omnibus, it wires MMM Securities, Monark's broker-dealer subsidiary, which forwards the cash to the fund's transfer agent. Otherwise it wires the transfer agent directly, and Monark does not hold or move the cash. Keep the cash available at the custodian until the order settles. See Custody Models.

Status notifications

Orders change state after the create response is returned - when they are accepted, sent to the transfer agent, and settled. Subscribe to order webhooks instead of polling, and use GET /primary/v1/omnibus/order/{id} to reconcile. See Webhooks for how to register an endpoint and handle each event.

Each event carries the current order, in the same shape as the order endpoint returns.

Update or cancel

An order can be changed or cancelled until Monark's cutoff for the fund's next dealing date. An order routed to the netting queue can be changed or cancelled only while it is PendingActions; an order with no outstanding actions goes straight to the netting queue. Otherwise, requests are refused with 409 and OrderNettingUpdateUnsupported or OrderNettingCancellationUnsupported.

PUT /primary/v1/omnibus/order/{id}

{
  "notionalAmount": 30000,
  "reason": "Client increased allocation"
}

POST /primary/v1/omnibus/order/{id}/cancel

Both are requests that are processed asynchronously. The response tells you whether the request was taken, not whether the order has changed:

{
  "cancelRequestId": "4b7a1d90-0000-4000-8000-0000000000b1",
  "orderId": "0ed24676-0000-4000-8000-0000000000e1",
  "status": "Pending",
  "reasonCode": null,
  "message": null,
  "createdAtUtc": "2026-09-18T18:02:11.000Z",
  "updatedAtUtc": "2026-09-18T18:02:11.000Z"
}

After a Pending response, wait for the OmnibusOrderCancelled or OmnibusOrderUpdated event, or retrieve the order again, before you tell the user the change is done. Orders that belong to a Model Order are cancelled through the Model Order. See Model Orders.

Handling errors

The reason codes above are the most common. The set is not exhaustive, so display message for any code that you do not handle explicitly. Branch on the reason code, not only on the HTTP status. See Errors & Reason Codes for the full list.

Next steps

• Show the order in the account's portfolio: Portfolio & Positions
• Submit orders for many accounts at once: Model Orders