The short definitions

Data cleaning removes or corrects errors: duplicate records, typos, invalid values, missing required fields. It improves the quality of data within a single system or file.

Data normalization standardizes data into a consistent structure across multiple sources. It doesn't fix errors — it translates different formats, schemas, and identifiers into a unified schema so that data from different systems can be compared, aggregated, and analyzed together.

You can have clean data that isn't normalized. And you can have normalized data that still has errors.

In wealth management, the more common and more expensive problem is normalization — because advisory firms pull data from 5-15 different systems, each of which represents the same information differently.

The wealth management normalization problem

Consider a single client household that holds accounts at Schwab, Fidelity, and Pershing.

Each custodian delivers data in a different format:

• Different field names for the same data (Schwab calls it "account_value"; Fidelity calls it "mkt_value"; Pershing calls it "total_market_value")

• Different identifiers for the same security (CUSIP, ISIN, ticker — and different representations of each)

• Different transaction type codes for the same event (a dividend reinvestment is coded one way at Schwab, a different way at Fidelity)

• Different date formats, different precision on numeric values, different handling of corporate actions

Before you can aggregate this household's total assets, calculate performance, or run any analysis that crosses custodians, you have to translate all three feeds into the same schema.

That translation is normalization. It doesn't require fixing errors. It requires mapping one system's language to another's — consistently, for every field, across every account, every day.

What cleaning does and doesn't solve

Data cleaning is necessary but insufficient for multi-custodian wealth management data.

What cleaning handles:

• Removing duplicate account records created by a sync error

• Correcting a client's name that was entered differently in two systems

• Filling missing tax ID fields before a regulatory submission

• Flagging transactions with invalid amounts

What cleaning doesn't handle:

• The fact that Schwab's position file uses CUSIP while Fidelity's uses ISIN

• The fact that different portfolio systems calculate realized gain differently

• The fact that "account open date" means different things across custody platforms

• The fact that a dividend reinvestment at one custodian shows up as two transactions at another

You can run a perfect data cleaning process every morning and still be unable to aggregate your clients' assets across custodians — because the data is clean but not normalized.

The practical consequence

Advisory firms that describe their data problem as "dirty data" often have a normalization problem that cleaning alone can't fix.

The symptoms look like:

• Reconciliation reports that don't match across systems, even when individual systems show correct data

• Performance calculations that differ depending on which system you pull from

• Client household views that require manual assembly because no system has the full picture

• Compliance reporting that requires manual cross-referencing because the data schemas don't align

These aren't errors in individual records. They're structural mismatches between sources. A data cleaning tool can't fix a structural mismatch — it can only fix individual record errors within a given structure.

The right sequence for advisory data infrastructure

Step 1: Normalization
Define a target schema — a single data model that every source gets translated into. This schema should represent all the concepts that matter in wealth management: positions, transactions, accounts, households, performance, billing, compliance events. Then build (or adopt) the translation layer that maps every custodian and platform's data into that schema.

This is the foundational work. It only needs to be done once per source, and then maintained as source schemas change (which they do, regularly, when custodians update their feeds).

Step 2: Quality validation
Once data is in a common schema, cleaning and quality validation becomes much more tractable. You can define rules that apply consistently across all sources: "no account should have a total value below zero"; "every transaction should have a valid security identifier"; "every client should have exactly one record in the household system."

Step 3: Reconciliation
With normalized, validated data, you can reconcile across sources — comparing the position as reported by the custodian against the position as held in the portfolio management system, flagging mismatches for resolution.

Most advisory firms try to do step 3 before completing step 1, which is why reconciliation is an ongoing manual process rather than an automated check.

Why the distinction matters for buying decisions

When evaluating data platforms, the normalization question is: does this platform arrive with pre-built mappings for the custodians and platforms I use? Or do I build the normalization layer myself?

Pre-built normalization coverage means the translation work is already done for Schwab, Fidelity, Pershing, Orion, Tamarac, Redtail, and 130+ other platforms. You connect the feeds; the platform handles the translation.

Building normalization yourself means your team writes and maintains the translation logic — a significant ongoing technical commitment that grows as you add custodians and as existing custodians update their feed formats.

For most advisory firms, pre-built normalization coverage is the right answer. The normalization logic isn't a competitive differentiator — it's plumbing. Getting it right matters. Building it yourself usually isn't the highest-value use of your engineering or data team's time.

The Milemarker position

Milemarker Data Engine provides normalized data, not cleaned data. The normalization handles the structural translation: mapping every custodian and platform's data into a single, consistent schema.

The distinction is intentional. "Cleaning" implies removing impurities from data that came in wrong. Normalization implies translating data that came in differently — which is the actual problem in multi-custodian wealth management data. The data from each custodian is correct by that custodian's definition. The challenge is that five custodians have five definitions.

Normalization makes the data comparable. Then you can validate it, reconcile it, and build reliable analytics, reporting, and automation on top of it.