Skip to main content

AxonFlow for Banking & FinTech

Banking and FinTech teams are deploying AI agents that move money, approve credit, triage fraud, and serve customers. Every one of those workflows touches regulated data, crosses compliance boundaries, and carries financial liability if the agent acts incorrectly. AxonFlow provides the runtime governance layer that sits between your AI agents and the actions they take -- enforcing policies, detecting sensitive data, gating high-risk decisions for human review, and producing the audit trail your compliance team and regulators will ask for.

This page maps AxonFlow capabilities to concrete banking workflows, regulatory requirements, and deployment patterns. Everything described here is shipped and available today.

The banking AI governance challenge​

Banks are not short of AI ambition. The challenge is that regulators have moved faster than most governance tooling. In 2025 alone, the RBI published FREE-AI with 26 recommendations covering everything from AI system registries to kill switches. SEBI's Regulation 16C made regulated entities sole-liable for AI/ML outputs in Indian capital markets. The EU AI Act entered into force with tiered obligations through 2027. MAS FEAT established fairness, ethics, accountability, and transparency principles for Singapore financial institutions.

These frameworks share three common demands:

  1. Auditability. Every AI decision that touches a customer, a transaction, or a regulated process must produce a traceable record. Not a log line -- a structured audit record with decision identity, the policies that were evaluated, the verdict, and a timestamp that survives supervisory inspection.
  2. Human oversight on high-risk actions. No regulator is comfortable with an unsupervised AI agent approving loans, releasing payments, or modifying KYC status. The expectation is a deterministic gate: high-risk actions pause for human review before they execute.
  3. Data protection at the boundary. Credit card numbers, Aadhaar numbers, IBANs, and account identifiers must not leak into LLM prompts, MCP connector payloads, or downstream tool calls. Detection must be accurate (checksums, not just regex), and the enforcement action must be configurable per environment.

Generic LLM proxies do not solve this. A proxy that rewrites prompts cannot enforce approval gates on multi-step agent workflows. A logging layer that captures raw requests cannot produce the structured audit records an RBI inspection or PCI-DSS QSA assessment requires. A gateway that detects PII but cannot distinguish between an Aadhaar number (12-digit, Verhoeff checksum) and a random number string will either miss real violations or drown your team in false positives.

AxonFlow is purpose-built for this problem. It governs the entire agent execution lifecycle -- LLM calls, MCP connector invocations, multi-step workflows, and external tool use -- with policy enforcement, structured audit logging, PII detection with checksum validation, and human-in-the-loop approval gates.

Use cases​

1. Payment disbursement agent​

What the agent does: An AI agent processes vendor payments. It receives an invoice, validates line items against purchase orders, and initiates a bank transfer via a payments API.

What could go wrong: The agent retries on a network timeout and double-posts a payment. Or it includes the vendor's bank account number in a prompt to an LLM for "summarisation". Or it approves a payment above the authorised threshold without human sign-off.

How AxonFlow prevents it:

  • HITL approval gates pause any payment above a configurable threshold. The require_approval policy action routes the step to a human approval queue where a reviewer approves or rejects via the API. Unanswered requests auto-expire after 24 hours.
  • PII detection catches bank account numbers, IBANs (MOD-97 validated), and credit card numbers (Luhn-validated) before they reach an LLM. The action is configurable: block, redact, warn, or log. See PII Detection.
  • Idempotency enforcement via retry_context and idempotency_key prevents duplicate payments on retry. The full pattern is documented in the Payment Agent tutorial.

2. Lending automation agent​

What the agent does: A lending agent pulls applicant data from a CRM connector, queries a credit bureau via MCP, runs affordability calculations, and drafts a loan offer.

What could go wrong: The agent leaks the applicant's Aadhaar number or PAN into the LLM prompt used for offer-letter generation. Or the credit bureau connector returns data that the agent forwards to an unauthorised downstream tool. Or the agent approves a loan without the mandatory human review required by RBI FREE-AI Rec 16 for high-risk AI decisions.

How AxonFlow prevents it:

  • India PII detection identifies Aadhaar numbers (Verhoeff checksum validated), PAN (format ABCDE1234F), and UPI handles in every governed interaction. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation on every connector call: request-phase (before the call), response-phase (on the returned data), and exfiltration-phase (if data flows to another tool).
  • HITL gates on the loan-approval step ensure a human reviewer signs off before the offer is issued. The approval queue API integrates with existing loan-origination systems.
  • Audit logging produces a complete decision chain across every step: LLM calls, connector invocations, policy evaluations, and human approvals. See Audit Logging.
# Policy: require human approval on loan decisions above threshold
name: lending-high-value-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.loan_amount
    operator: gt
    value: 500000
  - field: step_metadata.step_type
    operator: eq
    value: loan_approval

3. Fraud investigation copilot​

