A unified client record can still contain incompatible facts
An advisor may see a household’s retirement goal, a private-market capital call, an insurance premium, and a cash-flow projection in one workspace. That is useful only if the relationship among those records stays explicit. A current commitment can make an older liquidity assumption unusable; a policy change can make a coverage assumption stale; a document can be newer than the field copied from it.
Ebix says its September 2026 Meridian launch brings client management, financial planning, private markets, and insurance advisory together in a single environment. Its announced private-market workflow includes commitments, capital calls, distributions, tax workflows, and positions flowing into financial-plan analysis. That is a concrete example of a broader design problem: a shared household record does not decide which fact controls a planning calculation. Read the announcement.
Do not ask AI to smooth over the inconsistency with a plausible recommendation. Ask it to produce a client-plan conflict card. The card separates supplied evidence, conflicting values, calculations that require a rerun, and the person who may decide what happens next.
This differs from an auditable meeting-to-CRM workflow, which turns an advisor conversation into controlled record proposals. Here, the issue is not whether a field was extracted correctly. It is whether records that may each be correct can safely support the same household plan.
Start with a conflict taxonomy, not a generic alert
An alert that says “review client data” leaves the advisor with the original reconciliation task. A useful card names the conflict, establishes an authority order, and limits the automated action.
| Conflict type | Example | What the card must show | Default AI outcome |
|---|---|---|---|
| Freshness | A signed capital-call notice is newer than a planning cash balance | Both timestamps, source documents, and field owners | RERUN_REQUIRED |
| Scope | A retirement plan models liquid assets, while the dashboard includes restricted private holdings | Calculation scope and inclusion rule | RERUN_REQUIRED |
| Commitment | A projected commitment differs from a confirmed obligation | Client authorization, amount, schedule, and legal entity | HUMAN_DECISION_REQUIRED |
| Coverage | An insurance policy record and the needs analysis use different benefit or premium terms | Policy version, assumptions, and missing evidence | MORE_EVIDENCE_REQUIRED |
| Ownership | A household-level plan uses an asset held by another owner or trust | Registered owner, beneficiary, and plan treatment | DO_NOT_PROCEED |
The taxonomy is deliberately about record relationships, not investment selection. It lets a team test a system without asking a model to interpret suitability, legal ownership, or policy language beyond the evidence it has been given.
Define the authority order before the model sees a case
The firm, not the model, should define which source can establish each kind of fact. For example, a signed client authorization may control a commitment status; an executed policy document may control coverage terms; a planning assumption may describe a scenario but cannot overwrite either.
For every record in the card, retain:
- source system and immutable document or record identifier;
- source timestamp and the time the record entered the planning workflow;
- field name, value, currency, owner, and confidence of extraction;
- whether the value is confirmed, proposed, illustrative, or unresolved; and
- the calculation, report, or client communication that depends on it.
That discipline supports the kind of evidence and review separation used in an AI portfolio-commentary validation workflow. A fluent answer may correctly summarize a document while still being the wrong basis for a client-facing planning statement.
The SEC’s investment-adviser fiduciary interpretation describes duties of care and loyalty under the Advisers Act. Broker-dealer workflows can also have separate suitability obligations, such as FINRA Rule 2111. Those are not a shortcut to a universal rules engine. Have counsel and compliance determine the authority hierarchy, disclosures, and approvals applicable to the firm and account.
The client-plan conflict card
Create one card per decision boundary, not one giant household exception report. A decision boundary might be: “May the advisor discuss an updated retirement projection before the next capital-call requirement is resolved?”
card_id: CPC-2026-0910-014
decision_boundary: "Discuss updated retirement projection"
client_or_household_id: "internal-reference-only"
status: RERUN_REQUIRED
authoritative_records:
- type: capital_call_notice
source_id: DOC-884
captured_at: "2026-09-08T14:12:00Z"
fact: "Capital call due"
value: "25000 USD"
certainty: CONFIRMED
owner: alternatives_operations
- type: retirement_projection
source_id: PLAN-220
captured_at: "2026-08-31T09:00:00Z"
fact: "Available cash before reserve"
value: "60000 USD"
certainty: ILLUSTRATIVE
owner: lead_advisor
conflict:
type: FRESHNESS_AND_SCOPE
description: "Projection does not show whether the confirmed call is reserved."
affected_calculations:
- cash_flow_projection
- liquidity_reserve
prohibited_actions:
- send_client_projection
- change_investment_instruction
required_next_step: "Rerun with documented reserve treatment."
human_decision_owner: lead_advisor
evidence_gap_owner: alternatives_operationsThe card has no recommendation field. It may identify an affected calculation and an authorized reviewer, but it must not infer what the client should buy, sell, contribute, or surrender. That boundary also makes it safer to link the card to a financial research data-control contract: access to a record does not make the agent authorized to resolve the record’s business meaning.
Use three gates: reconcile, rerun, release
1. Reconcile the factual record
Compare the governing documents and system records side by side. Preserve the original values. If the conflict arises from a data feed, assign an owner to determine whether the feed, a mapping, or the source record is wrong. A model should flag an inconsistency; it should not silently select the value that makes the plan look most favorable.
2. Rerun only the affected planning logic
State the exact inputs and assumptions that must be recalculated: available cash, liquidity reserve, expected contribution capacity, projected premium, taxable distribution, or another defined factor. Capture the software version, calculation date, input set, and reviewer. The output should be a comparison of scenarios, not a prediction or client recommendation.
3. Release only reviewed client-facing work
Before a projection, note, or task moves to a client workflow, confirm that the conflict status is resolved or that the communication expressly frames the item as an open question. Keep client-facing drafting separate from approval, just as a reconciliation exception handoff separates detection from firm-authorized closure.
Copyable prompt for the conflict card
Use this prompt only with records the firm has approved for the task. Remove direct identifiers when an internal test can use realistic masked values.
You are preparing a client-plan conflict card for a financial-advisor workflow.
You do not give investment, tax, insurance, legal, or suitability advice. You do
not send messages, change records, execute transactions, or resolve conflicts.
Use only the supplied evidence. Do not infer missing facts. Treat signed or
otherwise designated authoritative records according to the firm's supplied
authority policy. Preserve competing values even if one appears more likely.
For each possible conflict, return:
1. CARD_STATUS: NO_CONFLICT, MORE_EVIDENCE_REQUIRED, RERUN_REQUIRED,
HUMAN_DECISION_REQUIRED, or DO_NOT_PROCEED.
2. DECISION_BOUNDARY: the specific client or operational action affected.
3. EVIDENCE_TABLE: source ID, timestamp, field, value, certainty, and owner.
4. CONFLICT: type, conflicting values, and why they cannot be combined.
5. AFFECTED_CALCULATIONS: named calculations and inputs to refresh; never
calculate an outcome unless all inputs and method are provided.
6. PROHIBITED_ACTIONS: communications, record changes, or transactions that
must remain blocked.
7. HANDOFF: required reviewer role, evidence-gap owner, and next action.
Rules:
- A plan assumption is not proof of a client commitment or insurance term.
- A document extraction score is not proof that the extracted fact is current.
- If ownership, authorization, policy version, or timing is uncertain, return
MORE_EVIDENCE_REQUIRED or DO_NOT_PROCEED.
- Never choose a financial product, tell the client what to do, or draft a
conclusion that the client is approved, covered, or financially on track.
- Cite the exact supplied source ID for every factual statement.Test the workflow before relying on it
Use controlled test cases with an expected status. The goal is not to reward a model for confidence; it is to catch an unsafe release path.
| Test case | Expected status | Failure to catch |
|---|---|---|
| Capital-call document postdates the cash-flow run | RERUN_REQUIRED | Model treats an old projection as current |
| Policy schedule conflicts with a manually entered premium | MORE_EVIDENCE_REQUIRED | Model picks the lower payment without source authority |
| A private holding is held by a trust outside plan scope | DO_NOT_PROCEED | Model counts it as household liquidity |
| Client verbally considers a commitment but has not authorized it | HUMAN_DECISION_REQUIRED | Model converts a tentative statement into a fact |
| All source IDs, timestamps, and scope rules match | NO_CONFLICT | Model invents an exception from missing context |
Log the prompt version, supplied evidence IDs, model version, expected status, returned status, reviewer disposition, and any corrected rule. The NIST AI Risk Management Framework is a useful voluntary reference for organizing this kind of governed, measured, and monitored AI use.
Keep the decision human and the evidence portable
A conflict card does not replace a financial plan, an insurer’s underwriting process, an operations review, or client consent. It makes one narrow question auditable: which facts conflict, which calculation must be refreshed, and who is accountable for the release decision.
That makes the artifact useful even when systems change. A new CRM, planning tool, private-market administrator, or AI assistant can consume the same card as long as source references and approval rules remain portable. The safest success condition is modest: the team can show why a client-facing workflow was paused, rerun, or released—and can reproduce that answer from the evidence.
Sources
- Ebix launches Ebix Meridian for U.S. financial advisory firms
- SEC Commission Interpretation Regarding Standard of Conduct for Investment Advisers
- FINRA Rule 2111: Suitability
- NIST AI Risk Management Framework
This article provides an educational workflow framework, not investment, legal, tax, insurance, compliance, or regulatory advice. Apply firm policies and obtain qualified review before using AI with client records or client-facing planning work.
About Enis
AI Engineer specializing in Machine Learning and LLMs. Combining Computer Engineering and Economics to build data-driven financial tools.