Proactive detection is becoming essential in banking fraud defence

At a glance

What this is: This webinar summary argues that banking fraud and cybercrime are moving earlier in the kill chain, with APIs, ATO, AI-assisted phishing and RTP fraud creating faster paths to loss.

Why it matters: It matters because IAM, fraud, and security teams need controls that detect abuse before transaction completion, especially where identities, APIs, and customer authentication are now part of the attack surface.

By the numbers:

• 59% of financial institutions are still in the dark about their API exposure.

👉 Read Arkose Labs' webinar takeaways on banking fraud, APIs and AI

Context

Banking fraud defence is increasingly an identity problem as much as a transaction problem. When attackers use reverse-proxy phishing, AI-assisted impersonation, API abuse and mule networks, the break point is often not the payment rail itself but the authentication and decisioning layer that sits in front of it.

The article’s central claim is that security teams need to detect and disrupt fraud earlier in the cyber kill chain, before stolen credentials, automated tooling and real-time payments combine into a high-speed loss event. For IAM and fraud leaders, that means control coverage has to extend from login and registration through to step-up checks, API inventory, and transaction proofing.

Key questions

Q: How should banks detect fraud before stolen credentials turn into losses?

A: Banks should place detection at the earliest trustworthy signals, not only after a payment attempt. That means combining login risk, device reputation, registration behaviour and transaction context so suspicious activity can be challenged before funds move. The goal is to interrupt attacker momentum while the session is still containable.

Q: Why do hidden APIs create fraud and access risk for financial institutions?

A: Hidden APIs expand the attack surface because teams cannot secure or monitor what they have not inventoried. When endpoints are unknown, access controls become inconsistent, logging is incomplete and abuse detection misses important paths. API inventory is therefore a governance requirement, not just a documentation exercise.

Q: What do security teams get wrong about account takeover defence?

A: They often rely on a single login decision and assume that successful authentication means the session is trustworthy. In reality, account takeover frequently becomes visible only after registration changes, device shifts or unusual payment actions. Defence has to follow the session, not just the login event.

Q: Who is accountable when fraud happens after authentication succeeds?

A: Accountability sits with the teams that own the identity journey, API exposure and transaction controls together. If authentication, fraud monitoring and payment risk are split into separate silos, attackers exploit the gaps between them. Governance should define who can stop a session before value moves.

Technical breakdown

Why early kill-chain detection matters in banking fraud

Early detection works because banking attackers increasingly chain low-cost access methods into high-speed abuse. A reverse-proxy phishing kit can capture credentials and MFA codes, then hand that access to an operator or automated service that moves quickly across login, registration, API calls and payment actions. The longer the exposure remains active, the more opportunity an attacker has to pivot from account access into fraud, mule transfers or data exploitation. In this model, the control problem is not only stopping a bad login. It is seeing the transition from authentication success to suspicious session behaviour early enough to interrupt downstream abuse.

Practical implication: move detection closer to authentication, registration and first-transaction decision points so abuse is interrupted before fraud is executed.

API security gaps create hidden entry points

APIs widen the banking attack surface because they are often distributed across mobile apps, partner integrations and back-office services, with incomplete inventories making some endpoints effectively invisible to defenders. That invisibility matters: an untracked API can become an unauthenticated, weakly protected or over-permissioned path into customer or payment systems. The article’s 59% figure on unclear API exposure shows that discoverability is now part of security architecture, not just documentation hygiene. Without a complete inventory, teams cannot apply consistent authentication, rate-limiting, abuse detection or monitoring across all exposed interfaces.

Practical implication: build and maintain a complete API inventory before relying on consistent policy enforcement or detection coverage.

Progressive proofing and transaction-layer controls

Progressive proofing means evaluating trust at multiple points instead of waiting for a final transaction verdict. In banking, that typically includes signals at login, registration, device change, payee setup, beneficiary modification and payment initiation. This matters because modern fraud often appears legitimate at the start, then reveals itself through subtle shifts in timing, device fingerprint, session behaviour or beneficiary risk. A single static decision at authentication is too narrow for fast-moving fraud patterns, especially when AI tools help attackers scale convincing attempts. The architecture has to treat identity assurance as a sequence of checkpoints, not a one-time gate.

Practical implication: add layered checkpoints across the customer journey so trust can be downgraded before money moves.

Threat narrative

Attacker objective: The attacker aims to obtain fast, low-friction access to accounts and payment flows so stolen value can be moved before intervention.

