Part 10 — System Blueprint

BRE Runtime Architecture

The BRE runtime should behave like a deterministic computation service, not a workflow engine, database-backed report builder or hidden underwriting desk. It receives a complete input snapshot, chooses an immutable rule_version_id, evaluates precompiled artifacts and returns a decision object. LOS workflow owns state movement, credit workbench owns CAM judgement, LMS owns booked dues and DPD, and the co-lending module owns partner_share, escrow and DLG ledgers. The BRE computes policy and records its trace.

This architecture also keeps the regulatory story clean. RBI’s June 24, 2026 draft Guidance on Regulatory Principles for Model Risk Management expects model inventory, documentation, validation, approval, monitoring, change management, business continuity and decommissioning controls across all material models, including third-party and AI/ML models (RBI draft model risk guidance transcript). The runtime therefore has to support versioning, replay and audit by design.

Runtime Shape

Component	Responsibility	Non-responsibility
Ruleset compiler	Converts authored decision tables, expressions, scorecards and DRD metadata into immutable artifacts	Does not evaluate live applications
Artifact registry	Stores `rule_version_id`, artifact hash, effective dates, validation status and rollback pointer	Does not edit rules in place
Version pointer service	Resolves active ruleset for product, lender, channel and decision point	Does not perform business evaluation
Stateless evaluator pods	Evaluate input snapshot against precompiled artifact and return output plus trace	No per-request DB reads for rules; no hidden feature fetch
Feature snapshot service	Freezes feature payloads from data-fetch DAG into encrypted object storage	Does not decide policy
Decision persistence adapter	Insert-if-absent by idempotency key; returns stored decision on replay	Does not mutate application state
Trace store	Stores per-node timing, rule-hit and hashed input/output records	Does not expose raw PII to broad roles

Compile on publish. A published artifact is immutable. Hot-swap uses a version pointer update, not pod restart or database row edits. Evaluator pods load current and recent artifacts into memory, watch for pointer changes, and keep old versions long enough to replay in-flight requests. This pattern supports commercial decisioning practice too: public Experian and Scienaptic material describes decision platforms with strategy testing, simulation, performance monitoring and versioned strategies, while FinBox distinguishes the decisioning layer from LOS workflow orchestration.

Orchestration Before Evaluation

Data fetching happens before evaluation through a DAG owned by integrations and credit ops. The DAG produces the canonical request described in BRE functional specification.

Data node	Parallelizable	Gate condition	Output
Dedupe and internal exposure	Yes	PAN/GSTIN/mobile available	Party/group match, exposure, block flags
KYC and BO status	Yes	Application parties created	`party_features`, KYC completeness, screening status
Bureau pull	Yes after consent	Active bureau consent and identifiers	`bureau_features`, obligations, score/rank
AA/banking pull	Yes after consent	Active AA or upload consent	`banking_features`, ABB, bounces, credits, EMI debits
GST/Udyam	Yes	GSTIN/Udyam or consent available	Turnover, filing discipline, MSME status
Financial spread	No for manual files	Uploaded/audited/provisional financials	Ratios, cash accrual, DSCR inputs
Collateral/valuation	Usually async	Secured product or collateral offered	LTV, legal status, insurance gaps
Partner/anchor feed	Yes	Partner consent and program active	GMV, settlement, churn and seller status

Synchronous decision path: pre-screen, small-ticket eligibility, pricing and deviation classification where all mandatory data is present. Async enrichment: collateral legal opinion, field investigation, uploaded financial spreading, partner callbacks, third-party model fallback. The engine must return refer rather than block forever when a required async node is incomplete.

Latency Budget

The numbers below are engineering targets for this reference architecture. They are not industry benchmarks and should be tuned after load testing.

Stage	p50 target	p95 target	p99 target	Notes
Version pointer lookup	2 ms	8 ms	15 ms	In-memory cache with registry fallback
Input schema validation	5 ms	15 ms	30 ms	JSON schema plus feature freshness checks
Rule/table evaluation	15 ms	50 ms	100 ms	CPU-bound for typical SME rulesets
Scorecard/model node	10 ms	40 ms	120 ms	Local scorecard; external model excluded
Co-lending allocation computation	5 ms	20 ms	50 ms	Split, blended rate and partner verdict merge
Reason-code ranking	5 ms	20 ms	50 ms	Deterministic ranker
Trace serialization	10 ms	40 ms	100 ms	Full trace to queue or write-optimized store
Decision persistence	15 ms	60 ms	150 ms	Insert-if-absent on idempotency key
End-to-end decision call	80 ms	250 ms	600 ms	Engineering target after feature snapshot exists

