A fluent answer to an investor can look uncomfortably close to an instruction to act. That is a design problem, not a wording problem. A safe mutual-fund service separates four jobs: understand the request, provide permitted information, apply deterministic eligibility rules, and route only an approved transaction to the system of record.
KFintech’s September 2026 ARYA announcement makes that boundary concrete. The company describes a conversational investor-service platform whose transaction requests pass through deterministic compliance software, including identity and eligibility checks, before reaching its record system. Its announcement is a product claim—not evidence that a particular fund transaction is appropriate or that its controls meet a U.S. firm’s requirements. It is nonetheless a useful architecture signal: language models can organize a conversation while code, approved policy, and an accountable operating workflow decide whether any action may proceed.
This guide provides a conversation–rule–transaction gate record and a copyable prompt for U.S.-oriented product, operations, and compliance teams. It does not provide investment advice, determine suitability, or replace a fund’s transfer agent, broker-dealer, adviser, or legal obligations.
Why a mutual-fund answer needs a separate action gate
Investor service starts with ordinary requests:
- “Which statement covers my last contribution?”
- “Can I start or change a systematic investment plan?”
- “Why is this redemption still pending?”
- “I want to put another $5,000 into the fund we discussed.”
Those requests do not carry the same consequences. A statement question may be answerable from approved records. A transaction request can require authenticated identity, current account state, product availability, required disclosures, and a separate authorization path. A model should never infer the missing pieces because a customer used confident language.
KFintech’s released materials distinguish natural-language conversation from deterministic handling of transaction requests. They say that self-hosted small language models handle the conversational layer while deterministic software handles intent routing, compliance gating, identity-related checks, and transaction execution. They also describe certain transaction journeys as live testing rather than a blanket launch. Treat vendor statements as inputs to diligence; do not copy their performance figures or infer that a capability is available in a particular market.
The principle is broader than one platform:
Conversation → intent classification → policy decision → approved transaction route
(AI may assist) (deterministic) (system of record)The arrow must be one-way. An answer can explain what is missing. It must not convert a vague or incomplete conversation into an order.
The conversation–rule–transaction gate record
Use one immutable record for each request that might produce a service or transaction action. Do not put account numbers, credentials, or unnecessary personal data in a general-purpose prompt.
| Field | What to capture | Gate result when missing or inconsistent |
|---|---|---|
| Request reference | Opaque request ID, timestamp, channel, and authorized account reference | ASK_FOR_INFORMATION |
| Intent class | INFORMATION, SERVICE_REQUEST, TRANSACTION_INTENT, or BLOCKED_OR_UNKNOWN | HUMAN_REVIEW for ambiguous classification |
| Permitted answer scope | Approved facts, source record IDs, as-of time, and disclosure copy | INFORMATION_ONLY |
| Action eligibility | Required identity result, account status, product and policy checks | HOLD if any predicate is unknown |
| Rule evidence | Policy/rule version, each deterministic predicate, and reason codes | HOLD if a version or result is absent |
| Transaction envelope | Explicit action type, account reference, amount or quantity if authorized, expiration, and destination system | Never build it from an unverified chat message |
| Human boundary | Named queue or approver for exceptions and high-impact actions | HUMAN_REVIEW when the route is required |
| Outcome | INFORMATION_ONLY, ASK_FOR_INFORMATION, HUMAN_REVIEW, READY_FOR_SYSTEM_ROUTE, or BLOCKED | Log the reason and next owner |
READY_FOR_SYSTEM_ROUTE is deliberately narrow. It does not mean “investment approved,” “suitable,” or “executed.” It means a non-LLM policy service has found every required input and may pass a bounded request to the authorized system. That system still owns its own confirmation, recordkeeping, and execution controls.
This mirrors the boundary in AI and Banking: PicPay vs ChatGPT Finances: reading account data, interpreting it, and moving money are separate permissions. It also extends the evidence discipline in AI Financial Analysis Controls from a report to a customer-service action path.
A copyable prompt for investor-service intent routing
Use this prompt only with approved, minimized data and a separate deterministic policy service. The model must not call a transfer, trade, redemption, or account-change tool.
You are an investor-service routing assistant. You are not an investment adviser,
compliance engine, transaction executor, or authorization service.
Use only the supplied approved facts. Never infer identity, eligibility, product
availability, account authority, investment suitability, or a transaction amount.
Never recommend a fund, predict returns, or create an executable transaction.
INPUTS
- request_id: [opaque identifier]
- customer_message: [minimized text]
- authenticated_context: [approved boolean and scope only]
- approved_facts: [source IDs, as-of time, permitted account/service facts]
- policy_snapshot: [rule version and allowed intent classes]
- deterministic_gate_result: [ALLOW | HOLD | DENY | NOT_RUN plus reason codes]
PROCESS
1. Classify the message as exactly one of INFORMATION, SERVICE_REQUEST,
TRANSACTION_INTENT, or BLOCKED_OR_UNKNOWN.
2. List the facts used by source ID and any material missing information.
3. Draft only a permitted informational response or a request for the missing
information. Do not restate a transaction as an order.
4. Map the deterministic gate result to exactly one outcome:
- INFORMATION_ONLY: the message needs no action;
- ASK_FOR_INFORMATION: required facts are absent;
- HUMAN_REVIEW: a policy exception or ambiguity exists;
- READY_FOR_SYSTEM_ROUTE: deterministic_gate_result is ALLOW and every
required field is supplied by an approved source;
- BLOCKED: deterministic_gate_result is DENY or the request is prohibited.
5. If the gate was not run, unknown, or inconsistent with the conversation,
choose HUMAN_REVIEW. Never choose READY_FOR_SYSTEM_ROUTE.
RETURN VALID JSON ONLY
{
"request_id": "",
"intent_class": "",
"facts_used": [{"source_id": "", "as_of": ""}],
"missing_information": [],
"policy_version": "",
"gate_result": "",
"reason_codes": [],
"outcome": "",
"permitted_response": "",
"human_owner_or_queue": "",
"system_route_allowed": false
}Validate the returned JSON outside the model. Treat malformed fields, invented source IDs, a missing policy version, or system_route_allowed: true without an ALLOW result as a failed gate.
Make repeatability testable
The useful test is not whether a chatbot sounds consistent. It is whether the same normalized request and rule version produce the same control outcome.
| Test | Setup | Expected result |
|---|---|---|
| Informational request | A dated statement question with verified scope | INFORMATION_ONLY; every claim cites an approved fact |
| Ambiguous action | “Add more to the fund” with no authenticated context or amount | ASK_FOR_INFORMATION or HUMAN_REVIEW, never an action route |
| Gate unavailable | A valid-looking transaction request with NOT_RUN | HUMAN_REVIEW; no transaction envelope |
| Rule denial | The gate returns DENY with a reason code | BLOCKED; response does not suggest a workaround |
| Same request replay | Same normalized input, policy version, and deterministic facts | Same intent class, outcome, reason codes, and route decision |
| Policy update | Identical request with a changed policy version | New result is logged as a distinct decision; do not overwrite the prior record |
Run this suite at release time and whenever a model, retrieval source, classifier, rule set, or transaction connector changes. The banking-agent red-team test harness is useful for adversarial conversation and tool-use tests; this smaller suite focuses specifically on the boundary between a service response and a transaction route.
Decisions that fail closed
Three design choices prevent a conversational convenience feature from becoming uncontrolled execution.
The model cannot upgrade its own authority
The model may label a message TRANSACTION_INTENT, but only a separate, versioned rule service can return ALLOW. A fluent explanation, a user’s apparent urgency, or an earlier chat turn must not substitute for that result.
The action is bounded and expires
If a downstream route is permitted, bind it to the exact action type, authorized account reference, reviewed facts, policy version, and an expiry. A generic “continue” token should not become a reusable mandate.
Unknown is an operating state
An outage, stale account fact, disputed identity result, or conflicting rule is not a reason to guess. It is a reason to hold the request, preserve the evidence, and route it to an accountable person. For an operational recovery workflow after a shared provider failure, use the AI Outage Recovery Drill for Financial Services.
Metrics that measure the gate—not investment outcomes
Do not measure this control with returns, sales, or completion volume alone. Start with reviewable operating metrics:
- unsupported-route rate: share of attempted system routes without every required gate field; the target should be zero;
- unknown-to-hold rate: share of intentionally incomplete tests correctly routed away from action;
- rule-version coverage: share of gate records with a retrievable policy version and reason code;
- replay consistency: share of identical normalized requests that return the same control outcome under the same rule version;
- exception ownership: share of
HUMAN_REVIEWrecords with a named queue and resolution reference; and - stale-fact rate: share of routes stopped because a required approved fact exceeded the product’s freshness policy.
These metrics describe control behavior, not the quality of an investment or the suitability of a fund for a particular investor.
Keep the investment decision outside the chat
A mutual-fund service assistant can reduce friction without turning a conversation into a recommendation or an order. Its most valuable answer may be: “Here is the approved information, here is what is missing, and this request cannot move forward until the separate control has passed.”
For a retail investor’s own research before confirming an order, use the distinct AI Investing Decision Card. It addresses source-backed research and the investor’s confirmation boundary; this gate record addresses institutional investor servicing and transaction routing.
Sources
- KFintech: ARYA press release and investor filing
- KFintech: ARYA press-release PDF
- NIST: AI Risk Management Framework
- FINRA Rule 2214: Investment analysis tools
About Enis
AI Engineer specializing in Machine Learning and LLMs. Combining Computer Engineering and Economics to build data-driven financial tools.