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.
At a glance
What this is: Arkose Labs argues that banking fraud defence now needs detection earlier in the attack flow, because coordinated cybercrime, CaaS phishing and API exposure are shortening the path from compromise to loss.
Why it matters: This matters to IAM and fraud teams because login, registration and transaction checks now have to work together, or attackers will move from identity abuse into customer harm before downstream controls can react.
By the numbers:
- 59% of financial institutions are still in the dark about their API exposure, according to Arkose Labs.
Context
Banking fraud controls fail when they only react after the transaction or account compromise has already progressed. In this article, proactive detection means moving identity and fraud checks earlier in the flow, before attackers can turn a small opening into customer loss, operational disruption, or both.
The article focuses on three pressure points that are reshaping fraud defence for financial institutions: cheaper cybercrime-as-a-service, faster abuse of exposed APIs, and real-time payment rails that reduce the window for recovery. For IAM and fraud programmes, that makes progressive proofing and early-session risk evaluation part of the control stack, not an optional enhancement.
Key questions
Q: What breaks when banks only detect fraud after a transaction is underway?
A: Post-transaction detection breaks when attackers can move from phishing or account takeover to money movement faster than analysts can react. By the time the fraud team sees the event, the account may already be compromised, the payment may already be sent, and the recovery window may be too small to matter.
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: How do banks know if progressive proofing is working?
A: Progressive proofing is working when risky sessions are challenged early, suspicious registrations are slowed or stopped, and fewer fraudulent events reach the transaction stage. If detections only appear after money has moved, the control is operating too late to change outcomes.
Q: Should fraud teams prioritise login controls or transaction monitoring first?
A: Fraud teams should prioritise the earliest control point that can reliably stop abuse in their environment. If attackers are using phishing, automation or exposed APIs to reach accounts quickly, login and registration controls usually deserve more weight than transaction-only monitoring because they shorten the path to loss.
Technical breakdown
Why earlier-stage fraud detection changes the control model
Fraud teams traditionally rely on post-event analysis, transaction monitoring, or step-up checks late in a session. That model assumes the attacker needs time to complete the fraud chain, but reverse-proxy phishing, automated account takeover and API abuse compress that timeline. Progressive proofing changes the architecture by introducing evaluation at login, registration and other early decision points, so the system can challenge suspicious behaviour before trust is fully established. In banking, that matters because the most expensive losses often occur after the attacker has already passed the first gate.
Practical implication: Shift fraud and identity controls toward early-session decisioning instead of waiting for transaction-time detection.
How cybercrime-as-a-service lowers the barrier to account takeover
Cybercrime-as-a-service turns attack capability into a subscription model, which means technical depth is no longer a prerequisite for large-scale fraud. That creates more volume, more variation and more automation in phishing, credential capture and account takeover campaigns. The article notes that attackers are using AI to improve the realism and scale of these operations, including reverse-proxy phishing that can capture credentials and MFA codes in a single interaction. Once the attacker can buy the capability, defenders face a broader and more persistent threat surface than traditional manual fraud rings created.
Practical implication: Treat low-skill, high-scale phishing infrastructure as an operational risk input to fraud detection thresholds and response timing.
Why API inventory and discoverability are fraud issues, not just security issues
Open APIs expand the attack surface because they expose business functions that can be abused directly, not just stolen credentials. The article highlights that many institutions still lack confidence in what APIs they have, which means some endpoints remain effectively invisible to governance and control owners. That is a fraud problem because hidden or weakly governed APIs can support account abuse, data leakage or transaction manipulation without triggering the controls built around user-facing channels. If you cannot inventory the endpoint, you cannot consistently protect the flow.
Practical implication: Bring API inventory and exposure management into fraud governance, not only application security.
Threat narrative
Attacker objective: The attacker wants to take over accounts, abuse exposed business functions and move stolen funds faster than banks can detect and reverse the fraud.
- Entry begins with cheaper phishing kits, reverse-proxy pages or exposed APIs that let attackers reach customer accounts and workflows.
- Credential harvesting and session capture follow when phishing infrastructure steals real credentials and MFA codes, or when API weaknesses expose reachable functions.
- Escalation occurs through automated account takeover, API abuse or movement into real-time payment channels that accelerate money movement.
- Impact lands as customer loss, difficult-to-trace fraudulent transfers and broader operational damage to banking systems and response teams.
Breaches seen in the wild
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Proactive detection is now a fraud control, not just a security control. Banking fraud has moved far enough upstream that waiting for post-transaction review is structurally too late. When attackers can buy phishing capability, automate account takeover and reach exposed APIs, the control point has to move toward login and registration decisions. For practitioners, that means fraud, IAM and application security can no longer operate as separate queues.
Cybercrime-as-a-service has changed the economics of abuse. A subscription model lowers the skill threshold for launching credible attacks and increases the volume of attempts banks must absorb. That does not just increase alert noise, it changes how rapidly a bank must decide whether a session, device or identity flow is trustworthy. The implication is that detection thresholds now have to be tuned for scale, not just sophistication.
Banking fraud defence is becoming an identity orchestration problem. Progressive proofing only works when identity signals, device signals, transaction context and API exposure are evaluated in sequence. Banks that treat these as disconnected controls will keep finding the attack too late. The practical conclusion is that governance has to follow the customer journey, not the organisational chart.
API inventory gaps are now exposure gaps in the fraud stack. If 59% of financial institutions lack confidence in their API exposure, the problem is no longer theoretical. Hidden endpoints let attackers reach business flows that were never designed for fraud resistance, which means the control assumption is already broken before the first alert fires. Security teams should treat discoverability as a prerequisite for any meaningful fraud posture.
Real-time payments compress the recovery window and raise the cost of delay. Faster payment rails do not create fraud by themselves, but they sharply reduce the time available to intercept and unwind abuse. That pushes the industry toward earlier scoring, stronger progressive proofing and faster operational handoff between fraud and response teams. For practitioners, the question is no longer whether to detect earlier, but how much earlier the control stack can reliably decide.
From our research library:
- U.S. fraud losses are projected to reach $40 billion by 2027.
What this signals
Progressive proofing is becoming the practical bridge between IAM and fraud operations. Banks that still separate authentication from fraud detection will keep reacting too late because the control stack is sequenced after the attacker has already gained meaningful trust. The operational shift is toward earlier, layered decisions that can interrupt abuse before a transaction exists to investigate.
API discoverability has become a fraud governance requirement. When exposed endpoints are not fully inventoried, the bank cannot consistently apply policy, score risk or measure exposure across the customer journey. That makes API management part of fraud containment, not just an application hygiene task.
Real-time payments reward speed on both sides. Faster rails compress the defender's response window and favour attackers who can automate selection, capture and monetisation. Banks need controls that decide earlier because delay now has a direct cost in irrecoverable loss.
For practitioners
- Implement progressive proofing at login and registration Add risk checks before a session is trusted, not only after a payment is initiated. Tie identity, device and behavioural signals to early-step decisions so suspicious activity is challenged before account takeover matures.
- Inventory exposed APIs across customer journeys Create and maintain a complete API inventory that includes mission-to-mission, process-to-process and customer-facing endpoints. Use that inventory to identify where fraud controls and access governance are missing.
- Tune fraud controls for cybercrime-as-a-service scale Assume phishing kits, reverse-proxy tools and automated takeover attempts will arrive at subscription scale. Adjust detection thresholds, analyst routing and response playbooks for high-volume abuse rather than isolated events.
- Align fraud and IAM decision points Map where authentication, step-up checks, account recovery and transaction approvals overlap, then close any gaps where an attacker can move from trust establishment to monetisation without another control firing.
Key takeaways
- Banks are dealing with fraud patterns that move faster than traditional after-the-fact monitoring can contain.
- The article highlights API visibility, phishing automation and real-time payments as the main pressure points behind that shift.
- Earlier identity and fraud decisions, especially at login and registration, are the controls most likely to reduce downstream loss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article stresses unknown API exposure as a banking fraud risk. |
| API6 — Unrestricted Access to Sensitive Business Flows | Fraud paths are described through business flows that attackers can reach and abuse. | |
| Recommendation — Inventory every API and tie exposure records to fraud controls before attackers exploit unseen endpoints. Restrict sensitive flows so customer and payment actions cannot be abused without strong verification. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Phishing kits and MFA capture make credential lifecycle and authenticator handling central to the issue. |
| Recommendation — Strengthen authenticator lifecycle controls to reduce the window for captured credentials to be reused. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article ties fraud exposure to trust decisions made before access and transaction handling. |
| Recommendation — Apply entitlement checks early in the customer journey so risky access is challenged before monetisation. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern described includes credential capture and fraudulent movement of value. |
| Recommendation — Map phishing and ATO indicators to credential access and exfiltration patterns in your detections. | ||
Key terms
- Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.
- 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.
- 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.
- Real-Time Payment Fraud: Real-time payment fraud is abuse of instant payment rails where funds settle too quickly for traditional post-transaction controls to help. The attacker relies on short decision windows, mule accounts, and weak recipient verification to move money before detection or reversal.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org