PersonaAgent: Retrieval-Augmented Transaction Anomaly Scoring with Refreshable Multi-Entity Persona Memory

Zhengyu Fang; Liang Wang; Yingtong Dou; Yuzhong Chen; Shubham Jain; Junpeng Wang; Xiran Fan; Menghai Pan

cs.LGNov 5, 2026

PersonaAgent: Retrieval-Augmented Transaction Anomaly Scoring with Refreshable Multi-Entity Persona Memory

Authors: Zhengyu Fang, Liang Wang, Yingtong Dou, Yuzhong Chen, Shubham Jain, Junpeng Wang, Xiran Fan, Menghai Pan,

Organizations: Case Western Reserve University, Cleveland, OH, USA · Visa Research, Foster City, CA, USA · Visa Research, Austin, TX, USA

Abstract

In large-scale payment networks, entities (card, merchant, etc.) and their interactions play a key role in transaction anomaly detection. However, transaction patterns between different entities usually change more frequently than the production model refresh schedule. Meanwhile, entity embedding tables suffer from high-cardinality and sparse interaction issues. To resolve the above challenges, we present PersonaAgent, an agentic transaction anomaly detection framework which represents the latest entity behavior signals as personas and saves them in a refreshable memory. Offline, a weekly scheduled batch job is used to extract the latest behavior signals and update them in the memory. At inference time, a lightweight adapter retrieves the corresponding entity behavior signals of each transaction from memory and uses them to augment the base anomaly classifier's scoring. Through comprehensive benchmarking with different anomaly detection models at Visa, PersonaAgent is able to score transactions efficiently (a 1,000-transaction CPU batch in 1-2 ms), lifting the PR-AUC by 0.65-6.58% and the production business metric by 8.93-14.24% relatively in deployment.

Figures & tables

Figure 1. Knowledge-latency motivation and shared persona context. Behavior may change before the next detector release. Offline-refreshed entity, group, and interaction records supply shared context to detector-specific adapters, which combine this context with each detector’s own score, while the four detectors remain frozen. Detectors 1–4 are Visa’s proprietary detection models: one production and three internal. A two-part schematic. The left panel contrasts entity behavior changing over weeks with a months-long detector release cycle. The right panel shows an offline-refreshed shared persona memory feeding four detector-specific adapters, each of which also receives a score from its corresponding frozen detector.

Figure 2. PersonaAgent lifecycle. (A) Three LLM proposal roles and a Protocol Critic perform bounded protocol self-evolution. A prespecified rule selects revisions using development-set results. (B) Weekly refresh updates numerical persona memory under the frozen protocol and fixed topic definitions. (C) Exact-key lookup and predefined fallback supply one record for each of five views. The adapter combines these with the frozen base score and its metadata-adjusted version. LLMs are used only at design time. A three-stage workflow. Offline construction contains a role-based protocol-design loop and a weekly refresh for five persona views. Online scoring produces one matched or fallback record per view, using fixed missing-value indicators when neither is available, and combines their numerical feature vector with the frozen detector's base score and predefined transaction metadata through a lightweight adapter to produce the final score.

Panel of Figure 3 — Figure 3. Descriptive visualization of semantic MCC and Location topics on two-dimensional t-SNE ( van der Maaten and Hinton, 2008 ) maps of narrative embeddings. Each equal-size point represents one MCC or Location, and color indicates its topic; Locations are anonymized. Section 5.3 evaluates the topics’ predictive value. Two side-by-side scatter plots show MCC and anonymized Location narrative embeddings colored by their assigned topics. The visualization provides descriptive context rather than a quality or performance test.

Persona view	Key	Main signal families
Card Spending Behavior Summary	Summary key	Aggregates over twelve months of eligible history; relative and temporal transforms; concentration and diversity; activity distributions (the card’s shares of eligible historical activity) over 56 Merchant topics, 19 MCC topics, and nine Location topics
Merchant topic	One of 56 topics	Merchants grouped within the parent MCC topic; authorization behavior, channel, cross-location activity, historical transaction-size patterns, outcomes available by cutoff $T$ , support, peer-relative deviation, and parent-topic aggregates
MCC topic	One of 19 topics	Prior-period levels, trends, recent-to-long-run ratios, robust (outlier-resistant) deviations, ranks, and population-relative behavior
Location topic	One of 9 topics	Prior-period geographic behavior with the same temporal and population-relative families as MCC topics
MCC–Location interaction	One of up to $19\times 9=171$ MCC-topic–Location-topic interactions	Supported interaction or predefined MCC-topic/Location-topic fallback; temporal change and departures from the separate MCC and Location topic patterns

Table 1. Non-sensitive schema for the five persona views. The summary key identifies the card. Every returned record also contains its support, valid time interval, source metadata, age, missing-value status, and fallback level. “Prior” means history available by the construction cutoff; all five views are rebuilt weekly.

