MCP and A2A in Agentic BFSI Systems: The Complete Implementation Guide

Why BFSI Needs Protocol-Level Standards

The IMF published a formal note in April 2026 on how agentic AI will reshape payments. Its central technical finding: MCP standardizes agents' access to external data and tools, while A2A protocols enable interoperability and coordination among agents developed by different vendors. The x402 standard builds on HTTP 402 and allows agents to embed payment requirements directly within HTTP requests, enabling automatic negotiation of paid services.

This tripartite stack - MCP for tool connectivity, A2A for agent coordination, x402 for payment negotiation - is not an academic proposal. It is the emerging infrastructure of financial services automation in 2026, documented by the IMF, adopted by PayPal and major payment networks, and backed by every major AI provider through the Linux Foundation's Agentic AI Foundation.

The scale context: BCG research identifies banking and fintech as the industries with the highest concentration of AI leaders. Nearly half of financial institutions already report regular use of advanced AI systems. The adoption of agentic architectures is accelerating as institutions seek differentiation through automation at scale.

Without protocol standards, financial institutions face three compounding problems.

The first is the N times M integration problem. A bank with 15 AI agents and 40 financial data sources needs 600 custom integrations. Each breaks when either side updates. Each represents a compliance surface that must be independently audited. MCP reduces this to 55 connections - 15 agents plus 40 MCP servers, each built and audited once.

The second is the cross-vendor agent coordination problem. A credit decisioning workflow may involve an LLM from Anthropic, a risk scoring model from a specialist vendor, a KYC verification agent from a compliance technology provider, and an internal fraud detection system. Without A2A, coordinating these systems requires custom orchestration code that is brittle, opaque to auditors, and impossible to replace without a full rewrite. A2A makes each agent replaceable without rewriting the coordination layer.

The third is the auditability problem. DORA, effective January 17, 2025, requires EU financial institutions to continuously monitor and control ICT systems with management-level accountability. AI agent decisions affecting customers, transactions, or regulated outcomes must be logged, classified, and reportable. Protocol-level standardization makes this tractable - when every agent interaction follows a defined wire format, audit logging can happen at the protocol layer rather than being bolted onto each application individually.

MCP in BFSI: Connecting Agents to Financial Systems

MCP is the vertical layer - it connects each AI agent downward to the tools, data sources, and systems it needs to interact with. In BFSI, these systems are more numerous, more sensitive, and more tightly regulated than in almost any other industry.

MCP reached 97 million monthly SDK downloads by late 2025 and has been adopted by every major AI provider: Anthropic, OpenAI, Google, Microsoft, and Amazon. The April 2026 shift is that the ecosystem is now acting like real infrastructure - registries, working groups, auth, task lifecycle, and enterprise rollout are getting more serious attention than protocol hype. The three-layer AI protocol stack - MCP for tools, A2A for agents, WebMCP for web access - is becoming the consensus architecture for enterprise deployments.

The BFSI MCP Server Taxonomy

Every financial data source or system capability becomes an MCP server. The taxonomy for a typical tier-two bank implementation:

Core Banking MCP Server exposes account balances, transaction history, product holdings, and customer relationship data. This is the most sensitive server in the stack and requires the most rigorous access control - row-level security ensuring each agent only sees the customer records its task authorizes.

Credit Intelligence MCP Server exposes credit bureau data, internal credit scores, debt-to-income calculations, and credit limit recommendations. This server must be flagged as a high-risk AI use case under the EU AI Act, requiring additional transparency and human oversight mechanisms.

Sanctions and AML MCP Server exposes real-time sanctions screening, PEP checks, adverse media monitoring, and AML alert queues. Every call to this server must be logged with immutable timestamps - this is not optional observability but a regulatory compliance requirement.

Market Data MCP Server exposes real-time and historical price data, volatility surfaces, yield curves, and benchmark rates. Latency requirements for this server are significantly tighter than others - sub-100ms for trading applications.

Document Intelligence MCP Server exposes document parsing, OCR, entity extraction from financial documents, and KYC document verification. This server wraps the bank's document management system and handles the unstructured data layer that other servers do not cover.

Regulatory Capital MCP Server exposes Basel III/IV capital adequacy calculations, RWA data, LCR and NSFR metrics, and regulatory limit monitoring. This server is read-heavy - agents query it to verify that proposed decisions comply with capital constraints before acting.

Communication MCP Server exposes customer communication channels - email, SMS, secure messaging - and handles delivery tracking, consent verification, and communication preference checking. No agent sends customer communications without routing through this server.

The MCP Wire Format in BFSI Context

A credit decisioning agent querying customer transaction history through MCP:

{
  "jsonrpc": "2.0",
  "method": "tool.call",
  "params": {
    "tool": "core_banking_api",
    "action": "get_transaction_history",
    "arguments": {
      "customer_id": "CUST-8847291",
      "period_months": 24,
      "include_categories": ["income", "regular_commitments", "irregular_debits"],
      "requesting_agent": "credit_decision_agent",
      "authorization_context": "CREDIT_ASSESSMENT_WORKFLOW_CR-20260608-001"
    }
  },
  "id": 1
}

