What is data reconciliation in wealth management?
Aggregation collects wealth data. Reconciliation checks whether comparable records agree. Learn how timing, scope, and unresolved differences affect its use.
Data reconciliation in wealth management is the process of comparing records that should describe the same financial activity or position, investigating differences, and documenting whether the data is fit for its intended use. It can involve custodian records, portfolio accounting, cash balances, transactions, and other sources used by the firm.
Aggregation brings those records together. Reconciliation asks whether they agree on a comparable basis. A connected dashboard can display data without proving that its underlying records have been reconciled.
For operations and technology leaders, the useful question is specific. Which accounts and fields were compared, for what date, against which source, and what remains unresolved?
Aggregation, normalization, reconciliation, and validation
These terms describe different work, even when a platform combines them.
- Aggregation collects records. It brings data from multiple providers into a dataset or view.
- Normalization aligns representations. It maps identifiers, formats, currencies, and transaction types so records can be compared without changing their meaning.
- Reconciliation compares equivalent records. It identifies matches and differences between sources or between a source and an internal book.
- Validation checks rules. It tests completeness, permitted values, relationships, or other requirements. A record can pass a format check and still disagree with the custodian.
SS&C Advent's Custodial Data guide illustrates the distinction through separate download, translation/posting, and reconciliation steps. Its reconciliation reports compare cash and securities positions. That older technical example is useful for understanding the process, not for establishing today's vendor coverage or performance.
A successful import is therefore evidence that data arrived. It is not, by itself, evidence that the data agrees with another record or includes every expected account.
Compare the same thing before comparing the numbers
A difference is meaningful only after the comparison basis is clear. Define the account, security, currency, valuation date, and accounting treatment before applying a matching rule.
For example, a trade-date position and a settled position may describe different stages of the same transaction. A market value calculated with one price can differ from a value calculated with another while the share quantity agrees.
Preserve several dates separately where they are relevant:
- The date the financial event occurred or took effect.
- The settlement or payable date.
- The date the source processed a correction.
- The timestamp when the firm received the record.
The SEC's T+1 investor bulletin explains settlement as the transfer of securities to the buyer and cash to the seller. It distinguishes the transaction date from the settlement date for covered U.S. securities transactions. That distinction does not establish when a particular custodian file will arrive.
The lesson is to retain meaning alongside values. The newest received record is not automatically the most authoritative record for every field.
What should a reconciliation compare?
Start with the records required by the decision, rather than a single household total.
Positions
Compare account and security identifiers, units, and the relevant position date. Where values differ, separate a quantity difference from a pricing or currency-conversion difference. Matching market values can conceal offsetting errors in the components.
Cash
Compare cash by account, currency, and the agreed balance definition. Available cash, settled cash, and a balance that includes pending activity should not be treated as interchangeable without checking the source definitions.
Transactions
Compare the underlying activity, including identifiers, dates, amounts, quantities, and status where available. Check for missing or repeated entries, reversals, and corrections linked to earlier events.
A positions comparison may identify a break without explaining its cause. Transaction history can help explain whether it reflects a missing event, a timing difference, or a mapping problem. Neither comparison should silently replace the other.
A timing difference is not automatically an error
Consider a hypothetical purchase entered in a firm's portfolio system today. The custodian file being compared still reflects yesterday's closing positions. The internal record includes the purchase; the file does not.
Changing the internal position to force a match would remove legitimate activity. Ignoring the difference forever would be equally unhelpful.
A controlled review would establish the file's effective date, identify the transaction, and classify the difference as an expected timing item if the evidence supports that conclusion. It would also set a follow-up point. If the next expected source update still does not include the transaction, the item needs further investigation.
Keep separate outcomes for a confirmed match, an explained timing difference, an approved tolerance, and an unresolved break. Do not collapse them into one green status. A tolerance is an approved comparison rule, not a declaration that a difference has no consequences.
A clean result needs a coverage check
Matching every record that arrived can still miss an account whose feed never arrived. Define the expected population and distinguish missing coverage from a genuine zero balance or closed account.
For each run, retain evidence of:
- Expected and received accounts or source files.
- The applicable as-of date and receipt time.
- Fields and record types included in the comparison.
- Unsupported assets or manually supplied values.
- Open differences and the reason for any exclusion.
Preserve externally sourced labels when combining views. FINRA Rule 2231, Supplementary Material .06 requires externally held assets to be clearly separated and identified on the customer statements it covers. That statement rule does not apply universally to every RIA, Canadian firm, or internal dashboard, but it shows why a consolidated display should not erase source distinctions.
For the connection questions behind coverage and freshness, use OneVest's custodian integration checklist.
Decide what unresolved data can be used for
Reconciliation should inform downstream decisions. The same unresolved item can have different consequences for an internal monitoring view, a client report, or a proposed transaction.
Define the permitted use and escalation path for each material break. Assign an owner, preserve the records compared, record the explanation or correction, and retain approval where the firm's process requires it. Avoid overwriting a source value solely to make a report look complete.
Ask the team responsible for the next action whether it can proceed, must display a qualification, or should wait. The choice should follow the firm's policy and the evidence, not the appearance of the dashboard.
Matching is also not a guarantee of correctness. Two systems can agree because both copied the same incorrect input. Reconciliation belongs alongside source controls and validation, rather than replacing them.
Where a connected wealth platform fits
The OneVest platform lists data aggregation and reporting among its capabilities and describes connecting custodians, CRMs, and other data sources. Its Operations Workspace brings workflows, approvals, and exceptions into a central operating context.
Those capabilities are relevant to the work surrounding data reconciliation. They do not, on their own, establish a particular reconciliation engine or matching methodology. During a product discussion, confirm which sources, fields, timing rules, and resolution steps your configuration supports.
Start with one consequential use case. Identify the records it relies on, define an equivalent comparison, account for missing coverage, and agree how unresolved differences affect the next action. That gives the firm a clearer basis for using connected data than a general promise of a single source of truth.