Account takeover (ATO) and fraud prevention in fintechs

How account takeover happens in fintechs

Account takeover (ATO) is the compromise of a legitimate account by a third party, who then operates as if they were the account holder. In fintechs, the impact is direct: unauthorized Pix transfers, fraudulent credit origination, changes to contact data to silence alerts, and cash-out via money-mule accounts. Unlike an infrastructure breach, ATO frequently does not trigger traditional controls because it uses valid credentials and the application's legitimate flows.

There are four predominant vectors. Credential stuffing reuses email-and-password pairs leaked from other services, tested at scale against the login screen with automation (listed by OWASP as OAT-008, Credential Stuffing, in the Automated Threat Handbook). SIM swap transfers the victim's phone line to a chip controlled by the attacker, neutralizing any second factor delivered by SMS or call. Social engineering, including fake-employee scams and real-time OTP phishing, tricks the victim into handing over codes or approving push notifications.

The fourth vector is credential phishing with a reverse proxy (kits like Evilginx), which intercepts username, password, and MFA token in the same session, bypassing OTP-based MFA. It is precisely this scenario that NIST 800-63B classifies as a channel attack and that only authenticators cryptographically bound to the origin (phishing-resistant) can block.

The central point for CTOs and risk teams: these vectors combine. A real campaign starts with leaked credential lists, scales with automation, escapes weak MFA via SIM swap or reverse proxy, and ends with social engineering to approve the final transaction. Defending a single isolated layer only pushes the attacker to the next one.

ATO signals: what to monitor before the loss

ATO leaves measurable traces before cash-out, and detecting them early is what separates a contained incident from a materialized loss. The useful signals are rarely a single binary rule; they are deviations from the historical behavior of each account and of the account population.

At the authentication layer, watch for spikes in login attempts with a low success rate (the signature of credential stuffing), successful logins from datacenter ASNs or residential proxy networks, impossible travel (login in Brazil and minutes later in another country), and anomalous velocity of attempts per IP, per account, and per device. OWASP recommends treating these metrics in aggregate, not just per IP, since botnets distribute the load.

At the account and transaction layer, the post-compromise signals are equally revealing: a change of email, phone, or password followed by a transfer attempt; registration of a new device and a high-value Pix to a key never used in the same session; disabling of notifications; and a change in the time-of-day pattern or in beneficiaries. Correlating the contact-credential change event with the subsequent transaction is one of the most effective fraud detectors in fintechs.

Turning these signals into action requires centralized telemetry and continuous correlation. Authentication logs, device fingerprint, geolocation, and transaction events need to converge into a single detection pipeline, where deterministic rules and anomaly models assign risk in near real time. Without this consolidation, each isolated signal becomes noise.

Phishing-resistant MFA: why passkeys and FIDO2

Not all MFA offers the same protection against ATO. SMS OTP, email OTP, and simple push notifications still depend on a secret or approval that can be intercepted, redirected, or socially extracted. NIST 800-63B explicitly discourages the use of SMS as a restricted (out-of-band) channel due to its vulnerability to SIM swap and interception, and classifies as phishing-resistant only authenticators that bind authentication to the origin (channel binding).

Passkeys, based on FIDO2/WebAuthn, meet this requirement. The private key never leaves the user's device, the authentication is cryptographically signed and bound to the domain (origin), and there is no shared secret that can be phished or reused. This nullifies credential stuffing, reverse-proxy phishing, and SIM swap as paths to login all at once. In NIST 800-63B terms, cryptographic authenticators with a phishing-resistant verifier are what enable AAL2/AAL3 without the weaknesses of OTP.

For a fintech product, the practical recommendation is to make passkeys the primary method and treat SMS OTP only as a recovery fallback with added friction and risk, never as the default second factor for sensitive operations. Step-up authentication, requiring re-authentication with a passkey before high-value transfers, beneficiary registration, or a change of contact data, closes the gap between authenticating the session and authorizing the critical action.

The migration does not have to be abrupt. It is feasible to enable passkeys in parallel, encourage registration during onboarding and at high-engagement points, and gradually reduce the surface of weak methods as adoption grows, always measuring registration and success rates by cohort.

Device fingerprinting, fraud detection, and response

