The payee add is the real transaction. Everyone guards the wrong step.

Every fraud team in the world puts its strongest control on the moment money moves. Attackers know this, so they stopped attacking that moment. They attack the settings page six weeks earlier, and then let your own systems approve a payment that looks completely ordinary. This is a lesson about picking the right event to protect.

The case file lands on a Wednesday. A commercial banking customer, a plumbing contractor with about ninety employees, is out one hundred and eighty thousand dollars. The fraud analyst opens the transaction detail expecting something obvious. A midnight login from an unusual country. A brand new destination. A round number. Something.

She finds none of it. The transfer went out at 10:42 on a Tuesday from the office IP the company has used since 2019, on a device the bank had seen four hundred times, under the controller's own credentials with a valid multi factor prompt satisfied on the controller's own phone. The amount is unremarkable for a firm that pays subcontractors in that range monthly. The destination was not new: on file for forty three days, already paid twice, both cleared without a whisper.

The bank's risk model scored the payment at the low end of the scale, and that is not a failure of the model. Given what it was asked, it gave the correct answer. Every feature it consults said this payment was normal, because by then it genuinely was. The fraud had already finished. What she was looking at was not the crime, it was the receipt for the crime.

She scrolls back through the account event log, past the payment, past the two small payments, past a month of nothing, and finds the actual attack sitting there in plain sight. Day one: the mobile phone number on the account was updated. Day one, eleven minutes later: a new payee was added, with a name one character different from a real subcontractor the firm had used for years. Day three: a first payment of two thousand one hundred dollars. Day nineteen: a second, larger one. Day forty three: the big one. Total elapsed effort by the attacker after the initial access, perhaps twenty minutes of clicking, spread across six weeks of patience.

Three controls fired during those six weeks. All three fired on the transfers. Zero fired on the phone number change, which took a one time code sent to the phone number that was about to stop being the customer's. Zero fired on the payee add, which the banking platform classifies, in its own internal taxonomy, as a profile update. Profile updates do not move money. That is the sentence, written somewhere in a product requirements document years ago, that cost this bank one hundred and eighty thousand dollars.

What is an account shape change, and why does it matter more than the payment?

An account shape change is any mutation that alters where money can go, who is notified when it goes there, or who can authorize it going. It is not the movement of value. It is the reconfiguration of the container that value moves through.

Once you start looking for these they are everywhere, and they are almost always filed under a heading like Settings, Profile, or Manage. That filing decision is the entire vulnerability. A team that puts an action under Settings has already decided, implicitly, that it is low stakes. The authentication requirement follows the filing, not the consequence.

The five shapes

They fall into five families, and every one appears in real loss cases.

Destination changes. Adding a payee or beneficiary, whitelisting a crypto withdrawal address, linking an external bank account, adding a card to a wallet, changing standing settlement instructions. These directly answer the question "where is money allowed to go from here".

Contact changes. Updating the phone number, email address, or postal address on file. These do not move money, but they redirect every warning you would otherwise receive about money moving. They are the fraud equivalent of cutting the phone line before breaking the window, and they are frequently the very first action an attacker takes.

Authenticator changes. Enrolling a new device, adding a new passkey or authenticator app, generating backup codes, registering a new phone for one time passwords. These change who counts as you tomorrow. We wrote about the special case of this in passkey recovery being the new weakest link, and the same logic applies to every account with a self service enrollment page.

Authority changes. Adding a user to a business account, granting a role, raising a payment limit, adding an authorized trader, changing an approval threshold. These change who can act and how much they can move.

Notification changes. Turning off alerts, switching to paperless, or adjusting alert thresholds so a payment lands just underneath. These change what you find out about, and when.

Notice the pattern. Not one of these transfers a cent at the moment it is performed, and every one determines the outcome of a transfer later. The industry built its strongest defenses around the event that has already been decided, and its weakest around the event that decides it.

The same failure, in five different industries

This is not a banking quirk. It reproduces anywhere an account holds a destination.

The column that should worry you is the last one. In every row the money movement is indistinguishable from normal business, because after the shape change it is normal business. You cannot detect your way out of a transaction that is, by every observable property, correct.

Why do attackers change the shape instead of just taking the money?

Because it is cheaper, quieter, and it converts a hard problem into an easy one.

Think about what an attacker faces if they try to move money directly after taking over an account. They are pushing a new destination, an unusual amount, and an unusual pattern through a risk engine that has been tuned for fifteen years on exactly that scenario. Velocity models, destination reputation, behavioural baselines, step up authentication, holds, callbacks. That is the fortified wall, and the entire security industry has been reinforcing it since online banking existed.

