The mechanisms, not the screenshots
Three pieces of work you can operate. Each one is rebuilt from something I shipped, so the trade-offs you can feel here are the trade-offs the team actually argued about.
The validation gate that moved accuracy from ~88% to 98%
Automated data-quality rules running inside the ELT, not after it. Toggle the rules off to watch bad records reach the dashboard the way they used to.
Rabalon — automated data-quality and validation rules in the ELT pipeline.
Validation rules in the pipeline
Each rule blocks bad rows before they reach a dashboard. Turn them off to see what the reporting layer used to receive.
10 of 12 bad records caught in the pipeline. 2 escaped every rule.
100 records from one load. Even with every rule on, two defects get through, which is why the honest number is 98 and not 100.
Catching credit deterioration 3–4 weeks earlier
Move the sensitivity threshold and watch the trade-off every risk team actually argues about: earlier warnings against more false alarms.
Ferrum Capital — Python anomaly-detection and risk models over financial and credit data.
than the account reaching formal delinquency
19 false alarms per quarter across the portfolio
Turning sensitivity up buys lead time and spends review capacity. The build settled in the 3 to 4 week band because that was the earliest warning the team could still act on without drowning in alerts.
From a vague business ask to a spec engineers can build
Seven steps from “can we get a report” to acceptance criteria and test cases, using a real credit-risk build as the worked example.
Ferrum Capital — reconstructed spec, employer-specific details generalized.
Credit-risk early-warning: from business ask to engineering spec
Reconstructed from a real build at a credit and lending business (2020–2023), with employer-specific table and field names generalized. The shape, the questions, and the acceptance criteria are the ones I actually use.
Step 1 of 7
What the stakeholder said
Verbatim, before any analysis. Written down because the wording matters later.
“We keep finding out about problem accounts too late. Can we get a report that shows us which ones are going bad?”
- Three undefined terms in one sentence: “problem”, “too late”, and “going bad”.
- A report was requested. A decision was described. Those are not the same deliverable.
- No owner named yet, and no stated action to take when an account is flagged.
Step 2 of 7
The questions that had to be answered first
Requirements gathering is mostly refusing to guess. Each answer removed a build path.
I took these to the risk lead and the collections team separately, because they defined “problem” differently and both of them were right for their own workflow.
- What decision changes when an account is flagged, and who makes it?
- How much earlier than today is worth having? A day? A month?
- What does a missed flag cost, versus a false alarm? (This sets the threshold, not statistics.)
- Which existing definition of a delinquent account do we adopt, and who owns it?
- How many alerts per week can the team actually work through?
Step 3 of 7
The requirement, stated so it can be built and tested
One user story, with acceptance criteria that a person other than me can verify.
As a risk analyst, I need accounts showing early deterioration signals surfaced weekly, so that outreach begins before an account reaches formal delinquency.
- GIVEN an account with a deterioration signal in the scoring window, WHEN the weekly run completes, THEN it appears on the review queue with the contributing factors listed.
- AND the queue is capped at the volume the team agreed it can work (alerts are worthless if they are ignored).
- AND every flagged account records why it was flagged, retained for audit.
- AND accounts already in formal delinquency are excluded — that is a different workflow.
Step 4 of 7
Data flow and interface points
Where the data comes from, what each hop guarantees, and who owns the edge.
The integration risk was never the model. It was the four upstream systems, each owned by a different team, each with its own idea of when a day ends.
- Sources: core account ledger, payment history, customer master, external credit reference data.
- Landing: raw, unmodified, timestamped on arrival. No cleanup at extraction (you cannot reconstruct what you dropped).
- Modeling: point-in-time account state. Financial data must be reproducible as of a date, or the audit fails.
- Serving: scored review queue plus the factor detail behind each score.
- Named owner per source, and an agreed contact for schema changes. This was the part that actually prevented incidents.
Step 5 of 7
Business definitions, written down once
The single highest-value page in any spec I have written. Ambiguity here becomes a production defect later.
Two teams had been using “active account” to mean different things for years, and both had built reports on it. Nobody had noticed because the reports never sat side by side.
- Every term used in the requirement gets one definition, one owner, and one location.
- Definitions live next to the model that implements them, so they cannot drift apart silently.
- “As of” semantics stated explicitly for every metric: event date, effective date, or reporting date.
- Where a definition is contested, the spec records both readings and who decided between them.
Step 6 of 7
Test cases and edge cases, handed over with the spec
Written before implementation, so “done” is not a matter of opinion.
Each of these became an automated check rather than a manual review step, which is the only version of quality control that survives a busy quarter.
- Account with no payment history: must not error, must not score.
- Account whose upstream record arrives late: must be scored on the next run, not silently skipped.
- Duplicate account records across source systems: must resolve to one, deterministically.
- Backdated correction upstream: must change the point-in-time result for that date, and be visible as a change.
- Zero-alert week: must be distinguishable from a failed run. (This one is always missing and it always matters.)
Step 7 of 7
What shipped
The number the spec was accountable for.
Python anomaly-detection and risk models over financial and credit data, surfacing potential issues 3 to 4 weeks earlier than the previous process and reducing escalation risk.
- Earlier detection mattered because it moved accounts into a workflow that still had options.
- The definitions page outlived the model. It was still in use after the scoring logic had been rewritten.
- Documented lineage and KPI logic let the team self-serve; adoption rose ~60% within six months.
The full build behind the first two is written up in the case study, and the requirements side has its own home on the analyst page.