Data Governance in Risk: Ownership, Stewardship and Trust

Data governance decides who is accountable for a number being right before anybody uses it. The arrangement names an owner in the business for each element, a steward who maintains it, and a written statement of what the element means, where it comes from, what it may contain and what happens when it is absent. At the invented Vindhya Commercial Bank Limited, 42 of 147 risk data elements carry all eight.

Everything in this guide rests on one reframing, and taking it now makes the rest fall into place. Most readers arrive believing data quality is a technical problem about systems: a better platform, a tighter interface, a cleaner load. It is not. Every one of the eight attributes below is a sentence somebody has to write and somebody has to be accountable for, and no system produces a single one of them. A source system can report what a field contains. A source system cannot say what the field means, who decided that, what report line the field feeds, or what everybody downstream should do on the morning it arrives empty. Every one of those is a human act, and a committee reading a number is trusting all of them whether or not it knows they happened.

What is data governance protecting, if it is not protecting the data?

Start with what is actually at stake, and it is not the data. Data governanceThe arrangement that decides who is accountable for a number being right, and what must be written down before anybody relies on it. in a risk function protects the trust a decision maker places in a number they did not compute and cannot check. Trust is the whole asset. A committee member reading a monthly risk report is not going to open a source system. The committee member is going to read a figure, believe it, and take a decision that costs money. Everything between the source and that moment is a chain of promises, and data governance makes each promise explicit and puts a name against it.

The everyday version is closer than it looks. A household runs on a small set of numbers: what comes in each month, the rent, the loan instalment, what is left. Somebody in that household holds each of those numbers in their head. The questions this guide asks of a bank apply just as well to that household. Does the phrase what comes in mean take-home or gross, before or after the reimbursement that sometimes arrives? Where does the figure come from, a payslip or a memory? Who updates it when it changes? And what happens in the month the second income does not arrive at all? Most households have never answered the fourth question, and that is precisely the month the budget stops working. The gap in a household budget and the gap in a bank's risk data set are the same gap: nobody wrote down what to do when the number is not there.

So the object being protected is trust, and trust is built in a chain. Six separate human acts stand between a source system holding a value and a committee acting on a number. Somebody agreed what the element means. Somebody named where it comes from. Somebody accepted accountability for it being right. Somebody was appointed to maintain it. Somebody thought about the morning it does not arrive and wrote down what should happen. And somebody traced the path from the source to the report line. Miss any one and the number still appears, in the same font, on the same day of the month, looking exactly as trustworthy as it did before.

The Data Owner: what is one person actually accountable for?

The first named job is the owner, and the word does more work than it looks. A data ownerThe person accountable for a data element being right, sitting in the business that uses it rather than in the technology that stores it. is the person accountable for a data elementOne defined item of data, such as a collateral valuation or an internal grade, that feeds a report line. being right. Not for storing it, not for moving it, not for the interface that carries it. For it being right. And accountability here has the ordinary meaning it has everywhere else: if the element is wrong, this is the person who has to explain it, and nobody gets to say they assumed somebody else was watching.

The owner sits inside the business using the number, and putting them anywhere else quietly destroys the role. The reason is not political, it is practical. Deciding what a collateral valuation means, whether it is the assessed value or the value after a charge, whether it includes the second charge or excludes it, and how old a valuation may be before it stops counting, is a set of business judgements. The questions are not about storage, so somebody who administers a store of values cannot make them. Each one is about what the business intends the number to represent. Asking a technologist to define a business term yields either a definition of the field or a definition somebody else gave them, and in both cases the accountability has evaporated on the way.

The household test again. In a household, the person accountable for what the phrase monthly income means is whoever earns and spends it, not the bank that shows the credit on a statement. The statement can confirm that a number arrived. The statement cannot settle whether the annual bonus counts, whether the reimbursement is income or a repayment, or whether the rent from the second property is dependable enough to plan around. All three are decisions, and the person who has to live with the consequence is the one who has to make them. Moving that decision to the record keeper produces a very tidy record of a number that means nothing in particular.

What does an owner actually decide, and who do they answer to?

