Abstract
The three lines of defense, the RCSA and risk-type committees were built for a world where information moved slowly and risks stayed in their lanes. Neither is true any more. Failures now cross risk types in hours, and the volume of rules, issues, vendors and data a risk function has to track keeps growing while headcount does not.
Yet operational risk is still managed one risk type at a time, by people moving information between systems by hand, on cycles measured in quarters. It also spreads attention roughly evenly across risk types, because each one has its own team and its own committee, when most of a firm's exposure actually rests on a small number of controls, vendors and processes. That model is running out of road.
This paper sets out what I believe replaces it. The model has three layers. At the bottom are governance chains that trace every obligation to evidence, the subject of my companion paper, The Governance Chain. Above them sits a knowledge graph that connects every risk type to the vendors, systems, processes and causes they share. I think of that graph as the firm's risk memory. On top, AI agents do the work that consumes most of a risk function's time today: reading new rules, issues and losses, proposing where each one fits, watching for decay, and answering questions with the path shown. People stay accountable for every judgment. They accept or correct what the agents propose, challenge independently, and decide.
I call the combination a risk brain. In what follows I describe its structure, the cross-risk relationships it makes visible, the questions it answers, how AI keeps it current under human control, how to govern it, and a phased path to build it.
The model at a glance
Read it from the bottom up. The chains make every obligation traceable. The graph connects the chains to each other and to what the firm runs on. The agents do the reading, mapping, watching and explaining that today takes most of a risk function's hours. Nothing an agent produces enters the graph or reaches a committee until a named person has accepted it. That rule is what makes the model safe to run in a regulated firm.
The biggest shift is in where attention goes. Today, effort is spread roughly evenly across risk types because each one has its own team and its own committee. With a risk brain, effort can follow concentration: the few controls, vendors and processes that hold up the most of the firm. A risk function that knows which twenty controls carry a third of its chains, or which three vendors sit under half its critical services, can put its testing, challenge and investment there first.
That shift is only possible because the work of gathering, reconciling and reformatting information moves to the agents. People then spend their time on what only they can do: judging, challenging and deciding.
1. After the chains: what you have, and what you still cannot see
Once every risk type has complete chains, a firm can answer questions it could not answer before. Does this obligation reach evidence? Which control holds it up? Is there an indicator watching that control? Those are big gains, and most firms are years away from them.
But chains are still organized one risk type at a time, and real failures do not respect those boundaries. A risk leader at a recent industry roundtable put it plainly: almost nothing in the real world is just one risk type any more. A cloud outage is a technology event, a third-party event, a business continuity event and, if customers are harmed, a conduct event. A fraud ring that recruits an insider is external fraud, internal fraud and financial crime at once. Each risk type's chain can be perfectly sound while the firm still misses how they connect.
There are four things the chains on their own cannot show:
Shared dependencies. Which vendors, systems, data sets, processes and people sit beneath several risk types at once.
Common causes. Which root causes keep showing up across risk types, such as weak change management, stale access or manual workarounds.
Cascades. How a failure in one place travels. An outage becomes a missed regulatory deadline, which becomes a customer complaint wave, which becomes a conduct finding.
Concentration. How much of the firm's control environment rests on a handful of controls, owners or teams.
2. From chains to a knowledge graph
A chain is a single path. A knowledge graph is the network you get when every path is loaded together and attached to the things the firm actually runs on. Getting from one to the other takes two additions to what the chains already hold.
The first is context nodes: vendors, systems, processes, products and business units, data sets, root causes and external loss events. The chains already mention these in passing, inside a control description or a loss narrative. In the graph they become nodes in their own right, so that one vendor or one system connects every chain that depends on it.
The second is typed relationships. A line between two nodes has to say what it means: a control depends on a vendor, a loss event was caused by a root cause, a KRI is measured from a data set. Without types, the graph can show that things are connected but cannot answer why.
The highlighted chain nodes are where most cross-risk connections attach. The chain stays the spine. Everything the risk brain does in later sections comes from walking these relationships across risk types.
3. How risk types connect
When I load chains for every risk type into one graph and add the context nodes from section 2, five kinds of connection between risk types show up. Each needs a different response.
| Connection | What it means | Example | What to do about it |
|---|---|---|---|
| Shared control | One control holds up chains in several risk types | Access recertification serves internal fraud, information security and third party | Name one owner, test once, report the result to every committee that relies on it |
| Shared dependency | Several risk types rest on the same vendor, system, data set or process | A single cloud provider under payments, fraud models and customer servicing | Map concentration; set impact tolerances on the dependency, not on each risk type |
| Common cause | The same root cause drives losses and issues in several risk types | Weak change management behind outages, billing errors and model failures | Fix the cause once, rather than patching each symptom |
| Shared obligation | One regulation is met through chains in several risk types | GLBA safeguards met through information security, third party and data management | Assign a single accountable owner for the obligation across chains |
| Cascade | A loss in one risk type triggers losses in others | An outage leads to missed SLAs, then complaints, then a conduct finding | Run scenarios along the cascade path and check that each hop has a control |
The first four are visible as soon as the graph exists. Cascades take more work, because they need relationships between loss events, not just between controls. Two sources help: the firm's own loss history, where one event's narrative mentions another, and external loss data, where a single news event often carries several risk categories at once.
4. The risk brain: asking the graph questions
A graph you can only look at is a poster. What makes it useful is being able to ask it questions and get an answer in minutes rather than weeks. That query layer is what I call the risk brain.
I have built a working prototype as a single self-contained file. It holds the chains in a small embedded database and has three views: an explorer for browsing chains and their links, a query console for asking structured questions, and an editor for adding or correcting entries. Everything runs locally, which matters when the data includes losses and regulatory findings. A production version would sit on the firm's GRC platform as the system of record, with the graph and query layer on top, and a language model so people can ask questions in plain English.
The value is in the questions. These are the ones I would put in front of a CRO or a Chief Controls Officer first:
| Who is asking | The question | What the graph does |
|---|---|---|
| CRO | If our largest cloud provider is down for a day, which risk types, obligations and customer services are affected? | Walks every path from the vendor node to the services and obligations above it |
| Chief Controls Officer | Which 20 controls carry the most chains, and when were they last tested? | Ranks controls by how many chains run through them, then joins test dates |
| Head of compliance | Which obligations rest on a single control, and which of those controls are rated weak? | Counts paths from each obligation to evidence and filters on test rating |
| Committee chair | Which issues open in other risk types touch controls that our risk type relies on? | Follows issue to control to every chain that control supports |
| Scenario owner | For this peer loss, which of our chains would it have hit, and where would they have broken? | Maps the external event to its risk category and walks the chains below it |
| Internal audit | Where do the same root causes appear in losses and issues across three or more risk types? | Groups loss events and issues by cause across risk types |
| Regulatory change | A new rule lands. Which policies, controls and owners does it touch? | Attaches the new obligation and lists everything downstream |
Two design choices make this work. First, every answer should show its path, so the person asking can see why the graph returned what it did. Second, the language model should only translate the question and explain the answer. The answer itself has to come from the graph, not from the model's memory.
5. Keeping it alive
Most past attempts at a single view of risk did not fail at the build. They failed in year two, when the business changed faster than anyone could update the map. A risk brain is only worth having if it stays current without a standing team re-mapping it by hand.
I see three things that make that possible.
A dynamic ontology. The node and relationship types from section 2 stay fixed. The tags beneath them do not. A controlled vocabulary of tags for products, processes, systems, vendors, causes and themes lets the structure absorb a new product line or a new risk theme, such as agentic AI, without a redesign. The vocabulary is versioned, and every change to it is approved.
AI that proposes, people who decide. New material arrives every day: rule changes, policy updates, new controls, issue write-ups, loss narratives, test results. A language model reads each one, extracts what matters and proposes where it attaches in the graph, with its reasons. A named owner accepts, corrects or rejects each proposal. Nothing enters the graph without that sign-off. I am testing this now with a pipeline of AI agents that pulls unique requirements out of policies, standards and procedures and proposes mappings to the full control population.
Signals that something is out of date. The graph should flag its own decay. Examples include a control not tested within its cycle, an obligation whose source rule has been amended, an owner who has left the firm, and a KRI that has not reported in two periods. Those flags go to the owner as work items, the same way a chain break does.
6. Governing the graph itself
Once a risk committee starts relying on the risk brain, the brain becomes a source of risk in its own right. It needs the same discipline we would ask of any other critical tool.
Ownership. Every node type has a data owner: compliance for obligations, the policy office for policies, operational risk for the taxonomy and losses, first-line owners for controls, risk reporting for KRIs. The graph itself needs a product owner who is accountable for its structure, vocabulary and quality, and that should sit in the second line or a chief controls office, not in technology.
Data quality. I would track a small set of measures and report them alongside the graph's answers: the share of chains complete to evidence, the share of controls with a current test, the share of loss events linked to a failed control, the share of nodes with a named owner, and the age of the oldest unreviewed AI proposal. An answer from a graph that is 60 percent complete should say so.
AI model risk. The extraction and mapping models fall within model risk management. They need a documented purpose, validation against a human-mapped sample, ongoing monitoring of how often reviewers accept or correct their proposals, and a clear rule that they propose and never decide. The same goes for the natural-language interface: test it against a fixed set of questions with known answers before anyone relies on it.
Access and sensitivity. Losses, issues, regulatory findings and investigations do not all belong in front of the same audience. Access should follow the most sensitive node in an answer, not the least. Starting with a local, file-based version is a practical way to prove value before the access model is built.
Independence. If AI drafts both the first line's self-assessment and the second line's challenge from the same graph, the challenge stops being independent. The graph should record who or what produced each assessment, and the second line should keep its own view.
7. Build path
I would build the risk brain in four phases. Each one starts only when the phase before has passed a clear gate, so the graph earns trust before anyone relies on it.
Foundation is the work in the companion paper: complete chains for every risk type, plus an agreed schema and tag vocabulary. Context adds the nodes the chains run on and loads internal and external losses. Query is where the risk brain first earns its keep. I would start with a local tool, a fixed library of questions and one committee willing to use the answers. Maintain brings in AI proposals with owner review and joins the graph to the GRC platform as the system of record.
The gate between Query and Maintain matters most. Before anyone lets AI keep the graph current, the graph's answers should match a careful manual check on a sample of real questions. If they do not, the problem is in the data or the structure, and AI will only spread it faster.
8. What changes for risk and control functions
The risk brain does not replace any function. It changes how they work together, and where their time goes.
| Activity | Today | With a risk brain |
|---|---|---|
| Committee reporting | Each committee sees its own risk type, assembled by hand each cycle | Each committee also sees the shared controls, dependencies and open issues it relies on from other risk types |
| RCSA | Assessed risk type by risk type, with the same control rated several times | Shared controls assessed once and the result flows to every chain that uses them |
| Scenario analysis | Workshops start from a blank page | Scenarios follow real cascade paths in the graph and are checked against peer losses |
| Regulatory change | Impact assessed through emails and spreadsheets | A new obligation attaches to the graph, and everything downstream is listed with its owner |
| Issue management | Issues closed within one risk type | Issues on shared controls flagged to every risk type they touch |
| Emerging risk | Raised in conversation, tracked loosely | New themes, such as agentic AI, enter as tags, and their exposure across risk types can be counted |
| Second-line challenge | Sampled, risk type by risk type | Targeted at the controls and dependencies that carry the most chains |
Underneath every row in this table is the same change described at the start of the paper: effort follows concentration rather than the organization chart.
9. Closing: the next operating model for operational risk
I opened with the problem: the structures operational risk relies on were built for a slower world, where risks stayed in their lanes. That world is gone, and adding headcount cannot keep pace with what has replaced it.
I do not think the answer is more people doing the same work faster. It is a different division of labor. Governance chains make every obligation traceable. A knowledge graph connects the chains into one picture of how the firm's risk fits together. AI agents do the reading, mapping, monitoring and explaining. People own every judgment, and nothing reaches the graph or a committee without a named person accepting it.
That is the model I believe operational risk is moving toward: connected instead of siloed, continuous instead of quarterly, and run by AI under human accountability. The firms that build it first will see their risk the way their business actually works. Most of the pieces are already in place. What is missing is the structure that joins them, and the willingness to let AI do the work in between.
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. He is the author of The Governance Chain: Tracing Operational Risk from Regulation to Evidence. More cases and a live graph are at satchit.net. 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. The roundtable remark in section 1 is from Risk.net's Operational Risk Leaders' Network report, Operational risk 2.0: joining up the function (London, September 2026). The examples of connections, queries and quality measures are illustrative and are not drawn from any firm's data.
On connected risk and knowledge graphs in banking, see Deloitte, From fragmented controls to connected risk, and MetricStream, The potential of knowledge graphs in GRC.