For most of the last decade, if you needed a machine learning model for fraud detection, AML, or credit that held up in production, you trained a gradient-boosted tree. XGBoost didn't win because research had nothing better, it won because nothing else matched its cost, its speed, and how easy it was to explain. Deep learning meant expensive GPU training for every customer, slower inference, and a model that risk teams would have to defend what was broadly believed to be a black box. 

Oscilar has worked that way too. We build a dedicated model for each customer and each risk type, have a data scientist tune it, and retrain it as new labels come in. It works. It's also slow to build, goes stale between retrains, and every new customer adds another model to maintain. None of those models learn anything from each other.

So our data science team asked a different question:

Could one model serve every customer and every risk type, stay current with every confirmed outcome, and still be as explainable as XGBoost?

That's the tabular foundation model we've built. This post covers how we thought about it, including what a tabular foundation model is, the three ways the industry is applying foundation models to risk, and why we chose this one.

What is a tabular foundation model?

A tabular foundation model is a model pretrained on large amounts of structured, row-and-column data, so it can make predictions on a new table without having seen that data before or having been trained on it. Instead of retraining on each customer's data, it reads labeled examples and the incoming transaction as context at decision time and returns a score directly.

"Foundation model" has become shorthand for chatbots, but large language models (LLMs) are only one family. The idea underneath is broader, and so is the architecture. Most foundation models, LLMs included, are built on transformers, and transformers come in different flavors. Ours is a transformer built for tables. Instead of reading words in a sentence, it reads rows and columns and uses attention to weigh which past examples and features matter most for the transaction in front of it. You pretrain a model once on a large, varied body of data so it learns general patterns, and then it can handle new tasks without being trained from scratch.

When you ask an LLM a question, it doesn't retrain on your question. It reads your prompt and answers. A tabular foundation model does the same thing with rows and columns. The "prompt" is a customer's labeled history: transactions, applications, accounts, and the outcomes confirmed for them. The answer is a risk score.

The input contains no free text, so the model has nothing to hallucinate on. It reads the same structured data our models already use. It's also a different model from the LLMs behind our AI Copilot and agents. We host the risk model ourselves, and no third-party API sits in the decision path.

Three ways to apply foundation models to fraud and risk decisioning

The industry has taken roughly three approaches.

1. Embeddings fed into another model. This is the path that TabBert, FATA-Trans, and TransTab architectures took. Each transaction becomes a high-dimensional vector, and that vector goes into a classifier, such as XGBoost, next to the existing features. This can add lift, but it also adds a second model. The decision now depends on hundreds of dimensions that nobody can explain, and generating those vectors in real time is expensive. 

2. Relational foundation models.  KumoRFM is best known for this approach. The advantage to these is their ability to read many tables at once to remove feature engineering. There are substantial downsides, though. These models are subject to heavy compute costs, daily retraining, and a distilled model to meet latency. They also output embeddings rather than scores, so a downstream model still makes the decision, and a schema change affects every stage of the pipeline. Any changes take at least a day to take effect, which means the model is not as agile as alternatives, especially when applied to a fraud landscape that can change in 15 minutes. Lastly, relational foundation models are not explainable, a key trait when used in fraud and credit use cases.

3. Tabular foundation models. These work on one table and output the score directly. Training happens as part of inference. Examples that you may have seen in the wild are TabPFN and TabICL. 

We chose the third approach, and we want to be clear about what that choice costs. A tabular model doesn't remove feature engineering, so we automated that work. It doesn't meet the real-time latency that fraud detection requires out of the box either, and getting it under 100 milliseconds took significant engineering effort. We were willing to do that work because of what the approach gives us in return.

Benefits of the tabular foundation model approach

There are five key benefits of using a tabular foundation model, rather than relying on one of the other approaches: 

• Training happens at inference. Each confirmed label informs the next decision, with no nightly retrain and no waiting for the next model cycle. This is the property that changes how a risk team operates.

• It scores directly. One model makes the decision. No second-stage classifier sits behind it.

• Explanations work the way they do today. Shapely additive explanations (SHAP) feature attributions and reason codes work as they do with XGBoost, so your auditors and regulators review the same artifacts they already know. If a compliance process requires the traditional format, we can distill the model into a standard XGBoost model.