Accountability with nothing to decide is a title. An owner decides four things, and each of the four turns into a line in a written record that other people can read without asking anybody.

The first decision is the definition, the sentence that says what an element covers and what it excludes. The second is the permitted values and the format, and a stated range is what makes a wrong value detectable rather than merely unusual. The third is the refresh frequencyHow often an element is expected to be updated, which is what makes it possible to notice that it has not been., the statement of how often the value should be renewed, and this third decision is quietly powerful: without an expected frequency there is no such thing as late, and without late there is no such thing as stale dataA value that is present, looks normal and is older than it should be, which is harder to notice than a value that is missing.. And they decide the rule for absenceThe written statement of what should happen when a value does not arrive, without which nothing happens., the statement of what should happen when the value does not arrive at all. Hold on to that fourth one. Everything below turns on it.

In this invented bank, Zoya Kalbagh is the data owner for the risk data set as a whole, and 103 of the 147 elements carry a named owner beneath her. The two-level structure is worth pausing on: it is the usual one, and it has a usual failure. A single accountable name at the top is what stops the set falling between functions. Named owners underneath are what make the accountability specific enough to act on. An owner for the set and no owners for the elements leaves one person accountable for 147 things they cannot individually see, and that is a way of having nobody accountable for any of them. Vindhya Commercial Bank Limited has both, on 103 elements. On the other 44 it has only the first.

Who does an owner answer to? In the ordinary case, the committee that receives the report the element feeds. The committee carries the consequence of the number being wrong. Notice what this bank's own record does not contain: it names an owner for the risk data set and does not record any committee receiving a measure of how complete that set is. The counts in this guide exist. Nothing in the record says who reads them. A measure with no reader is not a scandal and it is extremely common, and it is the reason a completeness measure can sit at 28.6 per cent for a long time without anybody being uncomfortable.

The Data Steward: who keeps the element alive between month ends?

The second named job is the steward, and the distinction from the owner is the single most useful idea in this guide for anybody who has to build one of these arrangements. A data stewardThe person who maintains a data element day to day, runs its checks and chases its breaks, usually sitting in the source system. maintains the element day to day. The steward runs the checks that test whether today's value looks like a value should look. The steward chases the breaks when a check fails. The steward fixes the record when it is wrong, knows which upstream team to call at seven in the morning, and holds the operational detail that nobody in a business function will ever carry in their head.

The steward sits where the value is produced, and that placement is the whole reason the job exists. Somebody in a business function can define what a collateral valuation means. But nobody in a business function can notice, on a Tuesday, that a file arrived at the usual time with the usual row count and the usual formatting and yesterday's values inside it. Yesterday's values in a normal-looking file are visible only to somebody close enough to the production of the value to know what normal looks like. So the steward sits in the source system, and in this bank the stewards sit across the source systems rather than inside the risk function. The risk function therefore cannot fix a data problem by working harder at its own end.

Two things follow that people get wrong. First, the steward is not junior to the owner in importance, only different in accountability: the owner answers for the element being right, the steward answers for having done the maintenance. Second, a steward with no owner is a person maintaining a value nobody has defined, and no job in this whole arrangement is more demoralising. Forty four elements in this bank currently offer exactly that.

Owner or steward: what breaks when one person is handed both jobs?

The two jobs get collapsed constantly, usually with the best intentions and usually because one person seems to know the most about the element. Here they are apart.

Now the failure mode. Maintenance has a queue and a deadline every single day and accountability has neither, so give both jobs to one person and the accountability quietly becomes a maintenance task. The daily work always wins. Six months later the checks are running beautifully, the breaks are chased inside an hour, and nobody has looked at whether the definition still matches what the business means. Checking the definition was never on anybody's list for today. Collapsing the two jobs does not produce one person doing both, it produces one person doing the urgent one.

What eight things should an element carry before anybody relies on it?

Here is the working record, and it is not long. The bank's data dictionaryThe written record of what each element means, where it comes from, what it may contain and what to do when it is absent. asks eight questions of every risk data element and numbers them T1 to T8. Eight lines on one element. Any institution can write a different eight, and the count is this bank's own choice rather than anybody's standard, but the shape is what matters: each line exists because somebody downstream will one day ask exactly that question and needs an answer without calling a meeting.

