Scoring Service

Problem

Lending partners needed a way to turn raw banking data into approve or reject decisions and approved limits, without hardcoding a new scorecard for every product. That meant supporting several scorecards at once, scoping decisions by organization and product, and keeping things fast even as score requests piled up.

My role

I took over the scoring service during its current phase and pushed it forward: multi-scorecard support, org and product scoping, dedup work to speed up repeated score requests, hardening around edge cases in the rules layer, and getting the whole thing running reliably in Docker. Some of the original foundation predates me. I focused on the parts that made it production-ready at scale.

Architecture

A Django/DRF service sits in front of PostgreSQL. Score requests carry customer banking signals, salary, account age, transaction and turnover history, loan history. PMML scorecards produce a score, and a configurable rules engine turns that into a decision: approve, reject, rejection reason, and approved limit. Celery and Redis handle the async and scheduled pieces. The service supports several scorecard variants, including MSME and IFB-oriented paths, scoped by organization and product so different partners can share the same engine without forking the logic.

Technical highlights

• Multi-scorecard support scoped by organization and product, so new lending products reuse the engine instead of forking it.
• Dedup and indexing work on score requests to keep decisioning fast under repeated load.
• Multi-stage Docker setup so local and production environments actually match.