Skip to main content

RBI FREE-AI Compliance

For the report's legal status, operating-control summary, and product boundaries, start with the RBI FREE-AI governance overview. This page focuses on technical implementation and API workflows.

Community vs Enterprise: what you can run where

The community build gives you the cross-framework foundations this page relies on: audit logging, policy enforcement, and PII/data detection. The regulator-specific workflow modules and APIs described here (the compliance registry, regulatory reports and exports, readiness/assessment surfaces, retention controls, and kill-switch APIs, where a framework has them) are Evaluation and Enterprise capabilities. The Community, Evaluation, and Enterprise columns in the capability table below are authoritative for exactly what each item needs. A higher-limit self-hosted evaluation is available under the free 90-day Evaluation License.

The Reserve Bank of India released the Framework for Responsible and Ethical Enablement of Artificial Intelligence — FREE-AI — on 13 August 2025. It is the report of a committee constituted in December 2024 pursuant to the 6 December 2024 RBI Statement on Developmental and Regulatory Policies.

Important framing: FREE-AI is a committee report with 26 numbered recommendations, not a binding circular. Annexure IV of the report discusses "AI Specific Enhancements in RBI Master Directions" but does not itself amend any Master Direction; RBI may operationalise selected recommendations through subsequent Master Directions or circulars — check the RBI Master Directions register for current status. Regulated entities (REs) — banks, NBFCs, payment companies, cooperative banks — that align with FREE-AI ahead of formal circular notifications are building the controls RBI is already signalling it expects. Primary source: RBI FREE-AI report (August 2025).

What FREE-AI actually asks for​

FREE-AI is structured around 7 Sutras (guiding principles), 6 Pillars (three Innovation Enablement, three Risk Mitigation), and 26 Recommendations distributed across those pillars. The most operationally material for AI runtime controls:

RecommendationSummaryWhat it means in practice
Rec 14 — Board-Approved AI PolicyEvery RE must have a board-approved AI policy covering governance structure, accountability, risk appetite, operational safeguards, auditability, consumer protection, AI disclosures, model lifecycle, and liability framework.Board-level AI policy with a low/medium/high risk classification. High-risk examples named in the report include credit underwriting, autonomous AI making financial decisions, and systems moving customer funds.
Rec 15 — Data Lifecycle GovernanceData governance frameworks must comply with applicable legislation, including the DPDP Act, across the full data life cycle.Purpose-limited data handling aligned with DPDP Act phased rollout — substantive compliance activates 13 May 2027.
Rec 16 — AI System Governance FrameworkModel governance across design, development, deployment, and decommissioning. Strong governance required before deploying autonomous AI systems; tasks AI can perform autonomously must be clearly defined vs instances where human oversight is required.Human-in-the-loop on medium- and high-risk use cases; the RE remains liable for autonomous-AI outcomes.
Rec 17 — Product Approval ProcessAI-specific risk assessment integrated into product approvals — fairness, bias, understandability, cybersecurity, compliance. The review team must be independent of the AI development and deployment teams.Separation of duties; a specific gate before launch.
Rec 18 — Consumer ProtectionCustomers must be explicitly informed when interacting with AI and should always have the option to switch to a human.Transparency disclosure on every customer-facing AI touchpoint.
Rec 20 — Red TeamingMedium- and high-risk AI applications must have at least semi-annual red-teaming, plus trigger-based red teams on major model updates, after vulnerabilities, or on regulatory change.Scheduled offensive exercise, plus an incident path for triggered events.
Rec 21 — Business Continuity Plan for AIAn AI model should be able to declare itself "unavailable" when it fails and trigger backup processes. Mandatory HITL reviews; periodic human validation (e.g., 1% sample) to detect silent model degradation.Deterministic fallback path + sampled human review even when the model seems healthy.
Rec 22 — AI Incident ReportingTiered incident reporting framework at entity, sector, and national levels. Timely, good-faith reporting; time windows vary by severity and system-wide implications.Structured incident pipeline that can escalate to RBI and sector peers.
Rec 23 — AI InventoryComprehensive internal AI inventory updated at least half-yearly, covering model type, use case, third-party/cloud/data dependencies, risk categorisation, and grievances. Sector-wide repository via the RBIH EmTech Repository.Model registry with owners, dependencies, and risk rating — available for supervisory inspections.
Rec 24 — AI Audit FrameworkThree-level risk-based audit: internal audits proportionate to risk; third-party audits for high-risk or complex use cases; biennial review of the audit framework itself. Audits cover Input Data, Model and Algorithm, Output and Behaviour.Independent audit posture with preserved evidence; a BCP and human override check is part of the audit.
Rec 25 — DisclosuresAI governance disclosures in annual reports and websites, analogous to climate risk and cybersecurity disclosures today.Board reporting + external disclosure pipeline.