Read the eight in order and notice that seven of them describe the value and only one describes its absence. T1 through T6 and T8 are all statements about a value that is there: what it means, where it came from, who answers for it, who maintains it, what it may contain, how often it renews, and how it reaches the report. T7 is the only line in the list that describes a day when the value is not there at all. The asymmetry is not a quirk of this bank's list. A record written by people looking at data that is arriving naturally comes out this way.

How complete is this bank's risk data set, and what do the counts prove?

Now the measured state, and every figure here belongs to the invented Vindhya Commercial Bank Limited. One hundred and forty seven data elements feed its monthly risk report. All eight attributes are present for 42 of them, or 28.6 per cent. A named data owner, T3, is present for 103, or 70.1 per cent, so 44 elements have nobody. A rule for absence, T7, is missing for 105, or 71.4 per cent. And lineageThe traced path from where a number originates to the report line it ends up in, which is what makes it checkable., T8, is missing for 71, or 48.3 per cent.

The 28.6 per cent needs naming before it goes any further. Vindhya Commercial Bank Limited has a second 28.6 per cent that means something else entirely, and the two are the identical fraction rather than a coincidence of rounding. The 28.6 per cent counted above is data governance completeness, 42 of 147 elements carrying all eight attributes, and it is not committee independence, the 2 of the 7 bodies other than the board itself carrying an independent director. Forty two over 147 reduces exactly to 2 over 7. Both are 28.57 per cent. The two are the same number about two unrelated things, and a paper that puts them in one sentence without naming the object has built a pattern out of a coincidence.

Now put the counts against each other. Together they prove something none of them states on its own. One hundred and forty seven less the 105 missing a rule for absence is 42. And 42 is exactly the count carrying all eight attributes. An element cannot be complete without T7, so every complete element is inside the 42 that carry T7, and since both sets have 42 members they are the same set. The elements missing a rule for absence are precisely the elements that are incomplete, so every ownership gap and every lineage gap in this bank sits inside that same 105. Nothing in that conclusion is assumed. Two counts landing on the same number force it.

Which attribute is missing most often, and why is that the worst one to lose?

T7 is missing on 105 of the 147, which makes it the most often absent line in the record, and it is also the line that decides what happens on the worst day of the year. The two facts are related, and the relationship is not bad luck.

Think about who writes a dictionary entry and when. The entry gets written by somebody looking at data that is arriving. The value is in front of them. The writer can see its shape, its range, its format, the place it came from and where it goes. Every one of the other seven attributes can be answered by looking at what is there. T7 asks about a state the writer has never seen, so it is the only attribute that cannot be answered by looking. The rule for absence requires somebody to stop, imagine a morning when the file does not come, and decide in advance who is told, what the report shows in the meantime, whether yesterday's value may be carried forward and for how long, and at what point the number stops being publishable. Writing that line is imaginative work, it takes a conversation with people downstream, and it is the first thing dropped when a documentation exercise is running behind.

So the attribute most often missing is missing for a structural reason rather than a careless one. Nobody skipped it. T7 is simply the only line that cannot be completed by describing what is in front of the person writing it. A record that describes the value and not its absence describes only the days when everything works, and those are precisely the days on which nobody needs a record.

What does an element without lineage actually lose?

Lineage, T8, is missing on 71 elements, being 48.3 per cent, and it fails differently from the others. An element with no lineage is not wrong. The element is present, it looks entirely normal, it has a definition and a source and an owner, and it sits in the report doing its job. The one thing lost is the ability to answer a single question, and that is the only question anybody ever asks in anger: where did this come from?

The question arrives on the day a number is challenged. Somebody outside the risk function says the secured advances figure does not match what they have. Now the work begins, and with lineage recorded it is a reading exercise: follow the path, find the step where the two versions part, done in an afternoon. Without lineage it is an investigation. Somebody has to reconstruct the path from people's memories, and reconstruction is not the same as tracing. The reconstruction is built by the same people whose work is being questioned. Lineage is what turns a number from something present into something checkable, and the difference only ever shows up under challenge.

