Points are money that nobody guards like money

A frequent flyer balance can be worth more than the contents of a current account, and it is usually protected by a password the member last changed in 2019. The theft does not happen at the login screen. It happens at redemption, which is the one place almost nobody looks.

Three weeks before a family trip, someone opens the airline app to book seats with miles. The balance reads zero.

It read 243,000 the last time they looked, which was about seven months ago, because that is how often people look at a loyalty balance. The activity log tells a tidy story. Eleven days earlier, at 04:12, someone signed in. Two minutes later they added a new redemption recipient. Four minutes after that they moved 180,000 points to a hotel partner programme. Then they spent the remainder on gift cards, in six transactions, each just under the threshold that would have triggered a manual review.

Every one of those actions was performed by an authenticated session. The password was correct. If the account had multi factor authentication enabled, the code was entered correctly too, because the attacker was relaying it in real time from a page the member believed was the airline. Nothing in the log looks like an intrusion. It looks like a member having a productive early morning.

The member calls the airline. The airline explains that points are not legal tender, that the programme terms disclaim liability for unauthorised redemptions, and that the gift cards were spent nine days ago. Sometimes, if the member is loud enough or senior enough in the programme, the points come back as a goodwill gesture. Often they do not. There is no regulator to escalate to, because there is no rule that says a loyalty balance must be protected like a deposit.

Why are loyalty points such an attractive target?

Because they combine three properties that almost never occur together: real value, liquid conversion, and consumer grade security.

The balance is real money, and the issuer knows it

A loyalty programme is not a marketing gimmick on the balance sheet. Outstanding points are a liability, and airlines carry that liability explicitly in their financial statements as deferred revenue, because a point is a promise of future travel that has already been paid for by a co-brand card issuer. The largest airline programmes are worth more, on some analyst valuations, than the airlines that operate them. That is not a metaphor about brand value. It is a statement about cash flows from selling points in bulk to banks.

Follow the money and the security posture becomes strange. A bank buys points from an airline for cash. The bank gives those points to a cardholder as a reward. The cardholder holds a balance the airline must honour. At every step, real money changed hands. At the final step, the asset sits in an account protected by whatever the loyalty programme's web team implemented, which is usually an email address and a password, because the programme was built by a marketing department to make joining as easy as possible.

Here is the comparison that makes it concrete. Two hundred and forty thousand airline miles will, depending on the programme and the route, buy a pair of long haul business class tickets. Call that somewhere between four and twelve thousand dollars of value. If a member had that much cash in a current account, the bank would apply transaction monitoring, step up authentication on new payees, a cooling off period on first time transfers, and regulatory obligations on unauthorised payments. Because it is points, they get a password field and a link that says "forgot password".

The grey market makes points liquid, which is what makes them worth stealing

Value alone does not attract organised theft. Liquidity does. A stolen asset is only useful if it can be converted to something spendable before anyone notices, and loyalty programmes have spent two decades building exactly the conversion rails an attacker needs, for entirely legitimate reasons.

Points can usually be transferred to a partner programme, which moves them beyond the issuing programme's fraud team and into an account the attacker controls. They can be spent on gift cards, which are bearer instruments that resell instantly at a discount. They can book travel for a third party, because the entire point of a loyalty programme is that you can book a ticket for your mother, so requiring the passenger name to match the member name would break the product. Every one of those paths exists because members want them, which is why this problem is hard rather than merely neglected: you cannot close the conversion rails without destroying the programme.

The account is dormant, which is the attacker's real advantage

Most security models quietly assume an owner who notices. Fraud on a debit card is discovered because people look at their bank balance. Fraud on a loyalty account is discovered when the member next tries to book a trip, which might be eight months later, by which time the gift cards are spent, the transferred points are gone, and the trail has gone cold.

How big is the problem, and why is the honest answer "nobody publishes it"?

Start with what is documented. The FBI's Internet Crime Complaint Center issued a public service announcement on 25 November 2025 reporting more than 262 million dollars in account takeover losses across more than 5,100 complaints filed since the start of that year. That figure covers account takeover in general, not loyalty programmes specifically, and it counts only complaints filed with the IC3, which is a small fraction of incidents. It is a useful floor and nothing more.

