PersonaLedger: Generating Realistic Financial Transactions with Persona Conditioned LLMs and Rule Grounded Feedback

PersonaLedger combina un LLM con reglas Python para producir historiales sintéticos de tarjetas condicionados por personas textuales. Parte de los veinte campos de Nemotron-Personas y usa Llama-3.3-70B-Instruct, con siete ejemplos en contexto, para inferir nivel de ingresos, límite de crédito, hábito de pago, suscripciones, facturas, coche y patrón de gasto. Después genera día a día un plan narrativo y transacciones. El programa corrige el signo y una pequeña parte del importe, inserta cargos recurrentes, pagos e intereses, ofrece contexto de calendario estadounidense, vigila compras de combustible y alimentación y actualiza saldos. Es una simulación condicionada por persona; los planes no son observaciones de razonamiento humano ni validan personalidad psicológica.

El paper declara unos 30 millones de eventos de 23.361 usuarios sintéticos: 22.018 normales y 1.343 ilíquidos. Tabla 1 desglosa 24,7 millones de transacciones diarias, 1,9 millones de pagos y 4,30 millones de cargos recurrentes, con 74.623 comercios, una media de 724,05 días y 1.242,10 eventos por usuario. A partir de esos historiales crea clasificación de iliquidez a nivel de usuario y segmentación de robo de identidad a nivel de evento para ventanas de uno y tres meses. Declara 150.000 secuencias de entrenamiento y 36.000 de test por tarea. En iliquidez, el mejor AUC es 0,828 a tres meses y 0,804 a un mes; el mejor F1 es 0,216 y 0,208. En robo de identidad, el Transformer alcanza los mejores F1, 0,262 y 0,476, y el mejor AUC de un mes, 0,870; TimesNet logra 0,790 a tres meses.

La evidencia no valida las palabras realistic y privacy-preserving en su sentido fuerte. El realismo se argumenta con ejemplos y estadísticas internas por edad, educación, coche, hábito de gasto, calendario, utilización de crédito y cobertura de comercios. No hay comparación con una población real reservada, distancia distribucional calibrada, transferencia a datos reales ni evaluación ciega por expertos. No usar ledgers privados reduce el riesgo de exponer registros de clientes, pero no constituye privacidad diferencial, prueba contra ataques ni garantía de representatividad. Las reglas codifican supuestos estrechos: festivos de EE. UU., dólares, cinco salarios fijos cada catorce días, saldo inicial de 5.000, interés del 5% y lenguaje de amenaza de procesamiento penal.

El código público contradice además una pieza central del método descrito. El paper dice que comprueba postcondiciones antes de aceptar, rechaza planes inválidos y devuelve una corrección dirigida al LLM. En el release, update_history solo reintenta por JSON inválido, depósitos o timestamps mal formados; luego ejecuta las reglas y añade todas las transacciones. No hay verificador general, rollback ni re-prompt específico. El crédito puede quedar por debajo de cero y se inserta un aviso para el día siguiente; la simulación termina al tercer aviso. La probabilidad pública de eventos aleatorios es 0,3, no el 0,1 del manuscrito. Tampoco hay semillas para fechas, eventos, importes o muestreo del LLM, por lo que no es posible la regeneración exacta prometida.

La evaluación publicada no es un test final independiente. Solo se liberan train y test. Para iliquidez, VALI y TEST cargan el mismo test_df, de modo que early stopping selecciona el checkpoint con test. Para robo de identidad se calcula test loss en cada época y se elige sobre las propias etiquetas de test el umbral con mejor F1. Además, la codificación categórica se calcula tras concatenar train y test, y las ventanas de test se muestrean aleatoriamente sin semilla. El generador de fraude reemplaza un día legítimo por transacciones de un usuario sintético ilíquido, no añade un día, lo que puede introducir atajos propios de ese pool. Los resultados son exploratorios y probablemente optimistas. El release es grande y útil, código, 100.000 personas de entrada y aumentadas, ejemplos, datos raw y ocho parquets de tareas, pero carece de validación separada, logs completos, snapshots de estado, checks por evento, resultados, tests y CI. Sigue siendo un preprint arXiv v2 enviado a ICLR 2026; el registro público no aparece como aceptado.

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.