1. Entry occurs through reverse-proxy phishing, AI-assisted impersonation and cheap phishing kits that capture valid credentials and MFA codes.
2. Escalation follows when attackers reuse those credentials for account takeover, API abuse or fraud orchestration across banking channels.
3. Impact lands in real-time payment fraud, mule-account laundering and customer loss before defenders can reverse the transaction.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Early detection has become the decisive control in fraud-heavy banking environments. The article’s core point is that attackers now compress the time between credential capture and damage, which leaves traditional after-the-fact review too late to matter. That shifts the governance question from how to clean up after fraud to where trust should first be challenged. For banks, the practical conclusion is that identity assurance must be evaluated where attacker momentum begins, not where transaction failure becomes visible.

API exposure is a governance problem before it is a technical one. If nearly six in ten institutions do not know their API exposure, the failure is not only weak tooling but incomplete inventory ownership and control scope. An unseen API cannot be protected consistently, risk-assessed accurately, or monitored for abuse pathways. The field implication is that API discovery now belongs in the same governance conversation as entitlements, secrets and external access.

Progressive proofing is the right concept for fraud, but only if trust signals are sequenced around attacker behaviour. Static authentication asks the wrong question at the wrong time in a live fraud chain. The important shift is to treat trust as a sequence of decisions across login, enrolment, device change and payment initiation. Practitioners should recognise that this is not a point control problem but a journey-control problem.

Cybercrime-as-a-service lowers the skill barrier, which raises the need for policy-driven detection economics. When phishing kits and support services become cheap and accessible, the defender cannot assume the attacker is a lone operator with limited scale. The governance response has to assume repeatable, outsourced abuse across multiple accounts, channels and sessions. For security leaders, that makes early friction and adaptive proofing a structural necessity, not a tuning exercise.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Our research also found that enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a deeper NHI governance lens, see the NHI Lifecycle Management Guide for how provisioning, rotation and offboarding reduce identity exposure over time.

What this signals

Identity-proofing depth now matters more than point-in-time authentication. Banking teams should expect attackers to keep compressing the window between credential capture and monetisation, which means risk engines need to evaluate behaviour across the full session. The governance shift is from static trust to staged trust, especially where APIs and payments can be reached quickly.

The article also reinforces a broader identity lesson: visibility is control. If teams cannot enumerate their APIs, they cannot apply consistent policy, and if they cannot distinguish normal from suspicious session behaviour, progressive proofing becomes reactive rather than preventive. That makes API ownership, logging coverage and journey-level escalation rules part of core security architecture, not adjacent work.

Attackers are buying capability, not just building it. The rise of cybercrime-as-a-service means security teams should plan for repeatable, outsourced abuse that arrives at scale and with low technical barrier to entry. That is a strong argument for using external authority references such as NIST Cybersecurity Framework 2.0 and internal risk metrics together when justifying investment in early-detection controls.

For practitioners

• Map the earliest fraud decision points Identify where login, registration, device change, payee setup and payment initiation can each trigger a separate trust decision. Use those checkpoints to interrupt abuse before settlement or mule transfer completes.
• Inventory every exposed API Build a complete inventory of banking APIs across web, mobile, partner and internal channels, then assign an owner to each endpoint so authentication, rate limits and monitoring can be enforced uniformly.
• Add adaptive proofing to high-risk sessions Increase challenge strength when session behaviour changes, such as new devices, unusual timing, beneficiary edits or repeated login failures. Treat these as escalation signals rather than isolated events.
• Shorten the fraud response path Predefine containment actions that can be applied before payment completion, including step-up verification, session interruption and beneficiary hold rules when risk indicators cross threshold.

Key takeaways

• The article shows that banking fraud increasingly succeeds when defenders detect abuse too late in the identity and transaction chain.
• The evidence points to a large visibility problem in API exposure, which weakens every downstream control that depends on knowing the full attack surface.
• Practitioners should shift from single-step authentication thinking to staged proofing, earlier detection and faster containment across the customer journey.

Key terms

• Account Takeover: Account takeover is the unauthorised use of a legitimate account after an attacker captures credentials or session access. In banking, the harm is not just login compromise. It is the ability to move through registration, payment and beneficiary workflows while appearing partially trusted.
• Progressive Proofing: Progressive proofing is a staged trust model that checks identity risk at multiple points in a user journey instead of relying on one authentication event. It is most useful where fraud can develop after login, because it allows controls to escalate as behaviour becomes less trustworthy.
• API Exposure: API exposure is the set of externally or internally reachable interfaces that can be discovered, accessed or abused by a third party. In practice, exposure becomes a governance issue when teams cannot inventory every endpoint, which leaves policy, logging and abuse detection uneven.
• Cybercrime-as-a-Service: Cybercrime-as-a-service is a criminal operating model where tools, infrastructure or attack services are rented or outsourced. It lowers the technical barrier for attackers and increases the speed, consistency and scale of fraud and credential attacks.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Arkose Labs: webinar takeaways on banking fraud, APIs and AI. Read the original.