Cybersecurity, Identity & Fraud
Account Takeover Detection API
The attacker has the correct password, and often the correct one-time code. What they do not have is the way your customer normally behaves once they are inside.
- Banks and fintechs
- Marketplaces
- SaaS platforms
- Telecom providers
- Gaming and wallet platforms
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Credential stuffing works because passwords are reused and breach corpora are enormous. Authentication succeeds, so from the system's point of view the customer logged in. The compromise only becomes visible afterwards, usually when money has moved or a payee has been added, and by then the useful decision point has passed.
What separates a takeover from a normal session is rarely the login itself. It is the combination: a device never seen on this account, from a network the account has never used, at an hour the customer does not usually log in, followed immediately by a sequence of actions — change the contact email, add a payee, raise a limit — that a legitimate user almost never performs back to back in ninety seconds.
Treating this as a scoring problem rather than a login check changes where the controls sit. Risk is evaluated continuously through the session, and the output is a graduated response: allow, step up before this specific action, or terminate. That is also where the legal weight lands, because continuous behavioural monitoring of identified users is personal data processing and in several jurisdictions needs disclosure and a lawful basis before a single signal is collected.
Who buys this
Banks and fintechs, Marketplaces, SaaS platforms, Telecom providers, Gaming and wallet platforms
What the API returns
What comes back
- A session risk score updated through the session, not only at authentication
- Device recognition and new-device assessment relative to the account's own history
- Network and geographic plausibility, including impossible-travel and hosting-origin checks
- Behavioural signals — navigation, timing, input cadence — where your client is instrumented and the user has been told
- Action-sequence risk for the patterns that precede loss: contact change, payee add, limit change, export
- Credential-stuffing pattern detection across accounts, identifying the campaign rather than the one session
- A step-up decision tied to the specific action, with the reason the challenge was raised
- Post-incident session reconstruction for dispute handling and regulatory reporting
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/sessions/evaluate | Evaluate risk at login or at any point in a session |
| POST | /v1/actions/authorise | Risk decision for a specific sensitive action |
| GET | /v1/accounts/{id}/baseline | The account's established device, network and behaviour profile |
| GET | /v1/sessions/{id}/timeline | Full reconstructed timeline for investigation or dispute |
| POST | /v1/feedback | Report confirmed takeover, confirmed-good session or challenge outcome |
| WS | /v1/stream | Push high-risk sessions and detected stuffing campaigns |
Request and response
illustrativeRequest
{
"session_id": "sess_9f2184",
"account_id": "acct_41827",
"stage": "pre_action",
"action": { "type": "add_payee", "payee_country": "LT", "amount_limit": 5000 },
"device": { "fingerprint": "df_new_8812", "first_seen": "2026-10-21T15:28:02Z",
"os": "Windows", "browser": "Chrome" },
"network": { "ip": "203.0.113.42", "classification": "hosting" },
"behaviour": { "collected": true, "disclosure_shown": true,
"keystroke_cadence_available": true },
"session_age_seconds": 94
}Response
{
"session_id": "sess_9f2184",
"evaluated_at": "2026-10-21T15:29:36Z",
"risk_score": 89,
"band": "high",
"decision": { "action": "step_up", "method": "out_of_band_confirmation",
"applies_to": "add_payee" },
"reasons": [
{ "code": "DEVICE_UNKNOWN_TO_ACCOUNT", "weight": 0.28,
"detail": "No prior session from this device in 24 months" },
{ "code": "NETWORK_HOSTING_ORIGIN", "weight": 0.22,
"detail": "IP classified as hosting; account has only used residential and mobile" },
{ "code": "ACTION_SEQUENCE_RISK", "weight": 0.25,
"detail": "Contact email changed 61 seconds before payee add" },
{ "code": "BEHAVIOUR_DIVERGENCE", "weight": 0.14,
"detail": "Input cadence outside account's historical distribution" }
],
"baseline": { "known_devices": 3, "usual_countries": ["GB"],
"typical_hours_utc": [7, 22], "sessions_analysed": 412 },
"campaign": { "stuffing_cluster_id": "cs_1182", "accounts_targeted_1h": 64 },
"customer_message": "We need to confirm this change with you before it takes effect.",
"processing_basis": { "behavioural_signals_used": true,
"disclosure_confirmed_by_client": true }
}Where the data comes from
| Your authentication and session logs | Logins, devices, networks and session events you already record — the core input and the baseline source |
| Device and session telemetry | Collected by your own SDK or web client, subject to the disclosure and consent position your legal team sets |
| Network reputation data | Hosting, proxy and anonymiser classification, either from an internal service or a licensed feed |
| Confirmed incident records | Your own takeover cases and their outcomes, which are what the model is trained to predict |
| Breach credential exposure indicators | Whether an account's credentials appear in known corpora, from a provider whose terms permit this use |
| Your action and transaction logs | In-account events, so the sequences that precede loss can be learned from your own history |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Per-account baselines rather than population thresholds, because a customer who always logs in from one device at one hour has a far tighter normal range than a travelling one
- Continuous session scoring with evaluation at sensitive actions, so the decision point is the payee add rather than the login that happened four minutes earlier
- Action-sequence modelling over the ordered event stream, which is where takeover separates most cleanly from legitimate use
- Cross-account campaign detection, since stuffing produces correlated failures across many accounts within minutes and that pattern is unmistakable in aggregate
- Behavioural features kept strictly optional and separately switchable, so the service degrades to device and network signals where collection is not lawful or not disclosed
- Graduated response design: the output is a decision scoped to one action, because terminating a legitimate session is itself a serious failure
- Threshold tuning against your actual costs — a challenge shown to a genuine customer has a measurable abandonment cost and it belongs in the optimisation
- Drift monitoring and challenge-outcome feedback, since both attacker technique and customer behaviour move continuously
What it changes for the business
Intervention before loss
Evaluating at the payee add rather than the login puts the control at the point where money is actually at risk.
Less friction for known sessions
Established device, network and behaviour means a recognised customer is challenged less, not more.
Campaign-level response
Cross-account correlation identifies a stuffing run while it is running, not in the following week's report.
Dispute evidence
A reconstructed session timeline is what resolves a liability argument with a customer or a regulator.
How it fits into your product
How it embeds
- Synchronous evaluation at login and before sensitive actions, with a documented latency budget
- Step-up decisions returned as instructions your existing authentication flow can execute
- Client SDK for device and behavioural collection, with the disclosure surface under your control
- A hard switch that disables behavioural collection per jurisdiction or per tenant without redeploying
- Deployment inside your infrastructure, which is the usual arrangement for session and account data
- Feedback and timeline endpoints wired into your fraud case management
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
What are the legal requirements for behavioural monitoring?
In many jurisdictions, including the EU and UK, collecting keystroke cadence, pointer movement or similar behavioural characteristics about an identified user is personal data processing that needs a stated lawful basis, a privacy notice that actually describes it, and often a data protection impact assessment. Some regimes treat behavioural biometrics as a special category requiring explicit consent. We build the behavioural layer as a switchable component for that reason: your legal team decides where it may run, and the service works on device and network signals alone where it may not. We will not design a flow that collects those signals without a disclosure in place.
Will this lock out legitimate customers?
Some, which is why the output is graduated rather than binary. A new device on a holiday abroad looks a lot like a takeover, and the right response is a confirmation step, not a terminated session. Challenge-outcome feedback is how precision improves, and we would track abandonment on challenged genuine customers as an explicit cost rather than treating friction as free.
Can you stop takeover where the attacker has the one-time code?
Sometimes, and only because the behaviour still differs. A code obtained by social engineering or SIM swap defeats the authentication factor entirely, so this is the layer that has to catch it — on the unknown device, the hosting-origin network, the contact change followed immediately by a payee add. It is not a guarantee. An attacker who is patient, uses a clean residential network and behaves normally for a week is a genuinely hard case and we would not claim to catch it reliably.
How much history does an account need?
Roughly twenty sessions before the baseline is tight enough to be useful. New accounts are the weakest case, which matters because new accounts are also disproportionately targeted. For those the API leans on network and device-population signals and reports lower confidence, rather than producing a confident score from four sessions of history.
Does session data have to leave our systems?
Normally no. Banks, telecoms and marketplaces almost always run this inside their own infrastructure, and the design assumes it. A hosted option exists but it changes the data protection analysis considerably, and we would walk through that before proposing it.
Related blueprints
Synthetic Identity Detection API
Flags applications where the identity elements do not cohere, using relationship and consistency signals rather than a single identity check.
IP Reputation Intelligence API
Proxy, hosting, bot and abuse indicators for any IP address, served as a lookup your product can call on every request.
Phishing URL Detection API
Risk scores and threat classification for any URL or domain, as a check your email gateway, browser or messaging product can run inline.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.