The Governance Chain

Abstract

Every obligation needs a path to the ground. In most large banks that path runs through eight links: the regulation, the policy, the risk category, the way it could fail, the weakness that would let it fail, the control, the indicator that warns us, and the evidence that proves the control works. I have spent more than 20 years building pieces of that path at six financial institutions. What I have learned is that each piece is usually in decent shape. The trouble is that a different team owns each one, in a different system, using a different taxonomy, and nobody owns the path.

This paper describes the governance chain, the method I use to trace all eight links as one line. I walk three public failures through it to show where they broke. I then draw chains for all sixteen operational risk types as one graph, which shows which controls carry more than one risk type and where chains stop short of proof. I close with how to test coverage against industry losses, what data it takes to build this on real inventories, and how to start with three extracts most firms already have.

1. The problem: eight links, eight owners

Walk into any large bank and ask for the obligations library, the policy inventory, the risk taxonomy, the RCSA, the KRI catalog, the issues log, the loss database and the testing evidence. You will get all eight, usually within a day. Now ask a simple question that needs all eight at once: which of our obligations rest on a single control that has not been tested this year? That one can take weeks, and the answer usually comes back as a spreadsheet stitched together by hand.

I have seen this from both lines of defense. The records are fine. The links between them are not. The obligations library names a policy but does not carry its ID. The RCSA ties controls to risks but not to the obligations those controls are supposed to meet. KRIs hang off a risk, not off the control they are meant to watch. Loss events record a root cause but almost never the control that failed.

This matters for three reasons.

Failures happen at the seams. In most of the enforcement cases I have studied, no single function was negligent. The break sat between two teams that each believed the other had it covered.

Examiners now want the path, not the pieces. Consent orders and MRAs increasingly ask a firm to show how a requirement reaches evidence. Showing that each piece exists is no longer enough.

Duplication hides in the gaps. When controls are mapped one risk at a time, the same control gets designed, tested and reported several times under different names, while some obligations have no control at all.

More assessments, more people and more reporting will not fix this. What fixes it is a common spine that every function's data hangs from. That is what the governance chain is.

2. The governance chain

The chain has eight links. Each one answers a single question, and a chain is only as strong as its weakest answer.

I built the chain this way for three reasons.

It has to run top to bottom with no gaps. A chain with a policy but no control, or a control with no indicator, is visibly broken. The break is the finding.

It names the failure before the control. When I start from the policy, controls end up mirroring the policy's wording. When I start from a concrete loss scenario, controls end up tied to what could actually go wrong.

Evidence is a link of its own. I have sat across from examiners enough times to know that a control you cannot prove is, for them, a control that does not exist.

I draw the chain as a line because it is easier to read. In practice it is many to many. One regulation feeds several policies, one control serves several risks, and one indicator can watch several controls. That is where the chain becomes a graph, which I cover in section 4.

3. Three public failures, traced link by link

I keep a library of public enforcement cases and trace each one through the chain. The pattern is consistent. The regulation was clear and the policy existed. The chain broke lower down, at the links where ownership changes hands. Here are three that show it plainly.

TD Bank. About 92 percent of US transaction volume, roughly $18.3 trillion, went unmonitored from 2018 to 2024. TD had transaction monitoring. What it did not have was a control and an indicator for coverage. Nobody was measuring how much of the business the monitoring actually reached. A control that was never pointed at a channel cannot fail where anyone can see it.

Capital One. An outsider used a misconfigured firewall and an over-privileged role to pull data on about 106 million people. The intrusion ran from March to July 2019 and was found through an outside tip. The lesson I take from it: moving to the cloud changes the risk profile, not just where the servers live. The chain has to be walked again before the move, not after.

CrowdStrike. A bad content update crashed about 8.5 million Windows devices. CrowdStrike pulled it in about 78 minutes, but recovery took days. For its customers, the third-party chain was only as strong as change controls they could not see. Impact tolerance testing is where that dependence shows up, and few firms had run it.

Across all three, the top of the chain held. The breaks sat in the control, the indicator and the evidence, the links that belong to different teams.

4. From chain to graph

Once I had chains for one risk type, the obvious next step was to draw every risk type together. When you do that, identical elements merge into a single node, and the shape of the control environment shows up on one page.

To test it, I built reference chains for all sixteen level 1 risk types in the ORX Event Type Reference Taxonomy. That came to 75 chains, 450 distinct elements and 444 links. Even in an illustrative set, 36 elements were shared across risk types and 11 chains stopped before they reached evidence.

The graph answers questions that no single function's system can answer on its own.

Which controls carry the most weight? Access recertification is a good example. It holds up chains in internal fraud, information security and third party at the same time. If it degrades, three risk types degrade with it, and three committees may each assume one of the others is watching.

Which obligations rest on a single control? A regulation with only one path to evidence is a single point of failure, however well that control tests today.

Where does the chain break? Anything above evidence with nothing below it is a break: a loss scenario with no control, or a control with no indicator. Breaks can be counted, tracked over time and given an owner.

Where are we doing the same work twice? Controls with different names in different risk types often do the same job. When they merge in the graph, the duplicates show up before anyone tests them twice.

I have published a live version of this graph, built on the illustrative chains, at satchit.net/graph. Anyone can load their own chains from a CSV and rebuild it in the browser. Nothing is uploaded.

5. Testing coverage against industry losses

A firm's chains show what it has thought about. Industry losses show what has actually gone wrong somewhere. I find the most useful view puts the two side by side.

