A fraud prevention API that returns a hard signal, not another score.
Most fraud stacks score three or four async signals behind the decision, pushing p95 latency past 800ms at checkout and login. PasskeyBridge returns a signed device-plus-carrier attestation in one call, so you can pre-filter the clean traffic and reserve the heavy signals for the residual tail.
- One REST call, signed and replayable for audit.
- Catches credential replay where device fingerprint and OTP both pass.
- Sits before Sift, Forter, Sardine, Alloy—no rip and replace.
- BYOK, zero PII stored, hashed identifiers only.
The gap in most fraud stacks
Device fingerprinting is a probabilistic score. Carrier signals from most vendors are a one-shot lookup at signup that goes stale within days. OTP is a challenge to the same channel an attacker already controls. When those three pass and the transaction still results in a chargeback, the pattern is almost always the same: the credential and the device both look clean, but they have just changed hands.
A pre-decision hard signal about the current binding between the human, the device, and the carrier line closes that specific gap. That is what this API returns.
What the signal actually contains
A single response gives you a signed attestation with three independently verifiable claims: the device holds a specific hardware-bound FIDO2 passkey and just proved it, the passkey binding to a carrier line has not been re-established recently (SIM swap with its age in hours, and porting, both checked live), and the request itself is DPoP-bound so replay outside the current session fails.
Every attestation is dual-signed with a classical scheme plus ML-DSA-65, JCS-canonicalised. You can store it, replay it into a rules engine days later, and it will still verify.
- Edge latency published live at /developers/playground.
- Single signed JSON payload, no SDK required beyond a 12 KB browser helper.
- Available as a step in a Sift/Forter/Sardine/Alloy workflow or standalone.
Where it fits in the stack
Most fraud teams wire this in as a pre-filter: clean signal skips the heavy async checks, ambiguous signal fans out to the existing engine, hard-fail signal blocks before the KYC or IDV credit is burned. The design goal is a meaningful cut in vendor spend on the clean-traffic path plus a lower p95 decision latency; the exact lift depends on baseline traffic mix and current vendor cost.
It is also usable inside recovery flows and high-value transaction gates as a standalone step, where the carrier-state check catches the overnight SIM-swap window that batch data pipelines miss entirely.
The PasskeyBridge approach
Hard signal, not another score
Returns a signed attestation you can trust as a binary input to your rules engine, not a probability you have to tune against 90 days of chargeback data.
See the OpenAPI spec →Carrier state, live
Every call checks the live SIM swap state, its age in hours, and porting on the carrier line tied to the account, not a value cached at signup. A recycled number reaches the platform as a signal type a tenant posts, not as a per-call check.
Carrier signal architecture →Replayable audit trail
Every attestation is signed classical plus ML-DSA-65 and JCS-canonicalised. Store it and re-verify it years later without re-hitting the API.
Post-quantum posture →We are not a fraud decision engine
PasskeyBridge does not score sessions, learn from chargeback labels, or tell you whether a transaction is fraud. It returns one specific, cryptographically verifiable signal about the human-device-carrier binding at request time. Your existing fraud engine (Sift, Forter, Sardine, Alloy, or an in-house model) consumes the signal alongside everything else it already looks at. If you are shopping for a decision engine, we complement rather than replace. If you are shopping for a hard input to feed it, this is what that looks like.
Frequently asked
- How do we integrate this without ripping out Sift/Forter/Sardine/Alloy?
- You add one REST call in front of the existing decision step and consume the signed attestation as a rule input. Most teams start with recovery flows or high-value transactions where the signal has the largest measured impact, then expand to login and checkout once the operational data proves out.
- What does 'zero PII stored' actually mean in practice?
- Phone numbers, email and IP addresses, and subject identifiers are hashed at the edge with keyed HMAC-SHA-256 under a server-held pepper before they touch storage. Cross-signal matching still works because the digest is deterministic; reading a stored identifier back to a person is not possible, because the pepper never leaves our servers.
- How does it hold up against agent and bot impersonation?
- LLM-driven session automation still fails the hardware-bound passkey check because there is no way to script a proof-of-presence from a hardware authenticator without physical access. Combined with the carrier-line binding, agent-driven onboarding and takeover attempts fail before they reach your IDV vendor.
- Is the signal available in server-to-server flows without a browser?
- Yes. The browser helper is only required to source the passkey assertion from the end user's device. Server-side flows (IVR routing, API-only account recovery, agent-desktop verification) call the REST endpoint directly with the stored binding and get the same signed attestation minus the fresh passkey assertion.
- How is this different from a device fingerprinting SDK?
- A device fingerprint is a probabilistic identifier. This is a cryptographic proof-of-possession plus a live carrier-state check, signed as evidence. Fingerprinting says 'this device looks like it did last time.' PasskeyBridge says 'this device holds this specific hardware-bound key right now, and its carrier binding has not moved.'
Guides for this
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production. No demo booking required.