Credit scoring & default prediction

Anyone who lends money or delivers before payment needs to know who will pay. This covers banks, leasing firms, BNPL providers, telcos, energy suppliers and Mittelstand firms selling on account. Credit scoring learns from past repayment outcomes and estimates a probability of default for each applicant or customer. It returns that as a score with a decision and the reasons behind it. The technique is 60 years old. Gradient-boosted trees, open-banking cash-flow data and tabular foundation models now let even small lenders build better models than static scorecards. EU law sets the limits: credit scoring of natural persons is high-risk under the AI Act, and the CJEU has ruled that a decisive score is an automated decision under Art. 22 GDPR.

Problem & value

• Today: large lenders run logistic-regression scorecards and IRB rating models, built with SAS or Python and reviewed yearly. SMBs and merchants use bureau scores (SCHUFA, Creditreform, CRIF) with fixed cut-offs, or a person makes the call by gut feeling. Thin-file applicants (young people, migrants, the self-employed, start-ups) are declined or priced badly because the bureau knows little about them.
• AI value: better ranking of good vs. bad risks at the same approval rate, or more approvals at the same loss rate. Instant decisions for small tickets. Use of cash-flow data from PSD2 account access for thin-file customers. Earlier warning on existing borrowers through behavioural scores. Consistent, documented decisions instead of individual judgement.
• Scale: Provenir reports more than 4 billion decisions a year for 120+ financial-services providers [10]. Vendor uplift figures are customer anecdotes, so validate on your own back-book.

Variants

• Consumer lending (banks, consumer-finance firms, car finance and leasing): application score at origination, behavioural score on existing accounts, and PD for provisioning (IFRS 9) and capital (IRB). Annex III high-risk, CCD2 creditworthiness rules.
• BNPL / checkout financing and telco or utility contracts: millisecond decisions on small amounts, with bureau data plus device, basket and order history. Fraud is a separate model (ANOM-001). Note that the C-203/22 case concerned a €10/month mobile contract [3].
• SME and corporate credit: ratings from financial statements (DOC-012), bank statements (DOC-017), register and payment-experience data. Not high-risk under the AI Act for legal persons, but sole traders and guarantors are natural persons.
• B2B trade credit at Mittelstand suppliers: setting payment terms and credit limits for customers, using Creditreform, D&B or CRIF company reports plus your own payment history. Late payment and collections after the invoice belong to PRED-021.
• Public sector and development banks: promotional loans and guarantee programmes use the same rating methods, under the same AI Act and GDPR rules.
• Private use: consumers check their own bureau data and score (free data copy under Art. 15 GDPR, the SCHUFA self-check) and correct errors before applying for a mortgage or a rental.

How it works

1. application / account event
2. data collection (application form, bureau call, PSD2 account data with consent, internal history)
3. feature engineering (WoE binning, ratios, transaction-category aggregates, cash-flow volatility)
4. PD model (scorecard or monotone gradient-boosted trees)
5. calibration to PD / rating grade
6. policy rules (hard rules, affordability check, limits, exclusions, fraud/KYC results)
7. decision: approve | refer to underwriter (human-in-the-loop) | decline + price/limit
8. reason codes + explanation letter (template or LLM-drafted, human-approved text)
9. monitoring (Gini/AUC, calibration, PSI drift, approval rate, fairness by group)
10. periodic re-development

• Model core: binary classification of "default within horizon" (e.g. 90+ days past due within 12 months) on tabular data. Logistic-regression scorecards stay the regulatory reference. Gradient-boosted trees (LightGBM, XGBoost, CatBoost) with monotonic constraints usually rank better and stay explainable. Tabular foundation models (TabPFN, TabICL) help most when data are small.
• Open-banking features: transactions are categorised first (LANG-033). From that come income stability, rent, existing debt payments, gambling or return-debit flags and balance trajectories. These are time-series and sequence features.
• Reject inference & bias: a model only sees outcomes for applicants who were approved. Use reject-inference methods and challenger tests so the model does not just copy the old policy.
• LLM role: not the scorer. LLMs draft explanation letters and underwriter summaries, checked against the actual reason codes. Vendors also add agents for onboarding and underwriter support [9][10]. Credit-memo agents for commercial lending are AGENT-028.
• Human-in-the-loop: underwriters review grey-zone cases and overrides. Every applicant can ask for human review of an automated decision (Art. 22(3) GDPR, CCD2) [2][5].

Data preparation

