FinTech

Real-time fraud detection inside the transaction flow

  1. Problem

    A payments platform needed to score every transaction for fraud in real time – but routing traffic through a separate Python scoring service added latency, infrastructure, and a second stack to operate.

  2. Solution

    Deep learning models built with Deep Netts run directly inside the Java transaction pipeline. Scoring happens in-process, with no network hop and no additional runtime to deploy or monitor.

  3. Outcome

    Fraud decisions now land in milliseconds, inside the same JVM that processes the payment – and the fraud team iterates on models with the tools the platform team already runs.

Read more
payment-service · fraud scoring (in-process)
TransactionRisk score
€86.40TX-48211 · Berlin, DE
APPROVE
$1,240.00TX-48212 · Austin, US
APPROVE
$4,980.00TX-48213 · Lagos, NG
BLOCK
€19.90TX-48214 · Milan, IT
APPROVE
¥8,200TX-48215 · Tokyo, JP
APPROVE
€312.00TX-48216 · Paris, FR
APPROVE
$2,750.00TX-48217 · Kyiv, UA
BLOCK
€54.10TX-48218 · Madrid, ES
APPROVE
€86.40TX-48211 · Berlin, DE
APPROVE
$1,240.00TX-48212 · Austin, US
APPROVE
$4,980.00TX-48213 · Lagos, NG
BLOCK
€19.90TX-48214 · Milan, IT
APPROVE
¥8,200TX-48215 · Tokyo, JP
APPROVE
€312.00TX-48216 · Paris, FR
APPROVE
$2,750.00TX-48217 · Kyiv, UA
BLOCK
€54.10TX-48218 · Madrid, ES
APPROVE
Model: FeedForwardNetwork · same JVMno network hop
30%
reduction in fraud losses
ms
decision latency, in-process
0
extra Python infrastructure
Enterprise IT

Forecasting cloud resources before the bill arrives

  1. Problem

    An enterprise platform team was over-provisioning cloud capacity to stay safe, because usage forecasts were coarse and reactive – and the cost of that safety margin kept growing.

  2. Solution

    Deep Netts models forecast resource demand from historical usage, running natively inside the team's JVM-based tooling. Predictions feed autoscaling and capacity planning directly, with no separate ML pipeline.

  3. Outcome

    Provisioning now follows predicted demand instead of worst-case guesses, cutting spend while improving stability during load spikes.

Read more
capacity-planner · demand forecast
Compute capacity · 12 months
Capacity follows the forecast
−21%
vs fixed capacity
Nov
forecast peak
Demand – actualDemand – forecastProvisioned capacityFixed capacity (before)Freed capacity

Illustrative data. Hover or use the arrow keys to read each month.

Monthly compute demand and capacity, vCPU
MonthDemandProvisionedFixed before
Jan (actual)520572920
Feb (actual)560616920
Mar (actual)540594920
Apr (actual)600660920
May (actual)640704920
Jun (actual)620682920
Jul (actual)690759920
Aug (actual)710781920
Sep (forecast)730803920
Oct (forecast)760836920
Nov (forecast)800880920
Dec (forecast)770847920
15–25%
cloud cost reduction
JVM-native
integration with existing tooling
Scientific Computing – Jefferson Lab

Predicting particle trajectories with neural networks

  1. Problem

    Every event in the CLAS12 detector leaves many segments in the drift chambers – from real particles and from background. The conventional algorithm has to try their combinations, tracking takes 80–90% of event processing time, and at high beam intensity good tracks get lost among the candidates.

  2. Solution

    Two neural networks built with the Deep Netts community edition, in Java, inside the lab's Java reconstruction software: a multi-layer perceptron that labels each track candidate a positive, negative or false track, and an auto-encoder that fills in a segment a chamber missed.

  3. Outcome

    On real data, 15.6% more reconstructed tracks – over twice as many with a missing segment – and 35% faster tracking. Physics analyses gain 15–35% more events (G. Gavalian et al., arXiv:2202.06869).

Read more
CLAS12 · drift-chamber track reconstruction
R1R2R3
138
Hits recorded
–
Kept (on tracks)
–
Rejected as noise
–
Tracks found
Noise hit Track 1 Track 2 Track 3

Illustrative hits. CLAS12: 6 sectors × 3 drift-chamber regions. Hover a track to isolate it.

+15.6%
reconstructed tracks on real CLAS12 data
35%
faster track reconstruction
+15–35%
events in two- and three-particle reactions
Research – University of Minnesota

Deep learning for drug discovery, in Java

  1. Problem

    High-throughput screening produces tens of thousands of data points in one session. Finding the compounds that cause the desired change in a protein calls for deep learning – but tools that depend on native libraries are hard to run on specific hardware, and QSAR methods need structural data such as SMILES that many library compounds lack.

  2. Solution

    Oscar Bastidas, Ph.D., analyses the screening data with Deep Netts feed-forward networks in Java, trained on the physical and chemical properties already in the compound library, with hyperparameters tuned to the data. His study of spike-protein dynamics with Zoran Ševarac, analysed in Java, was published in Scientific Reports (2024).

  3. Outcome

    Hit identification runs entirely on the JVM – no native dependencies, no QSAR input, and in the language the researcher already works in.

Read more
materials-model · property prediction
Property prediction · test set
Predicted vs. reference (48 structures)
0.983
R²
0.025
mean abs. error
000.250.250.50.50.750.7511Reference (simulation)Predicted (Deep Netts)perfect prediction

42 of 48 predictions within ±0.05 of the reference (shaded band).

Illustrative data, normalised property values. Hover a point for details.

Pure JVM
no native libraries to install
No QSAR input
models learn from properties already in the compound library

Have a workload like these?

Tell us about your system – we'll show you how Deep Netts fits inside it.