
Successful transformations start with clear data ownership. Every critical data asset should have one accountable owner, not a committee, department, or policy.
Every bank I’ve worked with has a data problem. Not a shortage of data — they have more of it than they know what to do with. The problem is ownership. Ask the team running a new AI initiative who owns the customer profile data they’re training on, and you’ll hear one of three things: a committee name, a department name, or silence. None of those answers are right.
A committee doesn’t own anything. A department is an org chart entry that reorganizes every three years. And silence means the question has never been seriously asked, which means the first time it gets answered will be under pressure, in a crisis, with a regulator in the room.
I’ve seen this play out in every possible way. A core banking migration where nobody could trace which system was the system of record for a given product. An AI project that made it all the way to production before someone noticed that the training data was pulling from a decommissioned source that three teams had been maintaining in parallel without knowing about each other. A regulatory audit where the examiner asked a simple question about data lineage and the answer took six weeks to produce. The technical problems were real, but they weren’t the root cause. The root cause was that nobody owned the data, so nobody was responsible for knowing any of this.
Ben Gurdus, who spent decades running core technology at Citibank, has the clearest articulation of why this matters: “If you don’t know who owns the data, there’s no belly button to push when something goes wrong.”
That one sentence is more useful than most data governance frameworks I’ve seen, because it names the actual requirement: not a committee, not a policy, not a taxonomy. A person. One person with a name, a domain, and the authority to make calls.
The fix is not glamorous, but it is specific:
-
- Name a data domain owner for every critical data asset — not a team, a person.
- Give that person the authority to say yes or no on how their domain is used, not just the responsibility to answer questions about it.
- Measure them on the health of their domain: lineage, quality, access control, and how quickly an exception can be answered.
- Make the ownership map visible and current, not buried in a governance wiki that nobody opens unless there’s already a problem.
None of this requires a new platform. It doesn’t require a data mesh or a lakehouse or a catalog. It requires the organizational will to put a name next to an asset and hold that person accountable for knowing what’s in it, who touches it, and what happens when something goes wrong.
The reason this keeps getting buried in transformations is that it feels like cleanup work rather than strategic work. It doesn’t have a product launch. There’s no ribbon to cut. The person who built it doesn’t get congratulated at a town hall. But when an AI initiative fails because nobody can trace what it was trained on, or when a regulatory exam becomes a six-week fire drill, or when a merger integration grinds to a halt because two systems both claim to be the source of truth for the same data, the question that eventually surfaces is always the same one: who owns this?
Every transformation that doesn’t answer that question at the beginning ends up answering it at the worst possible time.
— Rick Mavrovich