Beyond that, the numbers get soft quickly, and it is worth being blunt about why. Loyalty programmes do not publish fraud rates. There is no regulatory filing that requires them to. Points are not money in a legal sense, so unauthorised redemption is not a reportable payments fraud statistic in most jurisdictions, and the loss is absorbed as a programme expense rather than booked as fraud. Several vendor surveys report sharp rises in travel sector account takeover, including work published by the fraud vendor Ravelin describing a large increase in attacks against travel companies over a twelve month period, and those surveys are worth reading with the usual caution: they are self reported by respondents who are also buying anti fraud products, and each vendor measures its own book of business.

So the honest framing is this. We can say with confidence that loyalty balances are valuable, liquid, weakly protected and actively targeted. We cannot put a credible global number on the losses, and anyone who quotes one to you should be asked where it came from. What the programmes themselves know, from their own internal numbers, is the figure that would settle the argument, and they are not going to publish it.

Why does login multi factor authentication not stop points theft?

Because the redemption happens after the login, inside a session that has already been authenticated, and the session does not remember how carefully it was created.

This is the single most important idea in the post, so let me build it properly rather than assert it.

Think of a hotel keycard. You present identification at the front desk, the clerk checks it carefully, and you receive a card. From that moment on, every door in the building that the card opens will open, and none of those doors performs another identity check. The doors trust the card. The card exists because of a check that happened once, at the desk, possibly hours ago. If someone lifts the card from your pocket, they do not need to impersonate you at the front desk, because the front desk is no longer involved.

A web session is that keycard. When you sign in and satisfy a multi factor prompt, the server issues a session token, and every subsequent request carries that token. The redemption endpoint does not re-run the authentication. It checks that the token is valid and that the member it identifies has enough points. That is the correct design for almost everything a member does, and it is why sessions exist at all. It becomes a problem only when the action on the other end of the request moves value.

Now consider how attackers obtain the card. They do not need your password if they can obtain a live session, and there are several well documented routes.

Credential stuffing works because loyalty passwords are reused. A member who signs in twice a year is exactly the member who used the same password they use everywhere else, and the credentials for that password have been in a breach corpus since 2019. The programme's login page is a rate limited endpoint that an attacker with a residential proxy pool works through patiently.

Adversary in the middle phishing defeats multi factor authentication entirely by relaying it. The member receives a message about their account, follows a link to a page that proxies the real airline site, enters their password and their one time code, and the attacker captures the resulting session cookie. The member sees a successful login because there genuinely was one. We covered the mechanics of this at length in the piece on session theft, and it applies here with full force.

The call centre route skips the technology altogether. Someone calls, provides the member number and date of birth that appeared in a breach, says they cannot access their email, and asks the agent to update the contact address. That is not a technical attack. It is a conversation, and it is examined in more detail in the help desk reset piece and in the contact centre deepfake piece.

In all three routes, the login control did its job or was bypassed before it could. By the time the redemption request arrives, there is no distinction between the attacker's session and the member's session, because there is no such thing as an attacker's session. There is only a valid session.

What actually happens between the login and the empty balance?

The sequence is consistent enough to write down, and each step is chosen to defeat a specific control.

First, the attacker changes the account's shape before touching the balance. They update the email address or add a second one, so that redemption confirmations do not reach the member. They add a new redemption recipient or link a partner programme account. Sometimes they enrol their own authenticator, which converts a stolen session into durable access that survives the member changing their password later. This is the step that decides the outcome, and it is almost always treated as a settings change rather than as a transaction, which is the argument made at length in the piece on account shape changes and in the piece on authenticator enrolment.

Second, they wait. Not always, but often. A redemption immediately after a login from a new device is the one pattern that fraud scoring reliably catches. A redemption four days later, from a session established earlier, looks considerably more ordinary.

Third, they convert, and they structure the conversion to stay under review thresholds. Six gift card purchases of eight thousand points each attract less attention than one of forty eight thousand. Partner transfers are attractive because they are usually instant and effectively irreversible once the receiving programme credits them, since the receiving programme has no relationship with the defrauded member and no obligation to reverse anything.

