What MCP changes in the financial stack
Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024. It gives an LLM agent a single controlled interface to external systems: databases, APIs, file stores, and real-time data streams. For a bank, this means the agent stops being just a text generator and gains permission to perform specific operations, not directly through endpoints, but through an intermediary layer with permissions and audit logging.
The key difference from classic API integration is that a regular API exposes the entire endpoint to the agent and expands the attack surface. MCP works at the task level - every action is checked against permissions and policies, and the agent itself never receives raw tokens or credentials. According to Arcade, the MCP server acts as an authorization proxy: "validating permissions and executing actions on behalf of agents without exposing underlying credentials" (Arcade).
This is an overview of open practices, not a KT.Team case study. Below is what the market is already doing and the business results it delivers.
Real-time risk scoring and fraud detection
The main benefit is that the agent sees the full customer journey, not just a single transaction. By connecting payment flows and fraud analytics through MCP, the bank gets "real-time anomaly detection with automated controls": the system cross-checks the transaction against fraud databases, puts a risky operation on hold, notifies the investigations team, and logs an audit trail for compliance in parallel (Arcade).
For AML, this becomes a multi-agent setup with role separation: one agent parses the alert and identifies the violated rule, a second analyzes current and historical transaction patterns, a third documents the findings, and only after human validation is regulatory reporting produced (Arcade). KYC onboarding when connecting to CRM and watchlist platforms drops from days to hours.
Business outcomes reported by industry pilot reviews: a 20-40% reduction in manual compliance work, a 40-70% reduction in operating costs, and decision cycle acceleration of up to 90% (Codiste, Arcade). Industry surveys show that fraud detection and prevention account for about 51% of MCP use cases in financial organizations.
Access to compliance data as a tool
A separate class of open solutions is MCP servers built on top of specialized risk databases. AML Watcher has released an MCP server that gives agents direct access to sanctions lists, watchlists, and PEP databases without "heavy" legacy integrations. The stated data refresh rate is "as fast as every 15 minutes," so models work from current signals rather than nightly exports (AML Watcher).
The key mechanism is enrichment: the bank's internal risk logic is combined with fresh external hits from an external database. This helps the model refine the risk score, suppress noise, and escalate only what is truly important (AML Watcher). For the risk office, this means "intelligent risk monitoring, regulatory reporting, and scenario analysis" layered over fragmented sources.
This is KT.Team's approach in pure form: do not build a proprietary sanctions engine, but use a mature external access standard ("read before you write"), while keeping the bank's business logic in its own adjacent services.
Access architecture and security controls
Controlled access does not mean "giving the agent the keys to everything." Open materials describe a three-layer model: MCP clients orchestrate connections, MCP servers sit behind the firewall as integration endpoints, and the Role and Policy Enforcement layer limits which agent can invoke which action (Arcade). Each call is recorded: initiator, action and parameters, policy check result, executed operation, and which data was accessed.
Without controls, MCP is dangerous. An academic risk review (arXiv) highlights prompt injection through user content, tool poisoning from untrusted servers, over-permissioning, and leakage of credentials/PII. Recommended controls for finance:
- Least privilege — role-based tool allowlists (reports, but not data deletion).
- Per-user OAuth — individual authentication instead of a shared token.
- Input/Output filtering (DLP) — blocking account numbers, PII, and secrets before agent processing.
- Audit & provenance — a full log of calls, parameters, responses, and timestamps to prove compliance.
- Human-in-the-loop — manual approval for high-risk operations (transfers, data exports, regulatory filings).
- Sandboxing and private registry — server containerization and version-pinned, code-reviewed MCP servers (arXiv 2511.20920).
This set maps well to banking requirements: BSA/AML, GLBA, PSD2/PSD3 SCA, and EU DORA, thanks to granular permissions, real-time access monitoring, and end-to-end auditing.
Process flow
The "event to decision" flow: transaction / new client -> MCP client creates a task for the agent -> MCP server (behind the firewall) checks permissions and policy (Role/Policy Enforcement) -> the agent uses task-level calls to read the transaction stream, fraud databases, and external sanctions/PEP data (refresh ~15 min) -> internal risk score enrichment -> branching: low-risk is passed through with an audit log entry; high-risk -> transaction hold + alert + human-in-the-loop validation -> regulatory reporting. An immutable audit trail and DLP filtering of PII run through every step.
Business process takeaway
MCP turns fragmented agent-to-banking-system integrations into a single controlled, auditable access layer. The business impact is measurable: fraud holds and AML escalations happen in real time on fresh data (up to a 15-minute refresh), manual compliance work drops by 20-40%, and onboarding shrinks from days to hours, while every agent action stays within least-privilege and is logged for regulators. The decision-making process itself should be redesigned: move risk logic and human validation into explicit steps on top of MCP, and connect external sanctions and fraud data through a mature access standard instead of building custom engines.
