Proof of human intent: how to prove a person authorised an action

Every authentication system in production answers the question "who is this?" at the moment a session begins. Almost none of them answers the question that actually matters when money moves, which is "did a person mean to do this specific thing?" This page is about the difference between those two questions, why the gap between them is where the losses live, and what closing it looks like in practice.

The Tuesday that explains the whole problem

An accounts payable clerk opens an email from a supplier her company has paid every month for six years. The supplier is changing banks. The message comes from the right domain, references the correct open invoice number, and is written in the same slightly stiff English as every previous message from that account, because it was written by the person who has been reading that mailbox for three weeks.

The clerk follows the procedure. She calls the number on file to verify. Someone answers, confirms the change, and thanks her. She updates the vendor master record. Eleven days later the company pays an invoice of four hundred and twelve thousand dollars into an account controlled by someone none of them have ever met.

Now trace it through the controls. The email passed SPF, DKIM and DMARC, because it genuinely came from the supplier's real mailbox. Multi-factor authentication protected the clerk's login, and she really did log in. The callback happened and was documented. Two people reviewed the payment run. Every control fired correctly, and every one answered a question that was not the question.

The controls all asked some version of "is this session legitimate?" The answer was yes, every time. The question nobody asked, because no system in that stack is capable of asking it, was "did the person who is entitled to change that bank account actually decide to change it?" Nobody had ever built a way to ask.

This page is about that missing question. It has a specific technical answer that is neither new nor exotic, and that answer is simply not deployed where it needs to be.

What is proof of human intent?

Start with a distinction that sounds pedantic and turns out to be the whole thing.

Authentication establishes that a principal is present. You prove you hold a credential, and the system issues you a session. From that point on, the session is the authority. Every request carrying that session token is treated as coming from you, because at some point in the past it did.

Authorisation is a policy question layered on top: given this principal, is this operation permitted? Role checks and entitlement lookups evaluate what a principal is allowed to do.

Proof of human intent is a third thing that almost nobody implements. It asks whether a specific human, at this moment, formed and expressed the intention to perform this exact operation. It is not about identity and not about permission. It is about volition, and the artifact that proves it has to be produced by the person at the moment of the decision.

The analogy that gets people to the right mental model: a building pass gets you through the front door, and once inside you can open any room it opens, all day, without being asked again. That is a reasonable design for a building. Now make the rooms wire transfers, where walking in means emptying them. A pass checked once at eight in the morning is doing an enormous amount of work by three in the afternoon.

A signature over an action is a different artifact. It is not a pass, it is a receipt: at 15:04 on a Tuesday, this person, holding this key, on this device, agreed to send four hundred and twelve thousand dollars to this account number. It grants access to nothing. It records a decision, in a form anyone can check without trusting a log.

Why does authentication not answer the question?

Because the session is transferable and intent is not.

This failure has a name in the Identity Failure Map, where it is catalogued as IFM-01, Session-Inherited Authorization: every action after login carries the authority of the login, so anything that captures the session captures the authority. It is the single most consequential structural failure in modern identity, and it is invisible because it is how everything works.

Stealing the session directly

Adversary-in-the-middle phishing kits do not steal passwords in any meaningful sense. They relay the real login page, let the victim authenticate genuinely against the real identity provider, complete the real multi-factor challenge, and then capture the resulting session cookie. The victim's authentication was perfect. The attacker now holds the output of it. We covered the mechanism and the commercial kit ecosystem in your MFA worked perfectly, the attacker was already inside the session, and the important detail is that stronger authentication does not help, because the authentication is not what failed.

Getting the victim to authorise the attacker's session

The OAuth device authorization grant exists so a television can be signed into an account. The attacker starts the flow on their own device and social engineers the victim into entering the attacker's code on the genuinely real provider page. There is no fake site to detect, no lookalike domain, no credential typed into a hostile form. Everything is real except the reason. This is device code phishing, and it is elegant precisely because the phishing page is not a phishing page.

Its cousin is consent phishing, where the victim grants a hostile application an OAuth scope that then outlives the password change, the MFA enrolment and often the incident response, which is why the app you authorised in 2023 is still reading your mail is a persistence mechanism as much as an initial vector.

Getting a human to approve without understanding

