Learning From Event Histories

Extend the payment model with transaction attributes, account context, and a merchant-repeat target.

The transaction-history model reads an ordered sequence to predict a later dispute for each transaction. Now a payment service also wants to anticipate repeat payments. Add the evidence that question needs: how each payment was made and how long the account has been open. Then add a second outcome to the same observation.

This is a richer transaction model, built after the basic training and evaluation workflow. Keep the earlier model as a baseline so you can test what each addition contributes.

Keep Events And Account Context Together

Consider a direct debit to an internet provider. Keep that latest payment once, at the end of trxns, alongside the earlier transactions known at the decision time. Repeated amounts and booking days supply evidence of a recurring pattern:

account_age_days: 420
trxns:
  - booked_at: "2026-03-28T09:00:00"
    amount: 24.00
    merchant: Harbor Internet
    channel: direct_debit
    disputed: false
    repeats_next_30_days: true
  - booked_at: "2026-04-28T09:00:00"
    amount: 24.00
    merchant: Harbor Internet
    channel: direct_debit
    disputed: false
    repeats_next_30_days: true
  - booked_at: "2026-05-27T08:00:00"
    amount: 32.00
    merchant: Station Cafe
    channel: card
    disputed: true
    repeats_next_30_days: false
  - booked_at: "2026-05-28T09:00:00"
    amount: 24.00
    merchant: Harbor Internet
    channel: direct_debit
    disputed: false
    repeats_next_30_days: true

The transaction list is the event history, including the payment being scored. Each event keeps its amount, merchant, channel, and booking date together. account_age_days supplies profile context shared by the sequence. Use its value as known at the decision time.

Evidence	What it contributes
Amount, merchant, and channel within one event	Distinguishes a direct debit from a card purchase, even at the same merchant.
Ordered transactions and booking dates	Exposes repeated amounts, merchant visits, and calendar patterns.
Account profile	Supplies context shared by the transaction sequence, such as account tenure.

A calculated mean payment amount or dominant channel is another possible input. Compare those summaries with the event sequence to learn whether preserving individual transactions is useful.

Sort by booking time, oldest to newest. DateParts represents recurring calendar patterns in the booking day, weekday, and hour. It does not encode elapsed time between transactions. The sequence ends with the latest payment; records after that decision are excluded.

The snapshot cutoff is the final booking time, May 28, 2026 at 09:00. For every listed transaction, disputed records whether a new dispute against it was reported in the 30 days after that cutoff. repeats_next_30_days records whether another payment to that transaction’s merchant occurred in the same future window. All transaction predictions use the complete sequence known at this common cutoff.

Learn Two Outcomes From The Same History

Place both targets inside trxns, beside the transaction they describe. mask=True hides each transaction’s answers and supplies their supervision. The two predictions share encoded context, with their own decoders and supervision. This lets the application test a joint model against separate models for the two decisions:

import relflow as rf

model = rf.Model.xs(
    account_age_days=rf.Number,
    trxns=rf.Branch(
        length=32,
        overflow="tail",
        booked_at=rf.DateParts(
            dateparts=["day_of_month", "day_of_week", "hour_of_day"],
        ),
        amount=rf.Number,
        merchant=rf.Category,
        channel=rf.Enum(values=("card", "direct_debit", "bank_transfer")),
        disputed=rf.Boolean(mask=True),
        repeats_next_30_days=rf.Boolean(mask=True),
    ),
)
data = rf.ArrowDataModule(
    model=model,
    train="payments/context/train.parquet",
    validate="payments/context/validation.parquet",
)
model.fit(data, batch_size=128, max_epochs=30)

These application-supplied Parquet files keep profile context at the root and all transaction fields inside trxns. Every listed transaction supplies both Boolean labels. Their schema addresses are /trxns/disputed and /trxns/repeats_next_30_days.

Prediction files omit both outcome fields from every transaction while keeping the transaction records. Output format 2 returns results inside predictions.trxns, with inferred: true for both targets at every retained transaction position. See Prediction Output.

Shared context lets you test whether learning the account’s behavior helps both tasks. Inspect each outcome separately: improvement on repeat payments can accompany a regression in dispute detection. For repeat payments, measure precision and recall for another payment to each transaction’s merchant within the common 30-day window. For disputes, measure recall at the team’s review capacity. A dispute label records a later customer outcome and needs its own operational definition.

Choose A Learning Workflow

With settled outcome labels, train the supervised model directly. When you have many more histories than labels, first hide sampled transaction amounts or merchants and learn to reconstruct them from the remaining context. That gives unlabeled activity a learning role before adapting the model to dispute or repeat-payment prediction.

Reconstructing a hidden transaction value asks what fits the observed sequence. Predicting a later outcome asks what happens after the decision. Define and evaluate those objectives separately. The pretraining guide shows how to change objectives while reusing compatible learned state.

You can also export a contextual representation: learned vectors combining the account fields and its history. Keep the encoder fixed while training separate task predictors on those vectors. This tests whether the learned context is useful for another outcome before updating the encoder for it. Embeddings explains that workflow.

The next structural extension is Transaction And Account Outcomes: nest line items inside transactions, add a separate withdrawal history, and combine transaction dispute targets with an account-level loss target.

Make The Comparison About The Decision

For repeat payments, compare with rules based on merchant, amount, and the booking calendar. For disputes, compare with the existing tabular model and its history features. Keep the eligible payments, available evidence, and outcome windows identical.

Test each addition in sequence: history versus the payment alone, channel and profile versus history alone, then joint targets versus separate models. Later, compare reconstruction pretraining with the same supervised model trained from scratch. Evaluation explains these comparisons.

Forecast A Future Value

As an optional transfer to another event domain, a market-data application can supply daily bars and ask for the next trading day’s closing price. A bar is a multivariate event: opening, high, low, and closing prices plus volume belong to the same interval. The history-and-target pattern stays the same:

market_model = rf.Model.xs(
    daily_bars=rf.Branch(
        length=64,
        overflow="tail",
        booked_at=rf.DateParts(
            dateparts=["day_of_month", "day_of_week", "hour_of_day"],
        ),
        open=rf.Number,
        high=rf.Number,
        low=rf.Number,
        close=rf.Number,
        volume=rf.Number,
    ),
    next_close=rf.Number(mask=True),
)

Each bar keeps its price and volume measurements together. Prepare observations at the end of a trading day, including only completed bars known then. booked_at supplies calendar context for each completed bar, not elapsed-time gaps. The next_close label comes from the following trading day and becomes available after that day closes. Train from Parquet files through ArrowDataModule, as above, using files prepared for this market schema.

This defines one future-value prediction. If the application needs several future steps, define their target structure and evaluation horizon explicitly. Include a last-known-close baseline when evaluating this forecast.

Business Prediction Examples applies the approach to customer retention, reviewer engagement, and study reporting.