Which data: application data, repayment and arrears history, collections outcomes, bureau scores and, for companies, financial statements and payment experience. Optional PSD2 transaction data needs explicit consent.

Where it lives in an SMB: ERP or accounting (open items, dunning), CRM, order system, scanned contracts and annual accounts in a DMS or file share, and bureau reports as PDFs in mail.

Typical gaps: customers duplicated across systems, no consistent "default" definition, paper or scanned financials without structure, too few defaults for a stable model, missing outcome labels, and unclear legal basis for reusing data.

Steps: 1. Extract customer, invoice and payment data from ERP/CRM (PREP-005) and merge duplicates. 2. Define "default" (for example 90 days overdue or write-off) and harvest labels from dunning and collections records (PREP-020). 3. Digitise annual accounts with OCR (PREP-006, DOC-014). 4. Pseudonymise training extracts (PREP-022) and check purpose and legal basis (PREP-025). 5. Hold out a time-based test set (PREP-018).

Effort share: roughly 50-60 percent of the project is data work. SMBs buying bureau scores need only steps 1 and 2. See GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

• SMB (A): Bureau and platform scores (Creditreform, CRIF, SCHUFA B2B, Boniversum) are mature, EU-hosted and priced per query, and trade credit checks are a standard process.
• Enterprise (C): For lenders the score is core business; data is highly sensitive and volumes make per-query fees high, so a self-hosted gradient-boosting model on own history pays off.
• Developer (C): Open-source tabular ML (scikit-learn, LightGBM, scorecard tooling) runs on HW1 and gives full control over validation and explainability.
• Private (A): Consumers use the self-disclosure scores and credit monitoring offered by bureaus; there is nothing to build.
• Public (C): Municipal and utility receivables scoring involves citizen data and procurement rules, favouring a self-hosted or sovereign-cloud setup.

Path A — Buy (recommended for SMBs and most smaller lenders)

• Bureau scores and reports: SCHUFA (DE), CRIF (IT/DE), Creditreform (DE) [11], Boniversum (DE), infoscore/Experian, Dun & Bradstreet. For a merchant selling on account this is usually enough, together with your own payment history.
• Decisioning platforms with model hosting: Taktile (Berlin-founded, rules + ML + agents, used by banks and insurers [9]), Provenir [10], Experian PowerCurve, FICO Platform, SAS Viya, Zest AI (US). In Germany, core-banking and loan-origination suites add their own scoring modules.
• Open-banking data providers: finAPI (Munich; digital account check, KreditCheck, risk analysis API [12]), Tink (Visa), GoCardless Bank Account Data.
• Choose A when: you do not have years of labelled repayment data, or you want regulatory documentation, monitoring and audit trails from the vendor. Ask for EU hosting, model documentation for AI Act Annex IV, reason-code output and a DPA.

Path B — Build on cloud APIs / managed ML

• Managed ML platforms in EU regions: Azure Machine Learning (Germany West Central), Vertex AI (europe-west3), SageMaker (eu-central-1), Databricks. German sovereign options: STACKIT and Open Telekom Cloud, running your own containers. AutoML gives baselines. For production, train explicit, versioned GBM or scorecard models.
• Hosted tabular foundation models: the Prior Labs TabPFN API (German, Freiburg) handles small to mid-size datasets. TabPFN-3.5 (Sep 2026) supports up to 1M rows and 20k features. Production use requires the API or a commercial licence [7].
• LLM APIs for the explanation layer: Mistral (EU), Azure OpenAI or Claude/Gemini in EU regions. These draft letters and underwriter summaries from structured reason codes, with no raw bureau data in the prompt.
• Integration: bureau APIs, PSD2 AIS provider, loan-origination system, and a decision engine (Taktile, or your own rules service) as the place where policies are versioned.

Path C — Self-host (open source)

• Modelling: scikit-learn, LightGBM / XGBoost / CatBoost with monotone constraints. OptBinning for WoE binning and scorecards (Apache-2.0) [8]. InterpretML EBM for glass-box models. TabICL as an open tabular in-context model.
• Explainability & fairness: SHAP for reason codes, Fairlearn for group metrics [13], DiCE or OptBinning counterfactuals for "what would change the result".
• MLOps: MLflow (registry, lineage), Feast (feature store), Evidently or NannyML (drift and performance monitoring), served via FastAPI or BentoML. Rules in a DMN engine (Camunda, Drools) or OpenL Tablets.
• Explanation LLM (optional): Mistral Small or Qwen3 8B–32B via vLLM on HW2.
• Hardware: HW1. GBM training on millions of rows runs on a CPU server, and scoring takes milliseconds per request. Ops effort comes from model risk management, not compute.

