A playbook for the Head of Risk Data
If you are a Head of Risk Data, this is your playbook. It covers what your team ships, where its week goes today, the use cases agents take over first, the autonomy you can safely grant in each domain, and what to show leadership after the first quarter.
Key takeaways
- •Who this is for. The teams that aggregate exposures, capital, liquidity and credit risk data from every business line and turn it into internal risk reports and regulatory filings.
- •The problem today. Quarter-end reconciliation overtime, week-long hunts for moved exposures and lineage documents assembled by hand.
- •What changes. Risk aggregates are tied to the ledger every morning, so gaps are explained the day they appear. Source-system changes are detected before the daily risk run, so exposures never move without an explanation.
- •What stays with your people. Any change to reported risk, capital or liquidity numbers: these are filed under personal accountability, so the head of risk data approves.
- •The result. A risk data team that walks into quarter end with reconciled numbers and evidence already in hand.
The PRD for agentic risk and regulatory reporting data teams
This is the requirements document we would write with you for your team. Everything below expands on it.
| Who | Risk data aggregation, regulatory reporting, finance data and CDO teams at banks and insurers |
| The job | Every reported risk number traced, tied and approved before it is filed. |
| Environment | Databricks, Snowflake or Teradata; Airflow, Control-M or Autosys; dbt or SQL-based aggregation; finance ledgers; regulatory reporting tools such as AxiomSL or Wolters Kluwer. |
| Constraints | Any change to reported risk, capital or liquidity numbers always go to a named approver. BCBS 239 sets principles for risk data aggregation and reporting, and SOX expects controls over financial reporting. |
| Success is measured by | Risk-to-ledger reconciliation: from about a week to 8-15 min; Source change explained: from about a week to under 1 h; Lineage evidence pack: from about 2 weeks to hours; lineage and docs closed autonomously 86% of the time. |
| Owned by | A Head of Risk Data, with domain owners as named approvers. |
| Pilot scope | Daily risk-to-ledger tie-out on one risk domain at L2 for one quarter. |
What going fully agentic and autonomous means for risk and regulatory reporting data teams
- •Put your data pipeline on autopilot. Risk aggregates are tied to the ledger every morning, so gaps are explained the day they appear.
- •Run the data back office without the busywork. The work that fills the week today moves to agents: quarter-end reconciliation overtime, week-long hunts for moved exposures and lineage documents assembled by hand.
- •Scale data without scaling headcount. Source-system changes are detected before the daily risk run and lineage and documentation are generated from the live graph, so the data you manage grows without the team having to.
- •Get the plumbing off your plate. A risk data team that walks into quarter end with reconciled numbers and evidence already in hand.
Who this is for
The teams that aggregate exposures, capital, liquidity and credit risk data from every business line and turn it into internal risk reports and regulatory filings. They sit between the chief risk office, finance and the chief data office. Titles include Head of Risk Data, Regulatory Reporting Data Lead, Risk Data Product Owner and BCBS 239 Program Lead.
The shift
Risk data aggregation is where every upstream data problem in a bank ends up. Supervisors expect accurate, complete, timely and traceable risk data; business lines change systems constantly; and quarter-end turns every gap into overtime. Agents can keep the aggregation layer tied out, documented and traceable every day, so quarter end becomes a review instead of a rebuild.
The product you ship
- •Aggregated exposure, capital and liquidity data
- •Regulatory filings and internal risk reports
- •Lineage and reconciliation evidence for every reported number
- •Data quality metrics by risk domain
Where the week goes
- •A business line changes a source system and exposures move.
- •Reconciliations between risk and finance run at quarter end.
- •Lineage evidence is assembled by hand for each review.
- •Late feeds delay the daily risk run.
- •Every new regulatory request becomes a project.
Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:
Time spent on new data products moves from 14% of the week to 50%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.
Then and now
| Work | Today | With Data Workers |
|---|---|---|
| A source-system change | Exposures move unexplained | Mapped on arrival, impact on every report shown |
| Risk-to-finance reconciliation | Quarter-end overtime | Daily automatic tie-out |
| Lineage evidence for a review | Weeks of documentation | Generated from live lineage |
| Late feeds before the risk run | Run delayed | Freshness tracked, fallback proposed |
| A new report request | A project | A mission with tests and approvals |
These are the impact metrics we move for risk and regulatory reporting data teams:
- •Risk-to-ledger reconciliation: from about a week to 8-15 min
- •Source change explained: from about a week to under 1 h
- •Lineage evidence pack: from about 2 weeks to hours
Across the routine work in this domain:
The biggest change is Risk-to-ledger reconciliation: from about a week to 8-15 min.
Use cases, in depth
A loan system migration that moved exposures
Today. Credit exposures drop 3% after a lending platform release; the risk team spends a week finding a mapping change.
With Data Workers. Schema Evolution detects the change, blast_radius_analysis shows every report affected, Pipeline Building fixes the mapping, and Conductor holds the regulatory report inputs at L2.
What changes. Exposures are explained the same day.
Quarter end without the rebuild
Today. Risk and finance reconcile in the final week of the quarter.
With Data Workers. Quality Monitoring ties risk aggregates to the ledger daily; differences are traced by Incident Debugging when they appear.
What changes. Quarter end is a review.
Lineage evidence on demand
Today. A supervisor asks how a capital number is produced.
With Data Workers. trace_cross_platform_lineage and generate_documentation produce the path from source to report with owners and controls.
What changes. Evidence takes an afternoon.
Agents working together: A lending release that moved credit exposures
Minute by minute
This is an illustrative example. Facility data from a lending platform lands in Databricks nightly; dbt models aggregate credit exposure for the daily risk run at 07:00. The regulatory reporting domain is at L2.
| Time | Who | What happens |
|---|---|---|
| Mon 01:10 | Lending platform | Nightly extract arrives with a renamed facility type code |
| 01:12 | Databricks | The load completes; 2,140 facilities map to 'unknown' |
| 01:13 | Schema Evolution agent | detect_schema_change and run_quality_check flag the unmapped codes |
| 01:16 | Data Context & Catalog agent | blast_radius_analysis: credit exposure report, large exposures report, one filing input |
| 01:22 | Pipeline Building agent | Mapping diff proposed with tests; create_servicenow_ticket opens the ticket |
| 06:15 | Spellbook Data Catalog | Head of risk data approves |
| 06:18 | Autonomous Data-Conductor, via Airflow | Rebuild runs; exposures tie to the ledger |
| 07:00 | Risk run | The daily run reads complete exposures |
Without the agents, the 07:00 run understates exposure and the gap is found days later.
The agents on the job
| Agent | What it does for you | Tools it calls |
|---|---|---|
| Schema Evolution | Detects source-system changes and versions contracts | detect_schema_change, validate_schema_compatibility, generate_migration, rollback_migration |
| Quality Monitoring | Completeness, accuracy and risk-to-ledger tie-outs | set_sla, run_quality_check, get_anomalies, create_quality_tests_for_pipeline |
| Incident Debugging | Traces a moved exposure to its cause | diagnose_incident, get_root_cause, prepare_backfill, execute_backfill |
| Data Context & Catalog | Lineage and documentation from source to report | trace_cross_platform_lineage, blast_radius_analysis, define_business_rule, generate_documentation |
| Data Access & Governance | Access to risk data by role, with a full audit trail | provision_access, check_policy, request_governance_review, generate_audit_report |
| Pipeline Building | Builds new aggregations with tests | generate_pipeline, validate_pipeline, sandbox_test, deploy_pipeline |
Data Context Wizard keeps one governed graph of definitions, lineage and owners that every agent and person answers from. Autonomous Data-Conductor runs each job from detection to a verified result. Spellbook Data Catalog is where your team approves, audits and rolls back, and asks questions in plain English.
What goes on autopilot
Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:
- •Risk aggregates are tied to the ledger every morning, so gaps are explained the day they appear.
- •Source-system changes are detected before the daily risk run, so exposures never move without an explanation.
- •Lineage and documentation are generated from the live graph, so supervisor requests are answered in an afternoon.
Where your people stay in charge
Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.
- •Any change to reported risk, capital or liquidity numbers always goes to a named approver: these are filed under personal accountability, so the head of risk data approves.
- •Filing sign-off: this stays entirely with people.
Once a deployment has matured, here is how that ladder plays out across task classes:
Lineage and docs closes autonomously 86% of the time. For Reported risk numbers, autonomous closure is 0% by design.
What happens when an agent is wrong
- •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
- •At L3 act, reversibly, every change keeps a rollback point, and Conductor verifies the downstream number after the change. If verification fails, the change is reversed and the domain drops a level.
- •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope automatically.
- •One org-wide stop halts all autonomous dispatch, and every action lands in a hash-chained audit trail you can export with generate_audit_report.
How it fits your stack
Data Workers connects to what you already run: Databricks, Snowflake or Teradata; Airflow, Control-M or Autosys; dbt or SQL-based aggregation; finance ledgers; regulatory reporting tools such as AxiomSL or Wolters Kluwer. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.
- •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
- •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
- •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
- •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.
Governance and regulation
BCBS 239 sets principles for risk data aggregation and reporting, and SOX expects controls over financial reporting. Data Workers supplies column-level lineage, documented quality rules, named approvals on reported numbers and a tamper-evident audit trail. Your risk and control functions decide what meets each principle.
Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.
The alternatives risk and regulatory reporting data teams weigh
Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the right owner, blast radius, rollback, receipts, and current context about every other system.
Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.
Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the source systems, orchestrator, warehouse and BI, and Data Workers works across all of them.
In this space specifically. Regulatory reporting tools produce the filing; Data Workers keeps the data feeding them complete, reconciled and traceable.
The case for your CTO
What this replaces. Quarter-end reconciliation overtime, week-long hunts for moved exposures and lineage documents assembled by hand.
What your team gets back. A risk data team that walks into quarter end with reconciled numbers and evidence already in hand.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.
Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; any change to reported risk, capital or liquidity numbers stay at L2 with a named approver; and one org-wide stop halts all autonomous work.
Why now. Supervisors keep raising the bar on risk data, and quarter-end overtime is a fixed cost every quarter.
The first win. Daily risk-to-ledger tie-out on one risk domain at L2 for one quarter. The pilot below lays out the scope, what you see each week and the cost.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For risk and regulatory reporting data teams, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; any change to reported risk, capital or liquidity numbers always go to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: risk aggregates are tied to the ledger every morning, source-system changes are detected before the daily risk run, and lineage and documentation are generated from the live graph. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. Risk data aggregation will become continuous: reconciled every morning, lineage always current, and quarter end a sign-off rather than a project. Risk data teams will spend their time on new risk views the business asks for instead of rebuilding the old ones.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how risk and regulatory reporting data teams start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. Databricks, Snowflake or Teradata; Airflow, Control-M or Autosys; dbt or SQL-based aggregation; finance ledgers; regulatory reporting tools such as AxiomSL or Wolters Kluwer, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Daily risk-to-ledger tie-out on one risk domain at L2 for one quarter.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Risk aggregates are tied to the ledger every morning and source-system changes are detected before the daily risk run start running on reversible work. Any change to reported risk, capital or liquidity numbers stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Risk-to-ledger reconciliation: from about a week to 8-15 min
- •Source change explained: from about a week to under 1 h
- •Lineage evidence pack: from about 2 weeks to hours
- •the share of lineage and docs closed autonomously, targeting 86% as the deployment matures
- •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
The pilot is the start of a longer curve:
By month 12, more than 36% of agent actions run fully autonomously while reported risk numbers stay with a named approver.
FAQ
Will an agent change a filed number? No. Reported numbers sit at L2 and filing sign-off stays manual (L0).
Can it produce lineage evidence for supervisors? Yes. Lineage and documentation are generated from the live graph with owners and controls attached.
Does it work with our reporting tool? It works on the data feeding it and connects to the tools around it over MCP and APIs.
Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.
Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.
Sources
- •Data Workers, What is data governance (BCBS 239 example): https://dataworkers.io/resources/what-is-data-governance-with-example/
- •U.S. Bank posting, Technical PM 3, Data Platform, Analytics & Governance: https://www.complyapply.com/jobs/593858630-technical-product-manager-3-data-platform-analytics-governance-at-u-s-bank
- •Data Workers pricing: https://dataworkers.io/pricing/
- •Data Workers open-source repository (tool registrations): https://github.com/DataWorkersProject/dataworkers-claw-community
- •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
- •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team