Strong authentication does not eliminate the need to assess the context of each session. Device fingerprinting combines hardware, browser, and network attributes to recognize known devices and flag new ones, giving weight to a login that occurs from a device never seen associated with that account. Well implemented, it reduces friction for the legitimate user (who operates from familiar devices) and concentrates it exactly where the risk appears.

On top of this context runs the fraud detection engine: deterministic rules for known patterns (impossible travel, new high-value beneficiary, anomalous velocity) plus risk models that score aggregate behavior. The response should be proportionate to the score: allow transparently for low risk, require step-up with a passkey for medium risk, and block or send to manual review for high risk. This escalation preserves the experience without giving up containment.

Detection without operational response is incomplete. An ATO response plan needs clear runbooks: invalidate active sessions, force re-authentication, freeze pending transactions, revert contact-data changes, notify the account holder through an independent channel, and preserve evidence for forensic analysis and eventual reporting. In Brazil, this process connects to the cybersecurity and incident management requirements applicable to institutions regulated by the Central Bank, including the Pix ecosystem, where timeliness and traceability are expected.

Operating this chain, telemetry, detection, and response, continuously requires a 24x7 capability that many growing fintechs do not yet have in-house. This is where Decripte acts as a partner: a SOC with uninterrupted monitoring, correlation of ATO and fraud signals, and incident response with actionable runbooks, integrating with the authentication and anti-fraud controls already present in the product.

Building defense in depth against ATO

No single control solves account takeover, because each vector attacks a different layer. The password protects against casual access, but falls to a leak; strong MFA protects the login, but not the transaction authorization; device fingerprinting adds context, but does not authenticate. The strength lies in the overlap: to succeed, the attacker would have to bypass several independent layers simultaneously, which drastically raises the cost of the attack.

In OWASP terms, this means addressing automated threats (credential stuffing, account creation abuse) at the edge, identification and authentication failures in the login flow (an OWASP Top 10 category), and business logic at the transaction layer. Each requires its own controls, and the design must assume that any layer can fail in isolation.

A mature architecture chains together: credential hygiene (checking against leaked-password databases, per NIST 800-63B), passkeys as the primary phishing-resistant authenticator, device fingerprinting and per-session risk analysis, step-up authentication for sensitive actions, continuous monitoring with signal correlation, and a tested response plan. The result is not zero risk, but manageable and measurable risk.

For fintechs building or maturing this posture, Decripte offers a free plan to start monitoring and assess the ATO surface, with a path to evolve toward a 24x7 SOC and incident response as the operation grows.

Practical checklist

1. 1

   1. Map the vectors and the ATO surface

   Inventory all flows for authentication, account recovery, contact-data changes, and transaction authorization. Identify where there is a dependency on SMS/OTP and where a credential change can enable a transfer in the same session.

2. 2

   2. Block credential stuffing at the edge

   Check passwords against leak databases (NIST 800-63B), apply rate limiting per account, IP, and device, and implement automation detection following the OWASP Automated Threat Handbook (OAT-008).

3. 3

   3. Adopt phishing-resistant MFA

   Implement passkeys/FIDO2 (WebAuthn) as the primary authenticator targeting AAL2/AAL3. Demote SMS OTP to a recovery fallback with friction, never as the default second factor for sensitive operations.

4. 4

   4. Deploy device fingerprinting and a risk score

   Recognize known devices, flag new ones, and combine geolocation, ASN, and behavioral telemetry into a per-session risk score to calibrate friction proportionally.

5. 5

   5. Require step-up for sensitive actions

   Force re-authentication with a passkey before high-value transfers, beneficiary registration, and changes to email, phone, or password. Treat the action's authorization as a distinct event from the session's authentication.

6. 6

   6. Centralize telemetry and monitor 24x7

   Consolidate authentication, device, geolocation, and transaction logs into a single detection pipeline, with continuous correlation of ATO signals and uninterrupted coverage via a SOC.

7. 7

   7. Prepare and test the response runbook

   Document containment steps (invalidate sessions, freeze transactions, revert contact changes, notify through an independent channel, preserve evidence) and drill them, aligning with the Central Bank's incident requirements.

Frequently asked questions