What agentic AI can and can't do yet in BFSI workflows, and a five-phase way to sequence it
Most agent projects that stall in financial services, most likely, came face-to-face with a data problem the team didn't see coming: a customer who exists under two different IDs in two different systems, a position that's a day stale by the time the agent reads it, an access grant nobody scoped. The model reasons fine over whatever it's given. The problem is what it's given.
This document lays out how Syren sequences an agentic AI deployment in a regulated financial workflow, and — more usefully for a practitioner reading this before a scoping call — what agentic AI can be trusted to do in a given function today, and what still needs a person.
The sequencing part is called AEGIS or Assess, Engineer, Govern, Instrument, Scale. It's a five-step ordering, and it exists because the failures we see keep tracing back to one of these five steps being skipped or done out of order.
Two things worth stating up front, because they shape everything that follows. First, none of the specific scenarios below are drawn from a named client engagement — they're composite patterns, written to describe how the data problems and the capability limits typically show up, not to claim a specific result for a specific institution. Second, this is written for the person who has to scope or defend an agentic AI project internally — an account executive walking a prospect through what's realistic, or a practitioner deciding what to build first.
It's also worth being direct about timing. 2026 is the year the infrastructure caught up to the idea: Visa, Mastercard, and Stripe have each published protocols this year for AI agents to transact on a customer's behalf, and JPMorgan has said publicly it's moving toward agents that stay coherent for days rather than minutes. The open question is no longer whether AI is coming. AI is here but is their data is in a state where it's safe to let an AI agent act on it.
The five phases of AEGIS framework
| Phase | What has to be true before you move on |
|---|---|
| Assess | The workflow has been broken into its decision points, and the data behind each one has been scored for readiness. |
| Engineer | Identity, freshness, lineage, and shared definitions are solid enough for an agent to reason over. |
| Govern | Permissions, boundaries, and escalation rules are written down before the agent runs, not after. |
| Instrument | Every decision the agent makes is captured in a form a person can replay and question later. |
| Scale | Autonomy expands because the evidence supports it, not because a roadmap said it was time. |
These aren't strictly sequential in practice. Instrument feeds back into Assess for the next workflow, and Govern gets revisited every time you're about to widen what an agent is allowed to do. But skipping a phase to save time doesn't remove the work — it just moves it downstream, to a point where it's harder and more visible to fix.
Assess: Score the workflow before committing
Teams tend to pick their first agent project based on which workflow is most annoying that quarter, not on whether the data underneath it can support an agent. Both are reasonable inputs, but only one of them tells you whether the project will actually work.
In practice, this means decomposing the workflow into its real decision points and scoring the data behind each one across four questions:
- Do the customer, counterparty, and instrument resolve to a single trustworthy record
- Is the data current and traceable to its source
- Is access to it scoped and revocable and
- Does a structured record of past decisions already exist
We weigh identity resolution and data freshness most heavily and treat a low combined score, as a signal to fix the data before building anything. Teams that proceed anyway tend to do the same remediation work later, under worse conditions, once something has already gone wrong in production.
Engineer: the part of the project nobody wants to fund
This phase produces nothing an executive can see in a demo, and it's also where most of the real project effort goes. Concretely: resolving customer, counterparty, and instrument identities into one golden record instead of the several disagreeing versions that accumulate across a core system, a CRM, and whatever spreadsheet is filling a gap between them. Moving the workflow's inputs off overnight batch onto something closer to real time, so the agent isn't reasoning over a position that already changed. Tagging data transformations so that when an agent cites a number, tracing its origin is a lookup rather than an investigation. And agreeing, in writing, what terms like “exposure” or “customer” mean across every system that touches them, since two teams building against two different definitions of the same word is a common and avoidable source of disagreement between systems.
Govern: decide the rules before the agent needs them
The common shortcut is to grant an agent broad access and narrow it later if something goes wrong. That ordering is hard to defend anywhere, and it's specifically indefensible in a regulated environment. A best way to do this is define what an agent may touch as a written, versioned policy before any of its logic is built.
It also means deciding, function by function, where a human has to sign off and where they don't, as a design decision made with the people who will be accountable for it. And it means treating an agent's behavior specification the way an institution already treats a pricing or credit model: independently reviewed, with its limitations documented honestly, and a named person who can explain a given decision without needing to track down the engineer who built it.
Instrument: make every decision replayable
Every action an agent takes should leave behind a record of the full decision, for e.g., what it looked at, what it concluded and why, which systems it touched, what it ultimately did, and whether a person was involved when the decision is made. This is what allows an agent to be audited rather than simply trusted.
Alongside that record, we maintain a set of past cases with known-correct outcomes and re-run the agent against them whenever the prompt, model, policy, or available tools change, much like the discipline a software team applies to a regression suite, aimed at a system whose behavior can drift in less visible ways than code does. Without this, a quality regression tends to surface first as a customer complaint or a regulator's question, which is the most expensive way to find out.
Scale: autonomy must be earned
Whether an agent is “autonomous” is the wrong question. The useful one is what it's autonomous to do, and what evidence supports that. We use five bands, and a workflow moves to the next one when the evidence says so, not when a project plan says it's time.
| Band | What the agent is doing | What earns the next band |
|---|---|---|
| Shadow | Logging what it would have decided, without acting — running alongside the human doing the real work. | Enough of a sample to know how often it would have agreed with the human, and where it wouldn't. |
| Draft | Proposing the action; a person reviews and approves it before it executes. | A sustained high acceptance rate across a real caseload, not a curated pilot set. |
| Co-Pilot | Acting independently on a narrow, well-understood slice of cases; everything else still goes to a person, with no exceptions. | Escalation judgment that holds up under audit — the agent reliably knows what it doesn't know. |
| Delegate | Acting across most of the workflow; a person samples and reviews after the fact rather than approving beforehand. | Quality holding steady through a full external review cycle, not just an internal one. |
| Steward | Running the workflow end to end within its mandate; a person is involved only for genuine exceptions. | Reserved for narrow, low-consequence case classes, not the default BFSI workflows. |
Autonomy is not the goal. Most production agents in BFSI should be operating well at Co-Pilot, not racing toward Steward. The bands exist to make “how much is this thing actually deciding on its own” an answerable question.
What this can and can't do yet | A capability snapshot
Today, practitioners scoping a project should be asking, “what should we trust agentic AI to do this year, and what still needs a person.” The table below reflects where that line typically sits today across common BFSI functions. It will move as governance and audit practices mature; it's not fixed.
| Function | Reliable today | Still needs a person | Why |
|---|---|---|---|
| KYC / onboarding | Assembling the evidence file, running initial screening matches, drafting the exception memo. | The final approve or decline call on a borderline case. | The regulatory liability for that decision sits with a named individual, and the cost of an error is asymmetric. |
| Trade surveillance triage | Clustering and prioritizing alerts, assembling the relevant order, comms, and market context for a reviewer. | Closing an alert as a false positive without any review. | Closing an alert is itself a regulatory record; audit practice for autonomous closure is still forming, not yet settled. |
| Collections outreach | Segmenting accounts by risk and drafting compliant outreach copy. | Deciding hardship treatment or settlement terms for a specific customer. | Fair-debt-collection rules and reputational exposure keep this human-owned at most institutions today. |
| Reconciliation / settlement breaks | Matching records across systems and proposing the correcting entry. | Posting that entry without sign-off. | Segregation-of-duties controls on the general ledger predate agentic AI and haven't been rewritten around it yet. |
| Customer servicing | Resolving lookup-class requests — balances, statements, simple servicing — end to end. | Emotionally difficult or financial-hardship conversations. | Model judgment on ambiguous, high-stakes personal situations is still inconsistent, and getting it wrong in public is costly. |
Where this goes wrong
The most common failure is skipping Assess to hit a date someone else set, then discovering that a clean demo said nothing about the workflow's real identity resolution in production.
Close behind it is granting broad, shared access on the assumption it can be narrowed later, which tends to surface only at an incident review, when nobody can say exactly what the agent could touch.
A well-benchmarked model gets treated as proof the agent works, even though it was never tested against the institution's own tools and data.
An audit trail gets built after something has already gone wrong, which is a materially worse conversation to have with compliance than building it up front. And, periodically, a team pushes straight for full autonomy because it's the more impressive number in a slide deck, without the evidence to defend it if a regulator or an internal review asks.
None of these are unusual mistakes. They're ordinary ones, made under ordinary delivery pressure. AEGIS is mainly a way of making that pressure visible early enough to resist it.
Questions teams ask before they start
Agentic AI observes data, reasons over it, takes multi-step actions through tools and systems, and checks the outcome, largely without a person directing each step. RPA follows fixed rules and doesn't adapt; a chatbot answers questions but doesn't act. An agent in a BFSI workflow can triage an alert, pull evidence from several systems, and draft or execute a decision the way an analyst would, at machine speed.
AEGIS is Syren's five-phase approach to deploying agentic AI in regulated financial workflows: Assess a workflow's data readiness, Engineer the identity, freshness, and lineage layer underneath it, Govern the agent's permissions and escalation rules before it runs, Instrument every decision so it's auditable, and Scale autonomy only as the evidence supports it.
It depends more on data readiness than on model choice. A workflow that already scores reasonably well on identity resolution, freshness, governance, and auditability can usually reach a supervised Draft stage within a couple of months. A workflow that needs identity resolution or streaming pipelines built first typically adds a quarter or two before an agent is safe to run at all.
Compliance isn't added afterward — it's the Govern and Instrument phases. Treating an agent's behavior specification like a model-risk document, with independent review, documented limitations, and a named accountable owner, plus a replayable decision record for every action, is what lets an institution answer questions under SR 11-7, OCC guidance, or its own internal model-risk policy.
Very little agentic AI in financial services runs with full autonomy today, and most of it shouldn't yet. The Scale phase uses five bands — Shadow, Draft, Co-Pilot, Delegate, and Steward — where a workflow earns more autonomy only once its accuracy and escalation judgment hold up under audit. Most production agents in BFSI operate at Co-Pilot or Delegate, by design, not by limitation.
Workflows with high case volume, repetitive judgment calls, and an existing — even imperfect — audit trail tend to score highest on readiness. Trade-surveillance triage, KYC evidence assembly, and settlement-break resolution are common starting points, because the underlying data and escalation patterns already exist and mainly need to be engineered and governed for an agent.
No. The framework is designed to sit on top of existing core banking, CRM, and ledger systems — the Engineer phase resolves and streams data from those systems rather than replacing them. Most engagements pair an agent with the systems of record an institution already has.