Why the client record is the hardest part of a brokerage stack

Every system in a brokerage believes it owns the client. Reconciliation is what that belief costs.

Ask four systems in a brokerage who a client is and you get four answers. The CRM knows a person with a phone number and an owner. The trading server knows a login in a group with a leverage setting. The payment provider knows a payer with a card fingerprint and a country. The KYC vendor knows an applicant with a document and a result. Each one is correct. None of them is the client.

This is not a data-quality problem, and it usually cannot be fixed by choosing better software. It is structural: each system was bought to do one job well, and each one had to invent its own idea of a client in order to do it. The brokerage is then left holding the difference.

The difference has a shape

The work of holding that difference shows up in predictable places, and it is worth naming them because they are what an operating layer is actually for:

• —Onboarding state that is a field somebody maintains rather than a value derived from what happened

• —Deposits that exist in the provider before they exist on the platform, and a window in between where the desk cannot answer

• —A leverage change made on the server that the CRM never learns about

• —Withdrawal approvals that need three screens to make once and no record of why afterwards

• —Month-end figures rebuilt from exports because no system holds the whole picture

None of these is dramatic on its own. Together they are most of what a back office does all day, and all of it is reconciliation — work that produces no outcome except agreement between systems that should have agreed already.

One record is not one database

The instinct is to consolidate: move everything into one system and be done. That instinct is what makes replatforming projects, and replatforming projects are why brokerages live with the problem instead.

The alternative is narrower. Keep the systems. Give them one place to agree. A client record that is not a copy of the CRM but an operational history — verification events, funding events, platform events and every action a person took, in order, with an author. The CRM keeps being the CRM. The trading server keeps being the trading server. What changes is that there is now somewhere that holds what happened, rather than five systems each holding what they think is currently true.

The test

There is a simple way to find out whether a stack has this problem. Take one client whose situation is slightly unusual — a rejected withdrawal, a re-verified document, an account moved between groups — and ask someone to explain, from a single screen, what happened and in what order.

If that takes four windows and a colleague, the client record is not the hardest part of the stack because it is technically hard. It is the hardest part because nobody owns it.