Redemptions (Sell Orders)

A redemption is a Sell order, created through the same endpoint as a subscription. The differences are what you send and what you must show the user first.

Endpoints used

Workflow

1. Open the redemption ticket from a position, so the fund, share class, and distribution election are already fixed.
2. Retrieve the position with its tax lots, and calculate how many shares can be sold now.
3. Evaluate requirements with side=Sell, and complete anything outstanding.
4. Show the fund's repurchase terms and an estimate of the proceeds.
5. Submit the order with quantity, and branch on the status of the response.

Start from the position

A position is identified by account, fund, share class, and distribution election. Take all four from the position being redeemed, rather than asking the user to choose again - an account can hold the same share class under two distribution elections, and they are separate positions.

Validate the quantity

GET /primary/v1/omnibus/positions/{positionId}?includeLots=true

Positions cannot be sold short, so a redemption can never exceed Position.totalQuantity. The quantity the user can redeem now is Position.totalQuantity less the shares in the position's open Sell orders (Received, PendingActions, PendingExecution or Executed). Lots in evergreen fund positions are not locked: lockedUntil and lockReason are currently always null.

Note: Monark also reserves shares against open Sell orders. A redemption can be refused for insufficient shares even when the position looks large enough, if an earlier redemption is still open. The refusal message names the requested, available, and reserved quantities.

Requirements

Funds can define requirements for redemptions as well as subscriptions. Evaluate them with side=Sell and complete anything outstanding before you submit, exactly as for a subscription:

GET /primary/v1/omnibus/order-action/requirements?accountId={accountId}&financialAdvisorId={financialAdvisorId}&omnibusFundId={fundId}&omnibusShareClassId={shareClassId}&side=Sell

See Pre-Order Requirements.

Tax lot election

taxLotElection determines which lots are relieved first, and therefore what gain or loss the client realizes.

Because you already hold the position's lots, you can show the user which lots each method would relieve, and the resulting realized gain or loss, before they submit. This is one of the more valuable things a distribution platform can add to the flow.

Important: Any gain or loss you display is an estimate. Lots are relieved at the price the order actually fills at. At the transfer agent, and for a netted fill on a daily-NAV fund, that is the fund's next struck NAV, not the last reported one. A netted fill on a monthly-NAV fund is priced at the last NAV the fund has published when the netting session runs. Estimates shown in your UI are not tax advice or a substitute for the client's own cost basis reporting.

Repurchase terms

Evergreen funds repurchase shares periodically, and limit how much they repurchase in each window. Remind the user of the fund's terms on the ticket - these are the fields returned by the fund endpoint, described in Fund Detail:

If a repurchase offer is oversubscribed, the fund prorates it. The order still ends Settled: filledQuantity shows what was redeemed, and the unfilled shares (remainingQuantity) stay in the position and are no longer reserved. Submit a new redemption for a later window if the client still wants to sell. Make it clear at the point of sale that a redemption request is not guaranteed to be filled in full.

A redemption can also be routed to the netting queue with routeInstruction: IntraCustodianNetting, where it fills against buys at the same custodian, in the same fund, share class, and distribution election, at that day's NAV for a daily-NAV fund, or the last published NAV for a monthly-NAV fund. The netted part never goes to the transfer agent, so it is not prorated. See Subscriptions (Buy Orders) for the netting fields.

Submit the redemption

POST /primary/v1/omnibus/order
IdempotencyKey: 8a2f4b6c-1d3e-4f50-9a7b-6c5d4e3f2a10

{
  "referenceId": "RED-2026-000091",
  "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": "Sell",
  "quantity": 125.5,
  "currency": "USD",
  "distributionElection": "Drip",
  "taxLotElection": "FIFO"
}

Estimate the proceeds as quantity × the share class's latest NAV, and label it as an estimate. To redeem a whole position, send Position.totalQuantity rounded down to 6 decimal places: DRIP positions can hold up to 9, but a Sell accepts at most 6.

Handling errors

A redemption can be refused for reasons that only Monark can evaluate, so always branch on the status of the response rather than the HTTP code.

A refusal is not a failure of your integration - it is usually information the client needs. Render message in place, beside the quantity field, with the ticket still editable.

After submission

A Sell order is tracked, updated, and cancelled exactly like a Buy order, through the same endpoints and webhooks. See Subscriptions (Buy Orders).

The position is reduced when the redemption settles, or as each fill in the netting queue happens, not when it is submitted. Until then, show the open Sell order alongside the position, so the client can see that a redemption is in progress and does not submit it twice.

Note: The fund's transfer agent wires redemption proceeds to the account's custodian, typically 15 to 30 days after the redemption is sent to it. If the custodian is in the MMM Securities master omnibus, the proceeds pass through MMM Securities, Monark's broker-dealer subsidiary. Otherwise, Monark does not hold or move the cash. For the part of a redemption filled in the netting queue, the custodian moves the cash between its clients' accounts instead. See Custody Models.

Next steps

• Reflect the redemption in the client's holdings: Portfolio & Positions
• Redeem across many accounts at once: Model Orders