Notifications
Clear all
Topic starter
12/06/2026 9:54 pm
TL;DR: Banks are facing more coordinated cybercrime, cheaper phishing services, API exposure gaps and faster fraud paths through real-time payments, according to Arkose Labs and Datos Insights. The message for IAM teams is that detection and progressive proofing must move earlier in the flow, before attackers turn small openings into customer loss and operational damage.
NHIMG editorial — based on content published by Arkose Labs: webinar takeaways on banking fraud, APIs and AI
By the numbers:
- 59% of financial institutions are still in the dark about their API exposure.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map the earliest fraud decision points Identify where login, registration, device change, payee setup and payment initiation can each trigger a separate trust decision.
- 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.
What's in the full article
Arkose Labs' full article covers the operational detail this post intentionally leaves for the source:
- A fuller breakdown of the webinar discussion between Datos Insights and Arkose Labs on fraud trends, attacker economics and banking controls.
- More context on the API exposure problem, including the operational discussion behind the 59% figure and how institutions interpret it.
- Additional detail on progressive proofing, including how controls can be sequenced across login, registration and payment flows.
- The source article also expands on regulatory references such as DORA, NIS2 and PCI DSS 4.0 in the banking context.
👉 Read Arkose Labs' webinar takeaways on banking fraud, APIs and AI →
Banking fraud detection: are your controls keeping up with AI?
Explore further
13/06/2026 12:18 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Proactive detection is becoming essential in banking fraud defence
