Most fintechs already collect alternative data. Device attributes, session behavior and connection history sit in some form in almost every risk stack built this decade. What varies is which of those signals are read against each other, and where in the flow they get scored.
This article covers what alternative data means in fraud, which signal families carry the most weight, and why the scoring point matters more than the length of the source list.
In fraud, alternative data describes the session – not the person
Alternative data in a fraud context means signals produced by the session itself: the device, the browser environment, the connection, and the way a form is completed. None of it is drawn from a stored record about the user, and none of it depends on what they declare.
Identity data tells you who someone claims to be. Alternative fraud data tells you what is happening at the other end of the session: whether the browser has been modified to hide its configuration, whether the form was typed or pasted, whether the same hardware has already opened nine accounts under nine names. Declared data can be bought. Session data has to be produced live, every time, and producing it convincingly at scale is expensive for fraudsters.
That economics is why one signal set covers problems sitting under different owners on an org chart:
-
New account fraud and synthetic identities
-
Account takeover and credential stuffing
-
Bot-driven registration and account farming
-
Promo abuse and first-party chargebacks
The three signal families fintechs use most
-
Device and technical environment. Hardware and software attributes, virtual machine and emulator markers, antidetect browser artifacts, time-zone and language mismatches, and evidence that a configuration has been rewritten rather than set by its owner. This is what separates a genuine new customer on a new phone from a farm cycling through synthetic profiles.
-
Behavior inside the session. How the session runs rather than what it contains – typing cadence, copy-paste into fields a real user would type from memory, navigation that is too linear, a phone on an active call during authorization.
-
Connection and linkage. Geolocation that contradicts the IP, access from a network never used before, and the relationships between sessions: how many accounts share one device, how many devices share one identity, how many checkouts share one connection.
Each looks innocent alone, since legitimate customers travel, change handsets and log in at odd hours. Correlation across the three families turns noise into a decision.
Why pre-transaction risk detection beats post-transaction review
Most antifraud tooling is organized around review. The transaction completes, a model scores it, an analyst opens a case, and recovery starts from behind. On instant rails – Pix in Brazil, UPI in India, real-time transfers elsewhere – the money has moved long before the queue is touched. In e-commerce the same lag surfaces as a chargeback weeks later.
Alternative data moves the decision earlier because the signals exist before any money does. A device profile, a behavioral pattern and a connection history are available at registration, at login and at the point of authorization. That is the practical argument for pre-transaction risk detection: not a faster review cycle, but a decision taken while intervention still costs no more than a step-up check. Risk-based authentication depends on the same sequencing – an estimate arriving after the authentication step cannot shape it.
The same signals cut false declines
The reverse case gets less attention. Rules written to catch fraud also stop legitimate users who look unusual: a customer on a shared household device, a returning buyer on a new handset, a first-time applicant with no external record in a market where coverage is uneven.
A consistent device history, a stable connection profile and natural form completion are positive markers, and they exist for users no external database can confirm. Read this way the layer is additive: it ranks risk alongside the checks a business already runs rather than replacing any of them.
Three questions to ask before adding a signal layer
-
Does it work without relying on direct user identifiers, given DPDP, LGPD and comparable regimes?
-
Can its contribution be measured additively on your own traffic, not a vendor's sample?
-
Does it cover the channel where fraud enters, which is more often registration or login than the payment leg?
Where this leaves an antifraud team
Alternative data does not replace identity verification or transaction monitoring, and treating it as a replacement is how implementations stall. It is the layer that makes those checks decidable earlier, on evidence a user cannot supply on paper.
The teams getting value from it have done two unglamorous things: moved the scoring point back to registration and login, and measured the lift on their own traffic before committing. The window in which fraud can be caught keeps narrowing as rails get faster, and signals that appear only after the money moves are already outside it.
