Loan-level modeling has a prerequisite that decides most projects before a single model is estimated: the data layer. At millions of rows — production work here has run at roughly 15 million loan-level records — the tools most finance teams reach for stop working, and the modeling effort quietly dies in the plumbing.
What breaks first
Spreadsheets go first: row limits, recalculation times, and silent corruption make them unusable as a system of record at this volume. Ad-hoc extracts go next — one-off queries against an operational database produce inconsistent snapshots that no two analyses agree on. What remains is the real requirement: a warehouse that holds the loan tape as versioned, reconciled, query-ready history.
The platform that makes per-credit modeling feasible
Three layers do the work. ETL pipelines land raw operational data into the warehouse reliably and repeatably. SQL modeling turns raw tables into clean, documented entities — credits, balances, payments, defaults — that models and dashboards share, so every number traces to one definition. Dashboards then sit on those entities for default rates, charge-offs, and financial-statement monitoring, refreshing from the same pipeline that feeds the models.
Why one builder across layers matters
Most practitioners work one layer — the warehouse, or the pipelines, or the models. The failure mode of splitting them is well known: models built on data whose lineage nobody fully owns. Owning the full stack — warehouse architecture, ETL, SQL modeling, and the probabilistic models on top — is what lets per-credit information survive intact from raw source to provision number.
This note applies a core capability: data engineering — warehouse architecture, ETL, and SQL modeling that keep per-credit information intact at scale. The models on top draw on data science & AI, and it supports the credit-risk and provision specialist application.
Explore Data Engineering Explore Data Science & AI Explore credit-risk & provision modeling