Now consider changing the shape first. The payee add is scored, if at all, by a far simpler model, because settings pages are optimised for completion rather than suspicion, and there is often no step up beyond a code sent to a phone. Critically, once the change succeeds the attacker never has to defeat the transfer wall. They walk through the gate the customer already owns, at a normal hour, for a normal amount, to a destination the bank now considers established.

Here is the analogy worth holding onto. A burglar has two options for a well secured apartment building. Option one is to climb the fire escape at 3am and force a window, which is exactly what the alarm system, the motion sensors, and the night doorman exist to catch. Option two is to spend a week getting their name added to the building's resident list, obtaining a fob from the management office, and then walking through the front door at 10am on a Tuesday carrying a coffee, nodding at the doorman who has now seen them twice.

The second burglar is not defeating the security system. The second burglar has been onboarded by it. Every entry afterwards is not merely undetected, it is affirmatively approved, and it logs as a resident coming home. That is what a payee add does. It onboards the attacker's destination into your trust model.

Aging is a feature, and attackers use it

The forty three day gap in our opening case was not laziness. It was tradecraft. Nearly every fraud model treats payee age as a risk reducing feature: a destination that has been on file for weeks and has received prior payments that did not result in a chargeback or a complaint is, statistically, a good destination. That inference is completely reasonable and usually correct. Attackers simply supply the inputs.

The two small payments were not the attacker being greedy in stages. They were seasoning. Each cleared payment writes a row into the bank's own history that later gets read as evidence of legitimacy. The attacker is not evading the risk model. The attacker is training it.

Why does the industry authenticate settings more weakly than payments?

Three reasons, and it is worth being fair about all of them.

The first is a scoping error that is genuinely easy to make. When a security team writes down the list of high risk actions requiring strong authentication, they ask a natural question: does this action move money? Payee add does not. It fails the test, lands outside the perimeter, and inherits whatever the default is. The error is not in the reasoning, it is in the question. The right question is not "does this move money" but "does this determine where money can go". Those sound similar and produce completely different lists.

The second is conversion pressure, and it is real. Every extra step in adding a payee produces support tickets, and those have a hard cost that appears in someone's budget, while fraud losses are absorbed centrally and averaged across millions of accounts. The person who owns the settings page is not the person who owns the fraud loss. That misalignment is structural, and worth naming out loud in your own organisation, because until it is named nobody has an incentive to fix it.

The third is that regulation partly encoded the mistake. Under the European strong customer authentication rules, the trusted beneficiary exemption lets a payment service provider skip authentication on payments to a beneficiary the customer has previously added to a trusted list (see the EBA regulatory technical standards on strong customer authentication). The logic is sound: authenticate the addition, then relax the payments. But that logic only holds if the addition is authenticated to a genuinely high standard, because you are consciously trading all future friction for that single moment. In practice many implementations apply an ordinary code to the addition and then take the full exemption on everything after. The regulation identified the correct control point and the market under invested in it anyway.

Why do cooling off periods and change notifications fail?

These are the two mitigations almost everyone reaches for, and they fail in specific, learnable ways.

Notifications fail because of ordering

The purpose of a change notification is to tell the real customer that something happened, so they can object. The message is sent to the contact details on file. But the contact details are themselves an account shape change, and they are usually the very first thing an attacker modifies. This is the ordering attack, and it is trivially cheap: change the phone number, wait for the confirmation to arrive at the new number, then change everything else, with every warning message now being delivered to the attacker.

Some institutions send change notices to both the old and the new contact details, which is a genuine improvement and you should do it. It remains a notification rather than a control: it depends on a human reading their email, understanding what a routing number change implies, and reacting inside the window. The FBI's account takeover advisory of 25 November 2025 describes this exact sequence, criminals impersonating a financial institution, obtaining access, altering contact and payee details, then moving funds, and reports more than 5,100 complaints with losses exceeding $262 million since January of that year (FBI IC3 public service announcement).

Cooling off periods fail because they are a published constant

A cooling off period says a new payee cannot be used for some fixed interval. Twenty four hours. Forty eight. Sometimes seven days for higher risk products. This does stop the impatient attacker, and it is worth keeping.

But consider what it is from the attacker's side. It is a known, documented, publicly stated number. Exchanges publish their whitelist hold times in help centre articles. Banks state their new payee windows in terms and conditions. An attacker reads the number and sets a calendar reminder. The cost of defeating a cooling off period is exactly the cost of waiting, which for an attacker running dozens of compromised accounts in parallel is close to zero. Our opening case waited forty three days against a control designed around forty eight hours, and did so not because it was necessary but because patience is free.

