I build the path from raw data to a decision someone can defend.

Data analytics

Turning a business question into a defensible answer

Framing the question precisely, establishing whether the data can answer it, and reporting the result with its caveats attached. The output is rarely a model — it is a number someone will act on, with the reasoning visible behind it, and the recurring reporting that follows once that number starts to matter.

• Exploratory and diagnostic analysis, cohort and segment work
• KPI and metric definition — including what a metric will not tell you
• Forecasting, trend and variance analysis
• Dashboards and recurring management or regulatory reporting

Data science & engineering

Models built to be validated, on pipelines built to be traced

Statistical and machine-learning modelling end to end — feature design, selection against a real baseline, calibration, and monitoring for drift — standing on ingestion that standardises messy multi-source feeds, quarantines what fails validation, and isolates every run so any figure can be walked back to the exact extract it came from.

• Supervised and unsupervised modelling, anomaly and outlier detection
• Pipelines, data quality, lineage and reproducible re-runs
• Baselines, cross-validation, leakage checks, calibration, interpretability
• Simulation and optimisation for decisions under uncertainty (SimPy, Gurobi)

Risk management

Making a risk something you can put a number and a threshold on

Translating a stated risk appetite into indicators that can actually be measured, with thresholds that trigger something when breached — and applying the same governance to the models themselves, which are subject to their own validation, documentation and monitoring rather than a once-a-year review.

• Risk appetite, key risk indicators and threshold design
• Scenario analysis, stress testing and sensitivity work
• Control design, testing and effectiveness measurement
• Model validation, challenger models, back-testing and drift monitoring

Regulatory compliance — banking

Prudential programmes that hold up under supervisory review

Most regulatory work in banking sits inside a programme with a supervisory deadline. These are the points where the models, the data and the regulatory return have to start agreeing with each other — and where every number needs a trail back to its source.

• Basel IV (CRR3): output floor impact, revised standardised approaches, RWA reconciliation
• IRB: PD, LGD and EAD development, recalibration and model-change documentation
• Stress testing: scenario projections, EBA and ICAAP exercises, reverse stress tests
• IFRS 9: lifetime ECL term structures, staging criteria, post-model adjustments
• BCBS 239: risk data lineage, data quality controls and reporting reconciliation

In design

Network-level financial crime detection

Moving from transaction-level scoring to the entity graph behind it: resolution of counterparties across feeds, then detection of structures — layering chains, circular flows, shared-beneficiary clusters — that no single transaction reveals.

In design

Small, private, on-premise models

Distilling task-specific models small enough to run where the data cannot leave the building — for organisations whose material is too sensitive for an external API — and measuring exactly how much accuracy that costs.

Open

Your problem

The most interesting future project is usually someone else’s current one. If you have a data or AI problem that is stuck between a feed and a decision, I would like to hear about it.