For borrower-facing digital journeys, keep hard timeout at 1.5 seconds after snapshot creation. For credit workbench and batch monitoring, the timeout can be longer because human or portfolio processes absorb delay. Data-fetch SLAs are separate and usually dominate total elapsed time.

Throughput And Scaling

Rule evaluation is mostly CPU-bound once features and artifacts are in memory. Horizontal scaling is therefore straightforward: add stateless evaluator pods behind a load balancer, pin max concurrency per pod, and isolate heavy model nodes from basic rule tables if needed.

Scale dimension	Engineering target	Design control
Per-pod simple evaluations	300-800 eval/sec	4 vCPU pod, preloaded artifacts, no rule DB read
Per-pod mixed evaluations	100-300 eval/sec	Scorecards, co-lending allocation and trace serialization included
Cluster burst	Hundreds to thousands eval/sec	Horizontal pod autoscaling on CPU, queue depth and p95 latency
Marketplace batch offers	50,000-500,000 batch rows per run	Batch workers, trace sampling for non-issued offers, full trace for issued offers
Interactive journey	1 request per borrower action	Strict timeout, load-shed optional enrichment first

Load-shedding should preserve regulatory controls. Shed optional enrichment, simulation calls and non-critical trace analytics before shedding final decision persistence. If persistence is unavailable, return error and no borrower-facing approval. If monitoring batch is overloaded, queue with delay and alert policy_risk; do not silently skip EWS re-score.

Feature Caching

Source	Suggested TTL engineering target	Hard bound
Bureau report	7-30 days by product policy	Consent scope, CIC rules and lender policy
AA/banking	24 hours for instant journey; 7 days for manual CAM if no new statement needed	Consent expiry and statement end date
GST returns	Until next filing cycle or 7 days for live fetch	Return period and consent
Udyam/KYC	30 days for classification; current for KYC status	KYC risk and periodic review controls
Internal exposure	5 minutes for pre-screen; real-time before sanction	Internal ledger source of truth
Anchor data	Same day for daily feed; minutes for real-time settlement feed	Program agreement and consent
Collateral valuation	Product policy, often 30-180 days	Legal/valuation validity and market movement triggers

Cache keys must include party_id, source identifier, consent id or scope, feature version, source timestamp and transformation version. Do not cache only by PAN or GSTIN. Use request coalescing and stampede protection for bureau, AA and GST pulls: the first request owns the fetch, concurrent requests wait or use permitted stale data with staleness flags.

Concurrency And Idempotency

The idempotency key is:

application_id + decision_point + input_snapshot_hash + rule_version_id

For co-lending, include cla_id and partner policy version when partner verdict is part of the output. For monitoring/EWS, use loan_account_id, decision point, snapshot date and rule version.

Exactly-once decision persistence uses insert-if-absent on idempotency_key. If a duplicate request arrives, return the stored bre_result_id and canonical output. Never run a new decision with the same key and overwrite the old trace. Application state movement stays with LOS. LOS applies optimistic locking against application.application_state and version: a decision computed for credit_in_review cannot move a file that has already become rejected, sanctioned or returned_for_rework.

Out-of-order callbacks from data providers are handled by snapshot versioning. If an AA callback arrives after a decision has been issued, it creates a new feature snapshot and optional re-evaluation task. It does not mutate the old decision. Concurrent re-evaluations are allowed only when their snapshot hashes differ, their rule versions differ, or their decision points differ.

Determinism And Replay

Same snapshot plus same rule_version_id must reproduce the decision bit-for-bit. This is the core audit promise.

Forbidden nondeterminism:

Pattern	Replacement
Reading wall clock inside a rule	Inject `evaluation_timestamp` as input
Random challenger assignment inside evaluator	Precompute challenger bucket in caller or experiment service
Calling mutable reference data	Version-pin reference data in snapshot
Floating-point financial math with runtime-dependent rounding	Use decimal math and stored rounding mode
External model call without version/hash	Store model version, feature vector hash and response hash
Rule reading current DB state mid-evaluation	Include required state in feature snapshot