What the agent does: A fraud analyst asks an AI copilot to summarise transaction patterns, flag anomalies, and draft suspicious activity reports (SARs). The copilot queries internal transaction databases, card-network data, and external watchlists via MCP connectors.

What could go wrong: The copilot includes card numbers or account identifiers in its LLM prompts. Or an analyst asks it to run a SQL query directly, and the prompt contains an injection payload. Or the copilot drafts a SAR with fabricated details that the analyst does not catch because there is no review gate.

How AxonFlow prevents it:

  • Credit card detection with Luhn validation catches card numbers in prompts and connector responses. Configured via PII_ACTION (LLM path), GATEWAY_PII_ACTION (gateway path), and MCP_PII_ACTION (connector path).
  • SQL injection scanning on all queries prevents prompt-injection attacks that attempt to extract or modify data. See SQL Injection Scanning. Configured via SQLI_ACTION.
  • HITL approval on the SAR-generation step ensures no report leaves the system without human sign-off.
  • Cost controls prevent runaway investigation loops from consuming excessive LLM budget. See Cost Management.
# Decision Mode: check a fraud-copilot query before it reaches the LLM
curl -s -X POST http://localhost:8080/api/v1/decide \
  -H "Content-Type: application/json" \
  -d '{
    "stage": "llm",
    "caller_identity": {
      "gateway_id": "fraud-copilot-gw",
      "tenant_id": "investigations-us"
    },
    "target": {
      "type": "llm",
      "model": "gpt-4o",
      "provider": "openai"
    },
    "query": "Summarise transactions for card ending 4532-0151-1283-0366"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "a3f1d7c2-9e8b-4a1f-b5c3-2d7e8f9a0b1c",
  "trace_id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d",
  "stage": "llm",
  "reasons": ["Credit card number detected (Luhn-validated)"],
  "obligations": [],
  "evaluated_policies": ["sys_pii_credit_card"],
  "expires_at": "2026-05-25T12:30:00Z"
}

4. KYC verification agent​

What the agent does: A KYC agent collects identity documents, extracts data via OCR, cross-references against government databases (via MCP connectors), and makes a verification decision.

What could go wrong: The agent stores extracted Aadhaar, PAN, or passport numbers in LLM context across sessions. Or it makes a final KYC determination without human review, violating the separation-of-duties requirement under RBI FREE-AI Rec 17. Or the connector response from a government database contains PII that leaks into an unrelated downstream call.

How AxonFlow prevents it:

  • India PII detection including Aadhaar (Verhoeff checksum) and PAN (format validation), plus global detectors for credit cards, email, phone, IBAN, and more -- applied in every governed path.
  • MCP exfiltration-phase scanning prevents identity data returned by a government connector from flowing to an unauthorised tool or LLM.
  • Governance profiles enforce a strict posture. Setting AXONFLOW_PROFILE=strict ensures all detections trigger enforcement actions, not just logging.
  • Evidence export (Evaluation and Enterprise) produces audit packages suitable for regulatory inspection. See Evidence Export.

5. Trade compliance monitoring agent​

What the agent does: A compliance monitoring agent watches trade executions in real time, flags potential breaches of position limits or restricted-securities lists, and escalates to compliance officers.

What could go wrong: The agent sends trade data containing client identifiers to an external LLM. Or it fails silently when the LLM provider is down, leaving trades unmonitored. Or it escalates so aggressively that compliance officers experience alert fatigue and stop reviewing.

How AxonFlow prevents it:

  • PII detection catches client identifiers (SSN format-validated, email, phone, DOB) in trade data before it reaches external LLMs.
  • Circuit breaker and kill switch (Enterprise) provide deterministic fallback when LLM providers are unavailable, ensuring the monitoring pipeline fails loud rather than failing silent. This directly addresses RBI FREE-AI Rec 21 (AI must "declare itself unavailable" on failure).
  • Cost controls with warn and downgrade actions prevent runaway monitoring loops from exhausting LLM budgets. Budget limits are configurable per tenant. See Cost Management.
  • Decision Mode lets the compliance platform call AxonFlow as a policy decision service at every gateway layer without modifying application code. See Decision Mode.

Regulatory mapping​

The table below maps specific regulatory requirements to shipped AxonFlow capabilities. Each requirement links to the relevant compliance page for the full analysis.