Path D — Custom training

This is the normal case for banks with their own portfolio. You develop custom PD/LGD/EAD models on several years of performance data, with enough defaults per segment, through-the-cycle calibration and independent validation. Fine-tuning tabular foundation models on your own portfolio is new and needs a commercial licence for TabPFN-2.5 and later [6][7]. Training LLMs on credit data is rarely worth it, and their scoring cannot easily be explained.

State of the art (2026)

• Best practice: monotone-constrained gradient boosting or EBMs, calibrated to PD, with SHAP-based reason codes. Use a scorecard challenger for regulatory comparison and interpretation.
• Tabular foundation models: Prior Labs moved from TabPFNv2 (10k rows) to TabPFN-2.5 (Nov 2025, 100k rows), TabPFN-3 (May 2026) and TabPFN-3.5 (Sep 2026, up to 1M rows) [6][7]. They are strong on small portfolios and new products. For large, mature portfolios, tuned GBMs remain hard to beat. The weights carry non-commercial licences [7].
• Cash-flow underwriting: PSD2 account data is now standard for thin-file and SME lending. FIDA (financial data access) is still being negotiated at EU level, so do not plan on it yet.
• Limits: population drift (recessions, rate shocks), selection bias from past policy, proxy discrimination (postcode, name, language and device features), and few defaults in low-default portfolios. A model also cannot know about events after the data snapshot.

Shared resources & combinations

• Same tabular stack (tabular-ml, HW1, MLflow/feature store): PRED-010 insurance underwriting, PRED-015 AVM, PRED-021 collections, PRED-005 lead scoring, PRED-003 churn. One MLOps and monitoring platform serves all of them.
• Upstream data: DOC-017 bank-statement and payslip analysis, DOC-012 financial-statement spreading, LANG-033 transaction categorisation (feeds the cash-flow features), AGENT-015 KYC onboarding.
• Downstream and adjacent: AGENT-028 credit memo agent (uses PD as an input), PRED-021 collections after origination, PRED-016 liquidity, ANOM-001 / ANOM-017 fraud and document tampering (the AI Act exempts fraud detection from Annex III 5(b) [1]), ANOM-011 supplier risk.
• Governance: SEC-022 AI inventory and AI Act documentation. DATA-005 synthetic data for development and testing outside production.

Effort, cost & KPIs

• Path A: weeks for bureau-score cut-offs. 2–4 months to bring in a decisioning platform with your own model. Cost is per bureau query, per decision or a platform licence.
• Path B/C: 4–9 months for the first production model, including data mart, validation, documentation and decision-engine integration.
• Path D (bank): 6–12+ months per model family, plus yearly validation. IRB models also need supervisory approval.
• KPIs: Gini/AUC and KS on an out-of-time sample, calibration (predicted vs. observed default rate per grade), approval rate at constant bad rate, loss rate and vintage curves, PSI stability, share of manual referrals, time to decision, override rate, fairness gaps by protected group, and complaint and Art. 22 review requests.

People & change

Involve early: management (risk appetite, budget), the credit or receivables lead as process owner, IT and IT security (interfaces, bureau data), the DPO and legal/compliance (Art. 22 GDPR, SCHUFA case law, consumer credit rules), and data owners in finance. Add HR only if staff scores are computed, which this use case does not do.

Works council: usually no. The system evaluates customers, not employees, so §87(1) no. 6 BetrVG is not triggered by the scoring itself. It becomes relevant if the tool logs which clerk overrides or approves decisions in a way that measures individual performance; then involve the council, and inform it under §90(1) no. 3 about AI-supported work processes.

Data protection: a DPIA (Art. 35 GDPR) is very likely for systematic evaluation of people; conclude an AVV (Art. 28) with every scoring provider. See GUIDE-005.

AI literacy: the AI Act (Art. 4) requires measures that support staff's AI literacy; train underwriters on reading reason codes and on when to override (GUIDE-006).

Communication and pilot: start with one product line or customer segment in shadow mode, comparing the score with human decisions (GUIDE-009).

