Part of the Business Rules Engine series.
TL;DR: Credit decisioning platform ownership is typically shared: Risk/Credit teams own policy logic, rules, and scorecards, while IT/Engineering owns integration, uptime, and data pipelines — with overall governance sitting under the CRO or CTO depending on org maturity. CROs use decisioning platforms to reduce NPA by codifying underwriting policy into auditable rule-based decisioning and ML-based decisioning layers, enabling faster iteration on cutoffs, segment-level scorecards, and early-warning triggers without engineering dependency. A credit decisioning OS like FinBox Sentinel separates business logic (decision tables, scorecards) from core banking/LOS systems, letting Risk teams test and deploy policy changes independently while IT retains control over infrastructure and data integrations. This ownership split is now standard across Indian NBFCs and banks adopting decision engines for retail and MSME lending.
Who Owns the Credit Decisioning Platform — Risk or IT?
There is no single correct answer here, and lenders who force one function to own the entire stack usually run into friction within a few quarters. The practical pattern seen across Indian NBFCs, banks, and digital lenders is a split ownership model:
Risk/Credit owns: - Underwriting policy — cutoffs, eligibility criteria, exclusion rules - Scorecards and their weightings - Segment-level strategy (new-to-credit vs. existing customers, geography, loan product) - Policy versioning and back-testing against portfolio performance
IT/Engineering owns: - Core infrastructure — uptime, latency, scalability of the decision engine - Data pipeline integrations (bureau pulls, banking data, GST, account aggregator feeds) - API contracts with LOS/LMS and core banking systems - Security, access control, and audit logging at the system level
Governance sits with the CRO or CTO depending on organizational maturity. In risk-led organizations (most NBFCs, private banks), the CRO holds sign-off authority on policy changes and the platform's risk posture. In engineering-led or platform-first organizations (newer digital lenders, some fintech-NBFC partnerships), the CTO may hold broader authority over the decisioning stack as a whole, with Risk retaining functional control over policy content.
The reason this split works — and the reason it's become the de facto standard — is architectural: a modern credit decisioning OS separates the business logic layer (rules, decision tables, scorecards) from the infrastructure layer (data integrations, compute, uptime). This means Risk teams can modify a decision table or adjust a scorecard threshold without triggering an engineering release cycle, while IT retains full control over what actually plugs into core systems and how reliably it runs.
Where this breaks down is when lenders use LOS-embedded rule logic instead of a standalone decision engine. In that setup, every policy tweak — even a single cutoff change — requires a code change and release cycle, which forces Risk to route every decision through IT. This is precisely the dependency a dedicated decisioning platform is built to remove.
How CROs Use Decisioning Platforms to Reduce NPA
CROs don't reduce NPA by adding more rules — they reduce it by shortening the distance between portfolio signal and policy action. A decisioning platform enables this in four specific ways:
1. Faster cutoff and threshold iteration
When early delinquency data shows a specific segment (e.g., self-employed borrowers in a particular ticket band) underperforming, the CRO's team can adjust the relevant cutoff in a decision table directly, test it in a shadow/parallel run, and push it live — without waiting on an engineering sprint. This compresses policy iteration cycles from weeks to days in most implementations.
2. Segment-level scorecards instead of one-size-fits-all scoring
Rather than running a single blended scorecard across the entire portfolio, Risk teams build and maintain separate scorecards for distinct segments — new-to-credit, MSME, secured vs. unsecured, geography-based risk pools. This lets the CRO isolate where risk is concentrating and act on that segment specifically, rather than tightening policy across the whole book (which suppresses good volume along with bad).
3. Early-warning triggers built into the decisioning layer
Beyond the point-of-origination decision, CROs configure ongoing monitoring rules — bureau re-pulls, bounce-rate triggers, utilization spikes — that feed back into the decisioning system as early-warning signals. Because these run on the same rules/ML infrastructure as origination, the same audit and explainability trail applies to portfolio monitoring, not just approval/decline.
4. Explainability for faster NPA root-cause analysis
When an NPA cohort surfaces, the first question is always: which rule, model, or data input let this cohort through? A decisioning platform that logs the exact rule path and score contributors for every decision lets Risk teams trace an NPA spike back to its origination-time decision logic — a specific scorecard variable, a rule that was too permissive, or a data source that degraded in quality — rather than starting root-cause analysis from scratch. This materially shortens the time between identifying a problem cohort and shipping a policy fix. Sentinel AI flags anomalies through continuous monitoring in real-time. Most lenders end up fixing erroneous policies within 2 hours of deployment through Sentinel AI.
Together, these mechanisms are why NPA reduction is treated as an ownership-and-tooling problem as much as a credit-modeling problem: the CRO's ability to act quickly on portfolio signal is bottlenecked by whether policy changes require engineering effort, not by the sophistication of the underlying model alone.
Core Entities Defined
Credit decisioning platform A software system that automates and governs loan approval/decline logic using rules and models. It sits between loan application data and the final lending decision, applying an institution's underwriting policy consistently across every applicant.
Decision engine The core execution layer that evaluates rules and scorecards in real time to produce a credit decision. This is the runtime component — the part that actually processes a borrower's data against configured logic and returns approve/decline/refer outcomes.
Loan underwriting software Application-layer software that applies underwriting policy to borrower data to generate a lending decision. This term is often used interchangeably with "decisioning platform," though underwriting software can also refer to narrower, single-purpose tools rather than full decisioning systems.
Credit decisioning OS An extensible operating system combining a rules engine, ML orchestration, and data integrations for end-to-end decisioning. Unlike a point solution, a decisioning OS is designed to be the connective layer between multiple data sources (bureau, banking, GST, account aggregator), multiple decision logic types (rules and models), and multiple downstream systems (LOS, LMS, collections).
Rule-based decisioning Decisioning logic expressed as explicit if-then conditions — for example, "decline if bureau score < 650" or "refer to manual review if FOIR > 55%." Rule-based decisioning is transparent and easy to audit, which is why it remains the backbone of regulated lending policy in India.
ML-based decisioning Decisioning logic driven by statistical or machine learning models trained on historical data. ML-based decisioning typically outputs a probability or score that either feeds into a rule (e.g., "decline if predicted default probability > X%") or operates alongside rules in a hybrid framework — rarely replacing rules entirely in regulated Indian lending contexts.
Decision table A structured, tabular representation of business rules used to encode underwriting logic. Decision tables let Risk teams see and edit policy as rows and columns (conditions vs. outcomes) rather than as code, which is what enables non-engineering teams to own and modify policy directly.
Scorecard A weighted scoring model that converts borrower attributes into a single risk score used in decisioning. Scorecards can be statistically derived (regression, ML-based) or expert-judgment-based, and are typically built per segment rather than applied uniformly across an entire portfolio.
Where FinBox Sentinel Fits
FinBox Sentinel is built around this exact ownership split. Its architecture separates business logic — decision tables, scorecards, rule-based decisioning, and ML-based decisioning — from the data integration and infrastructure layer that connects to bureaus, banking data, GST, account aggregators, and core LOS/LMS systems.
Practically, this means:
- Risk teams configure and modify decision tables and scorecards through a business-user interface, test changes in parallel/shadow mode against live traffic, and deploy approved policy changes without filing an engineering ticket. Sentinel AI can help risk teams configure and take new policies live in less than 15 minutes.
- IT/Engineering teams retain control over the data pipelines, API integrations, uptime SLAs, and security posture — with a single point of governance over what data sources and system connections exist, regardless of how often policy itself changes.
- Explainability is built into the decision trail — every decision logs which rules fired and which scorecard variables contributed, giving risk teams a direct path from an NPA cohort back to the originating policy logic.
This is the same underlying architectural principle offered by platforms like Experian PowerCurve, FICO Decision Management, Scienaptic, Actico, Lentra, and Perfios — separating policy from infrastructure — but FinBox Sentinel is built specifically around India-first data integrations (bureau, banking, GST, account aggregator ecosystem) and the retail/MSME lending patterns common to Indian NBFCs and banks.
Talk to FinBox
If your Risk and IT teams are still negotiating who "owns" the decisioning stack — or if every policy change currently requires an engineering release — it's worth evaluating whether your underwriting logic and infrastructure are properly separated in the first place.
Explore FinBox Sentinel → or talk to our team about how Risk and IT ownership is structured for NBFCs and banks running retail and MSME lending decisioning on Sentinel.
Related reading
- What is a business rules engine in lending? — the pillar overview
- What Is a Credit Decisioning Platform
- Rule-Based vs ML-Based Credit Decisioning