The authorization_context field is not in the base MCP spec - it is a BFSI extension that links every tool call to the specific workflow and regulatory purpose that authorized it. This linkage is what makes the audit trail coherent: a compliance officer reviewing the audit log can trace every data access back to the specific customer interaction and business decision that justified it.

BFSI-Specific MCP Security Requirements

Standard MCP security is insufficient for financial services. Three additional layers are required in production.

Mutual TLS for all MCP connections. Standard HTTP with bearer tokens is acceptable for low-sensitivity applications. In BFSI, every connection between MCP client and MCP server must use mTLS - both sides present certificates, both sides are verified. This is the minimum standard for connections touching regulated financial data.

Role-based tool authorization at the MCP server level. Not every agent should have access to every tool on every MCP server. A customer service agent should be able to read account balances but not initiate transfers. A fraud detection agent should be able to read transaction patterns but not modify credit limits. MCP server-level RBAC enforces this regardless of what the calling agent requests - the server rejects tool calls that the calling agent's role does not authorize.

Data minimization in tool responses. MCP servers should return the minimum data required for the tool's stated purpose. A credit assessment query should not return the customer's full transaction history - it should return the summarized income and commitment data the credit model needs. Returning excess data creates unnecessary exposure and complicates GDPR compliance.

A2A in BFSI: Connecting Agents to Each Other

A2A is the horizontal layer - it connects AI agents to other AI agents. In BFSI, this is where the most complex and high-value automation lives, because financial workflows are inherently multi-agent: credit decisions involve risk, compliance, and customer agents simultaneously; fraud response involves detection, investigation, and remediation agents in sequence; regulatory reporting involves data collection, validation, and submission agents in a governed pipeline.

A2A launched in April 2025 with 50-plus supporting companies including Salesforce, PayPal, Atlassian, and major consulting firms including Accenture, BCG, Deloitte, McKinsey, and PwC. IBM's Agent Communication Protocol merged into A2A in August 2025. A2A v1.0.0 was released in April 2026, stabilizing the specification for enterprise adoption.

The A2A Agent Card in BFSI

Every A2A-compliant agent publishes an Agent Card at a well-known endpoint. In BFSI, Agent Cards carry additional metadata beyond the base specification:

{
  "name": "Credit Decision Agent",
  "version": "2.3.1",
  "description": "Evaluates retail credit applications against lending policy and regulatory requirements. Returns credit decisions with full rationale and confidence scores.",
  "url": "https://agents.internal.bank/credit-decision",
  "regulatory_classification": {
    "eu_ai_act_risk": "HIGH",
    "requires_human_oversight": true,
    "oversight_threshold_gbp": 50000,
    "regulated_activity": "CREDIT_ASSESSMENT",
    "fca_registration": "FCA-AI-2026-00471"
  },
  "capabilities": {
    "streaming": true,
    "human_in_the_loop": true,
    "audit_trail": "IMMUTABLE",
    "data_residency": "EU_ONLY"
  },
  "skills": [
    {
      "id": "retail-credit-assessment",
      "name": "Retail Credit Assessment",
      "description": "Assesses retail credit applications up to 500,000 GBP against current lending policy. Returns decision, rationale, confidence score, and required disclosures.",
      "input_schema": "CreditApplicationSchema_v4",
      "output_schema": "CreditDecisionSchema_v4",
      "avg_completion_seconds": 8,
      "human_review_required_above_gbp": 50000
    }
  ],
  "authentication": {
    "schemes": ["oauth2_client_credentials", "mtls"],
    "required_scopes": ["credit.read", "customer.read"]
  }
}

The regulatory_classification block is essential for BFSI A2A implementations. Any orchestrating agent consuming this Agent Card immediately knows that this agent is a high-risk AI system under the EU AI Act, requires human oversight for decisions above 50,000 GBP, and operates under a specific FCA registration. These constraints are machine-readable - the orchestrator can enforce them programmatically rather than relying on implementation-level guardrails.

A2A Task Lifecycle in Financial Workflows

A2A tasks progress through defined states: submitted, working, input-required, completed, canceled, and failed. The input-required state is particularly significant in BFSI - it is the protocol-level implementation of human-in-the-loop oversight.

When a credit decision agent encounters a boundary condition that exceeds its autonomous authority, it transitions the task to input-required and surfaces the decision context to a human reviewer through a defined interface. The task resumes from exactly that state when the reviewer responds. This is not a workaround. It is a first-class protocol feature designed for exactly the regulatory requirement that high-risk AI systems in financial services must support human oversight at defined decision points.

The Regulatory Layer: DORA, EU AI Act, and Basel III

Before implementing any agentic system in BFSI, three regulatory frameworks define the non-negotiable constraints.

DORA - Digital Operational Resilience Act

Effective January 17, 2025, DORA applies to all EU financial institutions and sets strict requirements for ICT systems including AI. Banks must assess AI failures under their incident classification process where they affect service availability, data integrity, confidentiality, authenticity, customers, or critical functions. Agentic workflows need documented fallback procedures, recovery objectives, and third-party exit plans - especially when they depend on a single LLM, cloud provider, or orchestration vendor.

The practical DORA requirement for MCP and A2A implementations: every agent interaction must be logged with sufficient detail to reconstruct what happened during an incident, classify the severity, and demonstrate that recovery procedures were followed.