Mirroring Your Organization with Multi-Agent AI for FSI Risk Assessment

In most financial institutions, risk assessment is a late-stage activity, but multi-agent AI can move it to the front of the design process. Architecture teams design digital banking platforms and payment systems. Security teams review them later against frameworks like NIST CSF and PCI-DSS, and risk teams produce assessments only after deployment decisions have already been made. Risk teams tend to lag the build, so by the time leadership sees a risk report, the architecture is locked in, regulatory exposure is unquantified, and remediation is expensive.

Financial regulators increasingly expect institutions to demonstrate risk assessment at the design stage. The EU’s Digital Operational Resilience Act (DORA) requires financial entities to identify and assess ICT (Information and Communications Technology) risks before deploying new systems. The Cyber Resilience Initiative (CRI) from the Basel Committee on Banking Supervision establishes global expectations for operational resilience in the face of cyber threats. The Office of the Comptroller of the Currency (OCC) heightened standards mandate pre-implementation risk assessment for significant technology changes. Yet most institutions still rely on manual, sequential processes where analysts read each design and map it to controls one requirement at a time. Cloud teams ship faster than analysts can review.

What if your AI system mirrored the way your institution actually works, with a dedicated architect who thinks like a Head of Technology, a security specialist who thinks like a CISO (Chief Information Security Officer), and a risk assessor who speaks the language of the CRO (Chief Risk Officer), all collaborating at the earliest stage of architecture design?

In this post, we show how to design a system of domain specialized AI agents, each mirroring a role in the financial services three lines of defense model. This is a risk governance model most financial institutions run on: the first line (business and technology teams) owns and manages risk day to day, the second line (risk and compliance) sets policy and independently oversees that risk, and the third line (internal audit) provides independent assurance that both are working.

The proposed architecture identifies risks at the architecture stage, produces fully traceable assessments aligned to financial services industry (FSI) risk frameworks, and communicates findings in the language each stakeholder understands. We built this using Strands Agents, Amazon Bedrock, and the Agent-to-Agent (A2A) protocol.

The challenge: siloed sequential assessment doesn’t scale

Assessing risk this way, one team after another, creates three problems:

Late visibility: The requirements themselves aren’t the unknown: PCI-DSS, encryption standards, and data-residency rules are well defined. The problem is when they get checked. Gaps like missing encryption for customer PII (Personally Identifiable Information) or data-sovereignty violations are caught only after architecture decisions are locked in, so the design has to be reworked, which consumes engineering time and pushes out delivery.

Lost context: Each handoff between teams loses nuance. The risk team doesn’t fully understand the architecture rationale, and the architecture team doesn’t see the regulatory implications of their design choices.

Inconsistent language: Architecture teams speak in components and data flows, security teams in controls and vulnerabilities, risk teams in likelihood and regulatory capital exposure. No single document connects these perspectives.

For organizations managing hundreds of cloud workloads across multiple divisions, this process doesn’t scale. It becomes a blocker, and in some instances, it increases risk by delaying visibility into issues that compound over time.

The solution: agents mapped to three lines of defense

Rather than building one large agent that tries to do everything, we designed a multi-agent architecture where each agent maps to a distinct defense line, giving it a focused mandate and the language of its stakeholder.

The first four agents form the assessment pipeline. A fifth, the Organization Profile Agent, is an optional supporting service that captures institution context (size, segment, jurisdiction, data classification) and feeds it to the others; it runs outside the four-stage flow, which is why the deployment comprises five services. We have chosen a sequential workflow for these agents. The sequential model, is used to let each agent consume the outcome of the upstream agent, rather than re-assessing from the input document.

Figure 1: Multi-agent architecture mirroring the financial services three lines of defense

Shift-left risk identification with regulatory traceability

The insight that shaped this system is when the assessment happens: all four agents run at the architecture design stage, before any deployment decision is made. They run as a sequential pipeline rather than in parallel: each stage depends on the interpreted output of the one before it, not on the raw architecture.

Step 1: Architecture analysis (Architect Agent, 1st line)

When a project team uploads an architecture diagram, the Architect Agent analyzes it to identify components, data flows, and architectural patterns. It produces a structured architecture review.