• Features change in seconds. Adding, removing, or changing a feature doesn't trigger a rebuild. Once the data reaching the model changes, the model is ready.

• One model covers fraud, AML, credit, and device and behavioral risk. We improve and maintain one asset instead of a growing fleet of bespoke models. Build time drops from weeks toward days.

How it performs

Results vary by dataset and use case. In our benchmarks, the tabular foundation model has improved recall by 35% to 65% at the same impact rate on some datasets: it catches more fraud without flagging more good customers. On others, it performs at the same level as XGBoost. Even then, you get that accuracy from one shared model that updates its context in seconds instead of waiting for a retrain.

It pulls ahead most clearly when labels are scarce. A per-customer XGBoost model needs a lot of labeled history before it’s reliable. A tabular foundation model starts from what it learned in pretraining, so a smaller set of confirmed cases goes further.

What the model is trained on

The model is pre-trained offline on industry fraud patterns and synthetic attack scenarios, including scenarios built to prepare it for patterns nobody has labeled yet. At decision time, a customer's confirmed cases go in as context.

Each customer's data and labels are used only in that customer's predictions. They never influence another customer's results.

The model still needs labels. For a handful of use cases (ACH, AML, card deposit, and device and behavioral signals), we have fine-tuned versions that work out of the box on day one. Everywhere else, the value grows with how quickly confirmed outcomes flow back. Teams with only a small set of labels still do well, because that’s where the model’s lead over XGBoost is largest.

Tabular foundation models vs. consortium models

Consortium models pool labeled data from many participants and train one model for one use case. They work out of the box, which is their main appeal. They're also slow to update, they tend to favor the largest participants, every feature change waits for the next training cycle, and they only know the patterns their members have already seen.

One way to see the relationship: a consortium model is a foundation model whose context you can't change. The labeled data a consortium trains on is the kind of data a tabular foundation model reads as context. Change the context and you have a consortium model for a different use case, updated by the next label instead of the next annual refresh.

The model isn't the moat

We don't try to out-scale the largest AI labs on raw model training, and we don't need to. Research on tabular foundation models is open. What decides whether one of these models works in a live risk stack is everything around it, like what data it sees, how fast it answers, how it explains itself, and how it's monitored and rolled out.

That's where our data science team now spends its time. With per-customer training gone, the main lever on performance is what we call continuous tabular context engineering, which means deciding what the model sees for each decision. It's a young discipline, and it's where we plan to keep pulling ahead.

What this changes for risk teams

• Faster models. Building a model takes weeks instead of months today, and we're working toward one week to ship a live endpoint that's ready to score transactions in production.

• Decisions that stay current. The model learns from today's confirmed fraud today, not after the next retrain. We update its context in seconds (5.8 seconds, to be exact) without disrupting live scoring.

• The same audit trail. You keep the same reason codes and feature attributions, and the same answer when a regulator asks why.

• A sounder base for AI agents. Agents investigate, write case narratives, and recommend rules, while the model and your rules make the decisions. Because the model produces reason codes, both your analysts and your agents can explain what happened.

Where we are

The model is running with our first pilot customer, and we'll share results once they're ready to publish. Also, keep an eye out for an upcoming webinar where Saurabh Bajaj and Eddy Fathi will walk through the approach live, including an interactive look at how the model reasons through a decision.

Frequently asked questions

What is a tabular foundation model?

A tabular foundation model is pretrained on large amounts of structured, row-and-column data and makes predictions on a new table without being trained from scratch. It reads a customer's labeled history as context at decision time and returns a risk score directly.

How is a tabular foundation model different from XGBoost?

An XGBoost model is typically trained for one customer and one risk type, and it has to be retrained as new labels arrive. A tabular foundation model serves many customers and risk types, and each confirmed label informs the next decision without a retrain. Explanations stay the same: SHAP feature attributions and reason codes.

Can regulators and auditors review its decisions?

Yes. It produces the same SHAP feature attributions and reason codes as XGBoost. If a compliance process requires the traditional format, the model can be distilled into a standard XGBoost model.

Is a tabular foundation model a large language model?

No. It reads structured data only, with no free text, so it has nothing to hallucinate on. Oscilar hosts the model itself, and no third-party API sits in the decision path.

Does one customer's data affect another customer's scores?

No. Each customer's data and labels are used only in that customer's predictions.