A concrete example: an Indian bank's customer-facing banking copilot​

Here is how a private-sector Indian bank usually lands on AxonFlow for an RBI-aligned deployment. The bank is building a customer-service and account-servicing copilot that answers account questions, drafts KYC follow-ups, helps with credit-card dispute triage, and — carefully separated from everything else — looks up loan-eligibility hints.

What RBI asks for, mapped to AxonFlow tiers:

FREE-AI requirementCommunityEvaluationEnterprise
Indian-PII detection on every governed prompt / response / connector result (Rec 15 DPDP alignment)sys_pii_pan, sys_pii_aadhaar in migrations; the platform india_pii_detector module covers 12 Indian identifier types (UPI, Aadhaar, PAN, IFSC, bank account, GSTIN, voter ID, driving licence, ration card, passport, Indian phone, pincode)SameSame + checksum-aware validation
Audit trail that survives a supervisory inspection (Rec 24)Governed LLM + MCP paths + per-request audit recordsSameSame + 10-year retention (AuditRetentionDays=3650)
Human review on medium/high-risk actions (Rec 16, Rec 21 BCP HITL)Policies can emit require_approval; no queue to act on themHITL queue (24h default, 100 pending cap)Production HITL queue + portal
Model fallback when the AI fails (Rec 21 "declare itself unavailable")Policies can route traffic to fallback via tenant rulesSameSame + /api/v1/rbi/killswitches first-class surfaces
AI system registry — Rec 23Not providedNot provided/api/v1/rbi/ai-systems with per-system records, owners, risk rating, dependencies
Model validation records — Rec 17 + 24Not providedNot provided/api/v1/rbi/validations with independent-reviewer approval transitions
Incident reporting — Rec 22Not providedNot provided/api/v1/rbi/incidents + /incidents/{id}/resolve
Board reports — Rec 14, 25Not providedNot provided/api/v1/rbi/reports with submit transitions for board-level disclosure
Audit exports for inspectionsRaw audit log; build the export yourselfSame/api/v1/rbi/audit-exports with /process + /download
RBI-readiness dashboardNot providedNot provided/api/v1/rbi/dashboard

What Community covers today​

Community is enough to prototype and validate most FREE-AI-aligned governance controls before committing to the Enterprise module:

  • audit logging with policy evaluation records
  • system and tenant policy enforcement
  • Indian-identifier detection on every governed prompt, response, and connector result (PAN and Aadhaar as dedicated sys_pii_* system policies; the full 12-type India detector on the india_pii_detector module)
  • governed runtime boundaries for LLM and MCP traffic — reviewable and monitorable

That makes Community a strong fit for engineering teams building the first iteration of a banking or fintech AI system before a compliance-driven rollout.

What Enterprise adds​

The dedicated RBI module is Enterprise-only. The verified API surface:

  • GET, POST /api/v1/rbi/ai-systems
  • GET /api/v1/rbi/ai-systems/summary
  • GET, PUT, DELETE /api/v1/rbi/ai-systems/{id}
  • GET, POST /api/v1/rbi/validations
  • GET, PUT /api/v1/rbi/validations/{id}
  • GET, POST /api/v1/rbi/incidents
  • GET, PUT /api/v1/rbi/incidents/{id}
  • POST /api/v1/rbi/incidents/{id}/resolve
  • GET, POST /api/v1/rbi/killswitches
  • GET /api/v1/rbi/killswitches/{id}
  • POST /api/v1/rbi/killswitches/{id}/deactivate
  • GET, POST /api/v1/rbi/reports
  • GET, PUT /api/v1/rbi/reports/{id}
  • POST /api/v1/rbi/reports/{id}/submit
  • GET, POST /api/v1/rbi/audit-exports
  • GET, DELETE /api/v1/rbi/audit-exports/{id}
  • POST /api/v1/rbi/audit-exports/{id}/process
  • GET /api/v1/rbi/audit-exports/{id}/download
  • GET /api/v1/rbi/policies/templates
  • GET /api/v1/rbi/policies/templates/{id}
  • GET /api/v1/rbi/policies/categories
  • GET /api/v1/rbi/dashboard

For the cross-framework view of regulated API families, use the Enterprise Compliance API Surface.

Industry playbook​

Commercial banks — customer-service + credit copilots​

The concrete flow above. Banks with large retail operations get the most value from the /ai-systems registry and /reports board-disclosure surface. The /killswitches surface matters because the RBI FREE-AI Rec 21 expectation — a model can declare itself unavailable and trigger backup — requires a first-class switch, not a config flag buried in an application.

NBFCs — loan-origination and collections AI​

