0
Separate channels: the session and the phone
Transaction verification · Fraud prevention
Transaction Authentication
Logging in safely is only half the job. Transaction authentication verifies the actions that move money or change an account, a wire transfer, a new payee, an online order, on a second channel the attacker does not control. Spriv sends the transaction to the user's phone for an Allow or Deny, or a reply by text, and returns the answer to your application.
A bank transfer confirmed on the second channel
0+
Countries reached by SMS
0
Languages with API code samples
0+
Issued patents, including transaction validation
The gap
Why login-only MFA is not enough
Multi factor authentication at sign-in proves who opened the session. It says nothing about what happens inside the session afterwards, and that is exactly where the most damaging fraud takes place.
Session hijacking
An attacker who steals a session cookie or token after login inherits a fully authenticated session. No second factor is asked for again, so every action they take looks legitimate.
Man-in-the-browser malware
Malware inside the user's browser can quietly change a transfer's amount or destination while showing the user the original details on screen. The user logged in properly, and still lost the money.
Account takeover after the fact
Changing the email address, phone number or mailing address lets an attacker lock the real owner out and redirect statements, cards and password resets.
What transaction authentication is. Transaction authentication, also called transaction verification or transaction signing, asks the user to confirm the details of a specific high-risk action on an out-of-band channel. Because the confirmation travels outside the browser, malware in the session cannot fake it. Automated MFA and session hijacks.
Banking
Transaction verification for banks and credit unions
Routine logins stay silent with adaptive MFA. The Allow / Deny prompt is reserved for the events that matter, so customers read it instead of tapping through.
Wire transfers above a threshold
Send any transfer above your chosen amount to the customer's phone with the amount and destination, and release it only on Allow.
Payee and address changes
Adding a new beneficiary or changing a mailing address is a classic first step in fraud. Confirm it out-of-band before it takes effect.
Password resets
A reset on a privileged or high-value account should be confirmed on the paired phone, so a reset link alone cannot hand over the account.
Custom high-risk events
Define your own triggers, then choose which method each user experiences for each event. Allow / Deny push.
Your data center, if you prefer. Banks and large institutions can run Spriv's Custom Servers in their own data center; everyone else uses Spriv's shared cloud servers. For the regulatory side, see FFIEC authentication guidance.
E-commerce
Online fraud prevention for card not present orders
In card not present fraud, a criminal uses stolen card details online, where no one can see the physical card. A confirmation on the cardholder's phone is something the thief does not have.
With two-way SMS, Spriv texts the customer a question about the order and the customer replies yes or no. The reply is sent to your endpoint by HTTP POST, so your checkout can ship, hold or cancel automatically. Two-way SMS needs no app and is billed per message. SMS verification.
Two-way SMS order confirmation
Did you buy a laptop from 'examplecompany' for $476? Reply yes or no. > yes → reply POSTed to your endpoint → order released
Location
Tying card use to the phone's location
Spriv's origins are in exactly this problem. In 2010 the NAVTEQ Global LBS Challenge judges described it as "a solution for automatic Internet authentication, preventing fraudulent use of stolen credit cards and user/password information by tying their use to the owner's mobile phone location."
Validating electronic transactions
Patents including "Method and system for validating electronic transactions" and "Method and system for monitoring and validating electronic transactions".
Reducing online fraud
"Method for reducing fraud in on-line transactions", US 11,308,477 and US 10,521,786. See the patents.
Impossible travel between transactions
Two transactions too far apart for the time between them are flagged in real time, under US 9,727,867. Impossible travel detection.
Integration
How to add transaction authentication with the API
Spriv's REST API has sample code in five languages. You authenticate with an API key and secret from the control panel's Service Account.
STEP 01
Send the transaction
When a high-risk action starts, your application calls the API with the user and the transaction details to show, plus browser agent data such as cookies for the fingerprint comparison.
STEP 02
The user confirms on the phone
The user sees the request on the paired phone as an Allow / Deny prompt, or receives a two-way SMS and replies yes or no.
STEP 03
Act on the answer
Your application receives allow or deny, or the SMS reply POSTed to your endpoint, and completes or blocks the transaction. API reference.
Start with the overview. The Spriv API page explains how the integration fits together, from adding users to pairing their phones.
Questions
Transaction authentication questions
What is out-of-band transaction verification?
It means the confirmation happens on a separate channel from the session that requested the transaction, here the user's phone. An attacker controlling the browser cannot see or answer it.
Will customers be prompted on every payment?
Only if you choose to. Spriv recommends adaptive MFA for routine activity and Allow / Deny only for exceptions, such as transfers above a threshold, so prompts stay rare and get read.
Do customers need to install an app?
Not for two-way SMS, which works on any phone with text messaging. Allow / Deny prompts and adaptive checks use the Spriv app on iOS or Android.
Does transaction authentication help with compliance?
Spriv's MFA is built to satisfy FFIEC, PCI DSS, HIPAA and SOX requirements and helps you meet strong-authentication expectations for high-risk transactions. Confirm the details of your own obligations with your auditor.
Explore
Related pages
Checkit!
Verify the transactions that matter
Two free users and two free servers, no credit card. Add transaction verification through the API and keep routine activity silent.