Push fatigue asks a person to approve something described in three words at eleven at night until they tap yes to make it stop. Number matching, now widely deployed, substantially mitigates the naive version, as approve is a button, not a sentence says plainly. What it does not do is bind the approval to an action. It proves you are looking at the right login screen, and says nothing about what happens once you are inside.

One-time codes have the same shape. A code proves whoever holds a SIM received a message, and carriers reassign SIMs through a retail process. Even a perfect channel proves delivery, not decision, which is the one time code is a delivery receipt, not a decision.

Turning a session into permanent co-ownership

The most underrated move in the whole catalogue: an attacker who holds a session for ten minutes can enrol their own authenticator, and now they have independent, durable access that survives the password reset and often survives the victim noticing. Almost every platform treats adding an authenticator as a routine settings change protected by the current session, while treating a payment as high risk. That is backwards, and the takeover button is labelled add authenticator works through why.

Not one of these five involves defeating cryptography or guessing a password. They all exploit the same design decision: authority, once established, persists and transfers.

What does a per-action signature actually contain?

Here is where most explanations get vague. Let us be concrete.

The core idea is that the thing being signed is not a random challenge, as in a normal WebAuthn login, but a value derived from the action itself. A login assertion says "the holder of this key was present." An action assertion says "the holder of this key was present and agreed to precisely this."

You start by building a canonical representation of the action. Canonical matters, because if the renderer and the verifier can serialise the same logical payment two different ways, you have moved the ambiguity rather than removed it. Fixed field order, no optional whitespace, explicit types, no floating point for money.

{
  "v": 1,
  "action": "vendor.bank_change",
  "tenant": "acme-manufacturing",
  "vendor_id": "V-88213",
  "old_account_last4": "4417",
  "new_routing": "021000021",
  "new_account": "9911204471",
  "effective": "2026-10-14",
  "requested_by": "u_2291",
  "nonce": "0f4a...c31d",
  "issued_at": "2026-10-02T15:04:11Z"
}

Hash that canonical byte sequence. The hash becomes the WebAuthn challenge. The authenticator on the approver's enrolled device requires a user gesture, a fingerprint or a face or a PIN, and returns an assertion signed by a private key that has never left the device's secure element.

payload_bytes = canonical_json(payload)          # deterministic
challenge     = sha256(payload_bytes)

assertion = navigator.credentials.get({
  publicKey: { challenge, userVerification: "required",
               allowCredentials: [approver_credential] }
})

# server side, at the release endpoint
assert sha256(canonical_json(payload)) == assertion.challenge
assert verify(assertion.signature, approver_public_key)
assert payload.nonce not in seen_nonces          # replay
assert now() - payload.issued_at < 300           # freshness
receipt = sign_ed25519(manav_key, {payload_hash, credential_id, ts})

Four properties fall out of this, and each one kills a different attack.

It is bound to the payload. Change one digit of the account number and the hash changes, so the signature no longer verifies. An attacker who intercepts the request cannot alter the destination without invalidating the proof.

It requires the device. The private key is in hardware on the approver's phone or laptop. A stolen session cookie does not contain it. Neither does a compromised mailbox, a bribed support agent, or a convincing voice on a video call.

It requires a gesture. User verification means a biometric or PIN at the moment of signing. Malware that silently replays a stored credential does not satisfy this.

It produces a receipt that outlives the system. The result is an Ed25519-signed record that verifies against a published key with no callback to anyone. An auditor in three years, an insurer during a claim, or a court can check it without asking the vendor whether their logs are trustworthy. That last property is what makes it evidence rather than telemetry, and it is the difference explored in your evidence is a log you wrote yourself.

How big is this problem, honestly?

The FBI's Internet Crime Complaint Center recorded approximately 20.9 billion dollars in reported losses across more than a million complaints in its 2025 report. Business email compromise alone accounted for about 3.05 billion dollars across 24,768 complaints, with the large majority of that money moving by wire or ACH. Deepfake-enabled fraud, tracked separately in compiled figures, added materially to that, and a single deepfaked video call was reported to have moved roughly 25.5 million dollars in the widely covered Arup case.

It would be easy to put the 20.9 billion figure at the top of this page and imply a signature addresses it. In the 20.9 billion dollar re-read we instead score every published category against one question: would a fresh, action-bound human signature have deterministically prevented this loss? Categories where an attacker acted as someone else score high. Categories where the victim knowingly authorised the payment, including most investment and romance fraud, score at or near zero.

