X2 for AI: One Real-Time Data Plane for Every Decision

Picture an ordinary trip. At 09:12, I tap my card at a café in Lisbon. I landed an hour ago.

By the evening, my bank makes a series of real-time decisions about me. A fraud check approves the payment. My app offers travel insurance and a higher credit limit. An agent stops someone who is testing my card online. A support agent reissues the card when I ask for it in a chat. A month later, a training run learns from the chargeback that closes the story.

Different models make these decisions: a rules engine, a gradient-boosted tree, a sequence model, a recommender, a scorecard and two agents. Each one needs the same thing: what the bank knows about me at that moment, delivered within its time limit. And each one must later answer a harder question. What did it know when it acted?

In most banks, every one of these decisions reads its own copy of that knowledge, built by its own pipeline. X2 is one real-time data plane for all of them. It replaces Kafka, Flink and Redis on the data path, and it serves live decisions, training and audit from one ordered history.

Two families of models share the request path

Most real-time decisions in banks and fintechs today come from rules and classic models on features. A rules engine applies thresholds such as velocity rules: more than three transfers to new payees in ten minutes. Credit teams use application and behavioral scorecards, which turn binned features into points that a regulator can read. Fraud teams compute a risk score with gradient-boosted trees, such as XGBoost or LightGBM, or with neural networks. All of them read features: counts, sums and averages that engineers design from past events.

A second family reads the raw events themselves. A sequence model reads the ordered history of one entity, such as a card, a customer or a device, and learns the patterns on its own, much as a language model learns from raw text. It trains by predicting the next event or a hidden one, and nobody designs its features. The shift is already public. Meta replaced feature-based recommenders with sequence models and gained 12.4% in online tests.¹ Stripe trained a payments foundation model on its transactions, and card-testing detection at large merchants rose from 59% to 97%.² J.P. Morgan AI Research trained TradeFM on billions of trade events.³

The two families will run side by side for years. A bank does not switch off a working fraud model in a day. A new model first runs as a challenger on the same decisions as the champion, and traffic moves only when it wins. During those years, the data plane has to feed both families from the same history, at decision time and at training time.

09:12: three models score one payment

The café payment arrives, and X2 appends it to a stream. A stream is a dense append-only sequence, and each message receives a position. After X2 makes that position durable and final, it permanently identifies the same payment.

X2 acknowledges a publish in under 10 µs and carries up to 5M messages a second per node. So the payment is already part of history when the models read it, and they score the event that is happening now, not a picture from five minutes ago.

Three models read that moment:

• The rules engine sees a foreign merchant in a country I have never paid in. Its “new country” rule would decline. A false decline costs the bank a customer’s trust and a lost payment.
• The gradient-boosted tree reads my current features: payments in the last hour, average amount over 30 days, distance from home, days since my last travel purchase. A stateful program computes them next to the stream. In X2 terms, it is a userproc: it reads each event as it arrives, updates the values under the card’s key, and saves a checkpoint with the input positions it covers. X2 keeps the current value of each key ready to read and records every update on a stream. The tree returns a medium risk score.
• The sequence model reads the latest events of my card through an index by entity. X2 finds them directly, without scanning the events of other customers. The model sees a flight purchase two weeks ago, a payment at the airport this morning, and now the café. That is a trip, not an attack.

The payment is approved. The approval becomes another event, and its record holds the entity, the positions each model read, the feature and sequence definition versions, the model versions, the scores and the action. A later reader can rebuild exactly what each model saw.

09:20: the app already knows about the trip

I open my banking app. A recommender, a sequence model trained on the event histories of millions of customers, ranks what to show me. It reads the same history of my card, and that history already includes the café payment from eight minutes ago. So the app offers travel insurance and a card with no foreign-exchange fees. A profile refreshed overnight would still believe I am at home.

On the same screen, a behavioral scorecard reads my current features and pre-approves a higher credit limit. It is a different model from a different team, but it reads the same source. Personalization does not need a pipeline of its own.

11:00: an agent investigates

Someone has bought my card details. Within two minutes, three $1 card-not-present payments hit three online merchants. This is card testing: the fraudster checks that the card works before a large purchase. The first payment is approved before the pattern exists. Then the velocity rule fires, the sequence model recognizes the pattern, and the next two are declined.

My bank does not block the card outright, because I am using it in Lisbon. Its policy hands the case to an agent. The agent reads my history and current state, compares the merchants with my past behavior, blocks card-not-present payments, and sends me a notification.

Each step of the agent is a record in its session journal on X2: what it read and at which positions, which model it called, which tool it used, and the result. This journal makes the agent:

• Durable. If the agent’s process dies after the block, a replacement reads the journal and continues from the first step without a result. Recorded steps are not repeated. When the replacement opens the session for writing, X2 fences out the old writer. Writes by position land exactly once, with no deduplication table.
• Observable. The journal is a live stream. A dashboard or a supervising agent can follow every step as it happens.
• Auditable. The bank can show what the agent knew and what it did, in the order it did it.

11:05: I ask for help

I get the notification and write in the app’s chat: “That wasn’t me. Please send a new card to my hotel and dispute the charge.” A support agent takes the conversation. It reads my session, the investigation journal and my current state. It reissues the card and opens a dispute for the $1 payment that went through.

Delivery to a new address needs approval. The agent writes an approval request, and a policy service writes the approval before the card ships. Every message, tool call and approval is a record in the same history as the fraud decisions. The support agent sees what the fraud model and the investigating agent saw. If its call to the card service is retried after a timeout, I still get one card, not two.

Thirty days later: the chargeback

The dispute resolves, and the chargeback for the $1 payment arrives. X2 appends it as a new event with its own position and a reference to the payment. It does not rewrite the payment. Corrections, reversals and labels all become new facts with their own permanent addresses.

One timestamp is not enough to place the chargeback. Event time records when the producer says an event happened: the payment carries 11:00, and the chargeback refers to it a month later. X2 also records the order in which events became part of durable history. Event time answers when something happened. Log order answers what the system knew.

An X2 cut maps each source stream to its exclusive next-read position. Messages below that boundary were available to a computation, and messages at or above it were not. The cut recorded with the 11:00 decision excludes the chargeback. A current cut includes it and can follow its reference back to the payment.

Training starts from the recorded decisions. For each one, it rebuilds the input at the decision’s cut and then attaches the later outcome as the label:

• The rules are backtested on the feature values they saw.
• The gradient-boosted tree and the scorecard retrain on point-in-time features.
• The sequence models read each history up to the decision’s cut.
• The agents’ journals become evaluation cases: what the agent saw, what it did, and how the case ended.

The chargeback supplies the label but never enters the input of the decision it judges. This is what keeps a model from looking excellent in tests and failing in production.

Serving and training read the same coordinates in different ways. Serving reads one entity under a latency limit: current values, the latest events, or both. Training reads many entities at many past cuts, and its limit is the number of contexts it rebuilds each second. Each path uses the physical read that fits its workload, but both apply the same definitions of entity membership, event order, corrections and the facts available at the cut. That removes one source of training–serving skew.

The latest values and events stay on the hot path, in memory, where a request reads them within its limit. Deep history is colder and much larger. Older retained ranges move to object storage, and their addresses stay the same, so a read means the same thing in every storage tier. Live and historical reads also use separate cache shares. A deep training replay does not evict the messages that serve live traffic, and a slow training reader does not set the pace for the fraud model.

What the same day costs on a typical stack

In most banks, a day like mine runs on several pipelines. Kafka moves the events. Flink computes features, and Redis serves them. A data lake keeps the history, and batch jobs rebuild training sets from it. Agents keep their traces in another store again. Each copy defines on its own which events belong to me, in what order, how corrections apply, and where the context ends. The copies drift, and teams find the gap after a model has already learned from it.

Feature platforms sit one level higher than the other columns. They define features and serve them, and they run on top of stores like Kafka, Redis and a lake. X2 can be the data plane underneath them.

Where X2 stops

X2 supplies ordered events, current values by key, cuts, checkpoints and journals. It does not own the models or the meaning of their inputs. The application defines which events belong to an entity, the feature formulas, the correction policy, the sequence length and the tools an agent may use.

The ML platform manages model artifacts, training jobs, serving runtimes, accelerators and the model lifecycle. Agent frameworks run the agent loop and the sandboxes. These systems use X2 data, but they deploy and scale separately from the data plane.

Back to Lisbon

In one day, my bank approved a payment it would once have declined, showed an offer that matched a trip it learned about eight minutes earlier, stopped a card-testing attack, reissued a card through a chat, and trained its models on the outcome. Seven models and agents took part. All of them read one history.

Each of them can also answer the question from the start. At every decision, the system knew exactly the facts below the recorded cut, and nothing that arrived later.

X2 gives every real-time decision in a company one ordered source of data: current state, the latest events, point-in-time training data, agent journals and audit.

Learn why Everything is a Stream, explore append-only storage, or contact us.

Footnotes

1. Jiaqi Zhai et al., Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations, ICML 2024. ↩

2. Emily Sands, Head of Data and AI at Stripe, on The Cognitive Revolution: Stripe’s Payments Foundation Model, September 2025. ↩

3. Maxime Kawawa-Beaudan et al., TradeFM: A Generative Foundation Model for Trade-flow and Market Microstructure, 2026. ↩