Multi-Custodian Data: An AI Provenance Contract

A wealth-management AI system can produce a polished answer from the wrong account, yesterday’s holdings, an unreconciled transaction, or a partial household view. In that case, improving the model will not solve the problem. The error occurred before the prompt began.

Multi-custodian firms combine position, transaction, cash, cost-basis, account, CRM, planning, and market data from systems with different identifiers and delivery schedules. Advisor360’s August 2026 platform release emphasized proactive AI and multi-custodian connectivity on a unified data layer. The product direction is important: useful advisor intelligence depends on data the firm already trusts.

The practical implementation question is more specific: what must be true about a data point before an AI system is allowed to use it?

This guide defines a provenance contract, a pre-answer prompt, and tests for stale, conflicting, and incomplete custodian data.

What is custodian data aggregation?

Custodian data aggregation combines data from multiple custody platforms into a normalized view. A production system may ingest:

accounts and registrations;
positions and tax lots;
settled and pending transactions;
cash and sweep balances;
corporate actions;
fees and billing data;
security masters and prices; and
household and advisor mappings.

Aggregation is not the same as reconciliation. A feed can load successfully while remaining incomplete, duplicated, stale, or inconsistent with another source. An AI system needs the reconciliation state, not only the value.

Why multi-custodian AI needs data provenance

Data provenance records where a value came from and what happened to it. For an AI-generated advisor insight, the minimum chain is:

source system
  → source account and record
  → ingestion event
  → normalization rule
  → reconciliation result
  → household/portfolio mapping
  → model input snapshot
  → generated claim

Without this chain, a reviewer cannot answer basic questions:

Which custodian supplied the position?
What was the source timestamp?
Was the transaction settled?
Was the price official, estimated, or missing?
Did a transformation change units or currency?
Was the value reconciled before the model saw it?
Which output sentences depend on it?

A minimum provenance contract for wealth-management AI

Every material model input should carry structured metadata.

Field	Purpose
`tenant_id`	Prevent cross-firm mixing
`household_id`	Define client-level scope
`account_id`	Identify the exact account
`custodian_id`	Identify the supplying institution
`source_record_id`	Trace back to the original record
`source_as_of`	State when the source value was effective
`ingested_at`	State when the platform received it
`reconciliation_status`	Mark verified, pending, conflict, or failed
`valuation_status`	Mark official, estimated, stale, or missing
`currency`	Prevent silent currency errors
`transformations`	Record normalization and derived calculations
`allowed_uses`	Limit reporting, research, communication, or action

Example JSON data contract

{
  "tenant_id": "RIA-42",
  "household_id": "HH-104",
  "account_id": "ACC-8801",
  "custodian_id": "CUST-A",
  "source_record_id": "POS-20260826-771",
  "asset_id": "SEC-00991",
  "quantity": 125.0,
  "market_value": 18450.00,
  "currency": "USD",
  "source_as_of": "2026-08-26T21:00:00Z",
  "ingested_at": "2026-08-27T02:14:06Z",
  "reconciliation_status": "VERIFIED",
  "valuation_status": "OFFICIAL_CLOSE",
  "transformations": ["CUSIP_TO_INTERNAL_SECURITY_ID"],
  "allowed_uses": ["INTERNAL_RESEARCH", "CLIENT_REPORT_DRAFT"]
}

The contract should be enforced by schema validation and policy code. A language model may explain the fields; it should not decide whether missing provenance is acceptable.

A pre-answer data provenance prompt

Use this prompt as a gate before a separate model drafts an insight.

You are validating a multi-custodian data snapshot for an advisor-facing AI
workflow. Do not analyze portfolio performance or produce client commentary.

For every account and material data element, verify:
1. tenant, household, account, custodian, and source-record identifiers exist;
2. source_as_of and ingested_at are present and within the workflow's freshness
   threshold;
3. reconciliation_status is VERIFIED;
4. valuation status and currency are explicit;
5. transformations are documented;
6. the proposed use is included in allowed_uses;
7. household coverage is complete for the question being asked.

Return one of:
- PASS: snapshot may proceed to analysis;
- PARTIAL: analysis may proceed only with named scope limitations;
- BLOCK: missing, stale, conflicting, unreconciled, or unauthorized data.

List every failed rule with account_id, source_record_id, severity, and required
remediation. Never replace missing data with an estimate.

How to resolve conflicting custodian data

Do not ask the model to choose the value that “looks right.” Use deterministic precedence and an exception queue.

