Credit decision engine for installment lending

Problem

Installment applications were decided by a process that existed only as a diagram and in the heads of the risk team. Some rules contradicted each other, limits were computed by hand, and paid bureau checks were sometimes run for applicants who would be declined anyway.

The business needed decisions that are consistent, explainable and cheap — with the risk team, not the engineers, owning the rules.

Approach & architecture

• Transcribed the process diagram into a registry of 49 rules and documented 8 contradictions for the process owner, legal and management to resolve before any code was written.
• Designed a hexagonal service: rules as pure functions, policy as versioned JSON documents, and ports with adapters for upstream systems — stub, operator entry and live.
• Two gates — internal registries and payment discipline, then bureau stop-factors — followed by limit, payment-to-income, prepayment and counter-offer rules. An orchestrator with 14 working and 6 terminal states, deadlines taken from policy and a manual-review queue with SLAs.
• Paid-call governance: an external check is refused until the gate that authorises it has passed; calls are idempotent and each one is written to a cost ledger.

Result

• Every decision returns a rule-by-rule trace, so the risk team sees exactly why an application was approved, reduced or declined.
• A policy playground lets the risk team try policy versions on anonymised applications before rollout.
• The MVP is deployed behind authentication; persistence and live bureau integrations are the next milestone.

What made it robust

• 160+ tests, including 28 scenarios over anonymised applications and a test that fails if the documentation drifts from the service.
• A seven-part design proposal — architecture, integration contracts and DDL, anti-fraud, regulation, ML roadmap, delivery — written before implementation.
• The applicable consumer-lending regulation was analysed and mapped onto the rule set.