Close over 50% of banking fraud deterministically. Add a signal on the rest. Ready for what comes next.
Social engineering is the headline loss of 2025. Agent-initiated action is the headline loss of 2027. Yuthent is issuer-side authorization infrastructure for both — every sensitive action signed fresh, on the cardholder's device, by a hardware-bound key tied to a physically verified identity, with no recovery through SMS, email, or passwords. The unauthorized-fraud category closes deterministically today. On the authorized-payment category, your fraud stack gets a binary field it has never had before: human_verified = true | false. On the agent category that every fraud model is about to degrade against, that field is the only control that still holds.
Per UK Finance H1 2025, £372M of the £629.3M UK banking fraud total sits in the unauthorized category — account takeover, session hijack, remote-access trojans, SIM swap, credential theft, card-not-present fraud, and stolen cards used with a known PIN. Every one of these attacks succeeds because the authentication primitive in production today cannot answer a single question: is the specific human who owns this account physically present on their bound device at the moment this action was authorized? Session tokens, OTPs, and push approvals cannot answer it. They confirm that a credential was present, not that a person was.
The authorized-payment category — £257.5M in the same report — is a different problem and Yuthent is explicit about it. Investment, romance, purchase, and advance-fee scams rely on the victim themselves authorizing the transfer with their legitimate biometric. No cryptographic primitive stops that. What Yuthent does inside that category is narrower and honest: for impersonation under pressure, invoice and mandate changes, and CEO fraud above threshold, we add a deterministic field to your fraud stack and enforce a second-signer flow. That is signal, not solution, and we say so.
The category the industry has not yet priced is coming faster than the budget cycle. Agent-initiated actions — autonomous systems executing on behalf of users, third-party agents with delegated API scope, prompt-injected LLM workflows that read an email and transfer a sum — produce no device fingerprint, no behavioral pattern, no velocity anomaly. Every fraud model in production is trained on human-behavior signals. Every one of them degrades the moment agents execute at scale. BaFin, the ECB, and the FSB have already flagged agentic-system risk; the EU AI Act Article 14 requires 'meaningful human oversight' on high-risk AI in financial services, and a logged click is not oversight. The only control that survives this shift is a fresh biometric signature from a physically identified human on a hardware-bound device. Yuthent ships that primitive today, and it is the same primitive that closes the unauthorized-fraud category — not a second product, not a second integration, not a second contract.
One primitive. Two commitments the industry has not made.
First commitment: per-action signing, not session trust. Every action tiered E or A produces a fresh cryptographic signature at the moment of approval. The private key lives in StrongBox on Android and the Secure Enclave on iOS — it is non-exportable and generated on-device at enrollment. The biometric check is delegated to the OS (BiometricPrompt, LAContext), not to custom models. Amount, payee, action identifier, and the full canonical payload are hashed into the signature. A mutated parameter post-approval breaks the proof. A session cookie, a stolen OTP, a hijacked cookie jar — none of them produce a Yuthent-valid signature without the human present.
Second commitment: no recovery path through weak credentials. Every competing system — FIDO2 passkeys, Visa Payment Passkey, Mastercard TAS, Okta, Microsoft Entra — has a fallback that downgrades to SMS, email, security questions, or a password reset. The passkey becomes theatre; the recovery channel is the real trust anchor. Yuthent rejects this model. If a cardholder replaces a device, re-binding requires the same physical identification strength as the original enrollment: document, face, liveness. The device is replaceable; the identity verification is not. Visa and Mastercard cannot match this without absorbing a UX change they are structurally unable to impose on their install base.
The two together produce a clean split. Unauthorized-fraud categories close deterministically — the attacker cannot produce the signature, and the recovery path cannot be exploited. For the authorized-payment categories Yuthent does not claim to solve, the fraud stack receives a signed proof-of-action event as a binary field. Actimize, Featurespace, Sardine, Feedzai, or an internal model — whichever is in production — keeps scoring. What changes is that one dimension of uncertainty (was it this human?) becomes a known, deterministic input. False positives drop. Edge cases that required identity challenge become resolvable in-band.
Seven scenarios issuers pay for. Where the defense actually lives.
Account Takeover (ATO) of the banking app
The pattern
Attacker obtains credentials through phishing, reuse from a third-party breach, or malware. Logs into the banking app from an attacker-controlled device or an attacker-held session. Initiates wire, payment, or internal transfer.
Why current defenses fail
Every control that re-validates the session (cookie, JWT, refresh token) passes. SMS and email OTP are attacker-controlled or intercepted. Device fingerprinting flags the new device but issuers default to soft-block with an OTP step-up that has already been defeated.
What Yuthent does
The E/A-tier action requires a fresh biometric signature from the key bound to the cardholder's original device. The attacker's session produces no signature. The action never reaches business logic. There is no OTP to steal.
Hardware-bound ES256 key (StrongBox / Secure Enclave) · per-device per-tier monotonic counter · attestation with nonce binding
Remote Access Trojan on a legitimate device
The pattern
Malware or a coerced-install remote-control app runs on the cardholder's own device. The attacker drives the banking app in real time, with the legitimate session, from the legitimate device.
Why current defenses fail
Device identity, geolocation, IP, and cookie all check out. Behavioral signals degrade but do not block deterministically. OTP sent to the same device is captured in real time.
What Yuthent does
The Authoritative tier requires a fresh biometric press. The RAT cannot synthesize the biometric — the matching is handled by the OS inside trusted hardware, with the result signed by a non-exportable key. Caller attribution is bound to the specific unlock event. A presented scenario without the genuine user fails at the key.
Fresh-biometric requirement per A-tier action · OS-handled matching (BiometricPrompt / LAContext) · no custom ML in the authentication path
SIM swap and number-port fraud
The pattern
Attacker ports the cardholder's phone number to an attacker-controlled SIM. Receives every SMS OTP. Completes password reset, enrolls a new device, or authorizes payment through SMS 2FA.
Why current defenses fail
Any control whose recovery path terminates at a phone number is defeated at the moment of port.
What Yuthent does
The trust anchor is not a phone number. It is a hardware-bound keypair tied to the specific biometric enrollment on the original device. A new SIM does not migrate the key. Re-binding a device requires re-identification, not an SMS recovery code.
Identity binding on device secure element · re-enrollment requires fresh KYC · no SMS-based recovery path
Credential stuffing and password reuse
The pattern
Credentials leaked in a third-party breach are replayed against the bank's login endpoint or a downstream corporate system (SAP, treasury, admin console) that still accepts password or OTP.
Why current defenses fail
Breached-credential detection and rate limiting reduce the surface but do not eliminate it. MFA via SMS or TOTP is phishable and portable.
What Yuthent does
Sensitive-tier actions refuse to sign without a fresh biometric on the enrolled device. Knowing the password is insufficient. Replaying a captured OTP is insufficient. The attacker is not physically present on the device, and the key refuses to produce a signature.
Per-action biometric · hardware-bound key · no shared secret in the verification path
Insider denial and privileged-user disputes
The pattern
An employee with legitimate access to an admin console, payment batch system, or treasury dashboard executes a high-value action. Under investigation, the individual asserts that someone else used their session — a claim the bank cannot falsify from session logs alone.
Why current defenses fail
Session-based audit trails prove that a credential was active. They do not prove which human authorized a specific action inside that session.
What Yuthent does
Every A-tier action carries a cryptographic proof bound to the specific biometric press on the specific device. Dispute investigation terminates at the proof, not at a log entry. The 'it wasn't me' defense requires breaking the cryptographic chain — a different problem than challenging a session record.
Hash-chained action ledger · daily tenant anchors · BigQuery-exportable proof stream
Agent-initiated action without a human in the loop
The pattern
An autonomous system — internal automation, a third-party agent with delegated API access, or a prompt-injected LLM workflow — executes a high-value action on behalf of a user. No human reviewed the specific action at the specific moment.
Why current defenses fail
Every detection system trained on human-behavior signals degrades against agent traffic. OAuth-delegated API keys and service tokens carry broad scope. EU AI Act and emerging frameworks require 'meaningful human oversight,' but most implementations log a click, not a cryptographic act of consent.
What Yuthent does
The agent cannot produce a fresh biometric signature. Any action tiered E or A that the agent attempts to execute fails at the signing step. A deterministic answer — not a score — separates human-authorized actions from agent-initiated ones, in a form the EU AI Act and DORA examiner can accept as evidence.
Per-action biometric-bound signature · binary human_verified event to fraud stack · EU AI Act-aligned proof record
Impersonation under pressure (signal, not solution)
The pattern
A scammer persuades the cardholder directly — a call from a 'bank officer,' a romance scenario, an urgent 'invoice change' from a spoofed vendor. The cardholder authorizes the payment themselves.
Why current defenses fail
No authentication primitive — Yuthent included — can detect a sincere user freely authorizing a scam.
What Yuthent does
Yuthent does not claim to stop a victim from freely choosing. We do three things regulators and operators already require. Amount and payee are hashed into the signature (PSD2 SCA Dynamic Linking). A second-signer flow is enforceable for CEO-fraud and invoice-change categories above threshold. A signed event stream lets your fraud stack hold, reverse, or escalate in real time. This is the category where we are signal, not solution, and we say so.
Payload-bound signature · dual-signing policy hook · outbound webhook to Actimize / Featurespace / Sardine / internal ML
What the SDK and the backend produce on day one.
Per-action binding at the secure element
Amount, payee, action identifier, and the canonical payload are hashed into the ES256 signature at the moment of approval. Parameter mutation post-approval invalidates the payload hash. PSD2 SCA Dynamic Linking, executed at the device secure element, not at a server checkpoint.
Hardware-bound, non-exportable keys
EC P-256 keypair generated inside Android StrongBox or the iOS Secure Enclave. The private key never leaves trusted hardware. Re-binding to a new device requires fresh physical identification — there is no SMS or email recovery path that would downgrade the trust anchor.
OS-handled biometric, no custom ML
Biometric matching is delegated to BiometricPrompt on Android and LAContext on iOS. Yuthent ships no face-matching model of its own and stores no biometric template on any server. Under GDPR Article 9 no special-category biometric data is processed by Yuthent at all.
Replay-protected, fail-closed grace window
Per-device per-tier monotonic counters prevent replay. A 24-hour grace window allows E/A-tier actions offline with a hard upper bound before re-sync is required. After the window, actions are blocked until the device reaches the control plane.
Hash-chained action ledger
Every Authoritative action is chained to the prior action by the same cardholder. Daily tenant-wide anchors are committed to a 90-day hot store and archived to BigQuery. Altering one record invalidates every record after it. External Merkle commitment is on the roadmap.
Signal feed to your existing fraud stack
Outbound webhook stream of approvals, refusals, revocations, and trust-signal changes. Consumed directly by Actimize, Featurespace, Sardine, Feedzai, or an internal model as a binary human_verified field. Integration is bidirectional — your fraud engine can inject a verdict back at verification time without SDK changes.
The evidence each framework demands.
PSD2 SCA · Dynamic Linking (RTS Article 5)
Amount and payee are bound into the device-side signature. Two factors of independent categories — hardware-bound possession and biometric inherence — preserved end-to-end. Article-level mechanical mapping available under NDA during scoping.
DORA · Operational Resilience
Cryptographic evidence per action, tamper-evident hash-chained ledger, and exportable proof records aligned with DORA's operational and ICT-risk requirements. Continuity controls include proof-verification perpetuity: verification requires only the public key and the action payload, both of which can be held by the customer independently.
EU AI Act · Meaningful Human Oversight
Cryptographic proof that a specific physically identified human authorized a specific action — as opposed to a logged click inside an autonomous workflow. Positioned as the deterministic evidence layer for the Article 14 human-oversight obligations on high-risk AI systems operating in financial services.
Independent security validation (scheduled)
A gray-box penetration engagement is scheduled during pilot readiness with a 30-day retest on High-plus findings. Scope is shareable under NDA pre-engagement; findings are shareable with enterprise customers under NDA post-engagement.
Yuthent does not replace your fraud stack. Actimize, Featurespace, Sardine, Sift, Feedzai, and internal models keep scoring risk on the probabilistic signals they are designed for. What changes is that one dimension of uncertainty — was it this human? — becomes a deterministic binary field in real time. Integration is bidirectional: the webhook stream delivers human_verified events outbound, and the external-decision callback lets your fraud engine inject a verdict back at verification time without SDK changes.
A design-partner pilot scopes one high-stakes flow — typically the wire channel or a privileged internal action — in staging, with an agreed KPI and an executive-level authority-gap report at conclusion. Integration ships on Android first, with iOS parity available. The control plane is live from day one. First technical call within five business days of NDA. One question to sit with before that call: when half of your transaction volume is initiated by agents — your customers' agents, third-party agents with delegated scope, internal automations — what do you want your proof-of-human to look like, and who produces it?
Start an enterprise pilot.
Tell us the flow you want to protect. We will come back with a working integration proposal. Founder reads every request. First call within five business days.