Preserve both source records.
Compare effective time, ingestion time, settlement state, and adjustment status.
Apply documented source-of-record rules by data type.
Recalculate normalized values.
Route unresolved differences to operations.
Mark downstream snapshots invalid until the conflict is resolved or explicitly waived by an authorized owner.

The exception record should show the competing values and the rule used to resolve them.

Portfolio data freshness rules

“Latest” is not a usable control. Define freshness by workflow and data type.

A quarterly review may tolerate previous-close positions.
An intraday cash question may require a newer feed.
A tax-lot decision may require settled transaction and adjusted cost-basis data.
A household allocation view may be unusable if one custodian has not delivered its file.

Return the actual timestamp and status in the answer. Never hide a stale source behind the date on which the model generated its response.

Six multi-custodian data test scenarios

1. Late feed

One custodian’s daily file is missing. A household-level allocation answer should block or declare the missing account scope.

2. Duplicate transaction

The same transfer appears in an initial file and an adjustment file. The pipeline should detect the source relationship rather than double-count cash.

3. Security identifier mismatch

Two custodians use different identifiers for the same asset. The normalized security master should join them without losing the source IDs.

4. Currency ambiguity

A market value arrives without currency. The system should block aggregation instead of assuming the household base currency.

5. Pending corporate action

A split or distribution is not final. The system should label the affected quantity and valuation as provisional.

6. Unauthorized downstream use

Data licensed for internal research is requested for a client-facing document. The policy layer should deny the use even when the data itself is accurate.

Metrics for custodian data aggregation and AI

Track:

on-time feed rate by custodian;
completeness by account and data type;
reconciliation exception count;
mean time to resolve conflicts;
stale-data block rate;
percentage of AI claims linked to source records;
household coverage at generation time;
unauthorized-use attempts; and
corrections after client or advisor review.

These measures reveal whether the AI is grounded in decision-ready data, not merely whether the pipeline is running.

Data lineage versus data provenance in wealth management

The terms are related but answer different questions. Data lineage describes the path and transformations that move data through the platform. Data provenance supplies the evidence needed to establish origin, identity, time, ownership, and fitness for a particular use.

For example, lineage may show that a market value came from a custodian position file, passed through a security-master mapping, received a closing price, and entered a household aggregate. Provenance adds the source record, effective time, reconciliation status, transformation version, responsible data owner, and allowed use.

An AI workflow needs both. Lineage helps engineers debug the pipeline. Provenance helps an advisor or reviewer decide whether a generated claim is supportable.

Common multi-custodian data failures

Household mapping drift

An account may be assigned to the wrong household after a migration, merger, or manual change. A technically accurate position then appears in the wrong client view. Monitor mapping changes separately from position changes and require dual review for material household transfers.

Partial-day inconsistency

One source may provide intraday cash while another provides previous-close positions. Combining them creates a view with no coherent as-of time. Preserve timestamps by data type and label mixed-time snapshots explicitly.

Adjustment-file duplication

Some custodians send corrected or supplemental records rather than full replacement files. Without source-aware deduplication, the platform may count a transaction or position twice. Store file lineage and adjustment relationships.

Silent default values

Missing prices, currencies, classifications, or cost basis may be replaced by zero, a previous value, or a platform default. Every imputation must be explicit. Client-facing and action-supporting AI should normally block rather than silently substitute.

Reconciliation after generation

If the platform generates commentary before reconciliation finishes, the output can remain available after its inputs become invalid. Tie every output to a snapshot ID and invalidate downstream artifacts when the snapshot status changes.

Implementation sequence for a single source of truth

Inventory every custodian, CRM, planning, market-data, and manual source.
Define canonical identifiers for tenant, household, account, person, security, and transaction.
Record source timestamps separately from ingestion timestamps.
Establish deterministic normalization and reconciliation rules.
Add freshness thresholds by workflow and data type.
Attach allowed-use policy to sensitive or licensed data.
Create immutable snapshot IDs for every AI task.
Require claim-to-source references in generated output.
Build an exception queue with named operational owners.
Re-run regression tests whenever a feed, schema, mapping rule, or model changes.

Start with one bounded question, such as previous-close household allocation. Do not begin with a universal advisor assistant that silently combines every available source.

The practical takeaway

A unified data platform becomes useful to AI only when every material value carries identity, time, source, reconciliation, transformation, and use rights. The model should receive a frozen, validated snapshot—not an undocumented collection of “latest” values.

For broader numerical and evidence checks, see AI Financial Analysis Controls. For system reliability patterns, see Engineering Financial Systems.

Sources

This article is an educational technology framework, not investment, legal, or regulatory advice.

#multi-custodian#data-provenance#wealth-management-ai#custodian-data-aggregation#data-lineage