FinCue — Consumer Lending Platform across Two Markets
Three storefronts on a single platform across two markets. Defaults down 42% while approvals grew 14 percentage points.
The Challenge
A consumer lending operator running short-term loans, installments, and marketplace BNPL across two markets and three brands. Over twenty-four months we rebuilt the platform around a hybrid scoring engine, moved payments onto an in-house card-acquiring stack, replaced the third-party telemarketing CRM with a closed-loop in-house dialer, and absorbed multiple credit-history sources into one feature pipeline. The headline number is the one that should not exist: defaults went down while approvals went up.
Three Products, Three Risk Profiles, One Backbone
Three lending products with materially different risk profiles, channel mixes, and operating cadences. Treating them as separate codebases would have tripled the cost of every scoring change. Multi-tenancy was the trade we made in month two.
| Dimension | Payday Loans | Installments | Marketplace BNPL |
|---|---|---|---|
| Term | 14–30 days | 3–12 months | 2–6 months |
| Underwriting target | < 1 min | 2–4 min | < 5 sec at checkout |
| Default profile | High frequency, thin-file | Lower frequency, thick-file | Skewed by merchant |
| Active markets | Both | Both | One |
Marketplace BNPL went from kickoff to first production decision in eleven weeks because the scoring engine, servicing domain, and payments stack were already in place.
Solution Architecture
Domain-driven decomposition
Hard boundaries between origination, scoring, underwriting, servicing, collections, payments, and the telemarketing pipeline. Each domain owns its data and exposes a contract. Multi-brand and multi-market are configuration — per-tenant policy bundles, market-scoped data partitions, per-brand UI surfaces.
Polyglot, paired to the work
A domain-rich CRUD framework for origination and servicing, a real-time runtime for the decisioning gateway and operator queue, a data-science stack for scoring and analytics, and one frontend stack across customer storefronts and the operator UI.
Event-driven coordination
An ordered, replayable event bus is the spine for async coordination, ETL, and the analytics pipeline. Domain databases sit behind clear contracts; the bus connects them without forcing a shared schema.
PCI-isolated payments
The in-house payments domain runs on its own cluster under a dedicated team. Card data sits in one tokenisation vault regardless of which acquirer carries the transaction, which dropped PCI scope from full to SAQ-D and made multi-acquirer load balancing safe to ship.
Three storefronts on a single platform. Per-tenant policy bundles resolve market, brand, and product at request time.
Hybrid Scoring: Rules, Bureau, ML
Pure rules plateau on discrimination. Pure ML breaks when regulators ask why a specific applicant was declined. The hybrid layers three engines, in order — risk owns the rule layer through a policy UI, data owns the ML layer, engineering owns the orchestrator.
Rules
KYC, fraud blacklist, sanction-list, age and residency, velocity. Fully explainable, fully auditable.
Bureau orchestrator
Multiple bureaus per market, normalised scores, fallback chain, circuit breakers prevent any single bureau from blocking the SLA.
ML cutoff
Gradient-boosted model on the marginal band, with explanation contributions persisted alongside every decision for audit and operator review.
Defaults down 42% while approvals grew 14 percentage points — the result of better discrimination. Drift monitors fired in month 17 and caught a channel-mix incident before defaults materialised.
Telemarketing — Closed Loop, EV-Ordered Queue, Script-Checking
The third-party CRM had no write-path back to scoring and ordered leads FIFO. We rebuilt everything above the telecom provider. Each lead is scored on probability of funded conversion and routed by expected value. A script-checking engine runs every call recording through speech-to-text and flags deviations, so team leads coach exceptions instead of listening to every call.
Once operators could trust the scoring recommendation and stop chasing low-EV leads, the floor shrank from 40 to 10 — a 4× reduction with higher conversion. End-to-end lead-to-funded conversion more than doubled on the same monthly lead volume.
Technical Stack
Domain services
CRUD-heavy domain logic — origination, servicing, collections, admin
Real-time paths
Decisioning gateway, telecom-channel integration, operator queue API
Scoring & ML
Data-science velocity without a backend ticket gate
Customer + operator UI
Single frontend skill set across customer storefronts and operator UI
Data plane
One database per domain; a replayable bus for ETL, analytics, and inter-domain coordination
Infrastructure
PCI-scoped payments domain runs on its own cluster under a dedicated team
Key Technical Decisions
Hybrid scoring over pure machine learning
Tradeoff: Three engines instead of one
Why: Pure ML breaks the operator's mental model and the regulator's audit trail. Rules give explainability and instant hard-cuts on fraud and KYC. Bureau orchestration gives heavy discrimination at low latency. ML pays its way only on the marginal band.
In-house PSP with multi-acquirer load balancing
Tradeoff: Ongoing certification work, one extra team on its own cluster
Why: Owning a single PSP would have made us hostage to one rail's auth rates, fees, and incident windows. We built an in-house card-acquiring stack and kept external acquirers on the same router, load-balancing on auth rate, latency, and cost. PCI scope dropped from full to SAQ-D because card data sits in one tokenisation vault regardless of which rail carries the transaction.
Multi-tenant configuration over per-brand forks
Tradeoff: Up-front work on the policy-bundle abstraction
Why: With three brands across two markets, the alternative was three codebases drifting apart within a year. Every scoring improvement would have shipped three times — or rotted in the others. We absorbed the cost in month two and saved it back every release thereafter.
Implementation Timeline
Discovery + Scoring v0
Rules + bureau scoring v0, origination refactor, multi-tenant policy-bundle abstraction in place.
PCI + Payments + ML v1
PCI prep, payments domain extracted, bureau orchestrator in production, ML scoring v1 in champion-challenger.
Telemarketing + Second Market + Own PSP
In-house telemarketing platform launched, second-market brands live, own PSP processing first card disbursements.
ML v2 + BNPL + Audit Passed
ML scoring v2 with closed-loop features from telemarketing, marketplace BNPL pilot launched, regulator audit passed in month 19.
Scale + Handover
Team stabilised at 30. Platform absorbed three policy iterations per month without engineering involvement beyond review.
Challenges and How We Solved Them
The Problem
Regulator opened a routine audit in month 19 with a three-week response window — explainability evidence for declined applications, data-retention controls, and a written description of automated decisioning safeguards.
Approach
Pulled existing explanation records and decision logs from the scoring service, mapped the platform's decisioning flow to the regulator's framework, held one working session with the compliance lead.
Outcome
Response delivered in eleven business days. Audit closed without findings. The decision logs and explanation persistence built two quarters earlier turned a potential crisis into a one-week deliverable.
The Problem
Model drift after channel-mix shift — an affiliate campaign in month 17 doubled traffic from a thin-file segment within ten days. FPD7 ticked up on the affected cohort and drift alarms fired before defaults materialised.
Approach
Tightened the policy bundle for the affected segment via the rule layer (no model retraining needed in the first week), triggered retraining on data including the new segment, ran champion-challenger for two weeks, promoted under a conservative cutoff.
Outcome
Cohort default rate normalised within six weeks. Without drift monitoring the problem would have surfaced six to eight weeks later — when the cohort would have been five times larger.
Numbers That Moved
10.6%
FPD30+ default rate
was 18.4% ↓
41%
Approval rate
was 27% ↑
38 sec
Time-to-decision (median)
was 14 min ↓
8.9%
Lead → funded conversion
was 3.8% ↑
24
Manual underwriting touches per 1k apps
was 380 ↓
10
Operators on the telemarketing floor
was 40 ↓
SAQ-D
PCI DSS scope
was Full scope ↓
30
Engineers
was 15 ↑
Before and After
| Dimension | Before | After |
|---|---|---|
| Lending products | Payday only | Payday + Installments + BNPL |
| Scoring engine | Heuristic decision tree | Rules + Bureau + ML |
| Payments | Third-party PSP, full PCI scope | Own PSP, SAQ-D scope |
| Telemarketing | Third-party CRM, 30-min lag | In-house, closed loop, EV-ordered |
| Deploy frequency | 4 per week | 38 per week |
Engagement Team
Lessons Learned
Where operator trust is a constraint, hybrid scoring beats pure ML. Both the risk team's challenge function and the regulator's audit are easier when most decisions never touch a model.
The build-vs-buy decision on the PSP is a unit-economics question, not an engineering one. At our volume the third-party PSP cost more every month than the engineering team that replaced it.
Telemarketing without a feedback loop to scoring wastes operator time. Operators were already collecting information that materially improves decisions; we were paying to collect it and then throwing the data away.
More cases
View all cases
Efficlose
Efficlose — Meeting Intelligence SaaS for Revenue Teams
EduHam