BFSI Compliance

Rensei's BFSI (Banking, Financial Services, and Insurance) compliance layer is a production-grade regulatory framework for organizations operating under SR 11-7, SOX, PCI-DSS, DORA, and related financial industry regulations. It provides automated risk scoring, human approval gates, segregation-of-duties enforcement, data residency controls, and compliance artifact generation - all integrated with the workflow engine.

Tenant tier detection

BFSI logic activates per-org based on the compliance_tier feature flag set by your Rensei operator. Tenants configured as regulated receive the full BFSI pipeline; standard tenants bypass all BFSI checks and run the standard execution path.

Risk scoring

assessRisk(input) evaluates a change against multiple risk factors and returns a numerical score (0-100) with a routing decision.

Risk factors

assessRisk() computes a weighted sum across four factors (weights sum to 1.0):

Infrastructure files are detected by pattern matching against paths including terraform/, pulumi/, cdk/, *.tf, *.hcl, docker-compose*, Dockerfile, .github/workflows/, k8s/, kubernetes/, helm/, .env*, and deploy/.

The weighted sum is rounded to the nearest integer (0-100). A runtime timestamp defaults to new Date() if not supplied.

Risk routes

const assessment = assessRisk({
  filesChanged: ['infra/terraform/main.tf', 'src/api/payments.ts'],
  dataClassificationsAccessed: ['pci'],
  servicesAffected: ['payment-service', 'fraud-detection', 'ledger'],
  isInfraChange: true,
})
// assessment.score ≈ 85 (infra + PCI + 3 services)
// assessment.route = 'cab-review'
// assessment.factors = [
//   { name: 'files_changed', weight: 0.25, value: 17, ... },
//   { name: 'data_classification', weight: 0.30, value: 90, ... },
//   { name: 'blast_radius', weight: 0.25, value: 80, ... },
//   { name: 'time_of_day', weight: 0.20, value: 0, ... },
// ]

Deployment window enforcement

checkDeploymentWindow() enforces market-hours deployment restrictions. By default, deployments are blocked during active market hours (Mon-Fri 09:30-16:00 ET) for PCI/regulated tenants.

const result = checkDeploymentWindow(new Date())
// During market hours:
// { allowed: false, reason: "Deployment during market hours (Mon-Fri 9:30-16:00 ET) requires CAB approval", nextWindow: Date }
// Outside market hours:
// { allowed: true }

This is configurable per-org. Off-hours deployments are logged to the audit trail regardless of whether they are allowed.

Segregation of duties

evaluateBfsiSegregationGate(input: BfsiGateInput) enforces role separation across SDLC stages. It is wired into a gate workflow node - not a bespoke dispatch-time hook - so the workflow engine enforces SR 11-7 segregation of duties as a first-class step. The gate is a no-op for read-only and internal-only verbs; it only activates on external-write verbs.

The built-in segregation rules prevent the same actor from holding conflicting roles:

const decision = evaluateBfsiSegregationGate({
  sideEffectClass: 'external-write',
  assignments: [
    { stageName: 'Development', actorId: 'user_alice', actorRole: 'development' },
    { stageName: 'QA', actorId: 'user_alice', actorRole: 'qa' },  // violation!
  ],
})
// decision.allow = false
// decision.violations = ["Actor user_alice cannot hold both 'development' and 'qa' roles"]

BFSI pipelines

Two pipeline configurations are provided out of the box. Both are arrays of StageDefinition objects, each with required gates, tool restrictions, and segregation rules.

Standard pipeline (BFSI_STANDARD_PIPELINE)

The standard pipeline covers the full regulated SDLC. Each stage defines required gates, the roles that can approve, required approval count (requiredCount), timeout, and onTimeout behaviour:

Stages with segregationRule set (Development, QA, Deploy) enforce dev-qa-deploy - the same actor cannot hold two or more of the roles development, qa, deploy.

Emergency pipeline (BFSI_EMERGENCY_PIPELINE)

A condensed pipeline for emergency hotfixes. Compresses to Emergency Development → Emergency Security → Emergency Deploy. All gates have short timeouts (1-4h) with deny on timeout and enforce the dev-deploy segregation rule.

Compliance artifacts

After a successful workflow run, generateComplianceArtifact() produces a structured record including:

• Participants and their roles at each stage
• Gate decisions (approved/rejected/escalated) with timestamps
• Risk assessment score and route
• Segregation-of-duties validation result
• Audit chain reference (workspace ID + sequence range)

These artifacts are stored in compliance_artifacts and are available at GET /api/compliance/artifacts.

Cedar policy integration

The BFSI module ships 11 Cedar policies. Installation into your org's policy set is performed by your Rensei operator during BFSI onboarding. Operator-level BFSI policy installation is covered in the operator docs.

All policies:

See Cedar Policies for the full policy evaluation model and the Cedar syntax used in each policy.

Workflow integration

Approval gates are wired into the workflow executor through the gate bridge. When a workflow reaches a gate-protected BFSI stage, the bridge:

1. Calls onStageTransition() to create the required approval gates
2. Returns blocked: true to the workflow executor
3. The executor suspends the workflow instance and emits a gate.waiting signal
4. When all gates resolve, the bridge emits gate.proceed and execution resumes

See Approval Gates for the complete gate lifecycle.

Related pages

• Approval Gates - gate creation, decision submission, escalation
• Cedar Policies - BFSI policy library and evaluation
• SDLC Variant Templates - sdlc-bfsi and model-risk workflow templates
• Audit Trail - compliance artifact events in the hash chain
• Workflow Gates - gate node suspension and timeout handling