The Architect Agent is equipped with tools that are AWS Lambda functions (including diagram analysis and project retrieval) using the Strands Agents tool interface. The agent decides which tools to invoke, in what order, and how to synthesize the results into a coherent output.

Importantly, the Architect Agent doesn’t assess security or risk; it optimizes purely for architecture quality.

Step 2: Security assessment (Security Architect Agent, 1st line)

The Security Architect Agent receives the architecture analysis via the A2A protocol. This protocol is mainly used to standardize cross agent communication and support dynamic inter-agent queries during the assessment. The security agent then evaluates each component against security control areas: access controls, network security, data protection, and audit logging.

The Security Architect Agent uses Amazon Bedrock to map controls from regulatory frameworks such as NIST 800-53, to the specific AWS services identified in the architecture. Each agent’s system prompt encodes the control mapping methodology for the applicable regulatory regime.

Step 3: Risk assessment (Risk Assessment Agent, 1st/2nd line)

The Risk Assessment Agent synthesizes inputs from both the Architect and Security Architect agents into a quantified risk assessment. It then combines these upstream inputs with an FSI risk assessment template to produce a structured report that speaks in CRO level language: likelihood, impact, regulatory exposure, risk matrices, and strategic recommendations.

The risk assessment templates can be tuned per division: a retail banking template emphasizes consumer data protection and PCI-DSS alignment, while a global markets template emphasizes transaction integrity and market risk. The result is that the same multi-agent system produces division appropriate assessments without code changes.

Step 4: Validation (Auditor Agent, 3rd line)

The Auditor Agent validates all outputs for completeness, consistency, and traceability. When an assessment comes back weak, with mismatched risk counts, a missing section, or risks that don’t trace to a component and control, the Auditor flags it and returns a REJECTED or CONDITIONAL verdict with specific findings. Two limits apply today: the Auditor agent is an LLM agent running rule-based checks, so the verdict isn’t fully deterministic. Findings are shown to the user rather than gating the workflow, and a fix means re-running the relevant agent. Next steps are to make the checks more structural, feed findings back for a targeted re-run, and add a severity threshold that pauses for human review while clean assessments pass through.

Full traceability: examination ready output

The traceability is what makes the assessment examination ready. The CRO sees regulatory exposure and risk appetite alignment. The CISO can drill into the specific control gap against PCI-DSS. The Head of Technology can trace it to the exact API component that needs mutual TLS (Transport Layer Security). All from a single assessment produced at the design stage.

Figure 2: End-to-end traceability from business risk to architecture component. Each finding links an operational risk scenario to its security control gap and the specific AWS service

Agents align with organizational teams

Each agent is independently deployable

Each agent runs its own Amazon ECS task with its own resource allocation, and its own deployment lifecycle. Each team can update the agent without any coordination with the architecture or risk teams.

Structured FSI risk output

Each agent’s output is shaped by templates that encode FSI risk methodology. The Risk Assessment Agent, for example, uses a template that defines:

• 8 FSI risk categories: Reputational, Regulatory/Compliance, Credit, Operational, Market, Liquidity, Technology/Cyber, and Privacy, the standard taxonomy used across banking risk functions
• 5×5 risk matrices: Each risk scenario includes a color coded likelihood vs impact heatmap (green/yellow/orange/red) that CROs and risk committees recognize immediately
• Control effectiveness ratings: Each control is rated as Effective (E), Partially Effective (PE), Ineffective (I), or Not Implemented (NI), the same scale used in internal audit reports

Architecture overview

Figure 3: Architecture overview

FSI Well-Architected Lens alignment

The updated FSI Lens for generative AI and agentic AI provides guidance across six pillars. Our approach aligns with several of these:

Security: Fine-grained permission models for agent actions, clear security boundaries between agents, and Amazon Cognito based JWT (JSON Web Token) authentication for all inter agent communication.

Operational Excellence: Decentralized team ownership plus audit trails suitable for regulatory examination.

Reliability: fresh agent instances per request to prevent state leakage.

Cost Optimization: Right sized ECS tasks per agent workload and template driven assessments to minimize token consumption.

Patterns

Structured input aggregation

