Pre-Order Requirements

Evergreen fund subscriptions on the Omnibus platform do not use paper subscription documents. In their place, each fund defines a set of requirements - disclosures, acknowledgements, e-signatures, and suitability questionnaires - that must be satisfied before it accepts an order. Monark tells you which requirements apply to a given account and order. Your platform presents them in its UI, in most cases to the advisor, collects the responses, and reports each one back. All actions are stored and auditable.

Monark keeps each response with the order and makes it available to the custodian.

Evaluate requirements after the user has chosen a fund and share class, and before you show them an order ticket they can submit.

Endpoints used

Workflow

1. Evaluate requirements for the account, advisor, fund, share class, and side.
2. If allSatisfied is true, continue to the order ticket. Some funds have no requirements at all.
3. Otherwise, present each requirement whose status is Required, using the control that matches its type.
4. As the user completes each requirement, report it to Monark.
5. Evaluate again, and continue only when allSatisfied is true.

Evaluate requirements

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

{
  "allSatisfied": false,
  "actions": [
    {
      "definitionId": "5c1d8a52-0000-4000-8000-0000000000d1",
      "name": "Acknowledge Subscription Process",
      "description": null,
      "type": "TextAcknowledge",
      "responsibleParty": "Advisor",
      "status": "Required",
      "actionText": "I acknowledge that subscriptions must be submitted at least five business days prior to the first day of each month.",
      "markdownText": null,
      "dataId": null,
      "documentType": null
    },
    {
      "definitionId": "5c1d8a52-0000-4000-8000-0000000000d2",
      "name": "Investor Suitability Questionnaire",
      "description": null,
      "type": "Questionnaire",
      "responsibleParty": "Investor",
      "status": "Satisfied",
      "actionText": null,
      "markdownText": null,
      "dataId": "9e2b7f10-0000-4000-8000-0000000000a7",
      "documentType": null
    }
  ]
}

Important: Requirements are evaluated for the combination of account and advisor. Send the same financialAdvisorId when you evaluate requirements, when you complete them, and when you submit the order. If you omit the advisor here but attach one to the order, the requirements that the advisor is responsible for are never presented. An individual order is then held in PendingActions until they are completed, and a batch of model order lines is refused with 409 (RequiredOrderActionsIncomplete).

Present requirements

Show Satisfied requirements as complete instead of hiding them. Users and compliance reviewers benefit from seeing the full set of disclosures that applies to the order.

Requirement types

For document requirements, documentType identifies the document, such as RegisteredFundProspectus_Monark or RegisteredFundSubscriptionAgreement_Monark. Retrieve the document itself with GET /primary/v2/document/{dataId}.

Responsible parties

responsibleParty tells you who is expected to act. Route each requirement to the right user for your distribution model.

Note: Treat each acknowledgement as a deliberate act by the responsible party. Do not complete requirements on a user's behalf, or in bulk, unless your firm's supervisory procedures provide for it. Keep your own record of what was shown, who accepted it, and when.

Complete a requirement

Report a completed requirement with its definitionId. This applies to every type except Questionnaire.

PUT /primary/v1/omnibus/order-action/requirements/{definitionId}/complete

{
  "accountId": "06309316-0000-4000-8000-000000000021",
  "financialAdvisorId": "01a0b508-0000-7000-8000-000000000031"
}

A successful call returns 204 No Content. The requirement is then returned with a status of Satisfied when you evaluate again. Only requirements with a status of Required need to be presented as outstanding.

Questionnaires

A Questionnaire requirement is satisfied by submitting answers, not by calling the complete endpoint. Calling the complete endpoint for a questionnaire returns 400.

1. Retrieve the questions. The requirement's dataId is the questionnaire ID. The questions returned depend on who is being asked - for example, individuals can receive state-specific suitability questions that entities do not - so always send the order context.

GET /primary/v1/questionnaire/{dataId}?investorId={primaryOwnerPartyId}&accountId={accountId}&financialAdvisorId={financialAdvisorId}

2. Render each question from its format:

Order questions by sequence, show explanation as help text, enforce required, and use dependentOn to show follow-up questions only when the question they depend on has been answered accordingly.

3. Submit the answers with the same context. Answer only the questions that were returned. Answers count toward the requirement only for the party it names: send financialAdvisorId for an Advisor questionnaire, and leave it out for Investor and CoOwner questionnaires, or the requirement stays Required.

POST /primary/v1/questionnaire-answer

{
  "questionnaireId": "9e2b7f10-0000-4000-8000-0000000000a7",
  "investorId": "0a4f6c1e-0000-4000-8000-000000000011",
  "accountId": "06309316-0000-4000-8000-000000000021",
  "createQuestionAnswers": [
    { "questionnaireQuestionId": "c41f0b7e-0000-4000-8000-000000000001", "value": "true" },
    { "questionnaireQuestionId": "c41f0b7e-0000-4000-8000-000000000002", "values": ["Growth", "Income"] }
  ]
}

Use value for single answers and values for MultipleChoiceMultiple. Once every required question has been answered by the right party, the requirement is Satisfied. There is no separate complete call.

Confirm before you continue

After the last requirement is completed, evaluate again and check allSatisfied before you enable the submit button. Do not infer it from your own UI state, because a requirement can be satisfied, or become required, outside the current session.

Handling errors

Errors on these endpoints are returned as a problem details object with status and detail. Invalid parameters return a validation problem with an errors map keyed by field.

Next steps

• Submit the order: Subscriptions (Buy Orders)
• Evaluate many accounts in one request: Model Orders