Skip to content
Iotron AI

Project scenario · Financial Services

How we would add machine-learning fraud scoring alongside an existing rules engine, inside a millisecond latency budget and without a black box.

Typical starting point: digital wallet and card issuer. This scenario shows how we approach this class of problem. It does not describe a named client engagement, so no results are claimed.

Typical client
Digital wallet and card issuer
Industry
Financial Services
Built with
Iotron Guard · Streaming ingestion (Kafka) · Online feature store · Gradient-boosted trees
Measured against
4 agreed measures

01The challenge

Static fraud rules that attackers learn quickly, rising false positives and an analyst queue that never empties.

Where we usually start

A common setup: a rules engine tuned over years, chargeback and confirmed-fraud labels that arrive weeks after the transaction, an authorisation path with a strict latency budget, and a model-risk function that needs every decision explained and every model documented.

02What it is measured against

How we would know it worked.

Agreed with the business before any model is built, and reported against throughout — so success is defined by the operation, not by the model.

Measures this project is reported against
#Measure
01Fraud caught at authorisation versus after the fact
02False-positive rate and customer friction from step-up checks
03p99 scoring latency inside the authorisation budget
04Analyst time per case and queue age

03The Iotron solution

What we build.

Iotron Guard running beside the rules engine: gradient-boosted models on transaction, device and behavioural features served from a low-latency feature store, each score returned with reason codes, and a case-management view that puts the evidence in front of the analyst.

How the project runs

  1. Weeks 1–3

    Map the authorisation flow and latency budget; build a labelled history from chargebacks, confirmed fraud and analyst decisions.

  2. Weeks 4–7

    Feature engineering (velocity, device, merchant and peer-group features) and offline evaluation against the current rules on the same transactions.

  3. Weeks 8–10

    Shadow scoring in production: the model scores live traffic but blocks nothing, and analysts compare its reasons with their own.

  4. Weeks 11–12

    Model documentation for model-risk review, then a staged switch-on: first to prioritise the analyst queue, then to step-up authentication.

  5. Then

    Monthly drift reports and retraining as new fraud patterns are confirmed.

Technology

  • Iotron Guard
  • Streaming ingestion (Kafka)
  • Online feature store
  • Gradient-boosted trees
  • SHAP reason codes
  • Case-management UI
  • Model monitoring

04Lessons from this kind of work

What we would tell the next team.

  • Shadow mode on live traffic is the fastest way to earn the risk team's confidence.
  • Labels arrive late; evaluation has to account for fraud that has not been reported yet.
  • Reason codes are a product feature, not documentation — analysts act faster when they can see why.
More on AI in financial services →

More scenarios

All scenarios →

Get in touch

Facing a similar challenge?

Tell us where your version of this problem starts. We will walk you through how we would approach it and what we would measure.