AI agents for loyalty fraud: catching the account takeover before the points are gone

A member logs in from a new phone, changes the account email, and minutes later transfers 180,000 miles to a stranger. By the time anyone notices, the points are spent and the real member is on hold with a call center.

Loyalty fraud is now one of the largest theft problems in travel. Industry estimates put losses above a billion dollars a year for large travel and hospitality companies, and account takeover was among the most targeted attack types in 2025. More than one in five consumers reported an ATO attempt.

The reason is structural. Points behave like cash, they sit in accounts the owner rarely checks, and close to half of loyalty accounts are dormant, which is exactly where a thief wants to work.

Loyalty fraud is a good job for an agent and a dangerous one, for the same reason. The detection is fast, signal-rich, and repetitive, which suits an agent. The response includes actions that punish a real customer if you get them wrong, which does not.

So the rule to build to: let the agent watch, score, and challenge in real time, and keep a human on any action that moves booked points or locks a traveler out. The rest of this is how to wire that on Salesforce.

This is the mirror image of points servicing

The most common loyalty ticket is a member saying “my points didn’t post,” and an agent handling that legitimate case is a workflow we’ve written up in full for Loyalty Management. Fraud is the same ledger seen from the opposite side. There the member is telling the truth and wants points added. Here someone is impersonating the member and wants points gone.

Both touch the same object, the points balance, which is why the servicing agent and the fraud agent must never be the same agent with the same permissions. A servicing agent that can credit points to fix a complaint, if compromised or confused, is a fraud agent’s dream. Keep them separate, and keep the fraud agent’s ability to move points at zero.

What the takeover actually looks like

Account takeover is rarely a single event. It’s a short chain, and the chain is the signal.

A typical sequence runs in three moves. First a login from an unfamiliar device or location. Then a change to the contact details, email or phone, so recovery flows route to the attacker. Then a rapid redemption or a transfer out, often to a gift card, a third-party account, or an unrelated member.

Each step alone is innocent. People buy new phones and travel to new cities. The pattern is what betrays it, and a few signals carry most of the weight:

Velocity that doesn’t fit the member. A dormant account that suddenly redeems, or a burst of transfers in minutes, is the single strongest tell.
A new device, IP, or geography that doesn’t match the member’s history, especially paired with an impossible-travel gap between two logins.
A contact-detail change followed closely by a redemption. The email swap right before the spend is the classic takeover fingerprint.
Redemption to a destination that carries value out of your control: gift cards, points transfers, or a booking for someone who isn’t the member.

None of these is a verdict. Each is a reason to look harder, and looking harder in real time, across every active session, is precisely the work a human fraud team cannot do at scale and an agent can.

The data foundation decides whether this works

An agent can only reason about signals it can see, and the signals here live in different systems. The login and device data sits in your identity provider or web layer. The transaction and balance data sits in Salesforce Loyalty Management. The member’s normal behavior, the baseline you measure deviation against, has to be assembled from history.

Data 360 is where those streams meet. Ingest the loyalty transactions and unify them onto the member profile. Bring in the behavioral events, session and device signals, through the Web SDK and streaming ingestion so they land in near real time rather than in last night’s batch. Fraud that completes in two minutes is invisible to a pipeline that refreshes hourly.

On top of that unified data, compute the risk signals as streaming calculated insights: redemption velocity over a short window, a device-newness flag, time since last activity, an impossible-travel check between consecutive logins. These become the features the agent reads.

The agent should not be re-deriving “is this device new” from raw logs inside the prompt. That computation belongs in Data 360, pre-computed and cheap, so the agent reasons over clean scores rather than raw noise.

The agent’s job is triage, not judgment

With the signals in place, an event-driven agent fits the shape of the problem. A triggered agent fires when a streaming insight crosses a risk line, a redemption on a high-risk session, a transfer right after an email change, and does the work a human analyst would do first: gather the context.

It assembles the case first. It pulls the member’s recent activity, the current session’s device and location against history, the size and destination of the attempted redemption, and the risk scores that fired the trigger.

Then it classifies the event as a likely takeover, an ambiguous case that needs the member’s help to resolve, or a false alarm on a member who bought a new phone in a new city.

From there it can take reversible actions on its own:

Require step-up verification before a high-risk redemption completes, challenging the session to prove it’s the member before any points move.
Hold a suspicious redemption in a pending state rather than reversing it, since a hold takes nothing from anyone and buys time.
Alert the real member through a known-good channel, the phone number on file from before the change, not the one just added.
Open and route a fraud case with the whole picture attached.

Step-up verification is the move that resolves most cases without a human and without offending anyone. A legitimate member passes the challenge and continues. A thief usually can’t, and the redemption never completes.

The industry pattern is to verify only when behavior turns suspicious rather than challenging everyone. The friction lands on the risky sessions, and the large majority of members never feel it. That risk-based branch is exactly the judgment an agent is good at.

The reversal is where a human signs

