Skip to main content
MathFi.ai works on any labelled, tabular data. It earns its place on the rare, high-cost decision: the case that matters most and is hardest to catch. Seven public datasets have been benchmarked against five widely deployed methods, each on an identical 80/20 split, so differences reflect modelling capability rather than partitioning. Results are reported on the minority class, because that is where the value sits. Across the seven, MathFi.ai takes the highest minority-class F1 in six, and the highest or joint-highest recall in all seven.

​
The seven decisions

Each row is a specific, costly decision, with MathFi.ai’s minority-class result. Full tables, every competitor score, the datasets and the methodology are on the benchmarks page.

​
What the numbers show

Recall is the consistent signature. In every domain tested, MathFi.ai surfaces more of the rare, high-value cases than any competing method. On stroke screening it finds 66% of the people who go on to have one, against 26 to 34% for the gradient-boosting methods. On clinical mortality it reaches 84.21% recall, nearly sixteen points clear of the field. Accuracy is the number to distrust. On stroke, CatBoost posts the highest accuracy in that table at 90.02% while catching 26% of at-risk patients. It is an accurate model and a useless screening tool. MathFi.ai accepts 82.58% accuracy precisely because it is doing the job asked of it. Where it trails, it trails deliberately. On warranty fraud, MathFi.ai reaches 96.24% recall against 81.95% for the gradient-boosting methods, but those methods lead on F1 (82.26% against 75.74%) and precision (82.58% against 62.44%). That configuration is recall-dominant: it catches nearly all the fraud and flags more legitimate claims to do so. Whether that is the right operating point depends on what a missed fraud costs you relative to a false accusation. You choose the operating point. On cardiac disease the same data produces a precision-tuned model (F1 84.20%, precision 87.01%) and a recall-tuned one (recall 91.46%, over seven points clear of the best competitor). That is the candidates table in Model Crucible doing its job: the trade is yours to make, not the library’s.
The radar dataset is not natively tabular. Its 34 features are derived from raw high-frequency signal returns. That is the pattern for any non-tabular source: encode it as numeric features and it is in scope.

​
Worked end to end

German Credit, step by step

The consumer-default row above, developed in full: the files, both products, the settings, the candidate models and the numbers from a real run.
That walkthrough is a separate run from the benchmark, so its figures differ slightly. Refinement results vary run to run, which the page says plainly.

​
Does your problem look like these?

Three questions. Is the expensive answer rare? Fraud that clears, machines that fail, claims that should have been challenged. If your positive class is a small fraction of your rows, ordinary methods are already struggling, whatever their accuracy score says. Is it tabular and labelled? Rows and columns, with a known outcome per row. Data that does not start out tabular still counts if you can encode it that way: signals, images and text all work once they are expressed as features in a CSV. Does a wrong answer cost real money? Both kinds. A missed case and a false alarm are both expensive, usually by different amounts. That asymmetry is exactly what the candidates table lets you trade against. If all three are yes, this is the right tool. If your classes are balanced and your current model already performs, the gain will be smaller.

​
By industry

Transaction and application fraud, credit and default risk, anti-money-laundering alert triage, collections propensity.Benchmarked on credit approval and consumer default. Fraud and credit datasets are imbalanced by nature and change as the people committing fraud adapt. Refine first: application data accumulates columns nobody has pruned in years. Then run the Crucible and choose the candidate whose recall matches your appetite for false declines.Worked example: German Credit.
Claims fraud, underwriting risk, lapse and renewal prediction, subrogation identification.Benchmarked on warranty claim fraud, where the recall-dominant profile is what most fraud operations want behind a human review queue. Claims data is wide and much of it is recorded after the fact, so Feature Refinery is doing two jobs here: finding the signal, and surfacing columns that only exist because the outcome was already known.
Diagnostic and clinical-outcome prediction, patient risk stratification, screening.Three of the seven benchmarks are clinical: stroke screening, cardiac disease and mortality risk. Two things matter here beyond accuracy: recall on the rare condition, and being able to explain a decision. Every model is deterministic and every prediction records the version it ran against, so a result can be replayed exactly.
Signal integrity, anomaly screening, sensor trust.Benchmarked on radar returns, where MathFi.ai is the only method to reach perfect minority-class precision without paying for it in recall.
Equipment failure and predictive maintenance, quality and defect detection, process anomalies.Failures are rare by design. A line with two or three failures a month gives a model almost nothing to learn from, and a model that predicts “no failure” scores 99% while being useless. This is the case MathFi.ai is built for.
Customer churn, propensity and next best action, returns abuse, late-delivery and disruption risk.Customer and operational tables are the widest data most businesses hold, and the least pruned. Refinement usually removes a large share of the columns and the model gets better for it.

​
Which product do I need?

Feature Refinery first

Use it when you are not certain which columns matter, when the data is wide or untidy, or when nobody has looked at the feature set in a while. Which is most of the time.

Model Crucible alone

Use it when your feature set is settled, when your target is multi-class, or when you are benchmarking against a model you already run.
Running both is the normal path. Refinement removes the columns that hurt and measures the target the cleaned data can reach, and that target is what the Crucible needs to produce a model worth having.

​
What this is not

Honest boundaries, so you do not spend a week finding them yourself.
  • Not raw media. The input is a CSV. Images, signals and text are in scope once encoded as features, but the platform does not do that encoding for you.
  • Not unsupervised. You need labels.

​
Not yet

A limitation rather than a boundary, and worth knowing the difference.
  • Multi-class through Feature Refinery. Refinement takes binary targets today. Multi-class refinement is a capability we plan to add. In the meantime a multi-class dataset goes straight to Model Crucible, which handles it.