Assess an application
A new applicant's profile and one order. The form starts at a typical applicant; change any detail and assess. Whether the credit file is thin is worked out for you.
What could change the outcome
Your repayment plan
What happens next
Why a person needs to look
Risk factors
Strengths
Checks
| Check | Detail |
|---|
Track record of similar past customers
The structured record an auditor would see. Shown here only: this site stores and sends nothing. Approver identity is not recorded (Decision 23).
Detail: compared with a typical applicant
How much each detail moves the probability of default, against the same detail set to the typical applicant's (the reasons above use these).
What would change the recommendation
The smallest single change, within the range seen in training, that moves this applicant across the review cutoff.
One input at a time, everything else unchanged. This describes how the model responds; it is not causal and not financial advice.
How this is built
A governed champion
Calibrated XGBoost, 13 features, selected and promoted through a champion / challenger workflow with an automated evidence gate. One feature was removed because it leaked the outcome, a decision taken on validity even though it cost a little Gini.
Verified, not assumed
The browser model was converted to ONNX and checked against the Python champion before publishing: zero decisions changed across 41,604 customers.
Re-run the check in your browser →Honest about scope
A customer-level portfolio-risk model, not a validated application-time underwriting model. It returns a probability and a review recommendation, never an invented credit score or limit.
Every decision on record
Each consequential choice, including the mistakes found and fixed, is in the Engineering Decision Log.