Skip to main content

Wealth Management AI: Blocking Unauthorized Financial Advice at the Gateway

The safest baseline for wealth management AI is simple: treat educational content as acceptable, treat personalized recommendation language as controlled, and put the enforcement point at the gateway instead of in prompt wording. Keeptrusts supports that model with financial-compliance for output-language controls, mnpi-filter for obvious non-public output phrases, pii-detector for client identifiers, rbac for adviser identity, and exportable decision events for review. That does not replace suitability review, licensing obligations, or fiduciary oversight, but it does stop a lot of avoidable risk from escaping through draft emails, assistant chat, or portfolio-commentary tools.

Use this page when​

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, AI Agents

The problem​

Wealth management assistants often start as harmless drafting tools. An adviser asks for a client-ready summary of market moves. A support user asks the assistant to explain a model portfolio change. A portfolio team uses AI to turn research notes into plain-language commentary. Those use cases are productive, but they have a habit of crossing into personalized recommendation territory without an explicit decision to do so.

This is exactly where the Financial Compliance policy becomes operationally useful. It gives you a place to block configured phrases and prepend disclaimers when output looks like advice. That is not the same thing as suitability review, and it does not know whether a recommendation fits a particular client. What it can do is prevent the most obvious forms of unauthorized recommendation language from leaving the gateway unchecked.

Wealth workflows also carry two other risks. The first is client-data exposure. Portfolio commentary and support conversations frequently contain account identifiers, household details, or internal book references that do not need to reach the model in raw form. The second is non-public research or issuer information. If the assistant can see unpublished research notes or restricted commentary, you need to worry about MNPI-adjacent output as well as plain customer privacy.

Finally, there is an operational question about scale. Wealth teams often roll out many small assistants: adviser note drafting, performance commentary, internal knowledge search, operations support, and service workflows. Without budget ownership and route-level policy differences, those assistants become hard to govern. That is why Spend & Wallets belongs in the conversation alongside content controls.

The solution​

The working pattern is to separate recommendation control, data minimization, and routing.

Use financial-compliance as your first output-language gate. Populate blocked_patterns with phrases that should never appear in client-facing or adviser-assist output and keep the disclaimer text short and unambiguous. This is a strong fit for wealth management because many risky failures are language failures before they are anything else.

Use mnpi-filter as a second output-side control where restricted research or issuer-sensitive language could leak into drafts. The current implementation is phrase-based and output-only, so it should be viewed as a last gate, not as a substitute for controlling the prompt inputs advisers can send.

Use pii-detector and rbac on the way in. pii-detector handles client and account identifiers, while rbac helps you separate licensed advisers, support staff, analysts, and service channels. That matters because not every role should get the same tool access or the same assistant route.

For multi-jurisdiction books, use region-specific gateways and Data Routing Policy backed by provider data_policy metadata. That is the accurate path for multi-jurisdiction routing if your wealth business spans different residency or provider constraints.

Implementation​

This example is a practical starting point for an adviser-assist or portfolio-commentary route where client-facing output must stay inside a narrow compliance boundary.

pack:
  name: wealth-adviser-assist
  version: 1.0.0
  enabled: true

policies:
  chain:
    - rbac
    - pii-detector
    - mnpi-filter
    - financial-compliance
    - audit-logger

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
    require_auth: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'CLIENT-[A-Z0-9]{8}'
      - 'ACCOUNT-[0-9]{8,12}'
    redaction:
      marker_format: label
      include_metadata: true

  mnpi-filter:
    detect_patterns:
      - earnings before announcement
      - merger not public
      - insider information
      - board decision

  financial-compliance:
    blocked_patterns:
      - you should buy
      - you should sell
      - strong buy
      - strong sell
      - guaranteed return
    required_disclaimers:
      - This is not financial advice.
      - Consult a qualified financial advisor before making investment decisions.

  audit-logger: {}

There are two practical reasons this works well in wealth management.

The first is that it gives you a controlled middle ground. You do not have to ban drafting assistants outright, but you also do not have to trust them with unconstrained recommendation language.

The second is that it makes review easier. When advisers complain that the assistant "got blocked for no reason," you can look at a defined phrase list, a specific policy outcome, and a known route. That is much easier to operate than endless prompt tweaking.

If you want a short validation loop before a wider rollout, use this:

kt policy lint --file ./wealth-adviser-assist.yaml
kt gateway run --policy-config ./wealth-adviser-assist.yaml --port 41002
kt events tail --policy financial-compliance
kt export create --format json --filter "policy=financial-compliance,audit-logger"

That is enough to confirm the route lints, runs, produces policy events, and exports the evidence your supervisors or compliance reviewers will eventually ask for.

Results and impact​

The main impact is fewer avoidable language failures in production workflows.

  • Client-facing or adviser-facing draft output is less likely to contain prohibited recommendation phrases because financial-compliance evaluates the response before delivery.
  • Obvious non-public phrases have a second output gate through mnpi-filter, which is useful on research-adjacent commentary routes.
  • Client identifiers are less likely to leave your boundary in raw form because pii-detector can sanitize them on the way in.
  • Route ownership becomes clearer when you pair adviser-assist rollouts with Spend & Wallets, especially for firms that stand up multiple small wealth copilots at once.

For operators, that means less time rewriting risky drafts by hand and more time deciding which assistant routes deserve expansion. The point is not to automate fiduciary judgment. The point is to keep the obvious mistakes from becoming delivered content.

Key takeaways​

  • Use Financial Compliance to control recommendation-style output language at the gateway.
  • Use MNPI Filter as an output-side backstop for restricted language, not as a full prompt-side confidentiality program.
  • Use pii-detector and rbac so adviser-assist routes are both minimized and attributable.
  • Handle multi-jurisdiction routing through deployment topology plus Data Routing Policy.
  • Pair assistant rollout with Spend & Wallets so wealth copilots have explicit cost ownership as well as compliance controls.

Next steps​