Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt

Use this file to discover all available pages before exploring further.

Purpose

This document maps Parmana Systems technical mechanisms to compliance requirements across Indian and global regulatory frameworks. Every mechanism cited is implemented and shipped. Nothing is aspirational. Frameworks covered:
  • RBI — Reserve Bank of India
  • IRDAI — Insurance Regulatory and Development Authority
  • SEBI — Securities and Exchange Board of India
  • DPDP Act 2023 — Digital Personal Data Protection
  • EU AI Act — High-Risk AI Systems
  • GDPR — Automated Decision Making
  • Basel III / BCBS 239 — Risk Data Aggregation
  • FATF — AML/CFT Guidance
  • SOC 2 Type II — Trust Service Criteria

The Compliance Foundation

Every governed decision produces one artifact: an ExecutionAttestation — Ed25519 signed over 17 fields. This single artifact satisfies audit trail, non-repudiation, policy versioning, and tamper-evidence requirements across all frameworks below.
// Every executeFromSignals() call produces this
const attestation = await executeFromSignals(
  {
    policyId:      "personal-loan",
    policyVersion: "1.0.0",
    signals: {
      monthly_income:  82000,
      loan_amount:     500000,
      employed:        true,
      emi_obligations: 12000,
      blacklisted:     false,
    },
  },
  signer,
  verifier,
  store
);

// attestation.decision.action       "approve" or "reject"
// attestation.decision.reason       which rule matched
// attestation.execution_fingerprint sha256 of inputs + policy
// attestation.policyId              which policy
// attestation.policyVersion         which version
// attestation.signature             Ed25519 — independently verifiable

India

RBI — Reserve Bank of India

Audit Trail (IT Governance Master Direction)

Every decision is stored in PostgreSQL via @parmanasystems/audit-db. Queryable via REST:
GET /audit/decisions?policyId=personal-loan&from=2026-01-01
GET /audit/decisions/:executionId
GET /audit/stats
GET /audit/security
The attestation is the audit record. It is cryptographically signed — cannot be altered without breaking the signature.

Non-Repudiation

Ed25519 signature over 17 attestation fields. Any party with the public key can verify any decision without accessing the original system.
const result = verifyAttestation(
  attestation,
  new LocalVerifier(publicKey),
  getRuntimeManifest(),
  provenanceInput
);

// result.checks.signature_verified   true/false
// result.checks.bundle_verified      policy bundle intact
// result.checks.evaluator_verified   evaluator unchanged
// result.checks.trust_root_verified  trust chain valid
// result.valid                       all checks passed

Policy Versioning (Change Management)

Every attestation records policyId, policyVersion, and bundleHash. Policy changes produce a new hash. Past decisions reference their exact bundle.
POL-001 through POL-022 — compilation errors block
deployment of invalid policies before they reach production.

Replay Prevention

Two-phase commit. Error code INV-013 on duplicate attempt. Security events appear in GET /audit/security. Alert on any INV-013 in production.

Fair Lending Evidence

execution_fingerprint = sha256({ policyId, policyVersion, signals }) Any signal not in the fingerprint did not affect the decision. Policies are auditable JSON — any reviewer can read the rules.

Signal Validation

All inputs validated before evaluation:
VAL-003  Signal not declared in schema — execution stops
VAL-004  Required signal missing — execution stops
VAL-006  Boolean signal invalid — execution stops
VAL-007  Integer signal invalid — execution stops
VAL-008  String signal invalid — execution stops
VAL-009  Enum value not in declared set — execution stops
No decision is made on invalid inputs. No silent failures.

Human Override Tracking

{
  "outcome": {
    "action": "reject",
    "requires_override": true,
    "reason": "Profile requires underwriter review."
  }
}
requires_override is signed into the attestation. Cannot be removed after signing. Queryable from audit database.

IRDAI — Insurance Regulatory and Development Authority

AI Governance Framework

Four-stage lifecycle enforces governance at every step:
Evaluate        — test hypothetical, no commitment
Simulate        — dry-run full pipeline, no signing
Execute         — governed decision, signed attestation
ConfirmExecution — verify execution matched authorization

Auditability of Claim Decisions

IRDAI inspectors can verify independently:
# Inspector needs only the public key and the attestation
parmana-verify \
  --attestation attestation.json \
  --public-key trust/root.pub \
  --policy-dir policies/insurance-claim/1.0.0