Figure 4. Selected supported MCC-topic–Location-topic interactions from an offline snapshot. The horizontal position, normalized within the displayed examples, shows the joint deviation (how far a pair’s behavior differs from what its separate MCC and Location patterns imply); dots grow in area and darken with MCC-relative interaction lift, which compares the pair’s behavior with that of its MCC topic alone. Topic IDs carry no risk ordering, and absolute values and Location identities are not disclosed. A horizontal lollipop chart lists eight anonymized MCC-topic–Location-topic interactions. Points farther right have larger normalized joint deviation; larger and darker points have higher relative interaction lift.

Stage	What is fitted or held fixed
Protocol design	Each candidate rebuilds memory and fits a temporary Detector 4 adapter for development evaluation.
Final fitting	The selected protocol governs persona construction; four final adapters are fitted and selected. One compatible package is frozen before Period 1.
Period 1	The frozen package is evaluated on held-out offline transactions.
Period 2	The same package scores live traffic; outcomes are joined later. No snapshot or adapter is replaced.

Table 2. Design, fitting, and evaluation stages. Detectors remain frozen throughout. Neither reported period is used for adapter or protocol selection.

Detector	Period	$\Delta$ BM1		$\Delta$ PR-AUC		$\Delta$ AUC
1	Period 1	$+15.03$	$[11.91,\,19.22]$	$+1.40$	$[1.28,\,1.52]$	$+0.27$	$[0.25,\,0.29]$
	Period 2	$+8.93$	$[7.73,\,10.23]$	$+1.30$	$[1.19,\,1.42]$	$+0.27$	$[0.25,\,0.29]$
2	Period 1	$+20.08$	$[16.99,\,22.69]$	$+4.91$	$[4.72,\,5.09]$	$+0.73$	$[0.70,\,0.75]$
	Period 2	$+14.24$	$[12.43,\,15.98]$	$+3.53$	$[3.31,\,3.75]$	$+0.66$	$[0.64,\,0.69]$
3	Period 1	$+4.99$	$[4.13,\,5.91]$	$+0.69$	$[0.60,\,0.77]$	$+0.28$	$[0.26,\,0.30]$
	Period 2	$+11.15$	$[8.65,\,13.60]$	$+0.65$	$[0.55,\,0.74]$	$+0.23$	$[0.22,\,0.24]$

Table 3. Relative improvement (%) over each frozen detector, with 95% confidence intervals. Period 1: held-out offline test; Period 2: deployment. † Design-time protocol selection used development-set feedback from Detector 4; neither reported period was used for selection.

Figure 5. Normalized standalone AUC strength of single-view predictors trained before Period 1 and frozen across both periods. AUC above chance is divided by that of the spending summary in Period 1. Both periods share this scale: 0 denotes chance, and 1 matches the reference, not perfect prediction. The Card Spending Behavior Summary ranks first in both periods, followed by Merchant topic, MCC–Location interaction view, MCC topic, and Location topic.

Figure 6. Semantic topics versus matched conventional clustering in Period 1, by group view. AUC above chance is normalized by that of the semantic Merchant-topic predictor, the largest plotted value: 0 denotes chance and 1 matches this reference. Labels give the differences in normalized strength; Location scores are nearly equal. A horizontal dumbbell chart compares semantic topics with conventional clustering in Period~1 for Merchant, MCC, Location, and MCC–Location interaction views derived from their respective groupings. Semantic topics have higher normalized scores in three views; Location scores are nearly equal.

Error	Transaction context	Persona evidence and alert change
FN	A money transfer with low group-view scores (Merchant pct15, MCC pct3, interaction pct9) and a $100–200 amount well below its Merchant topic’s usual level.	The spending-summary score was at pct99. PersonaAgent recovered this confirmed anomaly.
FN	A charge at a direct-marketing digital-goods merchant, with a spending-summary score at pct49 and a $100–200 amount well above its Merchant topic’s usual level.	The Merchant-view score was at pct90. PersonaAgent recovered this confirmed anomaly.
FP	A charge sharing the Merchant-topic record above, with view scores at pct90 (Merchant), pct55 (MCC), and pct44 (interaction), and an amount under $10.	The spending-summary score was at pct3. PersonaAgent withdrew this false alert.
FP	A transaction with Merchant- and interaction-view scores at pct83 and pct88 and an amount above $500, far above its Merchant topic’s usual level.	The spending-summary score was at pct7. PersonaAgent withdrew this false alert.

Table 4. Four sanitized Period 2 cases at the retrospective BM1 operating point. FN: an anomaly the frozen detector missed; FP: a false alert it raised. pct

n

gives the percentile of a view’s prediction score before fusion, among that detector’s Period 2 transactions whose alert status changed (all four change types).