The mechanics are simple once the taxonomy is mapped. Every external loss event, whether from ORX News, ORX Global Loss Data or a firm's own collection of public cases, carries a risk category. Attach those events to the matching node in the graph. Each risk category then shows two things at once: how many of our chains run through it, and how much the industry has lost there.

Three readings come out of that.

Losses with no chain. Risk categories where peers have lost heavily and we have no chain at all. These are the first chains to build.

Thin coverage. Categories with large industry losses and only one or two chains, often ending in a break. These need a closer look before the next RCSA cycle.

Possible over-investment. Categories with many chains and few external losses. The controls may well be right, but this is the first place I would look for duplication.

Conduct is where I expect most firms to find gaps. Sales practices, mis-selling and anti-competition cases produce some of the largest settlements in the public record. Yet the controls behind them sit in product, marketing and sales, not in operational risk, so chains built from an operational risk inventory tend to miss them. A scenario workshop rarely surfaces that on its own.

Two cautions. Public loss data leans toward large, newsworthy events, so it understates frequent small losses. And the mapping between your taxonomy and the external one has to be built once and agreed by the people who own both. Otherwise the overlay will mislead.

6. The data it takes, and the links that matter

Building this on real data takes one extract per link, plus the keys that join each link to the next. Most firms already have the records. The joins are where the work is.

The records alone do not make a graph. Six mappings do. In my experience they show up in roughly this order of reliability, strongest first:

1. Risk to control. Usually held in the RCSA and mostly complete.
2. Issue to risk. Usually there, though often without the control that failed.
3. Obligation to policy. Often buried in the text of the policy rather than held as a data link.
4. Control to KRI. Frequently missing, because KRIs tend to be tied to a risk only.
5. Policy to risk. Often implied by who owns the policy rather than recorded.
6. Loss event to failed control. The weakest of all. Loss databases record a root cause but rarely which control failed.

Where a mapping is missing, the graph shows a break that is really a data gap. I still count that as a finding. A firm that cannot link a loss to the control that failed cannot learn from its own losses.

7. A maturity model

I see firms move toward a connected view in four stages. Each stage cuts the time it takes to trace an obligation to its evidence, and each one depends on the data work done in the stage before.

Getting from stage 2 to stage 3 is mostly a data job: filling in the missing mappings from section 6. Stage 4 is where AI earns its place. A language model can read a new regulation, a policy change, an issue write-up or a loss narrative and propose where it attaches in the graph. A person accepts or corrects each proposal. That keeps the graph current without a standing team re-mapping it by hand, which is where most past attempts at a single view of risk ran out of steam.

8. How to start

You do not need all eight extracts to get value. Three extracts and one mapping will give you a working graph in a matter of weeks:

1. The RCSA risk-to-control mapping, with test ratings. This is the backbone. It shows which controls carry more than one risk.
2. The KRI inventory, with linked risk and control IDs. This shows which controls have nothing watching them.
3. The internal loss extract, with risk category. This puts your own losses on the graph next to your controls.
4. A one-time mapping of your taxonomy to an external reference. This lets industry losses attach on their own.

Regulation, policy and evidence can come in a second pass, once the first version has shown you where the gaps are.

Three choices make the first version easier to land.

Start with one risk type or one business unit. A graph of every control in a large bank is unreadable the first time anyone sees it. One domain done well makes the case for the rest.

Keep it local at first. Losses, issues and regulatory findings are sensitive. A tool that reads exported files in the browser, with nothing uploaded, gets through data protection review far faster than a new platform.

Give every break an owner and a date. A break with an owner becomes a remediation item. A break that only appears on a picture becomes a curiosity.

9. Closing

Risk and control functions are being asked to cover more ground with fewer people: cyber, resilience, third parties, data and now AI. Adding a new silo for each one does not scale. What scales is a common structure that every function plugs into, so that a question about one obligation, one control or one vendor can be answered across all of them at once.

That is the new way of working I see for risk and control functions. The first line, the second line and audit all work from the same chain, and a failure anywhere can be traced, link by link, to where it started. The pieces already exist in most firms. The work now is connecting the dots.

About the author

Anand Satchit has spent more than 20 years building risk, compliance and control frameworks at Goldman Sachs, Barclays, Morgan Stanley, Wells Fargo, MUFG and BNY Mellon, and now leads operational risk governance at a large US financial services firm. His work has centered on greenfield programs: policy frameworks, regulatory inventories, control rationalization and governance reporting. The governance chain grew out of that work. The companion paper, Beyond the Chain, describes what comes next. Views in this paper are his own and do not represent any employer.

Notes on sources

Risk types follow the sixteen level 1 categories of the ORX Event Type Reference Taxonomy. Level 2 names, the reference chains and all controls, indicators and evidence in sections 4 and 8 are illustrative, written by the author, and are not drawn from any firm's inventory or from ORX loss data.

Case facts in section 3 come from public records:

• TD Bank: US Department of Justice, TD Bank pleads guilty to Bank Secrecy Act and money laundering conspiracy violations (October 2024); FinCEN assessment against TD Bank (October 2024).
• Capital One: OCC news release on the civil money penalty against Capital One (August 2020); Capital One statement on the 2019 cybersecurity incident.
• CrowdStrike: CrowdStrike Preliminary Post Incident Review and Root Cause Analysis (July and August 2024); Microsoft statement on devices affected (July 2024).

On connected risk and knowledge graphs in banking, see Deloitte, From fragmented controls to connected risk.