The agentic data platform for financial services: regulatory reporting, lineage and change evidence on autopilot
If you are a data leader at a bank or asset manager, 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. Data leaders and teams at banks, asset managers and fintechs.
- •The problem today. Most of the data team's week goes to the reconciliation, rework and sign-off work behind every NAV, risk number and client statement.
- •What changes. Specialised agents take that work over across the systems you already run: they catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •What stays with your people. Anything regulated or customer-facing waits for a named approver with the full diff, blast radius and rollback plan in front of them.
- •The result. Data teams that spend their time on teams that ship client, risk and portfolio data products.
The PRD for agentic data in financial services
This is the requirements document we would write with you. Everything below expands on it.
| Who | Data leaders and teams at banks, asset managers and fintechs. |
| The job | From reconciliation shops to self-running data businesses. |
| Environment | Snowflake, Databricks or BigQuery; Airflow or Control-M; dbt; vendor SFTP and APIs from Bloomberg, Refinitiv/LSEG, ICE and S&P; an EDM or security master, and the other platforms your teams run. |
| Constraints | Regulated and customer-facing numbers always go to a named approver; agents run in your infrastructure under the roles you already govern. |
| Success is measured by | Analyst question on exposure: from about 2 days to seconds; Access for a new desk: from about 2 weeks to 5 min; Finding the right dataset: from about 3 hours to 30 s; access provisioning closed autonomously 84% of the time. |
| Owned by | The head of data or CDO, with domain owners as named approvers. |
| Pilot scope | Market and reference data at L2 for one quarter. |
What going fully agentic and autonomous means in financial services
- •Put your data pipelines on autopilot. Agents catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •Run the data back office without the busywork. The week that goes to the reconciliation, rework and sign-off work behind every NAV, risk number and client statement moves to agents.
- •Scale data without scaling headcount. New sources, partners and data products are onboarded as missions, not projects.
- •Get the plumbing off your plate. Data teams spend their time on teams that ship client, risk and portfolio data products.
The shift
Financial services runs on numbers that have to be right the first time: a NAV, a risk exposure, a client statement, a capital ratio. For twenty years the industry has met that bar with people. Every bank and asset manager has teams whose real job is reconciliation, rework and sign-off, sitting behind every report the business reads.
That model is breaking. Data volumes, product complexity and the number of systems feeding each number have all grown faster than headcount. AI makes it worse before it makes it better: a copilot that answers from the wrong table spreads a wrong number to a thousand people at once.
Our view is simple. The data back office of a financial institution should run itself. Agents should build and maintain pipelines, catch bad feeds before they reach a number, keep definitions and ownership current, and handle access by policy. People should set the standards, approve what matters and spend their time on the data products the business has been asking for for years.
How data work in financial services got here
The warehouse and reconciliation era. Data lived in mainframes, EDM platforms and a central warehouse. Every new report was an IT project. Quality was enforced by reconciliation teams who compared numbers after the fact, often in spreadsheets.
The modern data stack era. Cloud warehouses, dbt and orchestration made building faster and data mesh pushed ownership into business lines. But every tool added a new place to watch, every domain built differently, and the work of keeping it all running grew with it. Most data teams now spend more of their week on upkeep than on anything new.
The agentic back office. Agents do the upkeep. They read the whole estate, write real changes back under guardrails, verify the numbers downstream and leave a signed receipt for every change. Autonomy is set per domain, so a sandbox cleanup runs on its own while a change to a NAV input waits for a named approver.
The three eras side by side:
Each era changed the tools. Only the agentic back office changes who does the work.
A day on a financial-services data team today
It is 6:40am at an asset manager. A vendor price file has landed with a currency code in a new column. The overnight job did not fail; it loaded, and 140 fixed-income positions are now priced in the wrong currency. Nobody knows yet.
At 7:30 the fund accounting team notices a NAV variance on two funds. They raise a ticket. A data engineer starts tracing it at 8:15, finds the file at 9:40, fixes the mapping at 10:20 and reruns the load. Fund accounting re-strikes the NAV at noon, an hour past the cutoff the operations team prefers. The engineer spends the afternoon writing the incident note instead of the client data product she was meant to ship this sprint.
Nothing about this was hard. It was just long, manual and invisible until it hurt.
That morning is typical, not exceptional. Across a week, this is where the team's time goes, today and with agents on the back office:
Time spent on new data products moves from 18% of the week to 52%. 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 vendor changes a file layout | Found when a number looks wrong, traced by hand | Caught on arrival, mapped, tested and verified before the number is used |
| A new data product for a desk or business | A quarter of tickets, reviews and rework | Built, tested and documented by agents in weeks; engineers review instead of retype |
| Access for a new analyst or desk | A ticket queue and a manual policy check | Granted against policy the same day, every grant logged |
| Keeping the catalog and definitions current | A stewardship project that drifts | Kept current by the agents as they work |
| Migrating off a legacy platform | A multi-year program with a big-bang cutover | Moved in approved waves with parity checks on every table |
| Copilots on firm data | Stalled, because nobody trusts which table is right | Answer from governed definitions with provenance on every fact |
These are the impact metrics we move:
- •Analyst question on exposure: from about 2 days to seconds
- •Access for a new desk: from about 2 weeks to 5 min
- •Finding the right dataset: from about 3 hours to 30 s
Across the routine work:
The biggest change is Access for a new desk: from about 2 weeks to 5 min. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass.
Use cases, in depth
1. The late or broken price feed
The situation. Market and reference data arrive from many vendors on tight schedules. A late file, a restated price or a layout change lands in valuations, risk and client reporting before anyone sees it.
Today. The problem is discovered downstream, usually by the people who own the number. A data engineer traces backwards through jobs and logs, fixes the mapping, reruns and writes it up. Hours pass and the same class of break happens again next quarter.
With Data Workers. The Data Ingestion agent profiles every vendor file on arrival and flags the new column. Schema Evolution maps it. Pipeline Building updates the model and its tests. Quality Monitoring confirms positions now price in the right currency and tie to the vendor's totals. Autonomous Data-Conductor verifies the downstream NAV inputs and, because NAV tables sit at L2, holds the change for the fund accounting lead with the full diff. Approval takes one tap.
What changes. The break is fixed before the NAV is struck, the pattern is remembered, and the next layout change from that vendor is handled the same way without a ticket.
2. A new client data product in weeks, not quarters
The situation. A wealth business wants a unified client view across custody, CRM, transactions and advice notes to power advisors and a client-facing assistant.
Today. A cross-team program: requirements, source analysis, mapping workshops, build, test, sign-off. Six months is normal, and the result goes stale because nobody owns its upkeep.
With Data Workers. The team states the outcome as an Autopilot mission. Connectors and Ingestion agents land the sources. Pipeline Building builds the client model with identity matching and tests. Data Security classifies PII, Data Access & Governance applies advisor-level access rules, and Data Context Wizard publishes governed definitions of client, household and assets under advice. Spellbook gives the product a living page with owner, SLA and lineage.
What changes. The product ships in weeks, it stays current because agents keep it current, and the advisor assistant answers from the same definitions as the dashboards.
3. Migrating off the legacy warehouse or EDM platform
The situation. Every large firm has a platform it has been trying to retire for years: an on-premises warehouse, a legacy EDM, a reporting layer nobody wants to touch.
Today. A multi-year program with consultants, a frozen change window and a risky cutover. Parity testing is manual and partial.
With Data Workers. The Data Migration agent inventories every object and its consumers, then moves workloads in approved waves. Every wave runs parity checks table by table, and lineage proves which reports depend on what. Conductor watches SLAs through each wave and rolls back anything that drifts.
What changes. Migration becomes a steady stream of small, reversible moves instead of one big bet, and the old platform is switched off when the last consumer has moved.
4. Copilots that portfolio managers and risk can actually trust
The situation. The firm has licensed copilots and built internal assistants. Adoption stalls because the answers disagree with the reports.
Today. Each assistant is pointed at whatever tables a team could find. "Exposure", "AUM" and "client" mean different things in different places.
With Data Workers. Data Context Wizard holds one governed definition of every metric that matters, joined to lineage. Every assistant, agent and analyst answers from it, with the source attached to every fact. When a definition changes, every consumer moves together.
What changes. The copilot's number matches the report, so people start using it.
Agents working together: A broken price feed, fixed before the NAV is struck
The first use case above, run end to end. Five agents and one approver turn a silent misprice into a corrected NAV input before anyone in fund accounting sees a variance.
Minute by minute
This is an illustrative example. An asset manager loads vendor price files into Snowflake through Airflow; a dbt model builds the golden-source price table read by fund accounting at 10:30. The pricing domain is at L2 propose.
| Time | Who | What happens |
|---|---|---|
| 06:40 | Vendor SFTP | A price file lands with a new column; the currency code shifts one position |
| 06:41 | Airflow + Snowflake | The DAG loads it; 140 fixed-income rows carry the wrong currency |
| 06:42 | Schema Evolution agent | detect_schema_change flags the layout change; run_quality_check fails the tolerance test |
| 06:45 | Data Context & Catalog agent | blast_radius_analysis: the 10:30 NAV input and two risk reports |
| 06:49 | Pipeline Building agent | Mapping and model diff proposed with tests and a rollback point; create_jira_sm_ticket opens the ticket |
| 07:05 | Spellbook Data Catalog | The pricing lead reviews the diff and approves |
| 07:08 | Autonomous Data-Conductor, via Airflow | Reload and dbt rebuild; prices tie to vendor totals |
| 07:10 | Spellbook Data Catalog | Receipt written to the ticket; the lead closes it |
| 10:30 | Fund accounting | NAV inputs read verified prices |
How it fits your stack
Data Workers connects to what you already run: Snowflake, Databricks or BigQuery; Airflow or Control-M; dbt; vendor SFTP and APIs from Bloomberg, Refinitiv/LSEG, ICE and S&P; an EDM or security master. 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.
How autonomy expands over the first year
Autonomy is set per domain in Autopilot, and it only grows on evidence.
Autonomy is earned per task class. In a mature deployment, it looks like this:
Access provisioning closes autonomously 84% of the time. For NAV, risk and regulatory tables, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named person.
A typical path to get there:
- •Month 1, L1 everywhere. Agents map the estate, lineage and definitions and list what they would have fixed, with receipts. Nothing changes without a person.
- •Months 2 to 3, L3 and L4 on low-risk work. Sandbox cleanup, cost fixes, catalog upkeep and routine access grants run on their own. Reruns, backfills and schema fixes in staging run and stay reversible.
- •Months 4 to 6, new data products. Teams use the time they got back to ship the client, risk and portfolio data products in the backlog, built by the swarm and reviewed by engineers.
- •Months 6 to 12, wider autonomy where the evidence supports it. Repair classes with a clean record move up a level. NAV, risk and regulatory tables stay at L2: proposed with a full diff and approved by a named person. Sign-off on filed reports stays with people.
No agent approves its own work, irreversible changes need a named person, and every change carries a signed receipt: who proposed it, who approved it, what changed and how to roll it back.
The same path as a curve, month by month:
By month 12, more than 38% of agent actions run fully autonomously and manual work falls below 10%, while NAV and risk changes stay with a named approver.
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.
Governance and regulation
Banks and asset managers work under BCBS 239 for risk data, SOX for financial reporting, SR 11-7 for model risk and GLBA and PCI for customer and card data. Data Workers supplies column-level lineage, documented quality rules, scoped access, named approvals on regulated numbers and a hash-chained audit trail. Your control functions decide what satisfies each requirement.
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 financial services 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. EDM platforms, reconciliation tools and platform-native agents each own a slice; Data Workers runs the back office across them.
The case for your CTO
What this replaces. The week spent on the reconciliation, rework and sign-off work behind every NAV, risk number and client statement.
What your teams get back. Time for teams that ship client, risk and portfolio data products, on data that is verified before anyone reads it.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the platforms you already run, under the roles you already govern, inside your own infrastructure.
Risk and control. Autonomy is set per domain, starts at L1 and rises only on evidence. Regulated and customer-facing numbers stay at L2 with a named approver, and one org-wide stop halts all autonomous work.
Why now. AI copilots now quote firm data directly.
The first win. Market and reference data 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. In financial services, that climb looks like this:
- •Assisted. Agents work alongside each data team, read the whole stack and propose every fix with a receipt. Regulated and customer-facing numbers always go to a named approver.
- •Autonomous, under your governance. The upkeep behind the reconciliation, rework and sign-off work behind every NAV, risk number and client statement runs on its own, domain by domain, as the receipts earn it.
- •The agentic enterprise. The platform largely runs itself. People set direction and standards, and the teams spend their time on teams that ship client, risk and portfolio data products.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how financial services data teams start
The pilot is how a team proves the value on its own data before committing.
- •What we connect. Snowflake, Databricks or BigQuery; Airflow or Control-M; dbt; vendor SFTP and APIs from Bloomberg, Refinitiv/LSEG, ICE and S&P; an EDM or security master, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Market and reference data at L2 for one quarter.
- •First week. Agents run at L1 and show the fixes they would have made, with receipts.
- •By week two. Reversible upkeep (reruns, staging fixes, documentation, cleanup) runs on its own; regulated and customer-facing numbers stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Analyst question on exposure: from about 2 days to seconds
- •Access for a new desk: from about 2 weeks to 5 min
- •Finding the right dataset: from about 3 hours to 30 s
- •the share of access provisioning closed autonomously, targeting 84%
- •What you decide. Which domain or team goes next. 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.
Use-case guides
- •Data discovery for financial services: Analysts find the right, approved data in minutes.
- •Portfolio monitoring data: PMs see one reconciled view before the open.
- •LP and investor reporting data: Quarter-end reporting is a review, not a rebuild.
- •Credit risk data: Credit models run on reconciled exposure every day.
- •Fraud detection data: Fraud models never score on stale features.
- •Regulatory reporting data: Quarter end is a review with evidence ready.
Teams we work with in financial services
FAQ
Will an agent change a regulated number? Not above L2; filed numbers stay with people.
Does it run in our environment? Yes; the hosted Conductor sees workflow metadata only.
Does it replace our EDM? No.
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, retail and e-commerce industry page: https://dataworkers.io/blog/agentic-data-platform-for-retail-and-e-commerce/
- •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