Flagship product

Credit Risk Model

A credit risk model built around your borrowers.

Combine the application, bureau, portfolio and transaction data relevant to your product to estimate probability of default, separate risk more precisely, and improve the decisions your lending workflow already makes.

Credit Risk ModelAPI / batch
Probability of default1.2%
Risk score87 / 100

Stable verified income with consistent repayment behavior.

Stable verified income with consistent repayment behavior.
inflow_stability_index
+15
inflow_income_verified
+10
WHY THIS EXISTS

More separation where your approval decisions are hardest

A lender-specific credit risk model estimates the probability that each applicant will default, learned from your own borrowers and your own repayment outcomes. A standardized score ranks the whole market; your portfolio is not the whole market. Calibrating to your product, your customers and your default definition improves separation exactly where approval decisions are hardest: thin-file applicants, borderline segments, and the tail where losses concentrate.

From your data to a decision-ready score

Any appropriate combination of the data you already hold. No single source is required, and transaction data is valuable but not mandatory.

Combinations of the below data types be used in each model.

Application

Bureau report

Account

Account activity

Bank transactions

Credit payment

Credit schedule

Credit Risk Model

Trained on your borrowers and outcomes

Probability of default

Risk score

Explainable drivers

Consumer lending and business lending

The model is calibrated per lending product, because default definitions, exposure profiles and repayment patterns differ by product.

Consumer lending

For consumer lending, the model draws on application, bureau, account and transaction data, plus credit payment and repayment schedule history where it exists. Any combination is usable, no single source is required, and the model is calibrated to your product's own default definition.

Cash advance
Personal loans
BNPL
Credit cards
Lines of credit
Auto
Overdrafts
Debt consolidation

Business lending

Business lending draws on the same combination of application, bureau, account and transaction data, with financials and accounting data added where relevant to the product. Default definitions and exposure profiles differ from consumer lending, so the model is calibrated separately for each product rather than reused as-is.

What the lender receives

A score per applicant with the drivers behind it, plus the performance evidence your risk team needs before anything goes live.

Credit Risk ModelAPI / batch
Probability of default1.2%
Risk score87 / 100

Stable verified income with consistent repayment behavior.

Approval rate vs. loss rate
051015200255075100Approval rate %Loss rate %Current approachLender-specific model
Promoters
Income Stability
inflow_stability_indexinflow_payroll_frequency
Repayment Consistency
outflow_recurring_payment_consistency
Detractors
Thin Reserves
liquidity_runway_monthsbalance_min_30d
Bureau Utilization
bureau_utilization_ratio
Score drivers
FeatureValueContributionExplanation
inflow_stability_index0.82+15Good income stability (0.82).
inflow_income_verified$5,800+10Verified income of $5,800.
outflow_recurring_payment_consistency92%+892% of recurring payments on time.
liquidity_runway_months1.5−6Emergency fund covers 1.5 months.
bureau_inquiry_velocity3−43 inquiries in last 6 months.

Tens of thousands of features tested, dozens to hundreds often selected per model based on the data available and on what performs best.

For illustrative purposes only

Ready to see how much separation improves on your own thin-file and borderline applicants?

Where it fits in your stack

Your decision engine, scorecard and origination platform receive the score and its top drivers by API or batch, consumed exactly like any other risk input you already use.

Decision engine

Scorecard

Origination platform

LMS

CRM

Portfolio analytics

Carrington Labs delivers decision-ready scores through API or batch. You retain control of policy, cutoffs and final decisions.

What makes this different

Built on your book, not a pooled score

Trained on your borrowers and your repayment outcomes, and calibrated to your product and your default definition.

Uses the data you already have

Any appropriate combination of application, bureau, internal performance, portfolio and transaction data. Transaction data adds signal where you have it; it is not required.

Explainable by design

Every score carries drivers your team can use inside your own adverse-action process.

Maintained as a service

Model development, monitoring, recalibration and retraining as your portfolio develops, not a one-off model handover.

How this differs from a standardized score

