Multi-lender APIs
Parallel calls with circuit breakers, per-lender adapter abstraction and a normalised offer schema above.
05 — Credit broking
Credit broking platform — compliance aligned multi-lender journeys built to pass audits.
Most credit broking platforms were built before Consumer Duty. The journeys convert well, the vulnerability flagging is lightweight, the disclosure flow is the same as it was in 2018. The next FCA review will find all of this. The question is whether you find it first.
FCA · UK
01 — Problem
Where credit broking builds usually go wrong.
Credit broking platforms have a regulatory perimeter that’s quietly expanded since 2023. Consumer Duty changed the bar for what counts as a defensible journey; the financial-promotions overhaul (CP26/15 is the active thread now) keeps shifting what disclosures need to look like; and DISP rules continue to expect MI and audit trails most legacy platforms can’t produce.
We build credit broking platforms to that current perimeter — and to a forward-looking version of it. Vulnerability flagging is continuous and signal-driven, not a checkbox at intake. Multi-lender calls are parallel, circuit-breaker-protected and observable. Consumer-Duty evidence is generated as a by-product of the journey, not retro-fitted into a quarterly review.
Building this from scratch is one engagement. Re-platforming a working broker funnel to it without breaking conversion is a different — and more common — engagement.
02 — What we build
End-to-end, audit-ready, in production.
Soft search & eligibility
TransUnion or Experian soft search, pre-qualification logic and footprint-free eligibility checks.
Pricing & pre-qualification
Real-time, multi-lender pricing with binding-offer support and consistent rate-comparison surfaces.
Journey orchestration
Branching, vulnerability-aware, A/B-testable journey logic with full state recovery on drop-off.
Consumer Duty controls
Outcomes-tracking, evidence-of-judgement logging and quarterly MI bundles that hold up under regulatory review.
FCA CONC disclosures
Promptly, prominently, in-context — built to current CONC standards with the rule-change history baked into the codebase.
Complaint handling (DISP)
Workflow, MI, FOS-ready export and an evidence trail that survives DISP scrutiny.
Vulnerability flagging
Signal-based, ongoing (not point-in-time) — with the audit hooks the FCA looks for.
03 — Patterns
Build patterns we ship from.
Multi-lender panel orchestration
Parallel-call panel with per-lender adapters, circuit breakers, retry strategy and offer-normalisation layer.
AWS Step FunctionsAdapter patternPostgres
Real-time pricing engine
Sub-300ms multi-lender pricing with binding-offer caching and consistent comparison surface.
RedisKafkaInternal pricing DSL
Vulnerability-and-consumer-duty operating model
Continuous signal collection, evidence-of-judgement logging, outcomes-tracking MI.
SnowflakedbtLooker
DISP-compliant complaint workbench
Operations UI with workflow stages, evidence collection, FOS-ready export and full audit trail.
React workbenchTemporalPostgres event-sourcing
04 — Regulations
What this work has to comply with.
UKFCA CONC Ch. 3UKConsumer DutyUKDISPUKVulnerability guidanceUKCP26/15 (financial promotions)UKSM&CR for brokers
05 — Stack
What we build with.
Bureaus & data
TransUnion soft searchExperianClearScoreCredit Kudos
Decisioning & vendors
Decisioning vendorsProvenir adapter layerInternal rule DSL
Infrastructure
AWS Step FunctionsRedisKafkaSnowflake / dbt
06 — Recent build
A multi-lender broker funnel pushing 12,000 applications a week.
A UK credit broker had outgrown a single-page funnel that no longer met Consumer Duty expectations. They were pushing ~12,000 applications a week through a 7-lender panel, but the platform couldn’t evidence outcomes, the vulnerability flagging was intake-only, and the DISP complaint workflow lived in a spreadsheet.
We re-platformed the funnel over 14 weeks: parallel multi-lender calls behind a normalised offer schema; a continuous vulnerability-signal layer drawing from journey behaviour, contact channels and (where present) Open Banking data; a Consumer-Duty MI pipeline generating quarterly evidence packs as a by-product; and a DISP workbench that replaced the spreadsheet.
Conversion lifted by 31% in Q1 — most of it from journey orchestration improvements rather than the regulatory upgrades. But the regulatory upgrades were the reason the client could keep operating at that scale: the next FCA firm review approved the controls without remediation.
14 weeks
Replatform to production
31%
Conversion lift in Q1
12,000/wk
Applications handled
07 — FAQs
Questions we get every time.
How do you call 7 lenders in parallel and return the cheapest in under 300ms?
Three things: a fan-out / fan-in pattern at the orchestration layer (not sequential calls), per-lender circuit breakers with aggressive timeouts (we usually run 250ms p99 per lender), and a normalised offer schema so the comparison logic isn’t lender-specific. The lender adapters are kept thin and stateless. The hardest part is usually getting per-lender response times below the timeout consistently — sometimes that means caching ahead, sometimes it means asking the lender for a different endpoint.
What does a Consumer Duty-aligned broker journey look like?
Four things that aren’t always there: outcomes-tracking from intake to lender decision (not just to broker hand-off), evidence-of-judgement logging at every branching decision, vulnerability-signal collection that runs throughout the journey rather than at intake, and quarterly MI that maps the journey’s outcomes to the four Consumer Duty outcomes (price & value, products & services, consumer understanding, consumer support). Plus a complaint workflow that closes the loop back to journey design.
How do you handle vulnerability flagging across an application lifetime?
Continuous signal collection — payment behaviour, customer-initiated contact, journey behaviour (e.g. repeated abandonment in the same place), and Open Banking signals where available. Signals roll up to a flag state with three or four bands, not a binary. The journey reads the flag state at key decision points and either offers an alternative path or escalates to a vulnerability-aware operator. The audit trail records the signal, the flag state and the journey decision at the time of the decision.
What evidence does the FCA actually look for in a CONC review?
In our experience: (1) the journey behaves as documented — they’ll mystery-shop; (2) disclosures are prompt, prominent and in context — they’ll look at the rendered customer view, not the policy doc; (3) vulnerability flagging is genuine, not a checkbox; (4) complaint MI is consistent across firm reports and the underlying data; (5) there’s evidence of judgement — that you’ve actively considered, documented and reviewed customer outcomes, not just measured them. The fifth one is where most platforms fall short.
Can you migrate a broker platform without breaking conversion?
Yes, but only by running the new platform in shadow first. We typically build the replacement, route 5–10% of traffic for two weeks, compare conversion and outcome MI head-to-head, fix what differs, then ramp. The most common cause of conversion drop in a re-platform is journey-design drift — small changes that look like clarifications but materially shift the customer’s path. Shadow mode catches those before they affect 90% of traffic.
— Adjacent practices
Most builds combine two or three.
Scoping a credit broking build?
Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.