There is a household version of this too, and it is the one everybody has lived. Somebody in the household says the electricity bill has gone up. The number is right there on the bill. But where did the comparison figure come from, last year's bill, a memory, an average somebody once worked out? Without a traced path, the argument is not about electricity at all. The argument is about whose recollection is better, and an argument like that has no ending.

How many elements carry none of the three, and why is the answer a range?

Three gaps have now been counted: 44 elements with no named owner, 71 with no lineage, and 105 with no rule for absence. The previous section proved that the first two sets both sit inside the third. So a natural question follows, and it is the question anybody planning remediation asks first: how many elements are in all three, the ones with nobody accountable, no traced path and nothing defined for the morning the value does not arrive?

The record cannot say. Two sets of a fixed size cannot both fit inside a smaller container without touching, though, and that is better than a guess. Seventy one plus 44 is 115. The container is 105. Anything above the container has to be double counted, so at least 115 less 105, being 10 elements, must be in both sets. At the other end, nothing in the record stops all 44 ownership gaps sitting inside the 71 lineage gaps, so the overlap could be as high as 44. Between 10 and 44 elements carry neither an owner nor lineage nor a rule for absence, and no honest statement puts a single figure between those two.

The range is the right answer here rather than a weak one, and the reason matters. A number would be more comfortable to put in a paper, and every number between 10 and 44 would be an invention. The counts in this bank's record fix how many elements are in each set. The counts do not record which element is in which, and joint membership cannot be recovered from separate totals. Stating the bound is the only claim the record actually supports, and picking a point inside it would be manufacturing a fact and calling it analysis. A reader who understands that will spot the same move everywhere else it is made.

If the biggest gap were fixed everywhere, how complete would the set be?

This is the question a remediation plan actually turns on, and the arithmetic gives an answer that stops most plans in their tracks. Suppose the bank does the obvious right thing and writes a rule for absence onto every one of the 105 elements that lacks one. Writing 105 rules is a large, real job: 105 conversations with people downstream about what should happen on a morning a value does not arrive. How complete is the set when it is finished?

Start from what is inside the 105. Two counts landing on the same 42 proved that every one of the 71 lineage gaps sits inside it. So of the 105 elements missing a rule for absence, exactly 71 also have no lineage and exactly 34 do have lineage. Completeness needs all eight, so writing a rule for absence onto an element that has no lineage does not complete it. The eighth is still missing. At most 34 of the 105 can be completed by this work, so completeness rises from 42 to at most 76 of 147, being 28.6 per cent to 51.7 per cent, and then it stops dead.

Two things are worth noticing about that 76. First, it is not a modelled figure. The 76 is this bank's own 147 less its own 71, so the ceiling is a locked count rather than a projection. Second, the phrase at most is doing real work. The 34 will only all complete if each of them is missing nothing else, and the record does not say that. The honest line is the best case, and the real answer sits at or below it.

What happened on the day the feed simply stopped arriving?

Had anything warned them, and what happened to the warning?

Yes, and this is the part that makes the incident worse rather than better. Four months earlier, in month 6, the same collateral valuation feed was stale for 2 working days. A data quality check caught it. The check worked exactly as a check should work: it noticed, on the second day, that a value was older than it should be, and it said so. And then nobody raised it as an issue. The month 6 staleness sits in this bank's record as near miss N3, correctly recorded, correctly described, and connected to nothing.

So the month 10 incident was not the first time this feed failed. The month 10 incident was the second, and the first had already produced, free of charge and with no loss attached, exactly the information somebody needed: this feed goes stale, the existing checks notice it, and the record has no line saying what to do next. A near miss carries the same information as a loss and costs nothing to collect, and this bank collected the information and then did not use it. The value of a near miss record is not the recording. The value is in the linking.

Why does a count in this bank never travel without its object?

One habit is worth carrying away from this guide, and it costs nothing. In an institution of any size, small counts and round figures repeat, and a repeated number invites a reader to see a pattern that is not there. Vindhya Commercial Bank Limited is a good example, and 42 is its most crowded number.