RequirementRegulationAxonFlow CapabilityDocs
Human oversight on high-risk AI decisionsRBI FREE-AI Rec 16require_approval action, HITL approval queue, 24h auto-expiry (Evaluation), configurable TTL (Enterprise)HITL Approval Gates
AI system must declare itself unavailable on failureRBI FREE-AI Rec 21Circuit breaker with configurable failure thresholds, kill switch (Enterprise)Choosing a Mode
Audit trail surviving supervisory inspectionRBI FREE-AI Rec 24Multi-layer audit logging (Agent, Orchestrator, MCP, Workflow, Plan) with decision_id, verdict, evaluated policies, timestamp, identityAudit Logging
Data lifecycle governance (DPDP Act alignment)RBI FREE-AI Rec 15India-specific PII detection including Aadhaar (Verhoeff checksum) and PAN (format validation), plus global detectors for credit cards, email, phone, IBAN, and morePII Detection
Sole liability for AI/ML outputsSEBI Reg 16CPolicy enforcement at every governed boundary, HITL gates, structured audit trail proving governance was active at time of decisionAudit Logging
Card data protectionPCI-DSSCredit card detection (Luhn algorithm), configurable action per path: block / redact / warn / logPII Detection
IBAN protectionPCI-DSS, PSD2IBAN detection (MOD-97 checksum), same action configurationPII Detection
AI system transparency and explainabilityEU AI Act Art. 13-14Structured decision records with evaluated policies, verdict rationale, and W3C traceparent correlation across gateway layersDecision Mode
Human oversight for high-risk AIEU AI Act Art. 14HITL approval gates with API-driven approve/rejectHITL Approval Gates
Accountability and Transparency (FEAT Pillars)MAS FEATPolicy enforcement, audit logging, evidence export, governance profilesMAS FEAT

Note on PCI-DSS: AxonFlow is not PCI-DSS certified. It provides PII detection and audit capabilities that help reduce PCI-DSS scope for AI systems by preventing card data from reaching LLM providers and producing structured audit records of enforcement actions. PCI-DSS certification is the responsibility of your organisation's QSA assessment.

Reference architecture​

The diagram below shows AxonFlow in a typical banking stack. The pattern applies whether your AI agents are internal tools, customer-facing copilots, or back-office automation.

Every interaction between an agent and an LLM provider passes through the Orchestrator, where policies are evaluated and PII detection runs. Every interaction between an agent and a banking data source passes through the MCP Gateway, where three-phase policy evaluation (request, response, exfiltration) applies. High-risk steps route to the HITL queue. All decisions produce structured audit records.

Decision Mode for banking infrastructure teams​

Large banks and FinTech platforms typically run multiple gateway layers: an agent gateway that routes agent traffic, an MCP or tool gateway that governs connector access, and an LLM gateway that manages provider calls. Asking these teams to rearchitect their traffic flow through a new proxy is not realistic.

Decision Mode solves this. AxonFlow runs as a standalone policy decision service. Each gateway makes one inline POST /api/v1/decide call per request, receives a verdict (allow, deny, or require_approval), and enforces it locally. AxonFlow is never on the traffic path -- it is consulted, not traversed. This is the PDP/PEP pattern used across the industry by policy engines like OPA, XACML, and Cedar.

The shipped reference adapters cover all three gateway layers:

Each gateway passes a stage identifier (llm, tool, or agent) and a caller_identity with its gateway_id and tenant_id. AxonFlow evaluates the same policy hierarchy for all three and returns a verdict with a trace_id that correlates decisions across layers using W3C traceparent headers. The result: one audit trail, one policy brain, enforcement at every layer, and zero changes to your existing gateway code beyond the HTTP call.

For the full API reference, request/response schemas, and curl examples, see Decision Mode. For guidance on when to use Decision Mode versus Gateway Mode, Proxy Mode, or Workflow Control Plane, see Choosing an Integration Mode.

Deployment options for banking​

Banking teams have strict requirements around data residency, network isolation, and control over infrastructure. AxonFlow supports three deployment modes:

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full control over data, network, and upgrades.Banks with strict data-residency or air-gapped requirements
In-VPCAxonFlow runs inside your AWS VPC. No data leaves your network boundary. Managed by AxonFlow with your infrastructure controls.Banks that want managed operations without data leaving their VPC
SaaSManaged by AxonFlow in us-east-1. Fastest path to production.FinTech startups and teams that do not have data-residency constraints

All three modes support the same feature set. See Deployment Mode Matrix for the full comparison and Licensing for tier details.

A working example: the banking example​

The Banking Example walks through a complete end-to-end setup: configuring PII detection for Indian identifiers, setting up HITL approval gates on high-value transactions, enabling SQL injection scanning, and verifying the audit trail. It includes Docker Compose configuration, policy definitions, and test scripts.

Start there if you want to see the full picture running locally before mapping it to your own use cases.

Getting started​

Step 1: Run locally. Follow the Getting Started guide to run AxonFlow on your machine in under 5 minutes.

Step 2: Try the banking example. The Banking Example shows PII detection, HITL gates, and audit logging configured for banking workflows.

Step 3: Follow the payment agent tutorial. The Payment Agent - Retry & Reconciliation tutorial walks through building a payment agent that survives network failures without double-charging.

Step 4: Map your regulatory requirements. Use the compliance pages for your jurisdiction:

Step 5: Evaluate with real workloads. Request a free Evaluation License for self-hosted validation with HITL approval gates, evidence export, and higher limits. If you need enterprise features, direct rollout support, or managed SaaS, apply for the Design Partner Program.

Last updated on