Best practices for agentic risk and regulatory reporting data: a field guide for risk and regulatory reporting data teams
How risk and regulatory reporting data teams move their data back office to agents, practice by practice: the state of the space, the old world and the new, what the agents do step by step, how to set autonomy, who owns what, and how to start.
Risk data teams inherit every upstream problem in the bank, and supervisors expect the result to be accurate, complete, timely and traceable.
The daily work of tying out, documenting and tracing is repeatable. With agents doing it continuously, quarter end stops being a rebuild.
The state of the space
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.
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 old world
A lending release renames a code; exposures drop; the risk team spends a week finding out why, and quarter end brings three days of reconciliation overtime.
It is rarely one failure. Three patterns repeat:
- •A loan system migration that moved exposures. Credit exposures drop 3% after a lending platform release; the risk team spends a week finding a mapping change.
- •Quarter end without the rebuild. Risk and finance reconcile in the final week of the quarter.
- •Lineage evidence on demand. A supervisor asks how a capital number is produced.
The new world
The renamed code was mapped overnight, exposures tied to the ledger before the 07:00 run, and the reconciliation that used to take a week runs every morning.
Here is that new world as a chain of hand-offs between agents:
These are the impact metrics we move:
- •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 rest of this report walks through the 5 practices that make that possible. At a glance:
The practices, one by one
1. Tie risk to the ledger every day
Quarter-end reconciliation finds problems too late.
Why it is harder than it looks. Ledger and risk systems use different keys, cut-offs and adjustments, so tie-outs need rules, not one query.
The old world. Quarter-end overtime.
The new world. Quality Monitoring runs daily tie-outs; Incident Debugging traces gaps.
What the agents do, step by step:
- 1.The Quality Monitoring agent calls
run_quality_checkand ties aggregates to the ledger by entity. - 2.The Incident Debugging agent calls
get_root_causeand explains each gap. - 3.The Autonomous Data-Conductor calls
request_governance_reviewand escalates unexplained gaps.
In practice. A $40m gap is explained the morning it appears.
What to measure. Days per quarter risk ties to the ledger.
2. Detect source changes at the boundary
Most moved numbers start with an upstream release.
Why it is harder than it looks. Upstream teams release on their own calendars and rarely warn risk data.
The old world. Found days later.
The new world. detect_schema_change on every load; blast_radius_analysis on every change.
What the agents do, step by step:
- 1.The Schema Evolution agent calls
detect_schema_changeand catches the change on load. - 2.The Data Context & Catalog agent calls
blast_radius_analysisand lists affected reports and filings. - 3.The Pipeline Building agent calls
validate_pipelineand tests the remapping.
In practice. A renamed code is mapped before the risk run.
What to measure. Unexplained moves in reported exposure.
Practices like these compound. Across the routine work they cover:
3. Keep lineage live, not documented
Evidence assembled by hand is stale by the time it is read.
Why it is harder than it looks. Documentation decays the day after it is written.
The old world. Documentation projects.
The new world. trace_cross_platform_lineage and generate_documentation from the live graph.
What the agents do, step by step:
- 1.The Data Context & Catalog agent calls
trace_cross_platform_lineageand builds the live path. - 2.The Data Context & Catalog agent calls
generate_documentationand writes it with owners and controls. - 3.The Data Access & Governance agent calls
generate_audit_reportand packages evidence.
In practice. Evidence for a capital number in an afternoon.
What to measure. Time to produce lineage evidence.
4. Hold reported numbers for a named approver
Filed numbers carry personal accountability.
Why it is harder than it looks. Accountability for filed numbers is personal, so automation must stop at the right line.
The old world. Inconsistent review.
The new world. Reported domains at L2; filing sign-off at L0.
What the agents do, step by step:
- 1.The Data Context & Catalog agent calls
blast_radius_analysisand flags filing inputs. - 2.The Autonomous Data-Conductor calls
request_governance_reviewand holds the change at L2. - 3.The Data Access & Governance agent calls
generate_audit_reportand records the approver.
In practice. Every change to a filing input has an approver on record.
What to measure. Changes with approver on record.
Autonomy where work is reversible, a named approver where it matters:
5. Build new reports as missions
Every new request repeats the same build.
Why it is harder than it looks. Every new report repeats sourcing, mapping and testing.
The old world. Projects.
The new world. Autopilot runs report builds with tests and approvals.
What the agents do, step by step:
- 1.The Pipeline Building agent calls
generate_pipelineand builds the aggregation. - 2.The Quality Monitoring agent calls
create_quality_tests_for_pipelineand adds controls. - 3.The Data Context & Catalog agent calls
generate_documentationand documents it.
In practice. A new liquidity view in weeks.
What to measure. Weeks to a new report.
Designing the autonomy ladder
Autonomy is set per task class, not per tool. This is where we would set each class for a mature deployment, and why:
| Task class | Closed autonomously | Escalated | Handled by a person | Where we set it | Why |
|---|---|---|---|---|---|
| Lineage and docs | 86% | 10% | 4% | L4 once the receipts are clean | The work is reversible and repeatable |
| Freshness | 80% | 14% | 6% | L4 once the receipts are clean | The work is reversible and repeatable |
| Source drift in staging | 70% | 22% | 8% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Quality rules | 60% | 28% | 12% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Reported risk numbers | 0% | 86% | 14% | L2: always proposed to a named approver | The number carries accountability outside the data team |
| Capital and liquidity inputs | 0% | 84% | 16% | L2: always proposed to a named approver | The number carries accountability outside the data team |
The operating model: who owns what
Agents change who does the work, not who is accountable for it:
| Role | Owns | What the agents take off their plate |
|---|---|---|
| Head of Risk Data | Standards, autonomy levels per domain and which domain goes next | Assembling status, chasing owners, keeping the catalog current |
| Domain owners and approvers | Any change to reported risk, capital or liquidity numbers | Preparing the diff, blast radius and rollback plan for every proposal |
| Data engineers | Reviewing agent proposals and building new data products | Risk aggregates are tied to the ledger every morning; source-system changes are detected before the daily risk run |
The swarm behind the practices
| 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 disappears
- •Quarter-end reconciliation overtime.
- •Week-long hunts for moved exposures.
- •Hand-built lineage documents.
- •Late risk runs from missed feeds.
- •Report requests waiting a quarter.
The magic is not any single agent. It is that the back office keeps running: bad data is caught where it enters, every new table gets quality rules and documentation without anyone writing them, access follows policy, fixes are verified before anyone opens a dashboard, and every action leaves a signed receipt.
A product manager's scorecard
| Metric | How to read it |
|---|---|
| Days per quarter risk ties to the ledger | Baseline it in the first week of the pilot; review it monthly. |
| Unexplained exposure moves | Baseline it in the first week of the pilot; review it monthly. |
| Time to lineage evidence | Baseline it in the first week of the pilot; review it monthly. |
| Changes with approver on record | Baseline it in the first week of the pilot; review it monthly. |
| Weeks to a new report | Baseline it in the first week of the pilot; review it monthly. |
Where this goes next
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.
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:
Read the full playbook: Data Workers for risk and regulatory reporting data teams