Everything above is safe because it’s reversible. A hold releases. A challenge passes. A false positive costs a legitimate member one extra verification step, an annoyance, not an injury.

The actions on the other side are not reversible, and they are where the agent stops and a person decides:

Clawing back points that were already redeemed. This reaches into a booked balance and, if wrong, strips a real customer of miles they earned.
Reversing a completed transfer or a partner redemption, which may involve a third party and a settled transaction.
Locking an account outright. Do that to a legitimate traveler the day before a trip and you’ve turned a fraud control into a churn event.

The reason to hold this line is on the balance sheet as much as in the CX. Outstanding points are a liability a loyalty program carries and reports, a constraint the servicing workflow has to respect too. An adjustment to a booked balance is an accounting event, not a chatbot action.

So the agent’s output for a confirmed-looking takeover is a packaged recommendation: the evidence, the proposed reversal, and the member impact. A human fraud analyst approves or rejects it. That is the human-in-the-loop gate applied where it belongs, on the irreversible money-moving step, not on the detection.

That division also answers the “why not full automation” question. Full automation of the clawback optimizes for stopping fraud and ignores the cost of being wrong. In loyalty, the cost of being wrong is a furious high-value member and, at volume, a reserve you can’t defend to your auditors.

The failure modes to design against

A fraud agent is a high-value target and a high-blast-radius one, so a few controls are not optional.

Scope its permissions to read and to reversible actions only. It should be able to hold, challenge, notify, and open a case, and it should have no permission that mutates a points balance. The whole argument for locking an agent’s access to exactly its job, and no more, is in governing what an agent can reach, and it matters most for the agent whose neighbors are attackers.

Guard the inputs. If the agent reads member-supplied text, a support message, a profile field, treat that text as untrusted, because an attacker who controls an input can try to steer the agent through it. The prompt-injection risks and defenses are the same ones any agent that reads external content faces, with higher stakes here.

Filter the trigger so the meter matches the risk. A triggered agent bills on every fire, and login and redemption events are high-volume, so firing the agent on all of them is both noisy and expensive. Fire it on the scored, filtered signal, the high-risk session, not every session, for the credit-cost reasons laid out in the triggered-agents cost math.

And log every decision. A fraud control that can’t show why it challenged one member and cleared another is a compliance problem waiting to happen. Every fire, its evidence, its classification, and its action should be observable and reviewable after the fact.

Where to start

Don’t start with the agent. Start with the signals, because an agent grounded on weak signals produces confident, wrong verdicts, and a wrong verdict here has a name and a booking attached. Get the loyalty transactions and the behavioral events unified in Data 360 in near real time. Compute a handful of risk insights you trust, and validate them against known past fraud before any agent reads them.

Then add the agent as triage: fire on the high-risk signal, assemble the case, challenge or hold, and route the irreversible decision to a human with the evidence packaged. Prove the step-up challenge resolves the easy cases cleanly before you widen its reach.

Built that way, the agent gives your fraud team what they’ve never had, a watcher on every active session at once, and it never gets to reach into a member’s balance on its own. The speed is the agent’s. The clawback stays a human’s.

Understanding the basics

How is an AI fraud agent different from a loyalty servicing agent?

They act on the same points balance from opposite intents, which is why they should be separate agents with separate permissions. A servicing agent helps a verified member with legitimate requests like crediting missing points, so it needs the ability to adjust balances.

A fraud agent watches for impersonation and theft, so it should have no ability to move points at all, only to challenge, hold, notify, and escalate. Combining them puts a balance-mutating permission behind the exact surface attackers target.

What signals detect loyalty account takeover?

The strongest signals are behavioral patterns rather than any single event. Watch for a sudden burst of redemptions on a normally dormant account, a login from a new device or an impossible-travel location, and a contact-detail change followed closely by a redemption. Each is innocent alone, so the detection looks for the chain. A contact-detail change immediately before points leave the account is the classic takeover fingerprint.

Should an AI agent automatically claw back stolen loyalty points?

No. Clawing back redeemed points, reversing a completed transfer, or locking an account are irreversible actions that harm a real customer if the detection was wrong, and outstanding points are a booked liability whose adjustment is an accounting event. The safe design lets the agent take reversible actions on its own, holding a suspicious redemption, requiring step-up verification, alerting the member through a known-good channel, and package a recommendation for a human analyst to approve before any booked points move.

What Salesforce products support a loyalty fraud agent?

Salesforce Loyalty Management holds the points ledger and member records, Data 360 unifies the loyalty transactions with behavioral and device signals so risk can be computed in near real time, and Agentforce provides the triggered agent that fires on a high-risk signal, assembles the case, and takes reversible action. The pattern relies on streaming ingestion for the behavioral events, streaming calculated insights for the risk scores, and a human-in-the-loop step for any irreversible reversal.

Sitting on a loyalty program that’s a target and a fraud process that can’t watch every session at once? Talk to us. Getting the signals trustworthy in Data 360 before an agent ever acts on them, and drawing the line at the actions that move real balances, is the work that makes this safe to ship.