Different Constraints, Different Architecture
Multi-agent AI in financial services operates under constraints that other industries do not face. DORA enforcement requires operational resilience including third-party risk management for ICT systems. SS1/23 in the UK requires model risk management coverage that extends to AI systems. The EU AI Act treats credit scoring as a high-risk use case requiring explicit human oversight, documentation, and audit infrastructure.
These constraints shape multi-agent architecture in financial services beyond what general-purpose architecture frameworks describe. The patterns that work in retail or content moderation often do not transfer cleanly. The patterns that work in financial services have specific control layers that regulators expect to see.
Deloitte's 2024 financial services AI survey found 67 percent of multi-agent deployments in banking and insurance required architectural rework after initial design because the original architecture had not adequately addressed regulatory controls (Deloitte, "AI in Financial Services 2024"). The rework was usually for control layers that should have been in the architecture from initiation.
If your financial services AI project includes multi-agent design, the regulatory controls are not optional and the architectural integration is the work.
The Four Control Layers
Financial services multi-agent architectures require four control layers above and beyond what general multi-agent design typically includes. The layers operate at different points in the system and address different regulatory requirements.
The first layer is action authorization with regulatory scoping. Agents can take actions, but each action class maps to a specific regulatory framework. An agent that adjusts a credit limit is in scope for credit decisioning rules. An agent that processes a customer inquiry is in scope for consumer protection rules. The action authorization policy has to be aware of regulatory scope and enforce constraints accordingly.
The second layer is auditable decision trails. Every agent action that produces a regulated outcome has to be reconstructable. The reconstruction has to include the input the agent received, the reasoning it followed, the model and prompt version, the retrieval sources, and the human review (if any). The decision trail is the evidence that regulators ask to see during examinations.
The third layer is model risk governance applied across agents. SS1/23 and equivalent frameworks require model inventory, validation, and ongoing monitoring. In a multi-agent system, each agent's underlying model is a separate model risk management entity. The aggregate system's behavior is also a managed entity. The governance framework has to address both individual agents and the system.
The fourth layer is explicit human oversight at high-impact decision points. EU AI Act Article 14 requires meaningful human oversight for high-risk AI systems. Credit decisions, employment decisions, and consumer-facing financial decisions all qualify. The oversight has to be designed into the workflow, not added after the fact.
A multi-agent architecture in financial services that lacks any of the four layers will struggle in audit. An architecture with all four operates within the regulatory framework rather than against it.
What Each Layer Demands Operationally
The four layers have operational implications that affect how the multi-agent system is built and run.
Action authorization with regulatory scoping requires that the agents and the action authorization policy share a common understanding of regulatory classification. Each action has metadata about its regulatory scope. The policy enforces constraints based on the scope. This is engineering work, not policy work, although policy informs the engineering.
Auditable decision trails require logging infrastructure that captures multi-agent context, not just per-agent context. When the customer-facing agent escalated to the specialist agent who consulted the policy agent before responding, the audit trail has to show all of that, with traceability across the agent boundaries. The logging is more complex than single-agent audit logging.
Model risk governance across agents requires inventory management that tracks each agent as a managed model plus the aggregate system as a managed system. Validation evidence has to exist at both levels. Monitoring has to operate at both levels. The governance documentation has to cover both.
Human oversight at high-impact decisions requires workflow design that pauses for human review at the right points without making the system unusably slow. The oversight has to be meaningful (as defined in the HITL reference) rather than nominal. The reviewers have to be qualified for the financial workflows they oversee.
These operational implications are the work. Architecture diagrams can show the layers; operational discipline maintains them.
The Specific Workloads Where This Matters
Multi-agent design in financial services concentrates around recognizable workload categories where the regulatory and operational benefits justify the orchestration complexity.
Credit underwriting workflows where multiple specialized analyses (document review, risk scoring, policy compliance, exception handling) benefit from separate agents with coordinated handoff. The regulatory controls are unavoidable; multi-agent makes the architecture clearer to audit than monolithic alternatives.
Claims processing in insurance where different agents handle different claim categories or different processing stages (intake, fraud detection, coverage validation, settlement calculation). The multi-agent decomposition matches the human specialization pattern and makes auditability easier per category.
Customer service in regulated retail banking where one agent handles general inquiries, another agent handles account-specific actions requiring authentication, and a third handles complaint escalation. The separation of concerns simplifies the authorization model and the audit trail.
Compliance and surveillance workflows where multiple monitoring agents watch different signal types (transaction patterns, communication content, market behavior) and coordinate findings. Multi-agent fits because the monitoring tasks genuinely differ from each other.
Each of these workloads benefits from multi-agent decomposition aligned with regulatory structure. The architecture is not arbitrary; it follows how the regulatory framework already partitions the work.
What Goes Wrong When Controls Are Retrofitted
The 67 percent rework rate in the Deloitte data above usually traces to one of three patterns.
The first pattern is architecture that was designed for general-purpose multi-agent and then constrained to financial services after the fact. The constraints fit poorly. The system has to be redesigned for the controls rather than having the controls integrated cleanly.
The second pattern is audit trail that was designed for single-agent operation and stretched to cover multi-agent. The trail is incomplete in places that regulators care about. Examination findings drive rework.
The third pattern is human oversight that was implemented as nominal approval rather than meaningful review. The approval interfaces show insufficient context for the human to oversee meaningfully. Regulators recognize the pattern and require redesign.
The teams that avoid the rework usually had financial services regulatory expertise involved in the initial architecture rather than added later. The expertise is what shapes the architecture correctly from the start.
What Logiciel Does Here
Logiciel works with financial services engineering and compliance teams designing or remediating multi-agent AI architectures. The work is typically structured around the four control layers with priority on whichever layer is the most exposed in the current design.
The Multi-Agent Systems Architecture framework covers the general multi-agent orchestration tax considerations. The Fintech AI Compliance framework covers the four-pillar regulatory framework that multi-agent architecture has to fit within.
A 30-minute working session is enough to assess your current or proposed multi-agent design against the four control layers.
Frequently Asked Questions
When is multi-agent worth the complexity in financial services?
When the workload genuinely decomposes along regulatory or specialization lines that single-agent cannot match cleanly. Credit underwriting, claims processing, and certain compliance workflows commonly qualify. Many other financial services workloads benefit from single-agent design with tool use.
How do I handle model risk management for multi-agent systems?
Model inventory at agent level and at system level. Validation evidence at both levels. Monitoring at both levels. The work is roughly N+1 entities to manage where N is the agent count. Smaller multi-agent designs are easier on this dimension.
What is the right human oversight pattern?
Tiered based on decision impact. Routine actions can have lighter oversight. High-impact decisions (credit decisions, account closures, regulatory reportable items) need explicit meaningful review. The tiering has to match regulatory expectations.
How does this work with offshore or vendor-provided AI?
DORA requires explicit third-party risk management. Vendor-provided AI is in scope. The control layers extend to vendor relationships through contractual provisions, ongoing oversight, and exit planning. The architectural controls are similar; the operational arrangements differ.
What does an audit examination of a multi-agent system look like?
Examiners typically test the four control layers explicitly. Show me the action authorization policy. Reconstruct this specific decision from your audit trail. Demonstrate your model risk management coverage. Show the human oversight evidence for high-impact decisions. Each layer needs to produce evidence on demand. Sources: - Deloitte, "AI in Financial Services 2024" - Bank of England SS1/23, 2023 - European Commission, EU AI Act timeline