Fourth, nobody notices for months. The confirmation emails went to the attacker's address. The member is not watching. The programme's systems recorded a series of successful, authenticated, in policy transactions.

Which loyalty actions actually matter?

Not all of them. This is the practical heart of the problem, because a programme cannot put a security prompt in front of everything without destroying the experience that the programme exists to create. The useful move is to rank actions by two properties: how liquid the resulting value is, and how reversible the action is if it turns out to be fraudulent.

Read the bottom two rows again, because they are the ones programmes consistently get wrong. Neither moves a single point. Both are the actions that make the theft possible and invisible. A programme that gates gift card redemption but not the email change has installed a lock on a door while leaving the key under the mat.

What does a signed redemption look like?

The idea is narrow. Instead of the redemption endpoint checking that a session is valid, it requires a fresh cryptographic signature, produced on a device the member has enrolled, over the exact details of this redemption. Not a login. Not a code typed into a page. A signature over the payload.

The payload matters more than the cryptography, so look at it first. This is what the member's device signs, conceptually:

{
  "action":       "loyalty.redeem",
  "programme":    "AIRLINE-FF",
  "member_id":    "FF-4419-8827",
  "points":       180000,
  "type":         "partner_transfer",
  "destination":  "HOTELGROUP-REWARDS:88213904",
  "value_est_ccy":"USD",
  "value_est":    2160,
  "requested_at": "2026-09-24T04:12:07Z",
  "nonce":        "b7f1c0a4e2"
}

The member's device hashes that object and signs the hash with a private key that has never left the device. The programme stores the signature next to the redemption record. Now examine what each field is doing.

The points, type and destination fields are the reason this works. The signature covers them, so it cannot be lifted from one redemption and replayed on another. An attacker who somehow captures a signature for a 5,000 point gift card cannot reuse it to authorise a 180,000 point partner transfer, because the signature is over bytes that say 5,000 and gift card. This is the property that a one time code does not have. A six digit code is the same six digits regardless of what it authorises, which is why relaying it works.

Verification is unremarkable, which is the point:

def authorise_redemption(req, signature, member):
    if req.value_est < POLICY.signature_threshold:
        return ALLOW            # small redemptions are not worth the friction

    key = member.enrolled_keys.active()   # public key, registered at enrolment
    if not key:
        return STEP_UP          # no enrolled device, fall back to a slower path

    payload = canonical_json(req)
    if not ed25519_verify(key, sha256(payload), signature):
        return DENY

    if req.nonce in recently_used_nonces:
        return DENY             # replay
    store_receipt(req, signature, key.id)
    return ALLOW

What the programme keeps afterwards is a receipt: the payload, the signature, and the identifier of the key that produced it. That receipt can be verified later by anyone holding the published public key, without calling the programme's systems and without trusting the programme's logs. When a member disputes a redemption, the question stops being "our records show you did this" and becomes a checkable fact about whether the member's enrolled device produced a signature over those exact bytes.

That evidentiary property is worth as much as the prevention. Today a disputed redemption is one party's logs against another party's memory, and the party holding the logs also decides the dispute.

Why gate redemption instead of forcing multi factor authentication at login?

Because the second option does not survive contact with the business, and pretending otherwise is how security proposals die.

A loyalty programme's purpose is to make people choose one airline over another. Every point of friction in the enrolment and engagement path measurably reduces participation, and the marketing team that owns the programme knows this with more precision than the security team knows its own numbers. Telling that team to mandate multi factor authentication for a leisure travel customer base, many of whom sign in once a year on a phone they are not signed into, will produce a polite refusal and a long conversation about programme engagement metrics. Security proposals that lose that conversation do not get implemented, no matter how correct they are.

So invert it. Do not put the control where the members are, put it where the value leaves. Almost every member interaction with a loyalty programme is worth nothing to an attacker: checking a balance, browsing awards, claiming missing miles, updating a seat preference. The subset of actions that convert points into liquid value is small, and members perform them rarely, which means a prompt at that moment is both rare and contextually obvious. A member transferring 180,000 points to a hotel programme is not surprised to be asked to confirm on their phone. A member checking whether their flight credited is very surprised indeed.

