Let AI-powered wealth workflows investigate suitability. Keep distribution policy outside the model.

The new decision boundary an AI-powered wealth workflow introduces

An RM is in their workstation, in the middle of a client conversation. They select a structured note candidate and click "Check suitability".

Before agents, that button either called a fixed suitability engine or triggered a manual desk review. The determination was owned end-to-end by a single system or a human process.

With an AI service participating behind the button, the determination now gets built by the model. It fetches product data, reads the client profile, extracts facts from the conversation and the case file, and constructs the composite view : product eligibility, suitability, cross-border, concentration.

The RM sees a native application result.

They do not need to know an agent ran behind the workstation. The workstation, the CRM, the order-entry UI stay exactly as they are.

The question is not how do we centralize every wealth rule. It is :

Now that an AI capability behind the workstation participates in this determination, where does the policy authority live ?

Knowledge separates the two. The AI service investigates, gathers context, prepares the case. Knowledge determines what the AI capability is allowed to conclude before the workstation surfaces the outcome.

What Knowledge can be in your stack

Two shapes cover most Wealth deployments.

Wealth engagements often use both shapes at once.

The composite decision the AI capability navigates

Four dimensions typically shape the "can we propose this ?" determination.

Each of the four inputs may already have its own system of record : product master, CRM, suitability engine, portfolio engine, jurisdictional data. Knowledge does not replace them. It reads what they hold, applies the wealth policy that governs the composite, and returns a deterministic decision the workstation can act on.

Progressive context : the AI service investigates as policy asks

This is the operational shape that makes wealth interesting for an AI capability sitting behind a workstation.

The AI service does not need to fetch 47 fields up front. It starts with what it has ; Knowledge tells it what the applicable rules still need ; the service acquires each field (CRM lookup, portfolio call, LLM extraction from the case file, question surfaced back through the workstation), re-consults, iterates until a decision is reached.

Step 1. The AI service calls /resolve with what it already has (asset class, product type).

{ operation_status: "incomplete",
  required_context: [
    { field: "client.classification",
      reason: "required by rul-sp-elig-highly-complex",
      type: "enum",
      allowed_values: ["retail", "professional", "accredited"] },
    { field: "solicitation.type",
      reason: "required by rul-sp-crossborder-solicited",
      type: "enum",
      allowed_values: ["solicited", "reverse_enquiry"] }
  ] }

Step 2. The service fetches classification from the CRM and infers solicitation type from the case context, then re-calls /resolve.

{ operation_status: "incomplete",
  required_context: [
    { field: "client.knowledge_experience_level",
      reason: "required by rul-sp-elig-complex-ke-gate",
      type: "enum",
      allowed_values: ["insufficient", "sufficient"] }
  ] }

Step 3. The service fetches K&E level from the client dossier, then re-calls /resolve.

{ operation_status: "complete",
  verdict: "approval_required",
  cited_rules: ["rul-sp-elig-highly-complex-retail-notional",
                "rul-sp-crossborder-solicited-restricted"],
  signed_verdict: "eyJhbGciOiJFUzI1NiIsInR5cCI6ImdvdmVybmVkK2p3cyIsImtpZCI6...",
  consultation_id: "cns-..." }

The service does not encode which question comes next. Policy tells it. When compliance amends a rule and it starts requiring a new field, the next /resolve learns to fetch it, and only the fetcher needs to be added on the workstation-backend side. See Progressive context.

Four questions the AI capability should not answer from model judgment alone

Beyond the composite "can we propose this ?" decision, there are four related determinations the AI service may need. Each is a case where the deterministic policy authority should sit outside the model.

If your OMS or pre-trade engine already owns any of these decisions end-to-end, keep it there. Where the AI capability introduces a new boundary the existing systems do not cleanly cover, Knowledge governs it.

Compliance owns the policies delegated to Knowledge

Policies governing the AI capability's decision boundary can be versioned, approved and evolved independently of the AI service. Rules that remain owned by existing systems stay there.

Where Knowledge holds a rule, it lives in the back-office UI as a business-view object : scope (jurisdiction, asset class, client segment), conditions and thresholds, severity (allow / require approval / block / absolute ban), effective dates, rationale, approver. Compliance amends the threshold ; the next /resolve uses the new value. Prior consultations still point at the exact rule of their day, via immutable RuleVersion. See Auditability.

Insertion patterns

A wealth engagement typically inserts Knowledge in one of four ways.

Wealth decision pack

For a design-partner engagement, Asplenz ships a working starting point Compliance can calibrate against the firm's own policies :

Knowledge evaluates the institution's encoded policy. It does not replace the institution's regulatory judgment or execute the resulting business action. The pack does not ship regulatory interpretation ; it gives the bank a working shape to calibrate.

Start with one workstation decision

Pick one decision your AI service behind the workstation needs to make that is currently governed by human interpretation, fragmented procedures or custom agent logic. Run it in shadow mode against the current process. Cut over when parity and audit are proven.

Discuss your use case   ·   See pricing

Related