Newcomer Credit Data Platform: Jimmy Okoth

Progress

00Project base and workstation DoneLocal PostgreSQL with a least-privilege project user, a four-layer warehouse, an isolated Python environment, a dbt connection, and a check script that proves it all works.READ THE WRITE-UP →

01Synthetic data generator DoneA seeded generator for a synthetic town of 1,000 customers and about 60,000 bank transactions, with a manifest that fingerprints every file and twelve tests that prove the data keeps its promises.READ THE WRITE-UP →

02Loading the raw layer IN PROGRESSLoad the generated files into PostgreSQL with a loader that can run twice without creating a single duplicate, recording every load against the manifest's fingerprints.

03First dbt model Planned

04Affordability features PlannedPoint-in-time features in the marts layer.

The problem

People who move to a new country often have little or no local credit history, so the signals lenders usually rely on don't exist for them yet. This platform takes the financial records they do have, which are often messy, and turns them into fair, point-in-time affordability features.

What "point-in-time" means here

Every feature has to be built only from data that was available on the date a decision would have been made. No peeking at what happened later. It's what keeps the features honest.

How it's built

Data moves through four layers in PostgreSQL, each with one job:

raw: data exactly as received, never edited
staging: cleaned and typed
intermediate: business logic building blocks
marts: final outputs, like features and reports

dbt handles the transformations between layers. The whole setup lives in code, so it can be reviewed, repeated and rebuilt from nothing, and every step is safe to run twice.

Follow along

This case study grows with the project. Each stage gets its own write-up, errors included:

Before the First Pipeline: setting up the machine and project base
Fake Data, Real Discipline: the seeded test data generator