PersonaLedger combines an LLM with Python rules to produce synthetic card histories conditioned on textual personas. It starts from the twenty fields in Nemotron-Personas and uses Llama-3.3-70B-Instruct, with seven in-context examples, to infer income level, credit limit, payment habit, subscriptions, bills, car ownership, and spending pattern. It then generates a narrative plan and transactions day by day. The program fixes signs and slightly perturbs amounts, inserts recurring charges, payments, and interest, supplies U.S. calendar context, tracks fuel and grocery cadence, and updates balances. This is persona-conditioned simulation; the plans are not observations of human reasoning and do not validate psychological personality.
The paper reports about 30 million events from 23,361 synthetic users: 22,018 normal and 1,343 illiquid. Table 1 breaks these into 24.7 million daily transactions, 1.9 million payments, and 4.30 million recurring charges, with 74,623 merchants, a mean history of 724.05 days, and 1,242.10 events per user. The histories yield user-level illiquidity classification and event-level identity-theft segmentation for one- and three-month windows. The paper states 150,000 training and 36,000 test sequences per task. For illiquidity, the best AUC is 0.828 at three months and 0.804 at one month; the best F1 is 0.216 and 0.208. For identity theft, Transformer has the best F1, 0.262 and 0.476, and the best one-month AUC, 0.870; TimesNet reaches 0.790 at three months.
The evidence does not validate realistic or privacy-preserving in their strong senses. Realism is argued through examples and internal statistics by age, education, car ownership, spending habit, calendar, credit utilization, and merchant coverage. There is no held-out real-population comparison, calibrated distributional distance, transfer to real data, or blinded expert study. Avoiding private ledgers lowers direct customer-record disclosure risk, but it is not differential privacy, an attack-based privacy test, or a population-fidelity guarantee. The rules encode narrow assumptions: U.S. holidays, dollars, five fixed salary buckets every fourteen days, a 5,000 initial balance, 5% interest, and threats of prosecution.
The public code also contradicts a central part of the described method. The paper says that postconditions are checked before acceptance, invalid plans are rejected, and targeted corrections are returned to the LLM. In the release, update_history retries only for invalid JSON, deposits, or malformed timestamps; it then runs the rules and appends every transaction. There is no general verifier, rollback, or violation-specific re-prompt. Available credit may fall below zero and a warning is inserted for the following day; generation stops after the third warning. The public random-event probability is 0.3, not the manuscript's 0.1. There are no seeds for dates, events, amount noise, or LLM sampling, so the promised exact regeneration is not possible.
The reported evaluation is not an independent final test. Only train and test files are released. For illiquidity, VALI and TEST load the same test_df, so early stopping selects a checkpoint with test data. For identity theft, test loss is calculated every epoch and the threshold with the best F1 is selected against the test labels. Category encoding is also learned after concatenating train and test, and test windows are randomly sampled without a seed. The fraud generator replaces a legitimate day with transactions from an illiquid synthetic user rather than adding a day, creating a potential pool-specific shortcut. Results are exploratory and likely optimistic. The release is large and useful, code, 100,000 source and augmented personas, examples, raw data, and eight task parquets, but lacks a separate validation split, full logs, state snapshots, per-event checks, results, tests, and CI. It remains an arXiv v2 preprint submitted to ICLR 2026; the public record is not marked accepted.