The Problem
Alternative lenders serving small and medium businesses face a compound efficiency problem. Business loan origination — collecting applications, gathering financial documents, underwriting creditworthiness, generating term sheets, and managing closing — runs across disconnected systems with substantial manual handling at each stage. The result: weeks-long origination cycles that frustrate creditworthy borrowers who have alternatives, and a cost-per-loan that constrains profitability at smaller loan sizes.
Within that pipeline, risk assessment was a particular bottleneck. Analysts collected data from multiple sources — credit bureaux, bank statements, business financials — validated it manually, and applied scoring logic that existed largely in spreadsheets and analyst judgement. As application volumes grew, inconsistency across analysts was increasing loan default rates, and the team had no mechanism to scale processing capacity without proportionally expanding headcount.
The Constraints
Multi-tenant from the start. The platform would serve multiple lender instances — each with their own borrower base, loan products, underwriting parameters, and branding. Data isolation between tenants was absolute; configuration flexibility per tenant was commercially necessary.
Configurable underwriting, not hard-coded rules. Each lender applies different credit criteria, industry exclusions, collateral requirements, and loan-to-value ratios. A platform that hard-coded one lender’s logic would require engineering changes for each new client — eliminating the SaaS value proposition.
Explainability required by regulation. Lending decisions in the client’s jurisdiction required documented rationale that could be provided to applicants on request. Black-box model outputs were not acceptable — every decision needed an auditable trail of the inputs, the rules applied, and the score produced.
Data quality inconsistency across sources. Bank statement data, credit bureau pulls, and business financials arrived in different formats with different completeness levels. The scoring system had to handle missing or conflicting inputs without requiring manual intervention for every edge case.
Parallel operation during validation. The risk assessment system had to run alongside the existing manual process during a validation phase — producing decisions that analysts could compare before the manual process was decommissioned.
Our Approach
The platform is structured around three tiers: borrower-facing application and portal, lender-facing origination and underwriting workflow, and the shared infrastructure layer handling multi-tenancy and integrations.
The borrower portal (React, TypeScript) provides a guided application flow: business information, requested loan terms, financial document upload, and real-time status tracking through the origination lifecycle. Document uploads trigger automated extraction workflows that parse financial statements and bank statements into structured data consumed by the underwriting layer.
The origination workflow (Node.js, TypeScript) manages the lender-side process: application queue management, automated document completeness checks, credit scoring integration (configurable per tenant, supporting both bureau-based and alternative data scoring models), term sheet generation, and approval routing. Each lender’s workflow stages, approval thresholds, and compliance requirements are configured at the tenant level without code changes.
The risk assessment engine is a modular service integrated into the origination workflow via API. It aggregates borrower data from connected sources, applies a configurable scoring engine, and returns a structured decision with a full audit trail of the inputs, weights, and thresholds applied. The scoring engine is a hybrid: machine learning models for pattern recognition across historical loan outcomes, combined with rule-based validation logic for regulatory requirements and hard exclusion criteria. This combination provides predictive accuracy from the ML layer while keeping decision rationale auditable — satisfying both the performance goal and the explainability requirement.
Redis caches frequently-accessed external data pulls (credit bureau results, identity verification) to reduce latency without serving stale data. PostgreSQL provides the audit trail — every scoring event is an immutable log entry linked to the origination record.
Multi-tenancy is implemented at the database schema level: tenant-specific data is partitioned by tenant ID with row-level security enforcing isolation. Tenant configuration (branding, loan products, underwriting parameters, document requirements) is stored separately from application data, enabling runtime reconfiguration without downtime.
The risk assessment system ran as a parallel service for six weeks. Analysts compared automated decisions against their own assessments before the manual process was decommissioned.
The Outcome
- Origination cycle time reduced from 3–4 weeks to 3–5 days for standard business loan applications
- 50%+ reduction in risk assessment time per application
- 30–40% increase in processing capacity without headcount growth
- 20% improvement in decision consistency across the applicant portfolio
- Up to 15% reduction in default rate from improved scoring accuracy
- Multi-tenant architecture supports onboarding of new lender instances through configuration, not engineering
- Full audit trail in production, satisfying regulatory explainability requirements
Team
Engagement: 7 months, 5 engineers (1 tech lead, 2 backend, 1 frontend, 1 DevOps/data).
Stack: TypeScript, React, Node.js, Python, PostgreSQL, Redis, AWS, Kubernetes, Docker