The addressable share is a fraction of the headline. It is still measured in billions, and it is concentrated in exactly the categories where the current control set is most obviously failing. Anyone quoting the full total at you as an addressable market is either not paying attention or hoping you are not.

A second observation concerns defensive spending. The response to every category above has been to buy better estimation: deepfake detectors, behavioural analytics, device reputation, anomaly scoring. Those tools improve and the outcomes do not, because the generator improves faster than the classifier and the attacker gets unlimited attempts with feedback. The evidence, largely from the detection vendors' own public statements, is in detection debt, the meta-failure catalogued as IFM-14.

The map

Every sub-problem in this area, what the current control actually establishes, what it misses, and where to read further.

Where does the money actually leave?

If you are building a control programme, stop thinking about payments and start thinking about the operations that determine where a payment goes. Fraud teams guard the transfer. Attackers change the destination and let the company send the money itself.

The master data change is the attack

In vendor email compromise the fraudulent act is not the payment, which is legitimate and correctly approved. It is the edit to the vendor master file eleven days earlier. The same shape appears in payroll diversion, where the attack is a routing and account edit in a self-service HR portal with the confirmation email suppressed by a mailbox rule.

Public bodies have a structural version private companies do not: transparency obligations publish vendor names, contract values and payment schedules, so an attacker learns who to impersonate and for how much without compromising anything. That asymmetry is public bodies publish their vendor lists.

Healthcare has its own variant, where the enrolment record that tells a payer where to send electronic funds transfers becomes the target, and the provider's reconciliation lag means the diversion can run for weeks before anyone notices. That is provider EFT diversion.

Account-shape changes deserve more protection than payments

Generalise and you get a category most institutions have never named: operations that change what an account can do or where its value can go. Adding a payee, whitelisting a withdrawal address, linking an external account, changing a notification address, enrolling an authenticator. Each is filed under settings, while the transfer that follows gets the fraud model's full attention. The payee add is the real transaction makes the case for inverting that.

Fiduciary money raises the stakes without changing the mechanism

When money is held for someone else the same attack produces a far worse outcome. A firm that loses client funds faces professional discipline as well as loss, and in many jurisdictions must make the client whole regardless of fault. Identical mechanism, different consequence, which is why the client trust account gets its own treatment, as does real estate wire fraud, where the victim is a family wiring a down payment.

Why do approvals fail even when there are two approvers?

Because approvals in most workflows are clicks inside browser sessions, and independence is a property people assume rather than verify.

Correlated failure in maker-checker controls

Dual authorisation rests on the premise that two approvals are two independent events. If both approvals are session-based, and a single phishing kit harvests both sessions, the control has collapsed to one, and the audit trail records two green ticks. Two locks on the same door, opened with the same stolen key. Dual control is not dual when both approvers are behind the same phishing kit works through what independence means as a security property and how a signature restores it: two assertions, from two separate enrolled devices, over the same payload hash. Two stolen sessions produce zero valid signatures.

Mailbox-grade approval

Enterprise workflow tools ship email reply approval and chat reaction approval as features, because they are convenient and because approvers live in those tools. The consequence is that the approval inherits the security of the channel, which is IFM-02, Mailbox-Grade Approval. A thumbs-up emoji is a statement about who had a Slack session, not about who read the invoice. Reply APPROVE is not an approval, it is a mailbox proof names the category and shows the drop-in fix, which is that the chat message becomes the notification and the signature becomes the approval.

The callback is a control with four failure modes

Verbal verification is the most universally recommended control in payments fraud, appearing in title guidance, bank advice, insurer requirements and audit checklists. Its four failure modes are all now cheap: the number often comes from the attacker-controlled thread, caller ID is spoofable, voice is cheap to clone, and the call happens under time pressure by someone whose job is to complete the transaction. Call to verify, the number came from the fraud gives the teardown and an upgrade path.

What about the screen you are signing on?

There is a failure mode that survives even a perfect per-action signature, and it is worth taking seriously before we claim too much.

On 21 February 2025, roughly 1.5 billion dollars left the Bybit exchange in what public post-mortems describe as a compromise of a developer machine leading to injected JavaScript in a signing interface. The signers were shown what appeared to be a routine transfer. What they actually authorised was a change to the multisig contract. Three humans signed it, and by all accounts had no realistic way to detect the substitution.