No access to the live system required. No cooperation from the insurer required.

Model Change Documentation

attestation.runtimeHash       — runtime version
attestation.evaluatorHash     — evaluation engine version
attestation.releaseManifestHash — release manifest version
Any change to the governance system produces attestations with different hashes. Past attestations remain verifiable against the runtime that produced them.

SEBI — Securities and Exchange Board of India

Algorithmic Decision Audit Trail

Ed25519 signatures — any tampering breaks the signature. Every attestation stored in audit-db. Security events queryable: GET /audit/security.

System Integrity

result.checks.runtime_verified    runtime matches manifest
result.checks.evaluator_verified  evaluator unchanged
result.checks.release_verified    release manifest valid
result.checks.trust_root_verified trust chain intact
Any modification to the governance system produces attestations that fail these checks.

Replay Prevention

INV-013 error code on duplicate execution attempt. Treat every INV-013 as a security event.

DPDP Act 2023

Data Minimisation

Raw signal values are not embedded in attestations. Only execution_fingerprint (SHA-256 hash) is included. This reduces personal data in the audit record.
attestation has: execution_fingerprint (hash)
attestation does NOT have: the raw signal values
Store raw signals in your own data store with appropriate DPDP controls. Parmana stores the hash.

Purpose Limitation

signalsSchema declares which signals are in scope. Signals not declared in the schema are rejected — VAL-003. Undeclared signals cannot affect decisions.

Right to Explanation

attestation.decision.reason   — which rule matched and why
attestation.decision.action   — "approve" or "reject"

Global

EU AI Act — High-Risk AI Systems

Lending, insurance, employment, and education AI systems are classified as high-risk under Annex III.

Article 9 — Risk Management

RequirementMechanism
Risk management systemPolicy compilation validates rules before deployment
Testing before deploymentSimulate stage — dry-run without signing
Ongoing monitoringAudit database queryable over time

Article 10 — Data Governance

RequirementMechanism
Data qualitySignal validation (VAL-xxx) before evaluation
Relevant datasignalsSchema restricts which signals are accepted
Bias examinationPolicy JSON is human-readable — bias in rules is visible

Article 12 — Record Keeping

RequirementMechanism
Automatic loggingEvery decision produces signed ExecutionAttestation
Input data referenceexecution_fingerprint — SHA-256 of inputs
Logging periodexecutionId timestamp per decision

Article 13 — Transparency

RequirementMechanism
Transparency to deployersPolicy JSON is human-readable documentation
Intended purposepolicyId + policyVersion in every attestation
Deterministic behaviourSame inputs always produce same decision

Article 14 — Human Oversight

RequirementMechanism
Human oversightrequires_override: true in policy rules
Override capabilityrequires_override flag in signed attestation
Stop functionalityFail-closed — no partial decisions on any error

Article 17 — Quality Management

RequirementMechanism
Quality systemPolicy compilation with error codes (POL-xxx)
Post-market monitoringAudit database — query decisions over time
Incident reportingGET /audit/security — violations and anomalies

GDPR — Article 22 Automated Decision-Making

RequirementMechanism
Right to explanationdecision.reason in every attestation
Right to human reviewrequires_override: true in policy rules
Logic informationPolicy JSON is human-readable logic
Non-repudiable recordEd25519 signed attestation
Note: GDPR Article 22 compliance also requires data subject rights processes outside Parmana. Parmana provides the technical audit record. Data subject rights workflows are your responsibility.

Basel III / BCBS 239

Principle 2 — Data Architecture

RequirementMechanism
Single authoritative sourcePolicy bundle content-addressed by bundleHash
Data lineageexecution_fingerprint links decision to inputs
AutomationexecuteFromSignals() — fully automated governance

Principle 3 — Accuracy and Integrity

RequirementMechanism
Accurate dataSignal validation (VAL-xxx) enforces input accuracy
Reconciliationexecution_fingerprint enables reconciliation
CompletenessRequired signals enforced — VAL-004 on missing

Principle 6 — Adaptability

RequirementMechanism
Flexible reportingAudit database queryable by policy, time, decision
New risk categoriesAdd new policies without changing infrastructure

FATF — AML/CFT

