Go-Live Checklist

Work through this list in the sandbox, then review it with Monark before your production API key is issued.

Setup

• Every custodian your clients use is set up as a Financial Institution, and you have its financialInstitutionId
• Each custodian is enabled for the funds you plan to offer, and knows how it will receive funding instructions and settlement files from Monark and, if it is in the MMM Securities master omnibus, has opened its clearing account at MMM Securities
• Your production webhook is registered, verifies the X-Webhook-Signature (Base64 HMAC-SHA256), and skips repeats using X-Webhook-Event-Id

Accounts & Eligibility

• Your UI asks the advisor for each client's accreditation, eligibility and suitability information
• Every account has a current accreditation. Orders for accounts with none, one more than 12 months old, or NOT_APPLICABLE are refused
• Qualified client and qualified purchaser status is recorded, and funds are only offered to clients who meet their eligibility flags. Monark does not check these flags on orders
• Non-US accounts are excluded. Non-US investors are not supported

Orders

• Every order and model order sends a unique referenceId, and a timed-out request is retried with the same referenceId
• The same financialAdvisorId is sent when evaluating requirements, completing them, and submitting the order
• Your UI branches on the status of create and cancel responses, not only on the HTTP status code
• Rejection messages are shown to the user, alongside a way to correct and resubmit
• Amount inputs validate against the share class minimums before submission
• Share estimates and redemption proceeds are labelled as estimates, because orders generally fill at the next struck NAV
• Clients and advisors can see when an order can no longer be cancelled (Monark's cutoff)
• Every buying client has sufficient buying power at their custodian (no margin), kept available until the order settles
• Model orders are split by custodian, share class, side, distribution election and tax lot election, and pass the batch requirements check before submission
• Model orders are completed on the day they are created, with a totalOrderCount that matches the lines added, and their outcome is taken from the OmnibusModelOrderCreated, OmnibusModelOrderRejected or OmnibusModelOrderFailed webhook, not from the 202 response

Operations

• Order status is driven by webhooks, with the order endpoints used to reconcile
• The webhook event log is checked after any outage on your side
• Positions and dividends are read from Monark's positions and dividends endpoints, and differences are raised with Monark Operations
• You retain your own record of each acknowledgement, signature, and questionnaire response for your books and records

Sandbox Tests

• A model order taken from account creation to Settled, as in the Sandbox Walkthrough
• An individual buy with open order actions, completed from PendingActions
• A sell, including one refused with InsufficientSellableShares
• A cancellation before Monark's cutoff, and a refused cancellation
• The responses in Errors & Reason Codes that your UI handles

When these are done, Monark issues your production API key and base URL.