Forty two means five different things in this bank's records. There are 42 findings from control testing, rated on its own four point scale. There is Rs 42.0 crore of gross loss on incident I2, the settlement instruction that went out twice. There are 42 of the 147 risk data elements carrying all eight attributes, the data governance completeness count. There are 42 open issues aged beyond 90 days, being the 18 in the 91 to 180 day bucket plus the 15 in the 181 to 365 day bucket plus the 9 beyond 365 days. And there is Rs 42.0 crore of total excess of realised loss over measured value at risk across the year's seven backtesting exceptions. None of the five has anything to do with any of the others, and a sentence that carries a bare 42 has invited its reader to connect two of them.

The number 9 is just as crowded, and that is why it was named too: this bank has 9 processes numbered PR1 to PR9, 9 policies numbered PL1 to PL9, 9 letters of credit inside incident I13, 9 hours of outage in incident I9, 9 open issues aged beyond 365 days, 9 of its 42 findings carrying no stated cause, and 9 of its 16 key risk indicators sitting green. Seven objects, one number. The rule that follows is short: write the object, never the bare count.

The sharpest case is not a repeated count at all, it is an exact fraction. Forty two over 147 reduces to 2 over 7, and this bank has a genuine 2 of 7: the 2 of the 7 bodies other than the board itself carrying an independent director. Both are 28.57 per cent. One is data governance completeness and the other is committee independence, and no amount of staring at them will make them related.

Who actually picks this up, and what do they do with it?

Four people read a data completeness measure and read it for four different things. Watching all four read it is the fastest way to see what a completeness measure is for.

The chief risk officer, Sunanda Ravikumar in this invented bank, reads it for the ceiling rather than the level. Twenty eight point six per cent complete is uncomfortable and does not by itself tell her what to do. The useful fact is a ceiling: a second gap sits underneath the first, so the largest single body of remediation available cannot take the set past 51.7 per cent. A ceiling changes the shape of a plan from one workstream to two, and it changes what she can promise a committee. The most useful question anybody can ask of a completeness figure is not how low it is, it is what the best possible outcome of the obvious fix would be.

An internal auditor, Rustom Batliwala here, reads it for lineage and nothing else. Every finding he writes will eventually be answered with a number, and every number he is given has to be traced or it is an assertion. Forty eight point three per cent of this bank's risk data elements have no traced path from source to report line. Before he starts, then, he knows that roughly half of what he is about to be shown cannot be verified without reconstructing it by hand. The 48.3 per cent is a scoping fact, and it is worth more to him than the headline.

A credit analyst at another institution, looking at this bank from the outside as a counterparty, reads it for what it implies about everything else. Such an analyst will never see this measure, so the useful move is to ask for it. A bank that can state what share of its risk data elements carries a named owner and a rule for absence has thought about the question. A bank that cannot produce the figure at all has revealed something more interesting than any figure would have. Not that it is badly run, but that the numbers on its report have never been asked where they came from.

And the household version, where the mechanism is the same at every scale. A household takes the five numbers its own month runs on and writes four lines against each: what it means exactly, where it comes from, who updates it, and what will be done in the month it does not arrive. The fourth line is the one most likely to be skipped, and it is the only line that is about a bad month. Writing the four lines takes an evening, it produces no new information, and it turns five numbers relied on into five numbers that can be checked. The bank version needs 147 entries and a measure; the household version needs a sheet of paper, and the missing line is the same line in both.

Where do the expectations on risk data actually come from?

By itself, an owner, a steward, a definition and a rule for absence bind nobody. The obligation comes from somewhere else, and naming that somewhere precisely is where confident writing usually goes wrong.

The mechanism set out above is jurisdiction free. An owner, a steward, a written definition and a rule for absence are not Indian, European or American ideas. All four are what it takes for a number to be trustworthy, and a household applying them to five figures on a sheet of paper is doing the same thing this bank is doing across 147 elements. Where jurisdiction enters is not the mechanism, it is the obligation: who is compelled to do it, to what standard, on which entities, and by when.

What is covered separately?