Use cases
A Chief Risk Officer does not buy a QR code. They buy a control point: before a consequential action moves forward, prove that a real carried phone, verified subject, carrier relationship, and coherent human day stand behind it.
The risk question
KYC, document checks, passwords, OTP, push approvals, device fingerprints, and bureau files can all validate something useful. They still leave the institution exposed when the thing validated is portable, stolen, relayed, synthetic, or true only at one point in time.
Pulse moves the proof from the browser to the carried phone, then makes the customer’s server verify the result before the action is accepted.
Current stack
A file, document, code, face image, device fingerprint, or login event can look legitimate while the protected action is still controlled by the wrong party or backed by a fabricated life.
Pulse control
Pulse asks whether the applicant’s carried phone can produce a bounded, server-verifiable proof for this form submit, transfer, recovery, claim, onboarding, or admin action.
Where to deploy
The first deployment sits at the moment fraud becomes expensive, not at every login. Pulse belongs before the action that changes risk, moves money, grants access, creates a regulated record, or commits the institution to a consequential workflow.
Credit and lending
Protect credit applications, auto finance, personal loans, and dealership finance when the applicant is cold, thin-file, high-velocity, or expensive to manually review.
Risk question: Is there a real, coherent carried life behind this application before underwriting treats the file as a person?
Pulse answer: The form cannot proceed until the phone produces an action-bound bond and the customer’s server verifies the bonded session.
Deposit and account opening
Use Pulse when a new relationship clears static checks but the institution still needs confidence that the applicant is not a synthetic, mule, relay victim, or scripted submission.
Risk question: Is this a person with a carried-phone continuity pattern, or just a well-assembled record?
Pulse answer: The proof is bound to the phone, action, nonce, session state, and expiration window; screenshots and old challenges do not open accounts.
Account recovery
Use Pulse when passwords, email links, support scripts, and knowledge checks can be socially engineered or relayed by an attacker who is trying to make the honest user act as a confused deputy.
Risk question: Is the same carried device and subject present for this recovery, or is a legitimate person being tricked into proving the attacker’s session?
Pulse answer: The browser receives only a socket nudge; unlock still depends on an authoritative server fetch showing the session bonded.
Transfers and high-risk changes
Protect wires, payout changes, password resets, administrator actions, and step-up reviews where ordinary authentication is necessary but not enough.
Risk question: Is the verified person still present, on the same trusted device, with coherent continuity right now?
Pulse answer: Heartbeats keep the bond alive; silence, expiration, killed state, or invalid transition locks the workflow again.
CRO diligence
Pulse has to stand up to fraud, compliance, model risk, engineering, and examiner review. The product surface is small because the control plane behind it is explicit.
Can the browser fake it?
The trusted surface is the Pulse app. The server verifies session state, nonce, expiration, single-use challenge, device key, provider evidence, and valid state transition.
Can the socket unlock it?
A WebSocket event tells the browser to check again. The browser unlocks only after it fetches authoritative session state from the server and sees a bonded session.
Can an old QR work?
The QR carries a short-lived challenge, not a credential. Old screenshots fail because the nonce expires, the challenge rotates, and a consumed nonce cannot bond again.
What if the phone goes silent?
Bonded sessions require heartbeats. If the backend does not see the phone within the timeout window, the session moves to killed and the protected workflow locks.
What about privacy?
The institution receives the bounded result and review record needed for the action, not raw sensor data, raw location history, or a reusable private-data feed.
Who makes the decision?
Pulse informs clear, refer, stop, or step-up. The institution keeps credit policy, fraud policy, pricing, adverse action, manual review, and final decision authority.
Review record
The output is not a magic score and not a black box. Pulse gives the institution an action-bound proof result and supporting record: what action was protected, which session bonded, when the challenge was issued and consumed, what state transitions occurred, whether continuity held, and why the workflow cleared, stepped up, expired, or stopped.
Fraud ops
Fraud teams get a presence answer before a clean file, document package, or relayed approval becomes accepted risk.
Compliance
Compliance teams can see what was proven, what was not decided by Pulse, and why raw private history did not become a new institutional data burden.
Model risk
Pulse returns evidence for the protected action. It does not replace underwriting models, adverse-action policy, or human review.
FAQ
Where Pulse enters the workflow, what it proves, and what remains under institutional control.