Figure 7. Release control and request serving. Memory, release metadata, and compatible adapters are activated atomically as one package only after build and compatibility checks pass. Each scoring request selects one package version by event time and detector; health monitoring can halt a rollout or restore the complete previous package. If package selection or serving fails, the frozen base score is returned. A two-part system diagram. Release control validates a candidate package, activates it as a unit on success, and retains the active package on rejection. A previous complete package is retained for rollback. Each request pins a compatible package using event time and detector identity before serving. Sparse or unseen keys use predefined fallback records and continue scoring; pinning or serving failures instead return the frozen base score. Lookup, latency, and score-shift monitoring feeds back to release control.

Appendix figures & tables3 assets

Supplementary material from the paper’s appendix.

Appendix

Condition	Observable evidence	Safe action
Incomplete or stale build	completeness/freshness checks	keep the last active release package
Sparse or unseen key	support and fallback-level indicators	use predefined fallback; preserve its level
Memory lookup unavailable	lookup health and timeout	return the frozen base score
Unexpected score shift	score-change and no-regression checks	halt activation or restore the prior release package

Appendix

Table 5. Failure and fallback conditions in PersonaAgent’s path and the safe action for each.

Field group	Information
Identity and time	Persona view; summary, topic, or interaction key; valid interval; construction cutoff; memory-snapshot and topic-scheme identifiers
Evidence	Eligible aggregate values; relative ratios; temporal change; population/topic-relative ranks and robust deviations
Reliability	Support, missing-value status, memory age, fallback eligibility, actual fallback level, and validation results
Topic construction	Design-time narrative-schema and embedding-configuration IDs, topic identity, parent identity, and identity-consistency status
Source tracking	Protocol ID, execution configuration, release metadata, input-data lineage, build identifier, and activation decision

Appendix

Table 6. Non-sensitive fields associated with persona records and retrieval results. Exact field names and internal limits are implementation details.

Part	What it fixes	Example
$F$	Behavior signals, history windows, baselines, and support rules	cross-location share against a peer baseline
$N$	Numerical-evidence coverage, narrative fields, and source-consistency checks	4–6 selected behavior signals per narrative
$Q$	Semantic topic definitions, Merchant subdivision, and topic identities	behavior-feature clustering within an MCC topic
$R$	Exact keys, minimum support, fallback order, and missing values	low-support pair falls back to a predefined marginal, here MCC-only
$G$	Schema, cutoff-validity, freshness, drift, and compatibility checks	a stale build leaves the last validated package active

Appendix

Table 7. Components of the persona protocol, with one instance of each: behavior signals

F

, narrative schema

N

, topic construction

Q

, retrieval rules

R

, and release checks

G

Anomaly Detection

Anomaly detection finds rare or unexpected patterns in data, from defective products and system faults to fraud and security threats.

See all 689 papers

SR-Fraud: An Outcome-Supervised Reflective LLM Agent Framework for Non-Stationary Payment Fraud Detection
Sep 23, 2026Xuwei Tan, Yao Ma, Xueru ZhangConcept Drift Financial Fraud Detection
Coinbase, Inc. · The Ohio State University
AnomalyAgent: Training-Free Agentic Models for Zero-/Few-Shot Anomaly Detection
May 28, 2026Yi Zhang, Jiawen Zhu, Lele Fu +1Few-Shot Anomaly Detection Tool Use in VLMs
Singapore Management University, Singapore · Sun Yat-sen University, China
Topological Fraud Detection in Latent Transaction Spaces
Sep 8, 2026Avraham BourlaFinancial Fraud Detection Privacy-Preserving ML

Sep 23, 2026J/K move · Enter open · S save

SR-Fraud: An Outcome-Supervised Reflective LLM Agent Framework for Non-Stationary Payment Fraud Detection

Xuwei Tan, Yao Ma, Xueru Zhang

Coinbase, Inc. · The Ohio State University

Concept Drift Financial Fraud Detection LLM Agents

Open paper AskPDF arXiv

Real-time payment fraud detection is a non-stationary streaming prediction problem: adversaries adapt before supervised labels mature, and localized burst attacks can cause losses before retraining. Production systems typically rely on tabular classifiers and rules, which can struggle to capture these emerging sequential patterns before periodic retraining occurs. We present SR-Fraud, an outcome-supervised reflective LLM framework that decouples request-time decisions from offline adaptation. A frozen, stateless agent scores each transaction from a Hybrid Episodic Window to track behavioral shifts, while an offline reflection agent proposes boundary hypotheses from matured errors. A deterministic verifier then admits only supported hypotheses into an executable knowledge state. On a production payment-fraud benchmark, SR-Fraud improves all detection metrics over its frozen decision agent, obtains higher point estimates than static and periodically retrained CatBoost, and detects an emerging fraud burst.

Abstract

Anomaly Detection

Explore similar work

SR-Fraud: An Outcome-Supervised Reflective LLM Agent Framework for Non-Stationary Payment Fraud Detection

AnomalyAgent: Training-Free Agentic Models for Zero-/Few-Shot Anomaly Detection

Topological Fraud Detection in Latent Transaction Spaces