Both give you a score. The difference is what the model learned from, and how far it is tailored to your book.

Standardized / pooled scoreLender-specific Credit Risk Model
Trained onA reference population across many lendersYour borrowers and your repayment outcomes
CalibrationGeneric risk rankingYour product, customers and default definition
CustomizationFixed model and featuresFeatures engineered for your data
Who owns policyYou doYou do
IntegrationScore consumed by your systemsScore and drivers by API or batch
MaintenanceVendor release cycleMonitoring, recalibration and retraining as a service

How the model is built and maintained

Custom models as a service: we do the development and feature engineering inside client-specific data boundaries, subject to contract.

  1. 1

    Data preparation

    Your data is mapped, cleaned and de-identified ahead of modeling.

  2. 2

    Feature engineering

    Behavioral and performance features are engineered from your raw data.

  3. 3

    Training and validation

    The model is tested against your historical outcomes before deployment.

  4. 4

    Deployment

    Delivered via API or batch, alongside your existing rules and scorecards.

  5. 5

    Monitoring and retraining

    Performance is monitored on an ongoing basis and retrained around your portfolio.

EVIDENCE

Proven on your historical book before it scores anything live

We build the model on your historical data, score the applications you have already decided, and compare outcomes at matched approval rates. That gives your risk team a like-for-like read on separation and expected loss before production, on your book, not a reference portfolio.

Illustrative decile view
Decile 10.6% observed default
Decile 53.4%
Decile 1021.7%

Separation is assessed on your own historical outcomes; figures shown are illustrative.

Governance, explainability and integration

Explainability, lender control and data handling built into every deployment.

  1. Explainable outputs

    Every score returns its drivers with signed contributions and a plain-English explanation, for use within your own adverse-action process.

  2. Lender-controlled decisioning

    You set policy, cutoffs and overrides. Carrington Labs supplies the score, not the decision.

  3. Data handling

    Models are developed on de-identified data within client-specific boundaries, subject to contract. No PII is required.

  4. Compliance-ready

    Designed to support explainable, governed and lender-controlled use within your compliance framework.

  5. Integration

    API or batch delivery into your existing decision engine, scorecard and origination platform.

Frequently asked questions

Do we need transaction data?
No. The model can be built entirely on bureau, application and internal performance data. Where transaction data is available it adds signal, but it is never a prerequisite.
Whose data is the model trained on?
Yours. The model learns from your borrowers and your repayment outcomes, developed within client-specific data boundaries subject to contract, using de-identified data.
How do we know it performs before we deploy it?
We validate retrospectively on your historical book: scoring applications you have already decided and comparing outcomes at matched approval rates, so your risk team sees separation and expected loss before production.
Does this replace our scorecard or decision engine?
No. It supplies a score and its drivers into the systems you already run. Policy, cutoffs and final decisions remain yours.
Who maintains the model over time?
We do. Monitoring, recalibration and retraining are part of the managed service as your portfolio develops.
How is the model delivered?
By API for real-time decisioning or by batch for periodic scoring, into your existing workflow.
What data does a consumer credit risk model use?
Application, bureau, internal performance and portfolio data relevant to your product, plus bank transactions where you have them, though transaction data is never required. The model is trained on your own borrowers and repayment outcomes, not a pooled score.
Is a consumer credit risk model just a bureau score?
No. A bureau score ranks the whole market. A lender-specific model is calibrated to your product, your customers and your default definition, which improves separation exactly where approval decisions are hardest: thin-file applicants and borderline segments.
What data does a business credit risk model use?
The same underlying approach as a consumer model: application, bureau, internal performance and portfolio data, any appropriate combination, with financials included where relevant to business lending. No single source is required.
How does a business credit risk model differ from a consumer one?
Mainly in the inputs available: business lending typically adds financials alongside bureau, application and performance data. Both are trained on your own portfolio and your own default definition, and both are delivered with explainable score drivers.

See how a lender-specific model performs on your book.

A proof of concept runs on your historical data, so you can compare against your current approach before deploying anything.