Bound to the payee.
Bound to the amount.
Strong customer authentication proves someone got in. It does not prove this person agreed to send this amount to this recipient. Yuthent produces a signature over the payment itself, from a live human on a device you enrolled, that still verifies when the dispute arrives.
Authenticating the payer is not the same as authorizing the payment.
The customer authenticated. The customer also lost the money.
A payer under social-engineering pressure completes every authentication step correctly, because they are being coached through them in real time. Or an adversary-in-the-middle kit relays a one-time code inside its validity window while substituting the destination account. In both cases the authentication record is clean and the payment is fraudulent, and the bank has nothing that distinguishes this from a genuine instruction.
OTP and SMS codes
A code proves channel possession for a few minutes. Relay kits forward it inside the window, and a coached victim reads it aloud voluntarily.
Passkeys and FIDO2 at login
Phishing-resistant for the login ceremony, then a session token authorizes every payment after it with no further binding to any specific transaction.
Risk scoring and behavioural biometrics
Produces a probability, which is a signal and not an authorization. A score cannot be handed to a dispute process as proof of what the customer agreed to.
Transaction logs
Record what the system did. When the customer says they never authorized it, a log written by that same system is not independent evidence.
The signature is over the payment, not over the session.
Sits inside your existing payment flow as a verification step before submission.
Compose the instruction
Your backend defines payee, amount and currency. These become the signing payload, not decoration around a generic prompt.
Show it protected
The payer sees the payee and amount on a surface the calling application cannot overlay or alter, so what is displayed and what is signed are the same object.
Sign with a live biometric
Verification runs on-device in the Secure Enclave or StrongBox. A non-exportable key signs the instruction. There is nothing for a relay kit to forward.
Verify and chain
Your server verifies the signature against the enrolled key and the instruction it composed, then appends the proof to the hash-chained ledger for later retrieval.
Dynamic linking evidence, retrievable years later.
payee_hash
The destination account as shown to the payer. Substituting the beneficiary after signing invalidates the signature.
amount
The amount and currency signed for. An approval of one sum is not an approval of another.
display_hash
Hash of exactly what the payer was shown, bound into the same signature, satisfying the see-what-you-sign requirement rather than asserting it.
device_key_id
The hardware-bound key of the enrolled payer. Cannot be exported, cannot be used remotely, invalidated by the platform on biometric re-enrollment.
signed_at
The moment of authorization, inside a bounded challenge window, so a captured signature cannot be replayed against a later instruction.
Where the evidence gap costs money.
High-value transfers
The payments where reimbursement liability, not detection rate, is the number that hurts.
New payee setup
The step scam flows always pass through. Proof here binds the customer to the beneficiary they actually added.
Agent-initiated payments
When an automated agent composes the instruction, the human signature is what separates an authorized purchase from an unbounded one.
Answered plainly.
Does this stop authorized push payment scams?
No, and any vendor claiming otherwise is overselling. A coached victim can be persuaded to press. What changes is the evidence: you can show precisely what the customer was displayed and what they signed, which is what a reimbursement determination turns on, and you can require the top tier on the specific patterns scams travel through.
How does this satisfy PSD2 Article 97?
Article 97(2) requires the authentication code to be dynamically linked to the amount and the payee. Here the signature is computed over both, plus a hash of what the payer was shown, and is independently verifiable against the enrolled public key. The binding is cryptographic rather than procedural.
What about customers without a supported device?
Tiering and fallback are policy decisions you keep. The proof records which path was taken, so a lower-assurance route is visible as such in the evidence rather than silently indistinguishable from a full one.
Does this replace our fraud engine?
No. It sits alongside it and answers a different question. Your fraud engine estimates whether a payment is likely fraudulent. This establishes what the customer actually authorized. Scores route decisions; proofs settle disputes.
Put it on one flow first.
Tell us the action you need proof for. We come back with a working integration proposal and a signed sample you can verify yourself. First call within five business days.