The threshold approach follows naturally. Set a value threshold, express it in the currency the programme already uses for its own accounting, and require a signature above it. Below it, do nothing. This means the overwhelming majority of redemptions are untouched, and the small tail that represents most of the loss carries a control. It also means the control cost scales with what is at risk rather than with traffic.

What about the call centre?

The call centre is where a well designed technical control goes to die, so it has to be addressed directly rather than left as an exception.

If the redemption endpoint requires a signature, but a member can telephone and ask an agent to process the redemption on their behalf, then the attacker will telephone. This is not speculative. The pattern of moving from a hardened technical path to a softer human path is the defining behaviour of the account takeover groups that have caused the largest recent intrusions, and it is why the piece on bribed support staff exists.

The resolution is the same one that works elsewhere: the agent initiates, the member signs. The agent's screen shows the redemption they are helping with, they trigger a signature request, and it appears on the member's enrolled device. The agent never holds the authority to complete the transaction, which means an agent who is deceived, bribed or simply helpful cannot complete it either. The caller can be as convincing as they like. They cannot produce the signature.

That leaves the genuine case: a member who cannot sign because they have lost the device, changed phones, or never enrolled. Do not pretend this case away. It is real, it is common in a leisure travel population, and it is exactly where the fraud will concentrate once the main path is closed. The honest design is a slower path with a different risk profile: a documented cooling off period, a notification to every contact method on file including the ones that were not recently changed, and a hold on the redemption rather than a refusal. Slow is acceptable here in a way it is not for a payment, because a member redeeming points for a trip in three weeks can wait forty eight hours. That is a genuine advantage of this domain and programmes should use it.

What this cannot do

Several things, and they should be stated plainly.

It does not recover points already stolen. Everything here is preventative and evidentiary. A programme adopting signed redemptions today still has whatever historical exposure it has, and members whose balances went to gift cards in 2024 are not helped.

It does nothing about programme rule abuse by legitimate members. A meaningful share of what loyalty fraud teams spend their time on is not account takeover at all. It is members exploiting fare construction quirks, mileage running, brokering award tickets in violation of programme terms, or manufacturing spend. Every one of those is performed by the actual member, who will sign quite happily. Signatures are the wrong instrument entirely for that category, and a vendor telling a loyalty team otherwise is selling something.

It does not stop a member who is talked into signing. If someone telephones a member, convinces them their account is compromised, and walks them through authorising a transfer to a "secure holding account", the member will sign, and the signature will be perfectly valid. This is the same limit that applies to authorised push payment fraud, and it is a real one. What a signature does in that scenario is provide unambiguous evidence of what was authorised and when, which affects how the dispute is resolved but not whether the loss occurred.

It requires enrolment, which is a real programme cost. Members have to enrol a device at some point, and the enrolment moment is itself a target. A programme that lets an attacker with a stolen session enrol a device has moved the problem rather than solved it, which is why enrolment must itself be treated as a high consequence action.

Manav has not shipped integrations with loyalty platforms or airline passenger service systems. The primitives described here are the per action signature, the companion device flow for members without passkeys, and the offline verifiable receipt. Wiring them into a specific loyalty platform is integration work that does not exist yet.

What to do this week

For a programme operator:

1. List every action that converts points to liquid value. Gift cards, partner transfers, merchandise to a new address, third party travel. This list is usually shorter than people expect and it is the entire scope of the problem.
2. Add account shape changes to that list. Email change, phone change, authenticator enrolment, adding a redemption recipient, linking a partner account. These move no points and enable every theft.
3. Measure how many redemptions would be above a candidate threshold. Take your last twelve months of redemptions, apply a value threshold, and count. Most programmes discover that a threshold covering eighty percent of the loss touches a small single digit percentage of redemptions.
4. Check whether a confirmation email is sent to the address on file before a change, or only after. Sending it only to the new address after the change is worse than useless, and it is a surprisingly common default.
5. Audit the call centre's authority. Establish exactly which redemption and account change actions an agent can complete without the member. That set is your social engineering exposure, and it is usually larger than the security team believes.
6. Instrument dormancy. Flag accounts with no member initiated session in twelve months, and treat the first redemption after a long dormancy as a distinct risk case rather than as ordinary activity.
7. Write down the dispute process. If a member says a redemption was not theirs, what evidence decides it? If the answer is "our logs", note that the logs are written by the system that was compromised.

