Who belongs in a Pulse evaluation?

Risk, fraud, compliance, product, engineering, legal, and the action owner should review Pulse because it affects the customer step, the server check, and the review record.

What should the first Pulse deployment protect?

Start with one important action, such as application submit, account opening, account recovery, money movement, benefits claim, employment onboarding, or another moment where accepting the action accepts real risk.

What must the customer's server check?

The server must check the Pulse result before accepting the action. The browser, QR code, page update, and app handoff are not enough by themselves.

Does Pulse replace identity checks, fraud tools, or underwriting?

No. Pulse adds a phone-backed check before the action proceeds. The institution keeps identity checks, fraud policy, underwriting, pricing, notices, reviews, and final decision authority.

Evaluate Pulse

Evaluate the risky moment, not the widget.

Pulse is useful when it changes a real decision: the action waits for the applicant's phone, your server checks the result, and your team can explain what happened later.

Start here

Pick one action where a mistake is expensive.

Do not start with a generic page view or low-risk login. Start where a bad actor could create loss, get access, move money, change credentials, open a relationship, or push a regulated process forward.

Strong first action

Risk changes when the user clicks.

Application submit, account opening, recovery completion, wire approval, payout change, benefits claim, finance submission, onboarding, and admin privilege changes are strong starting points.

Weak first action

Nothing important happens yet.

Newsletter signup, marketing forms, generic page views, and actions already followed by a stronger server check are poor first deployments.

Evaluation team

Bring the people who will own the action after launch.

Risk and fraud

Name the attack.

Synthetic applications, tricked approvals, account takeover, mule onboarding, scripted submissions, or risky internal access.

Product

Choose the customer step.

Pick the exact button, submit, approval, recovery, transfer, or onboarding step where Pulse becomes required.

Legal and compliance

Review the record.

Confirm what Pulse checks, what it does not decide, what your team receives, and what remains available for review.

Engineering

Check it on the server.

Confirm the action is accepted only after your server checks the Pulse result.

Security

Test the ways it can fail.

Expired codes, reused links, fake page updates, stopped sessions, wrong states, and origin mistakes should fail closed.

Operations

Define pass, review, stop.

Decide what your institution does when Pulse passes, expires, asks for another check, or blocks the step.

Production control

The server is the final checkpoint.

The browser can show progress. The QR code can open the app. The page can wake up when the phone finishes. None of those should approve the action by themselves.

Action matches.

The Pulse result belongs to the expected customer, action, and session.

Time is fresh.

Old screenshots, copied links, stale sessions, and reused attempts fail before the action is accepted.

Phone result is clear.

Your policy decides whether a pass can proceed, a weak result routes to review, or a stop blocks the action.

A live page update can wake the page up. It cannot approve the action.

Success criteria

A good evaluation proves the action is safer.

Must pass

The action waits for Pulse.

The customer cannot submit or approve until Pulse returns a result and your server checks it.

Must fail

Copied proof does not work.

Old QR screenshots, reused links, fake page updates, and browser-only submissions fail closed.

Must explain

The record is clear.

Risk, compliance, and operations can see which action was protected, what result came back, and why the action passed or stopped.

Must preserve

Privacy limits hold.

The institution gets the result needed for the action, not raw location, raw sensors, or a new applicant surveillance stream.

FAQ

Common evaluation questions

Who belongs in a Pulse evaluation?: Risk, fraud, compliance, product, engineering, legal, and the action owner should review Pulse because it affects the customer step, the server check, and the review record.
What should the first Pulse deployment protect?: Start with one important action, such as application submit, account opening, account recovery, money movement, benefits claim, employment onboarding, or another moment where accepting the action accepts real risk.
What must the customer’s server check?: The server must check the Pulse result before accepting the action. The browser, QR code, page update, and app handoff are not enough by themselves.
Does Pulse replace identity checks, fraud tools, or underwriting?: No. Pulse adds a phone-backed check before the action proceeds. The institution keeps identity checks, fraud policy, underwriting, pricing, notices, reviews, and final decision authority.

Read Pulse Read Trust & Review Request a briefing