A delay is not a control. A delay is a speed bump that filters out the least committed adversary, and the adversaries who take one hundred and eighty thousand dollars are, definitionally, committed. Treat cooling off periods as what they are: a useful reduction in the volume of low effort attacks, and no defense at all against a targeted one.

What does it actually mean to sign an account shape change?

Here is the mechanism, and it is simpler than it sounds.

Today, when a customer adds a payee, the server checks that the request arrived inside an authenticated session and, if it is feeling careful, that a one time code was entered. Both of those are statements about the session. Neither is a statement about the change. If the session was stolen, and after adversary in the middle phishing kits that is an increasingly ordinary condition (see our lesson on why MFA works perfectly and the attacker is already inside the session), then everything the session asserts is worthless.

Signing the change means the server refuses to persist the mutation unless it receives a fresh cryptographic assertion, produced on a device that was enrolled to this specific human, over the exact content of the change. Not over a random challenge. Over the change itself.

The distinction matters enormously and it is where most implementations go wrong. If you sign a random challenge, you have proved that a key was present, which an attacker with a relayed session can sometimes still arrange. If you sign the hash of the canonical change payload, you have proved that a key was present and that the holder of that key was looking at these specific values. The signature is inseparable from the routing number.

The canonical payload

Canonicalisation is the unglamorous part that decides whether the whole thing works. Both the device that displays the change and the server that verifies it must agree, byte for byte, on what was signed. Sorted keys, a fixed field order, explicit types, no floating point, no locale dependent formatting. Here is what a payee add payload looks like in practice:

{
  "act": "account.payee.add",
  "account_id": "ACC-4471-8890",
  "payee_name": "Rivercourt Mechanical Ltd",
  "routing": "021000021",
  "account_number_last4": "8817",
  "account_number_sha256": "9f2c...a41b",
  "currency": "USD",
  "requested_at": "2026-09-04T14:22:10Z",
  "nonce": "a3f1c9d2e7b40518"
}

The device computes the SHA-256 of that canonical JSON and uses the digest as the WebAuthn challenge. The customer sees the payee name, the routing number, and the last four digits rendered on their own phone, from the payload, not from the browser tab that requested it. They confirm with their fingerprint. What comes back is an assertion that can only have been produced by the private key held in that device's secure element, over that digest.

The server side check is short:

payload  = canonical_json(change_request)
digest   = sha256(payload)

assert assertion.challenge == digest              # signed THIS change
assert assertion.credential_id in enrolled_keys(customer_id)
assert verify_signature(assertion, public_key)    # by THIS human's device
assert now - assertion.signed_at < 120            # freshly, not replayed
assert nonce_unused(payload.nonce)                # exactly once

receipt = store_receipt(assertion, payload)       # offline verifiable, kept
persist_payee(change_request, receipt_id=receipt.id)

Note the last line. The payee record does not just get created. It gets created with a receipt attached to it. That attachment is the part that changes what happens six weeks later, and it is the actual point of this lesson.

How does the transfer endpoint use the receipt?

This is the inversion that makes the whole approach worth the effort, and it is the thing most teams miss when they first hear "sign the settings change".

Today, at transfer time, a risk engine asks a question about the payee: how old is it? Has it been paid before? Did those payments complete cleanly? All of these are proxies. They are attempts to infer, from behavioural residue, whether the customer really meant for this destination to exist. They are proxies precisely because the real answer was never recorded.

Once the payee carries a receipt, the risk engine can stop inferring and simply look. The question changes from "does this destination look legitimate" to "did the account holder cryptographically authorise this destination, and can I verify that right now, offline, against a published key". That is not a probability. It is a fact with a signature attached.

# At transfer time, instead of:
if payee.age_days > 2 and payee.prior_payments > 0:
    risk -= 30

# You do:
receipt = payee.authorization_receipt
if receipt and verify_offline(receipt, published_key) \
   and receipt.subject == account.holder_id:
    route = TRUSTED           # provably authorised destination
else:
    route = FULL_REVIEW       # unproven destination, regardless of age

Read those two branches carefully, because the second one is the important half. A payee with no receipt is now suspicious forever. It does not age into trustworthiness. Time stops laundering it. That single change removes the attacker's entire strategy, because the strategy was built on the assumption that patience converts a fraudulent destination into a trusted one.

