Fintech & Financial Services
Software engineering for Lending
Origination, decisioning, affordability, servicing and collections: built by senior engineers who know that in lending the regulation is not a wrapper around the software, it is the software. We build decisioning you can explain to the FCA, affordability grounded in real data, and collections that treat people in difficulty lawfully and fairly.
Why the domain matters
Lending software is where a credit business actually lives. The rate card and the funding line matter, but the day-to-day economics are set by the systems that decide who gets lent to, how much, on what terms, and what happens when they fall behind. An origination journey that loses good applicants to friction, a decisioning engine that declines people it should have approved (or approves people it should not have), an affordability model that waves through a loan the borrower cannot sustain, a collections process that treats a vulnerable customer badly: each of these is a direct line to lost revenue, bad debt, or a regulatory problem that costs far more than the software ever did. We build across the whole lifecycle for consumer credit, SME lending, mortgages, BNPL and alternative lending, because the same disciplines run through all of them even when the products differ.
What makes lending different from most software we could be building is that the regulation is not a compliance layer you add at the end: it is the specification. Responsible-lending and affordability rules shape what the decisioning engine is even allowed to do. Consumer Duty shapes what a "good outcome" means and therefore what the system has to be able to demonstrate. The requirement to explain a decline shapes the architecture of the model that produces it. Rules on vulnerable customers, arrears and collections shape the servicing side as firmly as credit risk does. Build the software as though the rules are someone else’s problem and you get a system that is fast, elegant and quietly non-compliant, which in lending is not a minor defect, it is the whole thing broken.
We are engineers, not a decisioning-model vendor and not compliance consultants, and we are blunt about the trade-off at the centre of modern lending: automated credit decisioning carries real fairness, bias and regulatory risk, and the more of the decision you hand to a model the more of that risk you take on. A decisioning system that cannot explain why it declined someone is not an asset, it is a liability waiting for a complaint or a regulator. So we build decisioning that is explainable and auditable by design, we treat affordability as a question about a real person’s finances rather than a score, and we build collections to be lawful and fair before it is efficient. Where a model genuinely adds value we will build it; where a transparent rule set does the job with far less risk, we will tell you that instead.
The challenges in lending
Explaining an automated decline
If a model declines an application, you must be able to say why, to the customer, to a complaint handler, and to the FCA. A high-performing model that is a black box is a regulatory problem, not an advantage. The hard part is building decisioning that is both accurate and genuinely explainable, and knowing when a transparent rule set is the safer choice.
Affordability that reflects reality
Responsible lending turns on whether the borrower can afford the repayments without hardship, not on whether they clear a score threshold. Modelled or declared income and expenditure is often wrong; Open Banking data is closer to the truth but messy to categorise. Getting affordability right (and being able to show your working), is where a lot of lending software quietly fails its regulatory obligations.
Bias and fairness in the decision
A decisioning model trained on historical lending data learns the patterns in that data, including ones you could not defend if they were written down as a rule. Proxies for protected characteristics are easy to introduce by accident and hard to detect. Fairness has to be measured and monitored deliberately, because a model that is unfair on average will eventually produce a discrimination complaint you cannot answer.
Origination friction versus fraud and risk
Every extra field, document upload and verification step in the application journey loses genuine applicants, and every one you remove is a door for fraud and a gap in your affordability picture. Tuning that balance for each product, and doing it without breaking the data you are obliged to collect, is a constant tension that a naive "reduce friction" instinct gets wrong.
Collections and arrears done lawfully
When a customer falls behind, the rules on forbearance, communication, vulnerability and fair treatment are strict, and getting them wrong causes real harm and real regulatory exposure. Collections software optimised only for recovery rate (chasing hardest where it pays best), is exactly the kind of system that produces the outcomes Consumer Duty exists to prevent.
Auditability across the whole decision
For any loan you may later have to reconstruct exactly what data was used, what the affordability assessment concluded, which rules and model version applied, and why the outcome was what it was, sometimes years afterwards. Systems that overwrite state and log nothing make that reconstruction impossible, which turns a routine complaint or review into a crisis.
What we build for lending
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Loan origination platforms
End-to-end application and origination journeys for consumer, SME and mortgage lending, application capture, identity and verification, document handling, KYC/AML checks, and the orchestration that pulls credit and affordability data together into a decision. Built to collect the data responsible lending requires while keeping the journey as light as the product honestly allows.
Decisioning and scoring engines
Credit decisioning that combines rules and models. A transparent rule layer for policy and eligibility, scorecards or models where they genuinely add lift, and clear reason codes on every outcome. Versioned, testable and auditable, so you can replay any past decision and explain any decline. We are candid about where a rule set beats a model on risk-adjusted terms.
Open Banking affordability
Affordability assessment built on real transaction data via Open Banking (consented account access, transaction categorisation, income verification and expenditure analysis), turned into a defensible affordability conclusion rather than a raw feed. Designed around consent, data minimisation and the reality that categorisation is imperfect and its uncertainty has to be handled honestly.
Servicing and collections systems
Loan servicing for the life of the book (balances, schedules, payments, statements, early settlement, arrears tracking), and collections built to treat customers in difficulty lawfully: forbearance options, vulnerability handling, controlled and fair communications, and a full record of what was offered and done. Recovery matters, but not at the cost of the outcomes the rules require.
BNPL and point-of-sale infrastructure
Buy-now-pay-later and instalment infrastructure that has to make a decision in the checkout in milliseconds while still meeting affordability and responsible-lending obligations as regulation tightens around the sector. Merchant integration, real-time decisioning, instalment servicing and the audit trail to show each split was assessed, not rubber-stamped.
Broker and intermediary portals
Portals for brokers and introducers to submit, track and manage cases (decisions in principle, document exchange, case status and commission handling), with the same decisioning discipline and audit trail as your direct channel, so the intermediated book is not a blind spot in your compliance or your data.
Where we help
Consumer credit origination and decisioning
A consumer lender needs an application journey that converts, a decisioning engine that applies policy and credit risk consistently, and affordability that stands up to scrutiny, all producing declines it can explain. We build the origination and decisioning stack end to end, with reason codes and audit trails baked in rather than retrofitted after the first complaint.
Open Banking-based affordability
A lender wants to move from declared or bureau-estimated income and expenditure to real transaction data. We build the Open Banking integration, the categorisation and income-verification logic, and the affordability model that turns a messy transaction feed into a defensible conclusion, handling consent, revocation and the genuine uncertainty in categorisation honestly rather than pretending the data is clean.
Servicing and fair collections
A book has grown past what a servicing spreadsheet or a legacy platform can handle, and arrears need to be managed properly. We build servicing that tracks the loan through its life and collections that is fair and compliant first (forbearance, vulnerability, controlled contact), with the recovery efficiency coming from good process rather than from pressure that creates regulatory risk.
BNPL at checkout
A merchant or lender needs instalment decisions made inside the checkout in real time, at volume, while meeting affordability obligations that regulators are actively tightening. We build the real-time decisioning, the merchant integration and the instalment servicing, and we are straight about the tension between a millisecond decision and a genuine affordability assessment rather than papering over it.
How we build lending software
We start from the decision and the regulation, not from the screens. Before any journey is designed, the questions that matter are what data a lawful, responsible decision requires, what the decisioning engine is and is not allowed to do, and what you must be able to explain and reconstruct afterwards. Those answers set the shape of the whole system, and getting them last, which is what happens when you start from the UI and bolt compliance on at the end: is how lending software ends up fast and quietly non-compliant. Because we operate what we build, we design for the awkward moments the demo never shows: the declined applicant who complains, the arrears case that turns out to be a vulnerable customer, the regulator asking why a decision went the way it did.
On decisioning specifically, we treat explainability and auditability as requirements of equal weight to accuracy, not as things to be traded away for a better score. That usually means a transparent rule layer for policy and eligibility that a human can read and defend, models used where they genuinely add lift and can be explained, clear reason codes on every outcome, and strict versioning so any historical decision can be replayed exactly as it was made. We will build a model where it earns its place, and we will tell you plainly when a rule set does the same job with far less fairness and regulatory risk, because in lending the cheapest, safest decision is often the transparent one.
We build affordability and collections as first-class parts of the system rather than afterthoughts, because the rules treat them that way. Affordability is grounded in the best data available (increasingly Open Banking rather than declarations), and honest about its own uncertainty. Collections is built to be lawful and fair before it is efficient, with forbearance, vulnerability handling and controlled communication designed in. And the whole system keeps the record that lets you show, loan by loan, that you assessed affordability, treated the customer fairly, and reached a decision you can explain.
FCA regulation, responsible lending and Consumer Duty
Consumer credit lending in the UK sits under FCA regulation, and the rulebook that matters most day to day is CONC (the Consumer Credit sourcebook), which sets out responsible-lending obligations, creditworthiness and affordability requirements, and detailed rules on arrears, default and collections. These are not background context for the software; they are its specification. A decisioning engine has to make creditworthiness and affordability assessments the rules recognise as adequate; a servicing and collections system has to handle arrears, forbearance and default in the way CONC requires. We build to those obligations directly rather than treating them as something a compliance team will reconcile after the fact, and we design the system so the assessments it makes can be evidenced.
Consumer Duty raises the bar from "did you follow the rules" to "did the customer get a good outcome", and that changes what the software has to be able to do. It is no longer enough to decision and service loans correctly in a procedural sense; you have to be able to demonstrate that customers were treated fairly, understood what they were taking on, and were not led into products or outcomes that harmed them. In practice that means the system has to capture and evidence the outcome, not just the transaction, which is a design requirement, not a reporting afterthought. Treating customers fairly and the specific protections around vulnerable customers run through both origination and collections, and we build them in as behaviour rather than as policy documents that the software ignores.
The requirement we design around most carefully is explainability. Where a decision to decline or to set terms is made wholly or partly by an automated process, you must be able to explain it (to the customer, to a complaint handler, and to the regulator), and data-protection law reinforces this for automated decisions with legal or similarly significant effects. This is the single hardest constraint in modern lending software, and it is why we treat a decisioning model that cannot explain its declines as a liability rather than an asset. We are engineers and we build to make your firm’s obligations achievable in software; we are not your compliance function and we do not replace regulatory or legal advice. What we do is make sure the system is built so that meeting those obligations is possible, evidenced and auditable rather than aspirational.
Credit bureaux, Open Banking, payments and core platforms
Lending software is an integration problem as much as a decisioning one. On the credit side that means the credit reference agencies (Experian, Equifax and TransUnion), for bureau data, scores and, in the other direction, the performance and default reporting you are expected to share back. Each bureau has its own data model, its own quirks and its own contractual and data-protection constraints on how their data may be used, and a decisioning engine has to consume that data reliably, handle the cases where a bureau returns thin or no file, and keep a record of exactly what was pulled and when for every decision. We build these integrations to be resilient to bureau outages and clear about provenance, because "we decided on data we can no longer produce" is not an answer that survives a complaint.
Affordability increasingly runs on Open Banking, which is a categorically different integration from a bureau call: it is consented, revocable access to a customer’s real transaction data, governed by strict rules on consent, scope and data minimisation. The engineering is in turning a raw, messy transaction feed into a defensible affordability conclusion (categorising transactions, verifying income, identifying commitments and financial-difficulty signals), while handling consent lifecycle, revocation and the genuine uncertainty in categorisation without pretending the data is cleaner than it is. On the money side, payment and collections integrations handle disbursement, repayment collection (Direct Debit and card), failed-payment handling and reconciliation, all of which have to be exactly right because they move real money and feed the arrears picture.
Most lenders are not building on empty ground, so the harder integration work is often with what already exists: a core lending or loan-management platform, a CRM, a general ledger, and whatever the origination or servicing was done in before. We are candid that these integrations are where lending projects overrun, because the existing systems are frequently underdocumented and their data is rarely as clean as anyone believes. We would rather establish that reality early (by getting into the actual data and the actual APIs), than discover it in the migration. Where a system genuinely needs to talk to your stack, we build the integration properly, with reconciliation and monitoring, rather than a fragile connection that appears to work in a demo and drops payments in production.
Protecting sensitive financial data
Lending systems concentrate some of the most sensitive personal data there is: income, expenditure, full transaction histories from Open Banking, credit files, debts, arrears, and the financial-difficulty and vulnerability information that collections generates. A breach here is not only a data-protection failure, it exposes exactly the information that does people the most harm, and it destroys the trust a lending relationship depends on. We treat that data with the seriousness it warrants: encryption in transit and at rest, tight access control on who can see financial and vulnerability data and why, and detailed audit logging of access, because with data this sensitive who looked at what matters as much as who changed it.
Open Banking raises the stakes because you are holding a rich, categorised view of a customer’s entire financial life, obtained under a specific consent for a specific purpose. Data minimisation is not just good practice, it is an obligation: you keep what the affordability assessment needs and no more, you honour revocation, and you do not quietly repurpose transaction data for something the customer never agreed to. We build these systems so the consent boundary is enforced in the architecture rather than left to policy, and so the data’s provenance and permitted use travel with it.
Beyond confidentiality, the integrity and availability of lending systems have direct regulatory and financial consequences. If servicing miscalculates balances or interest, if payments are taken twice or missed, if an arrears state is wrong, the harm is immediate and the regulatory exposure real, so we build with the reconciliation, validation and auditability that catch these failures rather than trusting that they will not happen. And because we operate what we build, security and correctness are things we live with in production rather than a checklist signed off before launch. We are honest that no system is perfectly secure; what we offer is disciplined, defensible engineering proportionate to how damaging this data is if it leaks or goes wrong, not a claim of invulnerability.
What changes
Declines you can defend
Decisioning that produces a clear, consistent reason for every outcome and can replay any past decision exactly as it was made, so a complaint or a regulatory query is a lookup, not a crisis, and the model or rules that made the call are always explainable.
Affordability that holds up
Assessment grounded in real financial data, honest about its own uncertainty, and evidenced loan by loan, so responsible-lending and Consumer Duty obligations are met in the system rather than asserted in a policy document the software does not enforce.
Collections that reduces risk, not just debt
Servicing and collections built to treat customers in difficulty lawfully and fairly first, with forbearance and vulnerability handling designed in, so recovery comes from good process rather than pressure that turns into complaints and regulatory exposure.
What we build for lending
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for lending?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in lending choose us
We treat the regulation as the spec, not the wrapper
In lending, responsible-lending rules, Consumer Duty and the duty to explain a decision are not compliance decoration on top of the software. They define what it must do. We build to those obligations from the first decision about the architecture, which is why our systems can evidence what they did rather than merely claim it.
We build decisioning you can explain
We treat a model that cannot explain its declines as a liability, and we build decisioning that is auditable and versioned by design. Where a model genuinely adds lift we will build it; where a transparent rule set does the job with far less fairness and regulatory risk, we will tell you that plainly rather than sell you complexity.
We operate what we build
Origination, decisioning, servicing and collections all fail in ways that only show up in production. The thin-file applicant, the revoked Open Banking consent, the arrears case that is a vulnerable customer. Because we run these systems, we design for those moments rather than for the demo, and we are there when they happen.
Senior engineers, blunt about trade-offs
You get senior people who will tell you when reducing friction breaks your affordability data, when a bureau integration is fragile, or when a collections optimisation crosses into behaviour the rules exist to prevent. We would rather have the awkward conversation early than build something that demos well and fails a regulator.
Related sectors
Part of Fintech & Financial Services. Adjacent sectors we also know.
Common questions
Can you build automated credit decisioning that still meets the requirement to explain a decline?
Yes, and we treat that requirement as non-negotiable rather than as something to trade away for a better-scoring model. In practice that means a transparent rule layer for policy and eligibility that a person can read and defend, models used only where they genuinely add lift and can be explained, clear reason codes on every outcome, and strict versioning so any past decision can be replayed exactly as it was made. We are blunt that a high-performing model which is a black box is a regulatory liability, not an asset, so where a transparent rule set does the job with far less fairness and regulatory risk, we will recommend that instead of selling you complexity you would then have to defend.
How do you handle fairness and bias in a decisioning model?
Deliberately, because a model trained on historical lending data will reproduce the patterns in that data, including ones you could not defend if they were written down as a policy, and proxies for protected characteristics that are easy to introduce by accident and hard to spot. We build the ability to measure fairness across the decisions the system makes, and to monitor it over time rather than checking once at launch, so that drift and unintended bias surface before they become a discrimination complaint you cannot answer. We are also honest about the limit: where the cost of getting a decision wrong is high and fairness cannot be adequately assured, the responsible recommendation may be a transparent rule set or a human in the loop rather than full automation.
We want to use Open Banking for affordability. What does that actually involve?
More than plugging in a feed. Open Banking gives you consented, revocable access to a customer’s real transaction data, which is far closer to the truth than declared or bureau-estimated income and expenditure, but it arrives raw and messy. The real work is turning it into a defensible affordability conclusion: categorising transactions, verifying income, identifying existing commitments and financial-difficulty signals, and handling the genuine uncertainty in categorisation honestly rather than pretending the data is clean. On top of that sits the consent lifecycle (scope, data minimisation and revocation), which has to be enforced in the architecture, not left to policy. We build all of that as one system rather than treating the affordability logic as an afterthought bolted onto a data pull.
How do you make sure collections is handled lawfully and fairly, not just efficiently?
By building it that way from the start rather than optimising for recovery rate and hoping compliance keeps up. Collections software that simply chases hardest where it pays best is exactly the kind of system Consumer Duty exists to prevent, so we design forbearance options, vulnerability handling and controlled, fair communication in as core behaviour, with a full record of what was offered and done for each customer. Recovery efficiency then comes from good process and good data rather than from pressure that turns into harm and regulatory exposure. We are engineers building the system to make lawful, fair treatment the default; the policy on how you treat customers in difficulty is yours, and we build the software to enforce it consistently.
Are you a compliance consultancy or a decisioning-model vendor?
Neither, and it is worth being clear about that. We are senior software engineers who build and operate lending systems (origination, decisioning, affordability, servicing and collections), to a standard where your firm’s regulatory obligations are achievable, evidenced and auditable in software. We do not sell you a proprietary decisioning model you cannot inspect, and we do not replace your compliance function or your legal and regulatory advice. What we do is build the system so that meeting responsible-lending rules, Consumer Duty and the duty to explain a decision is possible and demonstrable rather than aspirational, and tell you honestly where the automated, model-driven approach carries risk that a simpler, transparent one avoids.
Building for lending?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if lending is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.