Concerns: fear of unfair rejections is met with reason codes, fairness monitoring and a human review for every decline or refer decision. Keep humans in control of final decisions (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: high-risk under Annex III point 5(b) for evaluating the creditworthiness or credit score of natural persons. Fraud detection is excluded [1]. Requirements include risk management, data governance, technical documentation, logging, human oversight and accuracy. Deployers that are bodies governed by public law or provide public services, and deployers using 5(b) systems, must do a fundamental-rights impact assessment (Art. 27). After the Digital Omnibus, the Commission's timeline says Annex III rules apply from 2 December 2027 [4]. Scoring purely of legal persons is not Annex III, but EBA guidelines still apply. Life and health insurance pricing is 5(c), see PRED-010. Social scoring across unrelated contexts is prohibited under Art. 5(1)(c). Do not use social-media behaviour or similar unrelated data.
• GDPR: the CJEU (C-634/21, 7 Dec 2023) held that producing a score is an automated decision under Art. 22 when the lender gives it a determining role [2]. In C-203/22 (27 Feb 2025) it held that applicants must get an explanation of the procedure and principles actually applied that they can understand. Showing how different data would have changed the result can be appropriate. Handing over the algorithm is not enough, and trade secrets go to the authority or court for balancing [3]. Provide human intervention, the chance to state a view and contest (Art. 22(3)) [5]. In Germany, § 31 BDSG on scoring also applies.
• Consumer Credit Directive (EU) 2023/2225 (CCD2): applies from 20 Nov 2026. It requires a creditworthiness assessment based on relevant, accurate income and expense data. It bans the use of special-category data and data from social networks. Where processing is automated, the consumer has rights to human review, an explanation and to contest the decision. Check national transposition [14].
• Banking supervision: EBA GL/2020/06 on loan origination (since 30 June 2021) require understanding of automated models, bias prevention, data quality, traceability, backtesting, overrides and documentation [15]. Also MaRisk (DE), CRR for IRB models, IFRS 9, and DORA for outsourced ICT and decision platforms.
• Mitigations: feature allow-list (no protected attributes or close proxies), fairness testing, independent validation, logged decisions with model version, fast human review.

Getting started

1. Define the target precisely (default definition, horizon, segment) and build an outcome-labelled data mart from at least 2–3 years of decisions, including declined applications.
2. Start with a bureau-score policy or a vendor platform (Path A). Measure the baseline approval rate, bad rate and time to decision.
3. Develop a challenger: an OptBinning scorecard plus a monotone LightGBM, and a TabPFN model if data are small. Validate out-of-time, with calibration and fairness reports.
4. Write AI Act and GDPR documentation from day one: intended purpose, data sheet, explanation templates, human-review process, logging.
5. Go live in shadow mode, then as a champion/challenger split. Monitor PSI, calibration and overrides monthly.

Sources

1. EU AI Act, Annex III (point 5(b) creditworthiness, 5(c) life/health insurance) — https://artificialintelligenceact.eu/annex/3/
2. CJEU press release 186/23, C-634/21 SCHUFA Holding (Scoring), 7 Dec 2023 — https://curia.europa.eu/jcms/upload/docs/application/pdf/2023-12/cp230186en.pdf
3. CJEU press release 22/25, C-203/22 Dun & Bradstreet Austria, 27 Feb 2025 — https://curia.europa.eu/jcms/upload/docs/application/pdf/2025-02/cp250022en.pdf
4. European Commission AI Act Service Desk — implementation timeline (Annex III from 2 Dec 2027) — https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
5. GDPR Art. 22 — https://gdpr-info.eu/art-22-gdpr/
6. Prior Labs — TabPFN repository — https://github.com/PriorLabs/TabPFN
7. Prior Labs — TabPFN models, limits and licences — https://docs.priorlabs.ai/models
8. OptBinning (optimal binning & scorecards) — https://github.com/guillermo-navas-palencia/optbinning
9. Taktile decisioning platform — https://taktile.com/
10. Provenir — AI decisioning platform — https://www.provenir.com/
11. Creditreform — Bonität & Risikobewertung — https://www.creditreform.de/
12. finAPI — account-data based credit checks — https://www.finapi.io/en/
13. Fairlearn — https://fairlearn.org/
14. Directive (EU) 2023/2225 on credit agreements for consumers (CCD2) — https://eur-lex.europa.eu/eli/dir/2023/2225/oj
15. EBA Guidelines on loan origination and monitoring (EBA/GL/2020/06), Final report — https://www.eba.europa.eu/sites/default/files/document_library/Publications/Guidelines/2020/Guidelines%20on%20loan%20origination%20and%20monitoring/884283/EBA%20GL%202020%2006%20Final%20Report%20on%20GL%20on%20loan%20origination%20and%20monitoring.pdf