That is IFM-03, Display-Signer Fusion: the component that renders the transaction and the component that holds the key share a compromise domain. A signature is only as meaningful as the accuracy of what the signer was shown. The remedy is to separate those domains, rendering the canonical payload independently on a companion device, and signing the canonical bytes rather than whatever the desktop claims they are. Bybit's signers signed what the screen showed covers the canonicalisation problem in detail, and it generalises well beyond crypto, to wire release screens, treasury portals and admin consoles.

Who can act when the account holder is not looking?

A large class of losses involves nobody stealing anything at all. Someone with legitimate access acts, or someone acts on an account whose owner is not paying attention.

The authorised employee problem

Every consumer platform, exchange, bank and telco runs a support function with power to change account details and read customer data, staffed at scale and frequently outsourced. That power is purchasable, and it has been purchased. The important distinction, developed in when support staff can be bought, is between the insider who reads data, which access control and minimisation address, and the insider who acts on an account, which access control cannot address because the insider genuinely has the access. For the second class the only control that survives is one where the customer holds a key the employee does not.

Emergency access that nobody reviews

Break-glass paths exist because the alternative is worse, and are controlled by after-the-fact review. Those reviews are voluminous, a log line rarely distinguishes a legitimate emergency from an illegitimate one, and challenging a clinician or senior engineer is organisationally expensive. Break-glass access is logged, reviewed later, and rarely questioned argues for keeping the path fast and changing what it produces: a signature with a stated reason.

Accounts with more than one human behind them

Shared credentials are everywhere: small business banking, retail point of sale, clinical workstations, on-call rotations, agencies managing client accounts. When something goes wrong the log names an account and the investigation becomes interviews. The audit log says admin, which human was that? argues you need not eliminate the shared account, only attribute the actions that matter.

Accounts with nobody behind them

Dormant accounts are attractive because they are quiet: an old email account still serving as recovery for newer ones, a lapsed brokerage account with a balance, a registrar account controlling live DNS. The takeover generates no complaint and appears in none of the statistics that drive budgets. The safest account to steal is one nobody has opened in four years ranks dormancy risk by what an account unlocks rather than what it holds.

Volume as its own authorisation question

One more: a credential that runs one query runs the query that returns everything. Authentication and volume are different questions and almost no system separates them, which is how a credential-theft campaign becomes a hundred million records. The credential was valid, the export was 100 million records argues for classifying egress by blast radius.

What proof of human intent does not solve

This section matters most, because a control sold beyond its evidence is worse than no control: it produces confidence without protection, and makes the next honest claim harder to believe.

It does not stop a person who means to send the money

The largest single category of consumer payment loss is authorised push payment fraud, where the victim is deceived into genuinely intending the transfer. They are not confused about who they are paying, they are confused about who that person is. Investment fraud, romance fraud and the hybrid commonly called pig butchering all have this shape, and in the FBI's reporting they represent a very large share of the total.

A signature does nothing here. The victim will sign. They will pass liveness, they will read the amount, they will confirm the beneficiary, and the money will go. Anyone who tells you otherwise is selling something. What changes under a mandatory reimbursement regime is not prevention but allocation, and there the artifact matters for a different reason: it records what the customer was shown and confirmed, which is materially better evidence for both sides than a firm's own logs of warnings it says it displayed. When the bank must refund the scam works through that argument and is careful to keep it symmetric.

The one place a signature does move the outcome in this category is when the design adds a second person rather than a second factor. An opt-in rule where transfers above a threshold or to a new payee require a designated trusted contact to co-sign inserts a human who is not inside the deception. A second signature is cheaper than a conservatorship covers the design, including the dignity and abuse questions that any such rule has to answer, and it is honest that adoption depends on banks shipping it.

It does not check that the destination is who the payer thinks

Name-checking services answer a genuinely useful and completely different question: will this payment arrive where the payer said it should. That catches misdirected payments and some impersonation. It cannot catch the case where the payer has been convinced to name the wrong party, and a mule account titled to match will return a clean result and increase the victim's confidence. Confirmation of Payee checks the name on the account, it cannot check the name in your head is the fuller treatment, and it is worth reading alongside this page precisely because the two controls fail in different directions and neither is a cure for persuasion.

It does not audit judgment