For a member, right now, without waiting for any programme to do anything:

1. Change the password on every loyalty account to something unique, because the current one is almost certainly reused.
2. Turn on multi factor authentication where the programme offers it. It does not stop everything described here, and it stops credential stuffing, which is the highest volume route.
3. Check the email address and phone number on file, and look at whether a second one has been added.
4. Log in once a quarter and look at the balance. Discovery time is the single variable that determines whether anything can be recovered.

The technical building blocks for the programme side are described in the developer documentation, and the signing flow can be tried directly in the signing demo.

Frequently asked questions

How do hackers steal airline miles? Usually through account takeover rather than any attack on the airline. They obtain a valid session using reused credentials, a phishing page that relays the multi factor code in real time, or a call centre agent talked into changing the contact details. Then they redeem quickly into gift cards or transfer the points to a partner programme, where the balance leaves the airline's control.

Does multi factor authentication protect loyalty points? Partially. It substantially reduces credential stuffing, which is the highest volume attack. It does not protect a redemption performed inside a session that already passed the multi factor check, and it does not help when the code itself is relayed through a proxy phishing page or when the account is taken over through the call centre.

How much account takeover fraud was there in 2025? The FBI's Internet Crime Complaint Center reported more than 262 million dollars in losses across more than 5,100 complaints filed in 2025 as of a public service announcement issued on 25 November that year. That figure covers account takeover across all sectors and counts only complaints filed with the IC3, so it is a floor rather than an estimate of the total.

Are stolen loyalty points ever recovered? Sometimes, as a goodwill gesture, particularly for high status members who complain persistently. There is generally no legal right to reimbursement, because points are not money and programme terms usually disclaim liability for unauthorised redemptions. Recovery is much more likely if the theft is discovered before the points are spent, which is why checking the balance periodically matters.

What is a signed redemption? A redemption that requires a fresh cryptographic signature from a device the member has enrolled, produced over the exact details of that redemption: the number of points, the type, and the destination. Because the signature covers those specific values, it cannot be captured and reused for a different redemption, and it cannot be produced by someone holding only a stolen session.

Why not just require a signature on every redemption? Because it would add friction to the large majority of redemptions that carry almost no risk, and loyalty programmes exist to reduce friction. A value threshold puts the control on the small subset of transactions that represent most of the loss, which keeps the cost proportionate and makes the prompt feel contextually reasonable rather than arbitrary.

Does this help if the member is tricked into approving the transfer? No. If a member is persuaded to authorise a redemption themselves, the signature will be valid, because it was. What the receipt provides in that case is unambiguous evidence of exactly what was authorised and when, which affects how the dispute is handled but does not prevent the loss.

Sources

1. FBI Internet Crime Complaint Center, public service announcements, including the account takeover advisory of 25 November 2025 reporting more than 262 million dollars in losses across more than 5,100 complaints. ic3.gov/PSA
2. FBI Internet Crime Complaint Center, annual Internet Crime Reports, for context on account takeover and related categories. ic3.gov/AnnualReport/Reports
3. Ravelin, published research on account takeover trends in the travel sector. Vendor survey data, self reported by respondents who also purchase anti fraud products. ravelin.com
4. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator assurance and the limits of out of band one time codes. pages.nist.gov/800-63-3/sp800-63b.html
5. FIDO Alliance specifications on device bound credentials and transaction confirmation. fidoalliance.org/specifications
6. European Banking Authority, regulatory technical standards on strong customer authentication, for the dynamic linking requirement used here as an analogy. eba.europa.eu

Loyalty fraud is hunted at the login screen and lost at the redemption button. One of those places is where the money leaves.