Fraud detection
Transaction scoring your analysts can tune, with case work that leaves an audit trail
We build scoring services that read a payment while it is still in flight, then hand the analyst a rules editor, a queue and a case file. Device signals, behavioural signals and account history feed one decision, and every decision is written down for later review.
Where it fits
The problem
Most teams inherit a rules file only one engineer dares touch, so a new fraud pattern waits weeks for a release. Alerts arrive without the account history behind them, analysts clear queues full of alerts that were never fraud, and paying customers get declined at checkout.
What we build
We build the scoring service, the feature store behind it and the console where risk staff work. Rules and thresholds move through a versioned change flow with a test harness, so a fraud analyst can ship a rule change in an afternoon without waiting on an engineering sprint.
How we engage
Senior engineers, four to eight people, working in your repositories and your cloud account. Models, rules and case data stay inside your infrastructure. We write the runbooks, the load tests and the handover notes, then your team runs the system and we stay on call for review work.
What we build
The pieces we usually build on a fraud engagement.
Inline transaction scoring
A scoring call sits in the authorisation path with a hard latency budget, features read from a store that holds account history in memory. Before this, most checks ran on an overnight batch, so the money had already left by the time the alert reached a human.
Device and behaviour signals
We instrument the client to collect device fingerprint, session and input timing, then join that with velocity counters per card, per device and per IP range. Teams scoring on payment fields alone cannot tell a returning customer from a card tester who copied the same details.
Rules an analyst edits
Rules live in versioned config with a simulator that replays last month of traffic before anything goes live. A fraud analyst writes the condition, sees how many alerts and declines it would have produced, and promotes it through review. The change ships without a deploy window.
Case management for analysts
Each alert opens a case carrying the transaction, the customer timeline, linked accounts and the reason the score fired. Analysts record the outcome in the same screen, so a decision made in March can be reconstructed in November without digging through chat logs and spreadsheet exports.
False decline control
Every rule and model runs in shadow mode first, with champion and challenger scoring the same traffic and a report on approvals lost per thousand attempts. Blunt thresholds turn away paying customers quietly, and that cost rarely shows up in the fraud numbers a board reviews.
Labels and retraining
Chargebacks, confirmed fraud and analyst outcomes flow back as labels into a training set holding feature values as they stood at decision time. Without that snapshot, retraining leaks information the model never had in production, and the offline numbers flatter a model that then underperforms.
Scoring, rules and case work in one console
A worked example that follows one flagged payment through scoring, analyst review and a recorded outcome.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Engineers who have run payments
Our people have worked inside card authorisation paths, PSD2 SCA exemption logic and chargeback flows. That matters when the argument is about a fifty millisecond budget or which exemption to claim on a low value transaction, because the tradeoff moves both fraud losses and approval rates.
Risk staff stay in control
We treat the analyst console as a first class product with its own usability reviews. Risk teams who cannot change a threshold without filing a ticket end up running the programme through spreadsheets, and the official system slowly stops matching how decisions actually get made.
Evidence an examiner can read
Every score, rule version, override and case note lands in an append only audit trail with the model version attached. When a regulator or an acquirer asks why a customer was declined in a given week, the answer comes from the record instead of an engineer's memory.
Questions
How do we cut fraud losses without declining more good customers?
Every candidate rule or model runs in shadow mode against live traffic first, and the report shows the fraud it would have caught alongside the approvals it would have cost. Where a score is ambiguous, the design sends the customer to a step up challenge under PSD2 SCA instead of a hard decline. You pick the tradeoff per segment.
Do you build rules or machine learning models?
Both, because they answer different questions. Rules carry the patterns your team already understands and stay readable during an audit. A gradient boosted model catches combinations nobody wrote down, and it returns reason codes so an analyst can see which features drove the score. The two sit in one decision service over a shared feature store.
Where does the data sit, and who owns the models after launch?
Everything runs in your cloud account. Card data stays tokenised, the feature store holds only what a decision needs, and access is logged per operator. Model training code, feature definitions and rule config live in your repositories. After handover your team retrains and promotes models, and we stay available for review work when you want it.
How soon does anything reach production?
The first milestone is shadow scoring on live traffic. It lands early because it touches nothing in the authorisation path, and it gives you a measured baseline before any customer is affected. Rules and thresholds go live in stages after that, one segment at a time, each with a kill switch and a rollback path.
Part of Fraud & Identity
Let genuine users through and hold fraud risk down, without turning onboarding into a wall.
Onboarding that converts,
controls that hold.
Where does risk cost you today: false declines, slow KYC, missed fraud? Tell us and we'll tune the system around it.