A signature binds intent. It does not evaluate whether the intent was sensible. An approver who signs without reading has produced a perfectly valid proof of a decision they did not really make. This is a real limit and it is not fixable with cryptography. What the receipt does change is accountability: the decision now has a name attached to it, produced by a deliberate act, which is a different governance position from a click in a shared session.

It does not survive a compromised signing device

If the approver's phone is fully controlled by an attacker, the attacker can produce signatures. Device binding raises the cost from "steal a cookie" to "compromise this person's hardware and defeat its biometric gate," which is a large increase and not infinity.

It does not work without a trustworthy first enrolment

Every property on this page rests on the binding between a human and a key having been established correctly once. An attacker who controls onboarding controls the key, and no amount of downstream signing repairs that. Enrolment is the trust bottleneck for the entire model and should be treated as the highest-assurance moment in the lifecycle, not a checkbox at the end of an HR workflow.

It adds friction, and friction has to be spent deliberately

Every gated action costs the honest user seconds and costs the organisation some rate of abandoned or delayed legitimate work. Gate everything and people route around you, which produces worse security than gating nothing because now the workaround is undocumented. The entire art is choosing the small set of actions where irreversibility and value justify the cost.

Where do the published standards sit?

None of this is a proposal to replace the identity stack. The mechanism described here composes with the standards already deployed, and it is worth being precise and generous about what each one establishes.

WebAuthn and passkeys solved credential phishing at the login handshake, which is a genuine and large achievement. The specification family has always contemplated binding an assertion to transaction context, and that capability did not survive into broad deployment, so what shipped everywhere authenticates a session start. A per-action assertion is not a competing technology, it is the same primitive invoked at a different moment, which is why any relying party already running passkeys can adopt it without changing authenticators. Passkeys prove you logged in, who signed the wire? covers the cryptographic difference between signing a random challenge and signing a challenge derived from a payload hash.

PSD2 dynamic linking, required under the European regulatory technical standards on strong customer authentication, is the one place regulation forced the correct property: the authentication code must be linked to the specific amount and payee, and any change must invalidate it. It is worth noticing that the industry already knows how to do this, has implemented it at scale, and does it only where compelled. That observation recurs across the standards series.

EMV 3-D Secure shifts liability on the basis of an issuer risk decision or a challenge that authenticates a cardholder session. It establishes something real about the transaction context and does not bind a human to this specific purchase in a way that survives session theft or an agent acting on the cardholder's behalf.

Confirmation of Payee and equivalent verification-of-payee obligations establish that the account name matches, which is orthogonal to intent and useful for a different failure.

NIST SP 800-63B gives the vocabulary for authenticator assurance and phishing resistance, and is the reason SMS has been discouraged for years. It describes how strongly you established a principal, not whether that principal formed an intent.

Read as a group they tell one story: each standard authenticates a layer, and the fraud has moved to the layer above it. Composition, not replacement.

What to do this quarter

A practical sequence for an organisation that wants to close this gap without boiling the ocean.

1. Inventory your account-shape changes. List every operation that changes where value can go or who can act: payee adds, bank detail edits, authenticator enrolment, notification address changes, withdrawal whitelists, delegate additions. Most organisations have never written this list down.
2. Rank by irreversibility, not by value. A reversible six-figure transfer is a lesser problem than an irreversible four-figure one. Irreversibility is what makes detection useless after the fact.
3. Find every approval that is a click in a session. Email replies, chat reactions, push taps, workflow buttons. Each is a Mailbox-Grade Approval until proven otherwise.
4. Pick three actions and gate those only. Vendor bank changes, payment release above a threshold, and authenticator enrolment is a defensible starting three for most finance organisations.
5. Enrol the approvers before you need them. At least two authenticators per approver, so "my phone broke" never becomes "so we skipped the control."
6. Write down what the receipt is for. Decide in advance who will verify it, in what circumstances: the auditor, the insurer, the bank during a recall attempt, the dispute process.
7. Measure the friction honestly. Track the added seconds and the abandonment rate. If a gate is costing more than the loss it prevents, remove it and say so.
8. Re-run the exercise for your agents. Anything an autonomous system can trigger belongs in the same inventory, which is the subject of the companion pillar on human-agent delegation.

If you want to see the mechanism before designing around it, the signing demo shows the payload, the assertion and the resulting receipt end to finish in about thirty seconds, and the developer documentation covers the API surface.

Reading paths

If you are responsible for accounts payable or treasury