For NBFCs (Non-Banking Financial Companies), the most material FREE-AI recommendations are Rec 14 (board-approved AI policy with risk classification), Rec 16 (autonomous decision framework — NBFCs often use AI to price loans, flag collection priority, and score creditworthiness), and Rec 22 (incident reporting — smaller NBFCs don't have mature incident frameworks; AxonFlow's /incidents workflow gives them the structured surface to adopt). Community policy enforcement + audit covers Rec 15 (data lifecycle, DPDP alignment). Enterprise covers the registry, validation, and reporting pieces that NBFCs otherwise build on spreadsheets.

Payment companies — transaction-monitoring + fraud AI​

Payment-system platform teams (PPIs, payment aggregators, fintechs under the PA-PG framework) face Rec 20 (at-least-semi-annual red teaming) and Rec 22 (tiered incident reporting) most directly, because payment-system failures cascade quickly. The /killswitches and /incidents endpoints become part of the real operational runbook, not compliance theatre.

Cooperative banks — internal research and analyst copilots​

Smaller cooperative banks often start with internal-only AI use cases — research assistants, analyst copilots, operational knowledge systems. Community is usually sufficient for these (Rec 15 data-lifecycle alignment, Rec 23 simple internal inventory). The move to Enterprise tends to wait until the bank expands into customer-facing AI or starts being asked about board-reportable AI inventory.

Example upgrade trigger​

A bank can start in Community to validate policy enforcement around customer prompts, internal copilots, and governed database access. The moment that same bank needs structured registry, incident, validation, or board-report workflows — whether driven by an internal audit, an RBI supervisory engagement, or a Master Direction operationalising FREE-AI — the Enterprise RBI module becomes the operationally credible path.

Enterprise Operating Workflow​

The licensed workflow surface below is included here so engineers can evaluate both the community baseline and the production operating model from one page.

The RBI module is the broadest compliance workflow surface in AxonFlow Enterprise today. It is designed for banking and financial-services teams that need more than request-time controls and want a governed operating model around AI systems themselves.

Requires Enterprise license.

FREE-AI Principles​

The RBI Framework for Responsible and Ethical Enablement of AI defines these principles:

PrincipleDescriptionAxonFlow Coverage
AccountabilityClear ownership of AI decisionsAudit trail, decision records
TransparencyExplainable AI outcomesDecision chain tracing
FairnessNon-discriminatory AIPolicy enforcement and externally computed fairness-evidence records
SafetyOperational safeguardsKill switch, circuit breaker
PrivacyData protectionPII detection and redaction
RobustnessReliable operationsValidation workflows, incident management

What The RBI Module Actually Includes​

The current enterprise build registers these route families:

AreaRoutes
AI system registry/api/v1/rbi/ai-systems, /api/v1/rbi/ai-systems/summary, /api/v1/rbi/ai-systems/{id}
Validations/api/v1/rbi/validations, /api/v1/rbi/validations/{id}
Incidents/api/v1/rbi/incidents, /api/v1/rbi/incidents/{id}, /api/v1/rbi/incidents/{id}/resolve
Kill switches/api/v1/rbi/killswitches, /api/v1/rbi/killswitches/{id}, /api/v1/rbi/killswitches/{id}/deactivate
Board reports/api/v1/rbi/reports, /api/v1/rbi/reports/{id}, /api/v1/rbi/reports/{id}/submit
Audit exports/api/v1/rbi/audit-exports, /api/v1/rbi/audit-exports/{id}, /process, /download
Templates and dashboard/api/v1/rbi/policies/templates, /api/v1/rbi/policies/categories, /api/v1/rbi/dashboard

All module routes use X-Org-ID for organization scoping.

Why This Matters For Banking Teams​

For many enterprises, "AI compliance" fails because the team can govern prompts and outputs but cannot answer harder questions:

  • Which AI systems are actually in production?
  • Who owns them?
  • When were they last validated?
  • Which incidents were material?
  • What was escalated to the board?
  • What evidence can we package for a review window?

The RBI module is built for those questions.

The strongest rollout pattern is:

  1. register every material AI system
  2. classify risk and ownership
  3. record validations on a real cadence
  4. log incidents and kill-switch activity as operational events, not ad hoc narratives
  5. package board reports and audit exports from the same system of record

That is what makes the docs and the product useful for a serious staff engineer or model-governance lead inside a regulated bank.

AI System Registry​

The registry is the anchor for the rest of the module. The create request supports system metadata, ownership, use case, data sources, residency, and validation cadence.

Register a system​

curl -X POST http://localhost:8080/api/v1/rbi/ai-systems \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "system_id": "credit-scoring-v2",
    "system_name": "Credit Scoring Model v2",
    "system_version": "2.1.0",
    "description": "Retail credit decision support",
    "risk_category": "high",
    "model_type": "ensemble",
    "model_provider": "internal",
    "use_case": "credit_decisioning",
    "use_case_description": "Assists loan underwriting decisions",
    "data_sources": ["bureau_data", "transaction_history", "kyc_data"],
    "sensitive_data_categories": ["pii", "financial"],
    "data_residency": "india_only",
    "owner_id": "risk-ml-1",
    "owner_name": "Risk ML Team",
    "owner_department": "Risk",
    "owner_email": "[email protected]",
    "validation_frequency_days": 90,
    "tags": ["lending", "retail"]
  }'

