What changed
FACT (cited): Hong Kong's SFC ordered crypto platforms and online brokers to implement phishing-resistant login within 12 months. FACT (cited): computer-use agents became cheap (Gemini 3.5 Flash computer use) and long-running (ChatGPT agent work). HYPOTHESIS: the combination silently breaks browser-agent access to trading accounts once passkeys are enforced.
Why now
The 12-month SFC compliance clock is dateable and started now; Flash-tier computer use only became economically viable this quarter. The collision window is real. However, 'why now' for the PLATFORM to buy an agent-access layer is much weaker than 'why now' for passkey adoption itself — the mandate compels the login change, not agent accommodation.
Converging signals
(1) SFC phishing-resistant login mandate, 12-month deadline (regulation). (2) Gemini 3.5 Flash computer use — cheap browser automation (ai). (3) Long-running ChatGPT agents doing multi-hour work (ai). The regulatory signal is a genuine forced action; the two AI signals establish the breakage mechanism but not buyer demand for this specific fix.
Customer pain
HYPOTHESIS, uncited: platforms fear churn from algorithmic/agentic retail traders when passkeys kill scripted browser logins. No complaint, hiring, or spend evidence was provided (demand_evidence is EMPTY). Critically, the pain may be largely illusory for the named buyer: virtually every licensed crypto exchange already offers API keys with scoped permissions (trade-only, IP allowlists, withdrawal bans) — the standard, existing answer to 'let a bot trade without my login credentials.' Browser agents locked out by passkeys can be redirected to the exchange's existing API. The unserved gap is only venues with NO trading API, and users too unsophisticated to use one — a thin sliver.
Who pays
Claimed buyer: HK SFC-licensed crypto platforms and brokers (compliance budgets). This is a regulated-financial-institution sale of security-critical authentication infrastructure — vendor due diligence, security audits, possibly SFC scrutiny of the vendor itself. That is enterprise procurement in everything but name, in a foreign jurisdiction where the founder has no presence, license familiarity, or network. Secondary buyer (agent-tool vendors) has no compliance budget and no deadline.
Solved today
Exchange API keys with granular permission scopes (industry standard for a decade); OAuth 2.0 token delegation; enterprise session-management vendors; passkey/FIDO2 platform vendors (Transmit Security, Descope, Corbado, Auth0) who are natural one-feature-away incumbents for 'delegated agent sessions.'
Why current solutions are bad
For API-equipped exchanges, current solutions are NOT bad — scoped API keys already deliver constrained agent access with audit trails. The genuine gap is brokers whose only interface is a web UI. But those brokers' agentic-user base is speculative and unquantified here.
Proposed product
Platform-side SDK/gateway: passkey-holder authenticates, then mints time-boxed, scope-limited delegated tokens for agent sessions (trade caps, withdrawal bans, full audit log), packaged as compliance-friendly middleware for HK-licensed venues.
MVP version
Reference implementation: FIDO2 relying-party flow + OAuth-style token minting service + policy engine (limits/bans) + audit log, with a demo trading sandbox showing an agent operating under a delegated token. Buildable solo in 60-90 days with founder's capital.
30-day build
Validate the kill question first: interview 10+ HK platform engineers/compliance officers (LinkedIn, HK fintech communities) asking specifically 'what will your agentic/scripted users do post-passkey, and is that your problem or theirs?' Simultaneously inventory the top 20 HK-licensed venues for existing API-key offerings — if >80% have scoped APIs, the wedge collapses.
60-day build
Only if validation survives: build the reference SDK + sandbox demo; publish a technical whitepaper on agent-safe passkey compliance to surface inbound interest.
90-day revenue plan
Realistically none. Regulated financial platforms do not integrate third-party authentication middleware from an unknown solo foreign vendor inside 90 days; 9-18 months of security review and trust-building is the norm. First revenue inside 180 days is implausible for the platform-side product.
Distribution path
Weakest link: no reachable channel. HK-licensed venues are a small, enumerable list (good) but are reached via compliance/security officers who buy from audited vendors (bad). Founder sells through demonstrated value, but demonstrated value in auth infrastructure requires exactly the trust artifacts (SOC2, pen-tests, references) that take longest to acquire.
Pricing hypothesis
Hypothetical: $2k-5k/mo platform license or per-delegated-session fees. Unvalidated — zero evidence of willingness to pay was provided.
Technical difficulty
Moderate — FIDO2/WebAuthn relying-party work, token service, and policy engine are well-trodden; solo-buildable. The hard part is not the code, it is being trusted to run it in a licensed venue's login path.
Legal / regulatory risk
High for the vendor: sitting in the authentication path of SFC-regulated platforms invites regulatory scrutiny; a delegation-layer bug enabling account takeover creates catastrophic liability. Also open question whether the SFC would view delegated agent tokens as undermining the very phishing-resistance it mandated.
Platform dependency
Depends on each venue's willingness to integrate; also on passkey/WebAuthn standards (stable) and agent frameworks (volatile).
Founder fit
POOR despite surface resemblance to his FMCSA ELDT win. The proven-edge lesson (government-portal mandates, confidence 0.80) does NOT apply: ELDT compels operators to FILE INTO a portal, so he built the filing rail and charged per transaction. Here the mandate compels platforms to change their OWN login; nobody is forced to buy agent access. The buyer is a regulated foreign financial institution purchasing security infrastructure — enterprise-procurement-only in practice, which the founder explicitly avoids. No fire-service/industrial/public-records leverage. The capital-and-runway lesson (0.90) softens the ramp objection but cannot fix an unreachable buyer.
Breakout potential
If agent-vs-passkey friction generalizes globally (plausible), the winning layer will be set by FIDO Alliance extensions, exchange incumbents, or auth vendors like Auth0/Descope — not a solo outsider. Upside exists but is not capturable by this founder.
Final recommendation
KILL for this founder. The convergence observation is genuinely sharp (passkeys are non-delegable by design; agents need delegation), but the monetizable wedge belongs to incumbents already inside the venues' auth stack. No demand evidence, no reachable buyer, existing substitute (scoped API keys), wrong sale type (regulated-institution security procurement), wrong jurisdiction. Revisit only if evidence emerges of platforms publicly struggling with agentic-user churn post-passkey, or if a US/global regulator issues a similar mandate touching a filing-shaped workflow.
Next action
Archive with a watch-trigger: monitor for (a) HK platform announcements about agent/API access changes tied to SFC compliance, and (b) any regulator mandating phishing-resistant auth where a REPORTING/FILING obligation (founder's proven shape) is also affected. Spend zero build dollars now.