RequirementMechanism
Auditability of automated decisionsSigned attestation per decision
Human oversight of high-risk decisionsrequires_override: true for high-risk rules
Record retentionPostgreSQL audit-db — configurable retention
Suspicious activityGET /audit/security — replay attempts and violations

Example AML screening policy

{
  "policyId": "aml-transaction-screen",
  "policyVersion": "1.0.0",
  "schemaVersion": "1.0.0",
  "signalsSchema": {
    "risk_score":         { "type": "integer" },
    "is_sanctioned":      { "type": "boolean" },
    "transaction_amount": { "type": "integer" },
    "is_foreign":         { "type": "boolean" }
  },
  "rules": [
    {
      "id": "block-sanctioned",
      "condition": { "signal": "is_sanctioned", "equals": true },
      "outcome": {
        "action": "reject",
        "requires_override": false,
        "reason": "Entity is on sanctions list."
      }
    },
    {
      "id": "review-high-risk-foreign",
      "condition": {
        "all": [
          { "signal": "risk_score", "greater_than": 75 },
          { "signal": "is_foreign", "equals": true },
          { "signal": "transaction_amount", "greater_than": 100000 }
        ]
      },
      "outcome": {
        "action": "reject",
        "requires_override": true,
        "reason": "High-risk foreign transaction requires MLRO review."
      }
    },
    {
      "id": "catch-all",
      "condition": { "all": [] },
      "outcome": {
        "action": "approve",
        "requires_override": false,
        "reason": "Transaction cleared screening."
      }
    }
  ]
}

SOC 2 Type II

Security

ControlMechanism
Logical accessEd25519 signing key — only key holder signs
System monitoringGET /audit/security — violations and anomalies
Incident detectionINV-013 triggers security event
Change managementbundleHash changes on every policy change

Availability

ControlMechanism
Health monitoringGET /health endpoint
PerformanceMillisecond latency per decision
PersistenceRedisReplayStore persists across restarts

Processing Integrity

ControlMechanism
Complete processingFail-closed — no partial results
Error handlingEvery error has specific code (VAL-xxx, POL-xxx)
Deterministic outputsSame inputs always produce same decision

Confidentiality

ControlMechanism
Data minimisationSignals not embedded in attestations
SignaturesEd25519 on all attestations
Access restrictionPublic key published — private key protected

Privacy

ControlMechanism
Data minimisationAttestations contain signal hashes not values
Purpose limitationsignalsSchema declares which signals are in scope
Explanationdecision.reason in every attestation

Producing Evidence for Regulators

What to provide

1. ExecutionAttestation
   GET /audit/decisions/:executionId

2. Public key (not secret — publish it)

3. Policy version from your git repository

4. Optional: release manifest + bundle manifest

5. Optional: signal provenance records
   (AA consent IDs, CIBIL references, document hashes)

What regulators verify independently

✅ Decision was "approve" or "reject"
✅ Decision made by the stated policy version
✅ Inputs fingerprint matches claimed inputs
✅ Signature is valid — decision not altered
✅ Policy bundle intact — rules not changed
✅ Evaluation engine is claimed version
✅ Release manifest is authentic
✅ Trust root is the claimed trust root

Command-line verification

parmana-verify \
  --attestation attestation.json \
  --public-key trust/root.pub \
  --policy-dir policies/personal-loan/1.0.0

Implementation Checklist

Minimum

☐ executeFromSignals() for every governed decision
☐ audit-db (PostgreSQL) storing every attestation
☐ RedisReplayStore in production (not MemoryReplayStore)
☐ Signing private key in secrets manager
☐ Public key published
☐ Policies versioned with semver
☐ requires_override: true on manual review rules
☐ GET /audit/* routes accessible to compliance team

Stronger

☐ Signal provenance for AA and CIBIL signals
☐ accountAggregatorProvenance() for income signals
☐ confirmExecution() after each disbursement
☐ ExecutionIntegrityProof stored with attestation
☐ verifyAttestation() run daily in separate process
☐ Alert on release_verified === false
☐ Alert on evaluator_verified === false
☐ Alert on any INV-013

Full audit readiness

☐ Trust root public key at well-known URL
☐ Raw evidence hashes in provenance records
☐ Regulator portal using GET /audit/* routes
☐ Quarterly verifyAttestation() test from clean environment
☐ Policy git history preserved as change evidence
☐ Annual signing key rotation
☐ Offline encrypted trust root backup

See also