The Risk Assessment Agent doesn’t analyze raw architecture diagrams. It receives pre-processed, domain specific inputs from the Architect and Security Architect agents. The benefit is that each agent can be optimized on its own. Better architecture analysis improves the architect’s output, which automatically improves the risk assessment, without changing the risk agent itself.

Prompt driven control mapping

Rather than hardcoding control framework logic, each agent’s control mapping methodology is encoded in system prompts that the owning team can update on its own cadence. The foundation model applies the prompt’s methodology to each architecture component, producing structured control assessments. When a new framework version is released or a new jurisdiction is added, the security team updates the prompt. No code deployment required.

Avoiding monolithic agent

A single agent tasked with architecture analysis, security assessment, and risk scoring would need an enormous system prompt, dozens of tools, and would produce inconsistent results as it context switches between domains. We tried this early on with a single agent and all the tools, and the quality of risk assessments dropped noticeably because the agent would lose track of which domain it was operating in. Splitting into specialized agents solved this immediately. The “large singleton” anti-pattern leads to tool confusion, slower execution, and higher costs. Domain specialization avoids it entirely.

Design considerations

Latency: A complete four agent assessment takes less than 10 minutes end to end. This can vary depending on model latency and size of the input design document.

Cost: Each assessment incurs Amazon Bedrock inference costs across four agents plus Knowledge Base retrieval calls.

Context window and prompt size: Claude Sonnet 4, used in the current version, supports up to 200K input tokens, which is sufficient for the architectures in our testing, but prompt discipline is required as additional frameworks are added to stay within token budgets.

Model hallucination and control accuracy: RAG (Retrieval Augmented Generation) against the Bedrock Knowledge Base substantially reduces fabricated control citations by grounding mappings in indexed framework text. The Auditor Agent catches structural inconsistencies but does not revalidate every control citation. Human review by a qualified security or risk professional remains necessary before using outputs.

Operational overhead: Independent ECS services require maintaining system prompts in Amazon S3, keeping Knowledge Base framework documents current, and managing ECS task health. The deployment scripts handle most of this, but the operational model is more complex than a single monolithic service.

Results: from weeks to minutes

We benchmarked the system on a curated set of FSI designs, each paired with a predefined ground-truth set of risks that was withheld from the pipeline. We ran the full pipeline on every design and scored its findings against that ground truth with a semantic judge.

Across the benchmark the system detected 72 percent of planted risks in roughly ten minutes per assessment, against the days of sequential manual review takes. We didn’t measure performance and cost at scale, and severity-rating accuracy, where the system tends to over-rate criticality. Time and token counts are approximate across the four agents plus knowledgebase retrieval.

To improve the evaluation results, the following key areas can be enhanced:

• Security agent to cover overarching reasoning such as dataflow and trust boundaries (currently only node-based assessment)
• Knowledgebase to cover the target services/nodes used in each solution with their associated controls
• Risk severities to be measured and calibrated based on each organization risk appetite

Deploy the solution

The complete reference implementation, including agent source code, system prompts, Lambda tools, Terraform infrastructure, and deployment scripts, is available at https://github.com/aws-samples/sample-agentic-risk-assessor. Before deploying, you need Amazon Bedrock model access for Anthropic Claude Sonnet 4 and Amazon Titan Text Embeddings V2. You also need Terraform, Docker, the AWS CLI, Python, and Node.js installed locally.

Each stage maps to a documented command in the DEPLOYMENT.md file in the repository, and individual agents or Lambda functions can be redeployed independently.

Conclusion

By designing agents that align with the organization structure, we ended up with a system where each team owns their piece, updates it on their schedule, and trusts the inter agent protocol to handle the handoffs, much like the institution itself operates.

The practical result is early risk visibility, designed to provide full traceability from operational risk down to architecture components, and communication in the language each stakeholder actually uses. Externalized prompts and templates give each team control over how their agent interprets frameworks and communicates findings.

To get started with multi-agent architectures for financial services, explore the Strands Agents documentation. For guidance on securing agentic AI workloads, refer to the Agentic AI Security Scoping Matrix and the Well-Architected FSI Lens.

If you would like to learn more about implementing domain specialized multi-agent systems for your risk and compliance workflows, please reach out to your AWS account team.