There is a second order effect that will help you sell this internally. Payees that do carry a receipt can be treated more generously than they are today, because cryptographic evidence that the holder authorised this destination is a far stronger signal than forty three days of silence. You lower friction on the legitimate majority and concentrate review on the unproven. The control does not simply add friction, it moves friction to where it belongs, which is the only kind of security change that survives a conversation with a product leader.

A worked example, end to end

Picture the same contractor on a platform that has adopted this. The controller adds Rivercourt Mechanical, sees the routing number and last four digits rendered on her phone, taps her fingerprint, and the payee is created with receipt rcpt_8f21c4 attached.

Now the attacker, holding a relayed session, tries the same thing. The session lets them reach the form and submit it. The server computes the digest and asks for a signature. The prompt goes to the controller's phone, in the controller's pocket, showing a payee name and routing number she does not recognise. Either she declines and the attack is reported, or it times out and the attack ends silently. There is no third branch where the attacker produces the signature, because the private key sits in a secure element in a building they are not in.

Six weeks later the legitimate transfer runs, the engine verifies rcpt_8f21c4 offline against the published key, and routes it as trusted. The fraudulent payee never existed, so there is no seasoning period, no test payments, and no case file on a Wednesday morning.

What happens when an AI agent manages the account?

This is why the timing matters now rather than in five years.

Assistants that manage financial accounts are arriving, and they collapse a distinction that was already blurry. When a human clicks through a settings page we at least have an intuition that a person was present. When an agent operates the account there is no such intuition, and the platform cannot tell from the traffic whether the holder decided to add this payee or whether the agent was talked into it by a poisoned email in the inbox it was summarising.

The clean way to handle this is to make the boundary explicit rather than implicit. An agent can hold a scoped, time bound, revocable delegation that permits a defined list of actions, for example reading balances, categorising transactions, and initiating payments to destinations that already carry a valid receipt. That same delegation explicitly excludes the account shape mutations. Adding a destination stays with the human, always, because adding a destination is the act that defines the blast radius of everything the agent is allowed to do afterwards.

That is a coherent security boundary and it is one a customer can actually understand: your assistant can pay the people you have approved, and only you can approve people. If you want the mechanics of how scoped delegation works in practice, we covered them in how delegation tokens work, and the developer reference lives in the documentation.

Honest limits

This control is precise, which means its boundaries are precise too. Being clear about them is how you avoid deploying it against problems it does not solve.

It binds intent, not judgment. This is the big one. If a customer is on the phone with someone impersonating their bank's fraud department, and that person talks them into adding a payee, the customer will look at the routing number on their own phone and approve it. The signature will be valid because it is valid. They meant to do it. They were deceived about why. Authorised push payment fraud lives entirely in this gap and no signature closes it. What the receipt does provide in that scenario is exact evidence of what was displayed and confirmed, at what moment, which matters for reimbursement disputes, but let nobody tell you it prevents the loss.

Enrollment is the trust bottleneck. The whole structure rests on the claim that the enrolled key belongs to the right human. An attacker who compromises the enrollment moment owns everything downstream. Enrollment deserves more care than any subsequent action, and every customer should have at least two enrolled authenticators so that "I lost my phone" never becomes "so we made an exception".

Legitimate urgency needs a documented path. Someone will need to add a payee at 2am with a dead phone. If you do not design that path deliberately, your support organisation will invent one under pressure, and the improvised version becomes the attack surface.

It does not address a corrupt insider. A signature proves the customer authorised the change. It says nothing about someone inside the bank writing directly to the database, which is a separate problem handled by tamper evident audit design.

Deciding what counts as a protected field is your call. There is no universal list. A brokerage and a payroll platform protect different mutations. The taxonomy has to be written by the people who understand which fields determine where money goes, and it should be reviewed whenever a new feature adds a field.

Coverage is not instant. Existing payees created before the control was deployed have no receipts. Do not treat them all as unproven overnight and freeze your customers' payment runs. Plan a migration, and be honest in your risk model that legacy payees are in a distinct, lower assurance category until they are re-attested.

What to do this week

None of this requires a platform migration to start. It requires an inventory and an argument.

