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
| Requirement | Mechanism |
|---|
| Risk management system | Policy compilation validates rules before deployment |
| Testing before deployment | Simulate stage — dry-run without signing |
| Ongoing monitoring | Audit database queryable over time |
Article 10 — Data Governance
| Requirement | Mechanism |
|---|
| Data quality | Signal validation (VAL-xxx) before evaluation |
| Relevant data | signalsSchema restricts which signals are accepted |
| Bias examination | Policy JSON is human-readable — bias in rules is visible |
Article 12 — Record Keeping
| Requirement | Mechanism |
|---|
| Automatic logging | Every decision produces signed ExecutionAttestation |
| Input data reference | execution_fingerprint — SHA-256 of inputs |
| Logging period | executionId timestamp per decision |
Article 13 — Transparency
| Requirement | Mechanism |
|---|
| Transparency to deployers | Policy JSON is human-readable documentation |
| Intended purpose | policyId + policyVersion in every attestation |
| Deterministic behaviour | Same inputs always produce same decision |
Article 14 — Human Oversight
| Requirement | Mechanism |
|---|
| Human oversight | requires_override: true in policy rules |
| Override capability | requires_override flag in signed attestation |
| Stop functionality | Fail-closed — no partial decisions on any error |
Article 17 — Quality Management
| Requirement | Mechanism |
|---|
| Quality system | Policy compilation with error codes (POL-xxx) |
| Post-market monitoring | Audit database — query decisions over time |
| Incident reporting | GET /audit/security — violations and anomalies |
GDPR — Article 22 Automated Decision-Making
| Requirement | Mechanism |
|---|
| Right to explanation | decision.reason in every attestation |
| Right to human review | requires_override: true in policy rules |
| Logic information | Policy JSON is human-readable logic |
| Non-repudiable record | Ed25519 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
| Requirement | Mechanism |
|---|
| Single authoritative source | Policy bundle content-addressed by bundleHash |
| Data lineage | execution_fingerprint links decision to inputs |
| Automation | executeFromSignals() — fully automated governance |
Principle 3 — Accuracy and Integrity
| Requirement | Mechanism |
|---|
| Accurate data | Signal validation (VAL-xxx) enforces input accuracy |
| Reconciliation | execution_fingerprint enables reconciliation |
| Completeness | Required signals enforced — VAL-004 on missing |
Principle 6 — Adaptability
| Requirement | Mechanism |
|---|
| Flexible reporting | Audit database queryable by policy, time, decision |
| New risk categories | Add new policies without changing infrastructure |
FATF — AML/CFT
| Requirement | Mechanism |
|---|
| Auditability of automated decisions | Signed attestation per decision |
| Human oversight of high-risk decisions | requires_override: true for high-risk rules |
| Record retention | PostgreSQL audit-db — configurable retention |
| Suspicious activity | GET /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
| Control | Mechanism |
|---|
| Logical access | Ed25519 signing key — only key holder signs |
| System monitoring | GET /audit/security — violations and anomalies |
| Incident detection | INV-013 triggers security event |
| Change management | bundleHash changes on every policy change |
Availability
| Control | Mechanism |
|---|
| Health monitoring | GET /health endpoint |
| Performance | Millisecond latency per decision |
| Persistence | RedisReplayStore persists across restarts |
Processing Integrity
| Control | Mechanism |
|---|
| Complete processing | Fail-closed — no partial results |
| Error handling | Every error has specific code (VAL-xxx, POL-xxx) |
| Deterministic outputs | Same inputs always produce same decision |
Confidentiality
| Control | Mechanism |
|---|
| Data minimisation | Signals not embedded in attestations |
| Signatures | Ed25519 on all attestations |
| Access restriction | Public key published — private key protected |
Privacy
| Control | Mechanism |
|---|
| Data minimisation | Attestations contain signal hashes not values |
| Purpose limitation | signalsSchema declares which signals are in scope |
| Explanation | decision.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