Guide · rw/applied-ai

AI for risk, forecasting and decisions.

Most organisations already hold the data they need. What they lack is a reliable way to move from reporting what happened to estimating what is likely to happen next, and to act on it inside the systems people already use. This guide describes how we build that, with the constraints of insurance, financial services and trading firmly in mind.

Model choice: accuracy versus explainability

High accuracy, high explainability: Gradient-boosted trees for risk and pricing
High accuracy, lower explainability: Deep learning for image, voice and pattern tasks
Lower accuracy, high explainability: Linear models and rule baselines for regulatory reporting
Lower accuracy, lower explainability: Avoid. Revisit the data or the decision framing.
01

Decision

Name the recurring decision, its owner and the action that follows a better estimate.

02

Data

Build a historical view with correct lineage, no leakage and consistent labels.

03

Model

Pick the simplest technique that clears the accuracy bar for the regulator and the business.

04

Deploy

Put the prediction inside the workflow, not on a dashboard nobody opens.

05

Monitor

Track drift, outcomes and business impact, with clear retrain triggers.

Start from a decision, not a model

Every engagement begins with one question: which recurring decision would change if the estimate were better? Pricing a policy, flagging a claim, sizing a position, approving a limit, scheduling capacity. If nobody can name the decision, the owner and the action that follows, no model will create value.

Data readiness in practice

Readiness is rarely about volume. It is about lineage, timeliness and leakage. Can you reconstruct what was known at the moment of the decision? Is the label you want to predict recorded consistently across systems and years? We spend the first weeks building that historical view, because a model trained on information that was not available in real life will look brilliant and fail in production.

Tabular risk / pricing85%
Time-series forecasting70%
Document-heavy workflows60%
Real-time trading signals45%

Choosing the right level of complexity

Gradient-boosted trees still win most tabular risk and pricing problems, and they are far easier to explain to a regulator than a deep network. Time-series forecasting benefits from hierarchical reconciliation more than from exotic architectures. Language models earn their place in document-heavy workflows: claims handling, KYC files, research summarisation. We pick the simplest technique that clears the accuracy bar, then invest the remaining effort in deployment.

Deployment where the work happens

A prediction that lives in a dashboard is a suggestion. A prediction that lives in the underwriting screen, the claims queue or the order management system is a decision system. We deliver models as services with clear contracts, plus the integration work that puts the output in front of the person or process that acts on it, including the fallback for when the service is unavailable.

Monitoring, drift and honest measurement

We instrument every model for input drift, output distribution and realised outcome versus prediction, and we agree in advance what triggers a retrain or a rollback. Business impact is measured against a holdout or a staged rollout, not against a promise made in a proposal.

Governance that survives an audit

In regulated environments the model is only half the deliverable. The other half is documentation: data sources, feature definitions, validation evidence, fairness testing, human override paths and version history. We build this as the project runs, so approval is a review rather than an archaeology project.

Platforms and partners we work with
Modelling and ML
PythonXGBoostLightGBMPyTorchscikit-learnProphet
Data platform
SnowflakeDatabricksdbtApache KafkaPostgreSQL
Serving and MLOps
Microsoft Azure MLAWS SageMakerMLflowKubernetesEvidently
Language and document AI
OpenAIAnthropic ClaudeAzure OpenAIMistralLangChain

What this looks like per sector

In insurance the highest-value work is usually pricing sophistication and claims triage: a gradient-boosted pricing model that reflects real risk, plus a triage score that routes the twenty percent of claims worth a human specialist on day one instead of day nine. Both need to be explainable to an actuary and a regulator, which is why we rarely reach for deep learning here.

In finance it is limit monitoring, fraud and anti-money-laundering alert quality, and cash-flow forecasting. The win is often not a smarter model but a sharper threshold: cutting false positives by half gives a compliance team back weeks of capacity every quarter.

On trading desks it is signal research, execution quality and exposure forecasting, delivered as low-latency services with hard fallbacks. Nothing goes live without a shadow period where the model runs alongside the current process and both are scored on the same outcomes.

Weeks 1-2

Decision framing

Name the decision, the owner, the action and the value of being right more often. Kill the ideas that fail this test early.

Weeks 3-6

Data reconstruction

Rebuild what was known at the moment of each historical decision, with lineage and no leakage.

Weeks 7-10

Baseline and model

Rule baseline first, then the simplest model that beats it by a margin worth deploying.

Weeks 11-14

Shadow run

Predictions produced in production but not acted on, scored daily against the incumbent process.

Week 15 onward

Live and monitored

Staged rollout, drift and outcome tracking, agreed retrain triggers and a documented override path.

Models are cheap. Decisions are not. We only build the ones somebody will actually act on.
Redwind AI practice
Key takeaways
  1. 01If nobody can name the decision, the owner and the follow-up action, there is no project worth starting.
  2. 02Leakage is the most common reason a brilliant offline model fails in production. Reconstruct the historical moment properly.
  3. 03Beat a rule baseline before reaching for complexity. In tabular risk work, boosted trees still win most of the time.
  4. 04A prediction in a dashboard is a suggestion. A prediction inside the workflow is a decision system.
  5. 05Collect governance evidence while you build, so approval becomes a review instead of an excavation.
Frequently asked
How much data do we need to start?

Less than most people assume, provided it is clean and correctly time-stamped. Two to three years of consistently labelled history usually beats a decade of data with changing definitions.

Can you work with our existing data platform?

Yes. We build on Snowflake, Databricks, Azure and AWS as we find them, and only propose a change when the current setup genuinely blocks the decision you want to improve.

How do you handle explainability for regulators?

We prefer techniques that are inherently interpretable for regulated decisions, and add feature attribution, validation evidence and fairness testing as standard deliverables rather than as an afterthought.

What happens if the model degrades?

Drift and outcome monitoring run from day one, with pre-agreed thresholds that trigger a retrain or an automatic rollback to the previous version or the rule baseline.

Where Redwind fits

We combine data engineering, machine learning and enterprise integration so the model actually changes a decision. For insurers, financial firms and trading desks that means less experimentation and more systems that improve outcomes.

See AI & Predictive Intelligence · Start a project