1. Write down every mutation that changes where money can go, who is notified, or who can authorize. Go through your own product surface screen by screen. Include the mobile app, the web app, the call centre tooling, and any partner or API path. The list is always longer than the security team expects, and the API path is almost always the one nobody remembered.
2. For each one, record the authentication required today and compare it to the authentication required for a transfer. Put the two columns side by side in a single table. This table, on its own, tends to end the debate faster than any amount of argument, because the asymmetry is usually indefensible once it is visible.
3. Check your notification ordering. Confirm that a contact detail change sends a notice to both the previous and the new address, and that a change to one contact channel notifies the others. If a phone number change only alerts the new phone number, fix that on Monday. It is a small change with immediate value.
4. Find out whether your risk model rewards payee age. Ask the data science team directly which features involving destination tenure or prior payment history reduce risk score. Then ask what an attacker would do with a forty three day head start. This conversation is usually short and productive.
5. Pick one shape change and require a payload bound signature on it. Choose the highest consequence, lowest volume one you have. Whitelist additions and external account links are usually the right first target: high stakes, comparatively rare, and the customers who perform them are already expecting a moment of ceremony.
6. Make the transfer path read the receipt. Signing changes achieves only half the value if the transfer still scores on payee age. Add the receipt check to the risk decision and, in exchange, reduce friction on receipted destinations so the change is not experienced purely as an additional obstacle.
7. Review your strong customer authentication exemptions, if you operate in Europe. If you take the trusted beneficiary exemption, look hard at how the beneficiary got added. You are trading all future authentication for that one moment, so that one moment should be your strongest control, not your weakest.

If you would like to see the signing flow before you build against it, there is a working demonstration in the walk up verification lab, which shows the enrolled device signing an action payload without any signup step.

Frequently asked questions

How do fraudsters use account takeover to steal money without triggering transfer controls? They change the account's shape first. They add a payee, whitelist a withdrawal address, or update the phone number that receives codes, all under weaker authentication because those actions move no money. They then wait out any cooling off period and make an ordinary transfer to what your systems now consider an established destination. The transfer looks normal because, by then, it is.

Should adding a payee require multi factor authentication? It should require more than that. A one time code proves someone controls a phone number, which the attacker may have changed minutes earlier, and a session based prompt proves nothing if the session was relayed. What the moment needs is a signature produced on an enrolled device over the exact payee details, so the proof is inseparable from the routing number being added.

What is a withdrawal whitelist and why is it attacked? A withdrawal whitelist is a list of destination addresses an exchange or bank permits withdrawals to, usually with a hold period before a new entry becomes usable. It is attacked because it is the highest value setting in the product. Once an attacker gets an address onto the list and waits out the published hold, the withdrawal itself faces almost no friction by design.

Why did my bank not stop a transfer to a payee that turned out to be fraudulent? Because at the moment of transfer, that payee was probably no longer new. If it had been on file for weeks and had received earlier payments that completed without complaint, most risk models treat it as a lower risk destination. The moment worth questioning is not the transfer but the addition, and whether anything proved you authorised it.

Do cooling off periods on new payees actually work? They filter out impatient attackers, which is a genuine benefit, and you should keep them. They do not stop a targeted attacker, because the period is a published constant that costs nothing to wait out. Treat a delay as volume reduction rather than as a control, and put the actual control on the moment the destination is created.

Does this stop scams where the customer is tricked into adding the payee? No, and any vendor claiming otherwise is selling something. If the real account holder is deceived into approving a destination, they will produce a valid signature because they genuinely intended the action. What the receipt gives you in that case is precise evidence of what was displayed and confirmed and when, which matters in a reimbursement dispute, but the loss still happens.

Where does this fit with PSD2 strong customer authentication? The European rules already point at the right place. The trusted beneficiary exemption lets you skip authentication on payments to a previously added trusted beneficiary, which only makes sense if the addition itself was strongly authenticated. If you take that exemption while adding beneficiaries under a one time code, you have taken the discount without paying for it.

Sources

1. FBI Internet Crime Complaint Center, public service announcement on account takeover fraud, 25 November 2025, reporting more than 5,100 complaints and losses exceeding $262 million since January 2025. ic3.gov/PSA
2. FBI Internet Crime Complaint Center, 2025 Internet Crime Report. ic3.gov annual reports
3. European Banking Authority, regulatory technical standards on strong customer authentication and common and secure communication under PSD2, including the trusted beneficiary exemption. eba.europa.eu
4. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator assurance levels, verifier impersonation resistance and session management. pages.nist.gov/800-63-3/sp800-63b.html
5. W3C Web Authentication (WebAuthn) Level 3 specification, for the assertion and challenge mechanics referenced in the signing flow. w3.org/TR/webauthn-3
6. United States Department of Justice, prosecutions relating to SIM swap enabled account takeover. justice.gov

Stop asking whether this payment looks normal. Ask who authorised the destination, and whether you can still prove it.