Data Quality as a Client-Service Issue, Not an IT Metric
A client does not experience your data architecture; they experience the number you put in front of them — and they decide, in that moment, whether you can be trusted with the rest.
The Figure on the Screen
There is a moment that every private bank prefers not to name. A relationship manager is sitting across from a client — a family that has kept its wealth with the institution for two generations — and on the screen between them is a number that is wrong. A valuation that is stale. A performance figure that will not reconcile with the client’s own records. A holding that was sold three weeks ago and still sits in the portfolio. Often the client notices before the banker does.
Nothing about that moment is an IT incident. No system is down. No ticket has been raised. Yet something has broken that is far harder to repair than any outage: the client’s quiet assumption that the institution knows their affairs better than they do. In a business whose entire premise is trusted stewardship, a wrong figure in front of a client is not a data defect. It is a reputational event, and it is felt as one.
I have watched organisations spend years trying to fix data quality and never close this gap. The reason is almost always the same. They have filed the problem under the wrong heading.
The Cost of the IT Framing
In most banks, data quality lives inside technology and operations. It is measured in completeness percentages, reconciliation break counts, and remediation backlogs. It is reported in a monthly pack that senior leaders skim. It competes for funding against every other item on an engineering roadmap, and it usually loses, because a completeness score of ninety-seven per cent sounds tolerable to anyone who does not have to sit in front of the client whose account is in the missing three.
The IT framing fails for three reasons, and they compound.
- It measures the wrong thing. A percentage treats every record as equal. But client relationships are not equal, and neither are the fields. A wrong middle name is noise; a wrong cost basis in a discretionary mandate is a fault line. Aggregate quality metrics are blind to materiality, so they reassure precisely where they should alarm.
- It sets the wrong owner. When quality is an engineering metric, the people who feel the consequence — the relationship managers, the client-facing teams — have no authority over it, and the people who own it never meet the client. Accountability and consequence sit in different buildings.
- It invites the wrong response. Framed as a backlog, poor quality becomes something to be worked down over time and prioritised against features. But you cannot tell a client that their incorrect statement is in a queue behind a platform upgrade. Service does not have a backlog. It has a standard.
The uncomfortable truth is that a data quality programme reported in completeness percentages is optimised to make leaders feel informed, not to make clients feel known.
What a Service Standard Actually Means
The shift I am arguing for is not a reorganisation or a new tool. It is a change in what the number is. When data quality is a service standard, it inherits the disciplines the bank already applies to everything else the client experiences directly.
Consider how a private bank treats a missed call, a late payment instruction, or an error in a client’s fees. None of these is filed as a technology defect to be remediated on a roadmap. Each has an owner who is answerable, a definition of what good looks like from the client’s chair, an expectation of resolution measured in hours rather than sprints, and a senior person who hears about it when it goes wrong. Data quality deserves exactly this treatment, and for exactly the same reason: it is part of the promise the bank makes.
Making that real requires three moves.
- Define quality from the client’s seat, not the warehouse. The relevant question is never whether a field is populated. It is whether the figure would survive the client looking at it. That reframes quality around the data the client actually sees and acts on — valuations, performance, holdings, income, fees — and around materiality rather than volume. A service standard for data is written in the language of the client statement, not the data model.
- Give it an owner who faces the client. Someone in the client-service line, not only in technology, must own the standard and answer for breaches of it. Engineering remains essential to the remediation, but the standard belongs to the business that carries the relationship. When the owner of quality is also the person who has to explain the error to the client, priorities correct themselves.
- Respond at the speed of service, not the speed of the backlog. A material error in front of a client is an incident with a clock on it. It should be escalated, owned, and resolved on a service timescale, with the root cause fed back into the platform separately. Conflating the two — making the client wait for the engineering fix — is what turns a defect into a grievance.
The Objection, and Why It Is Wrong
The reasonable objection is that this simply relabels a technical problem and adds pressure without adding capacity. If the data is wrong at source, calling it a service standard does not make it right.
That misreads what the reframing does. It does not pretend the engineering work is unnecessary; it changes which work gets funded and how urgently. When quality is an IT metric, the business under-invests in it because the business does not feel it. When quality is a service standard owned in the business, the investment case writes itself, because the same leaders who protect the brand in every other respect now see poor data for what it is — a standing threat to the relationship. The reframing does not remove the technical remediation. It finally gives that remediation a sponsor who cares.
There is a second, quieter benefit. Regulators have spent years pushing firms to treat the fair treatment of clients as an outcome the whole organisation owns, not a compliance function’s concern. A bank that already treats the accuracy of what it shows clients as a service standard is not scrambling to evidence good outcomes after the fact. It has been managing to them all along.
The Standard Is the Strategy
Private banking sells very little that a competitor cannot also offer. The products are broadly comparable; the returns are, over time, broadly comparable. What is not comparable is the felt experience of being known — of an institution that holds your affairs with a precision that quietly exceeds your own. Every wrong figure on a screen is a withdrawal from that account, and the balance is not visible until it is overdrawn.
A client does not experience your data architecture; they experience the number you put in front of them — and they decide, in that moment, whether you can be trusted with the rest.
Treating data quality as an IT metric was always a category error. It took the one thing that most directly expresses the bank’s core promise and buried it in an engineering backlog where no client-facing leader had to look at it. The correction is not technical. It is to move the standard back to where the promise lives — in the service the bank exists to provide — and to hold it there with the same seriousness as every other commitment made to the people it serves.