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.

Enterprise rollout playbook​

The strongest banking deployments treat AxonFlow as a governed runtime platform, not a single application integration. Use the public compliance guides to map obligations, then make the rollout decisions below before expanding beyond the first workflow.

Capability map for banking​

Banking requirementAxonFlow capability
AI system inventory, validations, incident records, and board reportingRBI FREE-AI capability mapping and audit evidence
Securities, advisory, and capital-markets audit postureSEBI AI/ML mapping and structured decision records
Singapore financial-services governanceMAS FEAT mapping across fairness, ethics, accountability, and transparency
High-value customer or transaction decisionsHITL approval gates and Workflow Control Plane
PII and financial-data controlsPII detection and policy management
Provider and connector operationsProvider routing and the connector capability matrix

For serious banking and FinTech deployments, the usual starting posture is:

  • In-VPC or self-hosted deployment when data residency, internal network boundaries, or bank-owned operations matter.
  • Proxy Mode for high-sensitivity transactional or decision-support flows where AxonFlow should sit on the governed request path.
  • Gateway Mode for existing applications that already own direct provider calls and need governance without a rewrite.
  • WCP for approval-heavy, multi-step workflows such as investigations, KYC review, case routing, or payment release.

This lets one platform serve multiple business units while keeping provider ownership, connector authorization, approval routing, and evidence export understandable to the teams that run the platform.

Provider strategy for financial services​

Provider choice in banking is rarely only a model-quality decision. It is also an operational and risk posture decision.

PatternWhy teams choose it
Bedrock-firstFits AWS-aligned estates that want regional control and enterprise operating consistency
Mixed-provider routingSupports a default provider plus a second provider for failover, benchmarking, or tenant-specific needs
Gateway Mode with direct provider callsLets existing internal apps keep provider SDK ownership while adding centralized governance and audit
Private or self-hosted inferenceUseful when especially sensitive workflows require a tighter customer-controlled runtime boundary

Start with Provider Routing and Choosing an Integration Mode before standardizing provider choices across business units.

Connector strategy for banking workloads​

A banking platform usually needs stronger rules for connector rollout than a simple "can this connector work" checklist. Typical connector categories include:

  • governed analytics or warehouse access
  • CRM, case-management, or investigation systems
  • internal APIs for customer, account, transaction, or risk data
  • ticketing and ITSM systems for operational workflows

Before exposing a connector to AI workflows, decide who owns it, which tenants or business units can use it, how credentials rotate, whether it belongs to one tenant or a shared platform, and which response fields may flow onward to an LLM or another tool.

Governance and approval design​

Banking is one of the clearest cases for enterprise approvals and evidence workflows. Common rollout patterns include:

  • requiring review before high-value customer actions are finalized
  • adding HITL gates to risk-sensitive recommendations
  • exporting evidence for quarterly review, model-risk oversight, or regulator response
  • using kill-switch or incident workflows when a model, connector, or workflow becomes unsafe

The goal is to turn governance into a platform workflow instead of a scattered set of spreadsheets and email sign-offs.

Practical rollout sequence​

  1. Start with one governed workflow, such as a fraud investigation assistant, credit-policy copilot, advisory support assistant, or payment review flow.
  2. Define operating ownership for providers, connectors, system policies, tenant policies, approvals, evidence export, and compliance operations.
  3. Add the compliance module or evidence package that matches the real obligation: RBI FREE-AI for broad financial-services model governance, SEBI for securities or advisory workflows, and MAS FEAT for Singapore financial-services teams.
  4. Standardize deployment mode, identity pattern, provider fleet, approval policy, and evidence export cadence before onboarding multiple teams.

What good looks like: one platform team owns deployment, providers, and connectors; one governance or risk function owns review and evidence expectations; application teams build workflows on standardized controls; and every high-impact decision can be explained through the audit trail.

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 and uses your infrastructure controls. Governed traffic can stay within your VPC boundary when paired with in-boundary model and connector paths.Banks that want managed operations without using shared SaaS
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.

Assessment Path​

Use this page as a domain map, then validate the runtime with the same rollout path:

Last updated on