Last checked against sources: 29 October 2026.
Cybercriminals are attacking financial firms through exposed apps, stolen payment keys, cloud desktops, wallet systems and trusted identities. Some groups now use AI agents to find weaknesses and plan attacks. Others reach money by abusing access that an organization or its customers already trust.
These financial cyberattack types need different controls. A data breach calls for work on exposure and access. Payment fraud requires checks where funds move. A convincing fake executive needs a verification process that holds up under pressure.
Security, fraud and treasury teams need to know which route they are facing.
The following five mechanisms draw on original research and official notices from South Korea, Latin America, India and Japan, alongside an exchange disclosure and FBI guidance. They explain how access becomes impact across financial services, with practical detection and response priorities for each route.
1. AI-Assisted Intrusion Through Exposed Applications
The entry point can sit outside a bank’s main transaction systems. In its 7 October 2026 ARTEX investigation, CrowdStrike describes reports of attacks on a loan-progress inquiry service and a mobile work-support system for staff. The campaign ran from late September to early October and resulted in stolen data.
Researchers recovered ARTEX settings, Claude Code session histories and memory files from exposed attacker infrastructure. ARTEX is an agentic penetration-testing tool. The recovered records gave CrowdStrike evidence of how the operator combined AI tooling with other offensive capabilities. For a related technical walkthrough, read our ARTEX and ConnectWise coverage.
A 21 October investigation by Straiker describes a wider operational use of AI in Latin America. CyberCartel operators used the CARLIY0S framework with Claude, Grok and Kimi models assigned to different tasks. Straiker reports more than 400 financial targets across months, including banks and payment providers, and evidence of stolen credentials.
The concern is that a small team can scan more targets and manage more tasks. The target count is not a tally of successful bank breaches. For defenders, the useful evidence is the workflow and the stolen access that researchers found.
Review logs from broker portals, staff tools and public APIs alongside the asset inventory. Look for repeated record lookups, bulk reads and access that crosses an account’s expected scope. On detection, close the exposed route, preserve logs and check whether stolen credentials can reach another service.
2. Payment API Abuse That Bypasses the Loan Workflow
Some attackers move beyond stealing records and invoke the systems that release funds. CERT-In’s 9 October advisory describes campaigns against Indian non-bank lenders, fintech firms and payment providers. After compromising applications or exposed APIs, attackers stole payment and partner-bank API credentials.
The transfers came from infrastructure already approved by the payment system. This allowed requests to bypass application checks for loan creation, customer verification, beneficiary checks and transaction limits. A bank can receive a technically valid request even when the lender’s normal approval process never took place.
The advisory describes possible AI-assisted tooling. In a separate 15 October notice, CERT-In reports malicious agentic tools shortening the time from initial access to financial impact from days to hours. It also describes repeat attacks after incomplete repairs. These findings make rapid containment part of payment security.
- Exposed application or APIExposureInitial compromise.
- Stolen payment credentialsAccessUse trusted infrastructure.
- Direct transfer requestPaymentBypass application checks.
- Mule accountPayment
This diagram follows the Indian payment scenario. It illustrates one route from access to funds, rather than a chain shared by every incident in this article.
Bind payout requests to approved records at the payment layer. Enforce transfer limits and second-person checks there, and reconcile outgoing payments against the lender’s own records. Alert on missing reference records, new beneficiaries and unusual transfer speed. Our guide to payment fraud detection and prevention explains how these checks fit into the wider payment process.
3. Cloud Desktop Compromise That Reaches Trading Accounts
An attacker can reach a trading account through the computer used to operate it. This is one route to account takeover. A Japanese cloud provider’s 22 October incident notice confirmed malicious programs on some customer server environments. Customers had also reported unauthorized operations in trading accounts linked to tools running on those servers.
The provider said trading credentials stored on the servers may have been obtained and misused. Its instructions covered brokerage and foreign-exchange tools, including MT4 and MT5. It asked customers to change passwords from another device, disconnect sessions and check trade histories and balances.
The case also involved extortion. The provider’s 29 October incident timeline records a demand of about ¥8 billion received on 21 October. A demand is not the amount paid or the value of confirmed trading losses. The opened notices do not establish an AI role in the intrusion.
For a financial firm, this creates a dependency to examine: where do customers, traders and partners store account access? Review hosted desktops and other remote environments as potential routes to trading sessions. Correlate new sessions, account changes and unexpected trading with relevant supplier alerts.
If the workstation is suspect, a password change alone may leave an active session behind. Follow the provider’s containment guidance and coordinate with the broker to revoke access, review transactions and preserve evidence. Use a separate, trusted device for recovery work.
4. Wallet Infrastructure Theft at a Crypto Exchange
Digital-asset custody adds another route to financial loss. An exchange’s 24 September original security notice reported unauthorized transfers involving some hot wallets. It estimated affected assets at approximately $351.6 million and said it had temporarily paused withdrawals during its investigation.
A hot wallet supports online activity. Its compromise concerns custody and transfer controls, while an exposure of customer records concerns information. The original notice said the attack vector was still under investigation. It does not establish that AI caused the incident or explain the full technical route.
The response lesson is to connect wallet operations with incident decisions. Security teams should be able to reach the people who can pause transfers, identify affected addresses and engage relevant response partners. Those responsibilities need to be clear before an alert arrives.
As a review priority, test whether unusual withdrawal activity can trigger a prompt hold without losing the evidence needed for analysis. Check access to online wallet infrastructure and the authority to approve transfers. These are steps for a security review. The cause of this incident was still unknown in that first notice.
5. Identity Impersonation That Turns Trust Into a Payment
An attacker may target the person who approves a transfer. Our business email compromise guide explains the related abuse of trusted business identities. The FBI’s guidance on generative AI financial fraud describes cloned audio used to impersonate individuals and gain access to bank accounts. It also describes generated video used in real-time calls featuring supposed executives or other authority figures.
This route puts pressure on identity checks and payment procedures. A familiar voice, face or writing style can become less reliable evidence of who is giving an instruction. The loss comes when staff or customers trust the false identity and grant access or send money.
The FBI advises verifying a caller through an independently sourced contact route. For corporate payments, translate that principle into a known callback channel and approval steps that cannot be waived by an urgent message. Treat changes to beneficiary details and requests for secrecy as reasons to verify the instruction.
Preserve the message, call details and payment record when a suspected impersonation reaches the team. Bring fraud response into the process early so it can assess transfer holds or recovery options. Staff should know how to escalate a suspicious instruction without first proving how the media was generated.
Build the Response Around Access, Funds and Recovery
The common defensive task is to shorten the gap between identifying dangerous access and stopping its impact. CERT-In’s examples show why payment checks must survive application compromise. The cloud desktop case shows why trading-account recovery may need action beyond the affected supplier.
The ECB’s July 2026 letter on AI-enabled threats calls for faster patching, stronger monitoring, attention to exposed assets and third-party readiness. It also calls for better response and recovery. These priorities fit the broader resilience work described in our Digital Operational Resilience Act guide.
Use a joint security and fraud exercise to test one concrete scenario: a valid credential is used to request an unexpected transfer. Establish who sees the signal, who can stop the funds, which access must be revoked and how the team checks that the attacker cannot return. Record the gaps, assign owners and retest the repaired controls.