Use the summary endpoint to give risk, platform, and governance teams a common picture of system posture:

curl http://localhost:8080/api/v1/rbi/ai-systems/summary \
  -H "X-Org-ID: bank-india"

Validations​

Validation records are intentionally rich. The create request supports:

  • validator identity and organization
  • validation period
  • dataset description and size
  • test scenarios
  • findings
  • accuracy_metrics
  • bias_assessment
  • stress-test results
  • remediation requirements and deadlines
  • report file references

Record a validation​

curl -X POST http://localhost:8080/api/v1/rbi/validations \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "system_id": "credit-scoring-v2",
    "validation_type": "independent",
    "validator_type": "third_party",
    "validator_name": "External Model Risk Review",
    "validator_organization": "Independent Audit LLP",
    "dataset_description": "Quarterly retail lending sample",
    "dataset_size": 120000,
    "test_scenarios": ["bias_audit", "stress_test", "out_of_distribution"],
    "accuracy_metrics": {"auc": 0.91, "precision": 0.84},
    "bias_assessment": {"gender": 0.06, "region": 0.04},
    "recommendation": "approve_with_conditions",
    "remediation_required": true
  }'

For engineering teams, this is where validation becomes operational rather than a PDF parked in a shared drive.

Incidents​

The incident service is built for AI-specific operational events, not generic outage notes. The request shape supports incident type, severity, impact counts, financial impact, evidence files, and board or RBI notification flags.

Record an incident​

curl -X POST http://localhost:8080/api/v1/rbi/incidents \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "system_id": "credit-scoring-v2",
    "incident_type": "model_failure",
    "severity": "high",
    "detected_by": "monitoring-system",
    "title": "Score instability after feature pipeline change",
    "description": "A production rollout caused score volatility outside approved ranges.",
    "affected_customers_count": 142,
    "financial_impact_inr": 0,
    "immediate_action_taken": "Traffic shifted to prior approved model",
    "board_notification_required": true,
    "rbi_notification_required": false
  }'

Kill Switches​

The RBI module also has its own governance-oriented kill-switch workflow. This is distinct from the shared Agent-side emergency stop API and is useful when the control needs to be modeled as part of the RBI governance record.

Create a kill switch policy​

curl -X POST http://localhost:8080/api/v1/rbi/killswitches \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "scope": "system",
    "system_id": "credit-scoring-v2",
    "fallback_behavior": "deny",
    "trigger_condition": "manual",
    "trigger_threshold": {
      "bias": 0.10,
      "accuracy_floor": 0.80
    }
  }'

Deactivate a kill switch​

curl -X POST http://localhost:8080/api/v1/rbi/killswitches/ks-123/deactivate \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "actor_id": "risk-ops-1",
    "reason": "Validated fallback and cleared incident"
  }'

Board Reports​

Board reporting is where AxonFlow becomes useful for enterprise governance, not just runtime control. The report flow supports generation, listing, retrieval, updates, and submission.

Generate a report​

curl -X POST http://localhost:8080/api/v1/rbi/reports \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "report_type": "quarterly",
    "report_period_start": "2026-01-01T00:00:00Z",
    "report_period_end": "2026-03-31T23:59:59Z",
    "report_quarter": "Q1-2026",
    "generated_by": "compliance-ops",
    "generated_by_email": "[email protected]"
  }'

Submit for approval​

curl -X POST http://localhost:8080/api/v1/rbi/reports/report-123/submit \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "submitted_by": "compliance-ops",
    "submitted_by_email": "[email protected]"
  }'

Audit Exports​

The RBI audit-export service supports explicit export type, date range, system selection, risk category filters, archival inclusion, and stated business purpose.

curl -X POST http://localhost:8080/api/v1/rbi/audit-exports \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: bank-india" \
  -d '{
    "export_type": "full_audit",
    "format": "json",
    "system_ids": ["credit-scoring-v2"],
    "risk_categories": ["high"],
    "include_archived": false,
    "requested_by": "audit-team",
    "purpose": "Q1 governance review"
  }'

This is one of the best enterprise upsell surfaces in the product because it turns governance evidence into a repeatable engineering workflow instead of manual extraction.

Dashboard Caveat​

The RBI dashboard endpoint exists, but in the current code it returns module/component health rather than a rich executive dashboard. That still makes it useful for operational checks, but you should not rely on it as a full governance summary surface.

Last updated on