Start with vendor email compromise for the dominant loss shape, then the callback teardown because it is almost certainly your current control, then dual control is not dual to understand why your two-approver rule may be one approver, then mailbox-grade approvals, and finish with the payee add is the real transaction to reorder your control priorities.

If you are in identity or security engineering

Read session theft first for the mechanism, then passkeys and transaction binding for the cryptographic distinction, then authenticator enrolment as a takeover primitive, then display-signer separation for the case a signature alone does not cover, and finish with volume as an authorisation question.

If you build consumer or retail banking products

Begin with mandatory reimbursement and proof of intent to understand where the liability is heading, then Confirmation of Payee for what name-checking does and does not do, then the trusted second signer as the one design that moves the needle on persuaded victims, then the case against SMS for authorisation, and dormant account risk for the quiet part of your book.

If you are writing policy or standards

Read the wedge-fit analysis for an honest account of what is and is not addressable, then detection debt for why current spending is not producing outcomes, then the Identity Failure Map for the vocabulary, then the authorised insider problem, which is the case where organisational controls structurally cannot help.

Frequently asked questions

What is proof of human intent? It is a cryptographic signature produced on a specific person's enrolled device over the exact details of one action, such as the amount, the recipient and the account of a payment. Unlike authentication, which establishes identity once per session, it proves that a particular human agreed to a particular operation at a particular moment, and it produces a receipt a third party can verify without trusting anyone's logs.

How is this different from multi-factor authentication? Multi-factor authentication makes it harder to start a session. It does nothing about what happens afterwards, because every subsequent action inherits the session's authority. An adversary-in-the-middle kit lets a victim complete a genuine multi-factor login and then steals the resulting session. A per-action signature does not inherit from the session, so a stolen session produces no valid approvals.

Does this stop scams where the victim sends the money themselves? No, and it is important to be clear about that. If a person is deceived into genuinely intending a payment, they will sign it. What a signature changes in that category is the quality of evidence for reimbursement decisions, and a co-signature rule can insert a second person who is outside the deception. Prevention comes from disruption and education, not from cryptography.

Do we have to gate every action? No, and you should not. Every gate costs the honest user time and produces some rate of abandoned legitimate work. The discipline is to gate the small set of operations that are irreversible and consequential, typically master data changes, payment release above a threshold, and authenticator enrolment, and to leave everything else alone.

What happens when an approver loses their phone? This is the most common operational objection and it is answered by enrolment policy rather than by the signing mechanism. Enrol at least two authenticators per approver, and design a recovery path that re-establishes continuity rather than restarting identity from documents. A control that is routinely bypassed because someone lost a device is not a control.

Does the receipt work if the vendor disappears? Yes, which is the point of offline verification. The receipt is an Ed25519 signature that verifies against a published key with no callback to any service. An auditor, an insurer or a court can check it years later without asking anyone whether their logs are accurate, which is what separates evidence from telemetry.

Where should an organisation start? Write down every operation that changes where value can go or who can act, rank them by irreversibility rather than by dollar value, then pick three to gate. For most finance organisations the defensible first three are vendor bank detail changes, payment release above a threshold, and authenticator enrolment.

Sources

1. Federal Bureau of Investigation, Internet Crime Complaint Center, annual Internet Crime Report series, for reported loss totals and complaint counts including business email compromise: ic3.gov annual reports
2. Microsoft Security, research and disruption reporting on adversary-in-the-middle phishing-as-a-service and device code phishing campaigns: microsoft.com security blog
3. W3C, Web Authentication specification, for assertion structure, challenge handling and user verification: w3.org WebAuthn
4. European Banking Authority, regulatory technical standards on strong customer authentication and common and secure communication, for the dynamic linking requirement: eba.europa.eu
5. National Institute of Standards and Technology, SP 800-63B Digital Identity Guidelines, for authenticator assurance levels and restricted authenticators: pages.nist.gov 800-63B
6. Public post-mortem analysis of the February 2025 Bybit incident, including BlockSec and other security research firms, for the signing interface compromise: blocksec.com blog
7. Payment Systems Regulator, published material on the authorised push payment reimbursement requirement: psr.org.uk
8. EMVCo, 3-D Secure specification materials, for the risk-based and challenge authentication flows: emvco.com

Authentication asks who is holding the session. The only question that matters when money moves is who decided, and that has a different answer, a different artifact, and a different failure mode.