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.
Stable verified income with consistent repayment behavior.
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.
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
The model is calibrated per lending product, because default definitions, exposure profiles and repayment patterns differ by product.
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.
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.
A score per applicant with the drivers behind it, plus the performance evidence your risk team needs before anything goes live.
Stable verified income with consistent repayment behavior.
inflow_stability_indexinflow_payroll_frequencyoutflow_recurring_payment_consistencyliquidity_runway_monthsbalance_min_30dbureau_utilization_ratio| Feature | Value | Contribution | Explanation |
|---|---|---|---|
inflow_stability_index | 0.82 | +15 | Good income stability (0.82). |
inflow_income_verified | $5,800 | +10 | Verified income of $5,800. |
outflow_recurring_payment_consistency | 92% | +8 | 92% of recurring payments on time. |
liquidity_runway_months | 1.5 | −6 | Emergency fund covers 1.5 months. |
bureau_inquiry_velocity | 3 | −4 | 3 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?
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.
Trained on your borrowers and your repayment outcomes, and calibrated to your product and your default definition.
Any appropriate combination of application, bureau, internal performance, portfolio and transaction data. Transaction data adds signal where you have it; it is not required.
Every score carries drivers your team can use inside your own adverse-action process.
Model development, monitoring, recalibration and retraining as your portfolio develops, not a one-off model handover.
Both give you a score. The difference is what the model learned from, and how far it is tailored to your book.
| Standardized / pooled score | Lender-specific Credit Risk Model | |
|---|---|---|
| Trained on | A reference population across many lenders | Your borrowers and your repayment outcomes |
| Calibration | Generic risk ranking | Your product, customers and default definition |
| Customization | Fixed model and features | Features engineered for your data |
| Who owns policy | You do | You do |
| Integration | Score consumed by your systems | Score and drivers by API or batch |
| Maintenance | Vendor release cycle | Monitoring, recalibration and retraining as a service |
Comparing against a decisioning platform instead? See the comparison.
Custom models as a service: we do the development and feature engineering inside client-specific data boundaries, subject to contract.
1
Your data is mapped, cleaned and de-identified ahead of modeling.
2
Behavioral and performance features are engineered from your raw data.
3
The model is tested against your historical outcomes before deployment.
4
Delivered via API or batch, alongside your existing rules and scorecards.
5
Performance is monitored on an ongoing basis and retrained around your portfolio.
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.
Separation is assessed on your own historical outcomes; figures shown are illustrative.
Explainability, lender control and data handling built into every deployment.
Every score returns its drivers with signed contributions and a plain-English explanation, for use within your own adverse-action process.
You set policy, cutoffs and overrides. Carrington Labs supplies the score, not the decision.
Models are developed on de-identified data within client-specific boundaries, subject to contract. No PII is required.
Designed to support explainable, governed and lender-controlled use within your compliance framework.
API or batch delivery into your existing decision engine, scorecard and origination platform.
A proof of concept runs on your historical data, so you can compare against your current approach before deploying anything.