Laissez les workflows wealth AI-powered investiguer la suitability. Gardez la policy de distribution hors du modèle.

La nouvelle frontière de décision qu'un workflow wealth AI-powered introduit

Le RM est dans son workstation, au milieu d'une conversation client. Il sélectionne un candidat de note structurée et clique sur « Check suitability ».

Avant les agents, ce bouton appelait soit un moteur suitability fixe soit déclenchait une desk review manuelle. La détermination était possédée end-to-end par un système unique ou un process humain.

Avec un service IA qui participe derrière le bouton, la détermination se construit maintenant par le modèle. Il fetche les données produit, lit le profil client, extrait des faits depuis la conversation et le dossier, et construit la vue composite : éligibilité produit, suitability, cross-border, concentration.

Le RM voit un résultat native de l'application.

Il n'a pas besoin de savoir qu'un agent a tourné derrière le workstation. Le workstation, le CRM, l'UI d'order entry restent exactement comme ils sont.

La question n'est pas comment centraliser toutes les règles wealth. Elle est :

Maintenant qu'une capability IA derrière le workstation participe à cette détermination, où vit l'autorité policy ?

Knowledge sépare les deux. Le service IA investigue, rassemble le contexte, prépare le cas. Knowledge détermine ce que la capability IA est autorisée à conclure avant que le workstation ne surface le résultat.

Ce que Knowledge peut être dans votre stack

Deux formes couvrent la plupart des déploiements Wealth.

Les engagements Wealth utilisent souvent les deux formes en même temps.

La décision composite que la capability IA navigue

Quatre dimensions shapent typiquement la détermination « pouvons-nous proposer ceci ? ».

Chacun des quatre inputs peut déjà avoir son propre système de record : product master, CRM, moteur suitability, moteur portefeuille, données juridictionnelles. Knowledge ne les remplace pas. Il lit ce qu'ils tiennent, applique la policy wealth qui gouverne le composite, et retourne une décision déterministe sur laquelle le workstation peut agir.

Progressive context : le service IA investigue à mesure que la policy demande

C'est la forme opérationnelle qui rend le wealth intéressant pour une capability IA sise derrière un workstation.

Le service IA n'a pas besoin de fetcher 47 champs d'entrée. Il démarre avec ce qu'il a ; Knowledge lui dit ce que les règles applicables exigent encore ; le service acquiert chaque champ (lookup CRM, appel portefeuille, extraction LLM depuis le dossier, question remontée à travers le workstation), re-consulte, itère jusqu'à ce qu'une décision soit atteinte.

Étape 1. Le service IA appelle /resolve avec ce qu'il a déjà (asset class, type de produit).

{ 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"] }
  ] }

Étape 2. Le service récupère la classification depuis le CRM et infère le type de solicitation depuis le contexte du cas, puis rappelle /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"] }
  ] }

Étape 3. Le service récupère le niveau K&E depuis le dossier client, puis rappelle /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-..." }

Le service n'encode pas quelle question vient ensuite. La policy le lui dit. Quand compliance amende une règle et qu'elle commence à exiger un nouveau champ, le prochain /resolve apprend à le fetch, et seul le fetcher doit être ajouté côté backend du workstation. Voir Progressive context.

Quatre questions que la capability IA ne devrait pas répondre depuis le jugement du modèle seul

Au-delà de la décision composite « pouvons-nous proposer ceci ? », il y a quatre déterminations liées dont le service IA peut avoir besoin. Chacune est un cas où l'autorité policy déterministe devrait vivre hors du modèle.

Si votre OMS ou moteur pre-trade possède déjà une de ces décisions end-to-end, gardez-la là. Là où la capability IA introduit une nouvelle frontière que les systèmes existants ne couvrent pas proprement, Knowledge la gouverne.

Compliance possède les policies déléguées à Knowledge

Les policies gouvernant la frontière de décision de la capability IA peuvent être versionnées, approuvées et évoluées indépendamment du service IA. Les règles qui restent possédées par les systèmes existants y restent.

Là où Knowledge tient une règle, elle vit dans l'UI back-office comme un objet business-view : scope (juridiction, asset class, segment client), conditions et thresholds, severity (allow / require approval / block / absolute ban), dates d'effet, rationale, approver. Compliance amende le threshold ; le prochain /resolve utilise la nouvelle valeur. Les consultations antérieures pointent toujours sur la règle exacte de leur jour, via RuleVersion immuable. Voir Auditability.

Patterns d'insertion

Un engagement wealth insère typiquement Knowledge d'une de quatre façons.

Pack de décision Wealth

Pour un engagement design-partner, Asplenz ship un point de départ opérationnel que Compliance peut calibrer contre les policies propres de la firme :

Knowledge évalue la policy encodée de l'institution. Il ne remplace pas le jugement réglementaire de l'institution ni n'exécute l'action métier qui en résulte. Le pack ne livre pas d'interprétation réglementaire ; il donne à la banque une forme opérationnelle à calibrer.

Commencer par une décision workstation

Pickez une décision que votre service IA derrière le workstation doit prendre qui est actuellement gouvernée par de l'interprétation humaine, des procédures fragmentées ou de la logique d'agent custom. Faites-la tourner en shadow mode contre le process actuel. Cutoverez quand la parité et l'audit sont prouvés.

Discuter de votre use case   ·   Voir pricing

Related