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

Monitoring that survives an examination

Financial-crime compliance built so that every alert, every threshold and every dismissed case has a reason attached to it. A supervisor’s question is rarely “is the model accurate?” — it is “show me why this rule is set here, what it found, and what you did about it” — which makes lineage and documentation part of the control, not paperwork after the fact.

• AML/CFT transaction monitoring: typology coverage and rule rationale
• KYC and customer due diligence data, sanctions and PEP screening
• Alert-to-report quality: investigation trail, escalation, unusual-transaction reporting
• Audit-ready lineage, reproducible regulatory reporting, privacy and retention

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.