Application journeys
Multi-step, branching journeys with abandonment recovery, save-and-resume, and Consumer-Duty-aligned disclosures throughout.
04 — Lending
Lending platform engineering — originations, decisioning, servicing and collections.
Most lending platforms get the application form right and the rest wrong. The fault lines show up six months in: a decisioning engine that can’t articulate why it declined, an arrears workflow that wasn’t built with Consumer Duty in mind, securitisation reporting that needs a developer for every quarterly export.
FCA · UK CFPB · US FCAC · Canada
01 — Problem
Where lending builds usually go wrong.
We build lending platforms end-to-end across consumer instalment, SME working capital and BNPL programmes. The pattern that distinguishes platforms that survive their first regulatory review from those that don’t isn’t the application form — it’s everything downstream.
Decisioning that produces a reasoned record for every decline. Affordability calculations the firm’s compliance officer can defend in front of the FCA. Collections workflows that flag vulnerability signals continuously, not at intake. Securitisation reports the treasury team can run themselves.
We don’t build “a loan platform” — we build the eight or nine components that make a loan platform survive contact with real customers, real regulators and real performance volatility.
02 — What we build
End-to-end, audit-ready, in production.
Decisioning engines
Rule-based or model-driven decisioning with explainability, audit trail and reasoned-decision records for every outcome.
Bureau integrations
Experian, Equifax and TransUnion in parallel, plus alt-data providers (Plaid, Credit Kudos, Aire) — with a canonical schema above.
Affordability scoring
Open Banking-backed real-income, regular-outgoings and disposable-income calculations — defensible under Consumer Duty challenge.
Loan management
Disbursement, repayment schedules, restructures, partial payments, write-offs and back-book transfers.
Collections workflows
DISP-aligned, vulnerability-aware, with escalation logic and the audit trail to evidence forbearance decisions.
BNPL & revolving credit
Interest accrual, instalment management, dispute handling — built for the FCA’s incoming BNPL regime (15 July 2026).
Securitisation reporting
Investor packs, performance reporting, hold-back accounting — exportable by the treasury team without developer involvement.
03 — Patterns
Build patterns we ship from.
Originations engine
Application journey with decisioning integration, document collection, identity, affordability and disclosure orchestration.
AWS Step FunctionsOnfidoPlaid
Decisioning service
Rules + model serving with reasoned-decision recording — explainable under GDPR Art. 22 and Consumer Duty.
Drools / OPASageMakerSHAP
Loan management system
Event-sourced loan ledger with disbursement, schedule, restructure and write-off support — and back-book transfer capability.
Postgres event-sourcingKafkadbt
Collections workbench
Operations UI with vulnerability flagging, forbearance workflow, DISP-aligned complaint handling and full audit trail.
React workbenchTemporal workflowPostgres
04 — Regulations
What this work has to comply with.
UKFCA CONCUKConsumer DutyUKDISPUSTILA / Reg ZUSECOAUSCFPB Section 1071CAFCAC consumer credit rulesGlobalAML / KYC obligations
05 — Stack
What we build with.
Bureaus & alt-data
ExperianEquifaxTransUnionPlaidCredit KudosAire
Decisioning & ML
Drools / OPASageMakerSHAP / LIMEInternal rule DSL
Workflow & ops
AWS Step FunctionsTemporalOnfidoPostgres event-sourcing
06 — Recent build
A BNPL decisioning platform built for the FCA’s 15 July 2026 DPC start-date.
A UK BNPL provider needed to be Consumer Duty Product Catalogue (DPC) compliant ahead of 15 July 2026. Their existing decisioning was a Python rule sheet — fast to build, impossible to defend if challenged on a per-customer decline.
We delivered a decisioning service with rules-and-models in one pipeline, a reasoned-decision record for every outcome, a champion-challenger framework for safe rule changes, and an explainability layer that produced GDPR Art. 22-defensible explanations for adverse outcomes.
The platform shipped two weeks ahead of the DPC start-date. The client passed their internal FCA-readiness review on first submission, and the decisioning team has since shipped 14 rule changes through the champion-challenger framework without a single rollback.
8 weeks
Build to production
2 weeks
Ahead of DPC deadline
14
Rule changes shipped, zero rollbacks
07 — FAQs
Questions we get every time.
How long does a lending platform MVP take to ship?
For a single-product consumer instalment platform: 10–14 weeks to a production launch behind a closed beta, including originations, decisioning, bureau integration, affordability, loan management and basic collections. Add 4–6 weeks for BNPL because the regulatory complexity is higher. Add 6–10 weeks for SME because the underwriting layer is materially different.
What does an explainable decisioning engine look like under Consumer Duty?
Three properties: (1) every decision produces a reasoned record that a human reviewer can read and either defend or challenge; (2) model contributions are explainable per-decision (SHAP or equivalent), not just at the model level; (3) rule changes are versioned, peer-reviewed and run in shadow before they affect customers. Consumer Duty doesn’t mandate any specific implementation — what it asks for is “evidence of judgement.” The three properties above are how you produce that evidence.
Can you integrate to Experian, Equifax and TransUnion in parallel?
Yes, and we recommend it — bureau coverage gaps are the most common reason a credit platform under-decisions. The right pattern is parallel hard-search calls behind a single canonical-schema layer, with a routing decision about which bureau drives the underwriting decision (usually the one with the deepest file, with the others as confirmation). Soft-search journeys typically use one bureau by commercial choice.
How do you handle FCA CONC affordability requirements with Open Banking data?
Open Banking gives you real-income (calculated, not declared), regular-outgoings detection and disposable-income headroom — three things bureau-only affordability can’t produce. The compliance question is whether the affordability calculation is defensible per-customer, not whether it produced the right portfolio outcome. We build affordability as an evidence-producing service: every decision retains the source transactions, the categorisation choices and the calculation logic at the time of the decision.
What’s the right pattern for arrears workflow under vulnerability rules?
Vulnerability flagging is continuous, not point-in-time at intake. Signals come from payment behaviour, customer-initiated contact, third-party disclosures and (where available) Open Banking signals. The workflow has two paths: a standard collections track for accounts without vulnerability flags, and a slowed-down forbearance track for accounts with them. The DISP-defensible part is the audit trail — every escalation decision needs an evidence record.
— Adjacent practices
Most builds combine two or three.
Scoping a lending build?
Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.