Banking, Payments & Credit
Credit Risk Scoring API
A credit model is not judged on its accuracy alone. It is judged on whether you can explain any single decision it made, to the applicant and to your regulator, two years later.
- Banks
- Lenders
- BNPL providers
- Embedded finance platforms
- Credit unions
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Most lenders can build a model that ranks default risk reasonably well. The hard part is everything around it: which attributes you are permitted to use, whether the model treats protected groups differently in effect even when it never sees the attribute, how an adverse decision is explained to the applicant in language that is both accurate and legally adequate, and how the whole thing is documented so that a model risk review does not stall for six months.
Those constraints are not a compliance wrapper to be added at the end. They determine the modelling itself. Monotonic constraints on features, so a model can never score an applicant worse for having more income. Reason code generation that maps to the specific factors the regulation requires you to disclose. Disparate impact testing on every candidate model, with proxy attributes examined because a postcode can encode what the law forbids you to ask. A model built without these and retrofitted afterwards usually has to be rebuilt.
There is also a plain fact about data that gets glossed over. Alternative data is attractive precisely because it is predictive, and the reasons it is predictive are sometimes the reasons it is prohibited. Social connections, device characteristics, shopping categories and browsing behaviour can all carry default signal; using them in a credit decision ranges from clearly permitted to clearly unlawful depending on the attribute, the jurisdiction and the product. That determination is made before the feature is engineered, not after the model is fitted.
Who buys this
Banks, Lenders, BNPL providers, Embedded finance platforms, Credit unions
What the API returns
What comes back
- Probability of default over a defined outcome window, with a calibrated scale
- Reason codes for every decision, ordered by contribution and mapped to disclosable factors
- Score band and recommended decision against thresholds you configure
- Affordability assessment separate from risk ranking, since they answer different questions
- Feature contribution detail for each application, retained for audit
- Declined-decision explanation text suitable for an adverse action notice
- Model documentation pack: development data, validation results, monitoring design
- Fairness testing output across the protected groups your jurisdiction requires
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/applications/score | Score an application and return decision with reason codes |
| POST | /v1/affordability | Affordability assessment from income and commitment data |
| GET | /v1/decisions/{id} | Retrieve a stored decision with its inputs and model version |
| GET | /v1/decisions/{id}/explanation | Applicant-facing explanation and adverse action text |
| GET | /v1/models/{version}/validation | Validation and fairness test results for a model version |
| POST | /v1/outcomes | Submit realised default and repayment outcomes for monitoring |
Request and response
illustrativeRequest
{
"application_id": "app_4410982",
"product": { "type": "unsecured_instalment", "amount": 8000.00,
"term_months": 36, "currency": "GBP" },
"applicant": {
"bureau_reference": "br_77120",
"employment_status": "employed",
"time_in_employment_months": 41,
"declared_annual_income": 38500.00,
"existing_commitments_monthly": 740.00
},
"permitted_sources": ["bureau", "open_banking", "internal_history"],
"require_reason_codes": true
}Response
{
"application_id": "app_4410982",
"model_version": "pd_unsecured_v4.2",
"probability_of_default": 0.0417,
"outcome_window_months": 12,
"score": 684,
"score_scale": "300-850, higher is lower risk",
"band": "near_prime",
"recommended_decision": "approve_with_pricing_tier_3",
"reason_codes": [
{ "code": "R-14", "contribution": 0.031,
"disclosable_text": "Length of credit history is shorter than typical for this product" },
{ "code": "R-07", "contribution": 0.022,
"disclosable_text": "Proportion of income committed to existing credit is high" },
{ "code": "R-22", "contribution": 0.011,
"disclosable_text": "Recent number of credit applications" }
],
"affordability": {
"assessed_disposable_monthly": 612.00,
"proposed_repayment_monthly": 248.90,
"result": "affordable",
"basis": "open_banking_verified_income_and_expenditure"
},
"excluded_attributes": ["age", "postcode", "marital_status", "nationality"],
"decision_record_id": "dec_2026102110552201",
"scored_at": "2026-10-21T10:55:22Z"
}Where the data comes from
| Credit bureau data | The regulated, purpose-limited core of any credit decision; permissible purpose, consent and reciprocity obligations all apply and are not negotiable |
| Open banking transaction data | Verified income and expenditure with the applicant’s explicit consent, which materially improves affordability assessment — and the consent scope limits what else it may be used for |
| Your own lending history | Applications, approvals, repayments and defaults on your own book, which is usually the most predictive and most defensible dataset you have |
| Applicant-declared information | Income, employment and commitments as stated, used alongside verification rather than instead of it |
| Public insolvency and judgment registers | Statutory records where the jurisdiction permits their use in credit decisions |
| Excluded by design | Protected characteristics and their close proxies, and alternative data whose use in credit decisions is prohibited or unsettled in your jurisdiction — these are excluded at the feature engineering stage, not filtered at the end |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Monotonic constraints on every feature where the direction of effect is known, so the model can never penalise an applicant for a change that should help them
- Model class chosen for explainability as a first-order requirement: constrained gradient boosting or a scorecard, not an unconstrained ensemble that cannot produce defensible reason codes
- Reason code generation from per-application feature attribution, mapped to a fixed, reviewed vocabulary of disclosable factors rather than generated freely
- Proxy analysis on every candidate feature, testing whether it predicts a protected attribute — geography, device and merchant-category features are the usual offenders
- Disparate impact testing across the groups your jurisdiction requires, on every model version, with results retained as part of the model documentation
- Reject inference handled explicitly and conservatively, because a model trained only on approved applicants is biased by your own past policy and the correction is itself a modelling assumption
- Out-of-time validation on a holdout period, plus stability testing, because a model validated only on a random split will overstate its performance
- Production monitoring on population stability, score distribution, calibration and realised default by band, with defined thresholds that trigger review
What it changes for the business
Defensible decisions
Every decision is reproducible with its inputs, model version and reason codes, which is the form a complaint or regulatory query actually arrives in.
Faster model governance
A documentation pack produced alongside the model, rather than reconstructed afterwards, is usually what determines whether approval takes weeks or quarters.
Better risk separation
Verified income and expenditure data improves affordability assessment particularly for thin-file applicants, where bureau data alone is weakest.
Controlled expansion
Clear band-level performance lets you extend lending into adjacent segments with measured rather than assumed risk.
How it fits into your product
How it embeds
- Synchronous scoring inside your decision flow, with every decision written to an immutable record before the response returns
- Threshold and policy configuration held outside the model, so your credit committee changes policy without a model change
- Champion/challenger deployment so a new model version runs in shadow on live applications before any decision depends on it
- Adverse action text generated per decision in your supported languages, drawn from the reviewed reason code vocabulary
- Model documentation and validation output exported in the format your model risk function consumes
- Deployment inside your infrastructure, which is effectively mandatory here given bureau licence terms and data protection obligations
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Which attributes will you refuse to use?
Protected characteristics — race, ethnicity, religion, sex, nationality, marital status, disability and, in most jurisdictions, age beyond a statutory minimum. We also refuse close proxies where testing shows a feature predicts a protected attribute strongly enough to act as a substitute, which in practice most often means fine-grained geography. Beyond the clear prohibitions there is a grey zone, and our position is that if we cannot explain to your regulator why a feature is in the model, it does not go in the model.
Can you use alternative data to lend to thin-file applicants?
Some of it, and less than vendors suggest. Verified transaction data with consent is genuinely useful and broadly permitted. Device, social and browsing-derived attributes are predictive and frequently either prohibited or unsettled, and ‘unsettled’ is a bad basis for a credit decision you will have to defend. We go through this source by source during discovery and the answer is often no.
Is the model explainable enough for adverse action notices?
That is the constraint the model is built around, which is why we do not use unconstrained ensembles here. Every decision yields ordered feature contributions mapped to a reviewed vocabulary of disclosable reasons. We would not accept a model that scores marginally better and cannot produce a defensible reason code, and we would tell you if you asked for one.
Does this make the lending decision?
No. It returns a calibrated probability and a recommendation against thresholds you set. The credit policy, the thresholds, the override process and the final decision remain yours, held outside the model so your credit committee can change policy without touching it. The model is an input to a decision your institution owns.
What about bias already in our historical data?
It is there, and a model fitted on it will reproduce it. Past lending decisions embed past policy, including policy that may not withstand scrutiny, and the applicants you declined have no recorded outcome at all. We handle this with explicit reject inference, proxy testing and disparate impact measurement on every version — but we will not claim to have removed it. If testing shows a disparate outcome we cannot explain by permitted factors, the honest outcome is to change the model, and sometimes to tell you that a segment should not be modelled on the data available.
Related blueprints
Cash Flow Forecasting API
Runway, liquidity and scenario forecasts from transaction and ledger data, embedded in accounting and SME banking products.
AML Screening API
Sanctions, PEP and adverse media screening with entity resolution and relationship analysis, built so every hit can be explained.
Transaction Fraud Scoring API
Real-time risk scores for payments and account events, with explanations your analysts and your customers can both understand.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.