Replay has two modes. Audit replay returns exact historical output using old artifact and snapshot. What-if replay uses historical snapshots with a new candidate ruleset and writes to a simulation namespace only. What-if replay must never create deviation, sanction_condition, partner_share or borrower-facing offers.

Failure Modes And Degradation

Failure	Runtime behavior	Allowed degradation
Bureau provider timeout	Data DAG retries with circuit breaker	If bureau is mandatory, return `refer` or `provider_unavailable`; do not approve with missing bureau
AA/GST provider unavailable	Queue async enrichment and mark missing source	Cached-feature decision only if staleness policy permits
Artifact registry down	Continue with in-memory active artifacts	Block publish and pointer changes
Version pointer conflict	Use pointer resolved at request start	Persist resolved `rule_version_id` in trace
Trace store slow	Persist decision first, enqueue trace with back-pressure	If trace queue full, fail closed for sanction decisions
Decision DB unavailable	No final decision returned	Caller retries with same idempotency key
External model unavailable	Use documented fallback scorecard only if approved	Otherwise `refer`
Co-lender partner verdict delayed	Return originator verdict plus partner pending	No final co-lending sanction until both policy verdicts are resolved

Circuit breakers are per data provider and per endpoint. They maintain states closed, open, half_open, thresholds, retry-after timestamp and owner. Timeout policy must be shorter than borrower-facing SLA. Retries are safe because decision persistence is idempotent, data fetches carry provider request ids, and payment or booking side effects are outside the BRE.

Observability

Signal	Dimension	Owner
Decision volume	Product, channel, decision point, ruleset version	`policy_risk`, engineering
Outcome mix	Approve/refer/decline/error, reason code	`policy_risk`, credit
Latency	p50/p95/p99 by stage and node	Engineering
Rule-hit distribution	Rule id, score band, deviation severity	`policy_risk`
Drift alerts	Feature distributions, score bands, approval mix, bad-rate lag	Risk analytics
Override rate	Rule outcome versus human final decision	Credit management, internal audit
Canary dashboard	Champion/challenger version, split, stop-loss metrics	`policy_risk`
Co-lending mismatch	Originator verdict, partner verdict, split, booking age	Partner ops and finance
Trace completeness	Full trace present, snapshot hash present, PII policy	Compliance and audit

Full trace retention is required for issued decisions and model governance. For high-volume pre-approved marketplace offers that are never shown to borrowers, retain aggregate metrics and sampled traces until the offer is issued; once an offer is displayed, preserve full trace. The trace sampling policy itself should be documented and reviewed.

Security

BRE inputs include PAN, GSTIN, bureau data, bank transactions, financial statements, KYC, anchor data and sometimes collateral documents. Use encryption in transit and at rest. Secrets for bureau, AA, GST and partner calls remain in integration services, not evaluator pods. Evaluator pods receive normalized features, not provider credentials.

Access follows actors permissions:

Role	Access
`policy_risk`	Rule definitions, aggregate traces, masked feature values, simulation data
`credit_analyst`	Application decision output, reason codes and rule trace needed for CAM
`credit_manager` / `national_credit_head`	Deviations, DoA routing, decision trace and approval context
`partner_api_client`	Contracted status, partner verdict and borrower-facing reasons only
`dsa_user`	Coarse status only; no hidden rule thresholds or bureau data
`internal_auditor`	Read-only evidence export, masked unless approved audit purpose requires detail
`system_admin`	Platform administration, no business approval or unlogged export

Deployment And Operations

Operation	Procedure
Publish ruleset	Compile, validate, simulate, approve, store artifact, update pointer atomically
Canary	Send defined percentage or segment to challenger, with deterministic assignment outside evaluator
Rollback	Repoint active version, keep failed version for audit, run impact replay
Scale out	Add pods; warm artifacts before receiving traffic
Disaster recovery	Restore artifact registry, pointer store, decision DB, snapshot store and trace store to consistent point
Decommission	Mark ruleset/model inactive, preserve inventory and traces, remove from pointer service