On 29 October 2026, unauthorised transfers from Binance hot wallets affected approximately $6.34 billion in digital assets, according to the exchange’s preliminary report. The attackers used an internal AI tool to expand their access after compromising an employee’s computer. They later reached the wallet signing service and initiated transfers outside the normal withdrawal process. By 3 November, Binance reported that approximately $2.85 billion in assets had been frozen or intercepted. The findings were preliminary and subject to independent review.
The Binance hack shows one way AI changes FinTech cybersecurity. An internal tool can become part of a breach. In other cases, attackers use AI to develop malicious software or impersonate someone authorised to request a payment. Each scenario puts a different control under pressure, from the permissions granted to engineering tools to the final decision to release funds.
AI cybersecurity risks exposed by the Binance hack
According to Binance, the internal AI tool helped the attacker extend a foothold from a compromised device to other employees in wallet engineering. The exchange later rebuilt the affected AI tool and its access controls, replaced affected devices and revoked credentials and tokens linked to the incident.
For a payment service provider (PSP), the question is what an internal tool can reach through its own permissions and those of the employee using it. An assistant might only be intended to explain an error or summarise a fraud alert. If its integrations can also access production credentials or modify deployment settings, compromising the tool can expose systems far beyond its intended task.
Review these permissions alongside the controls on the payment release service. An engineer’s ability to deploy changes, for example, deserves scrutiny if those changes can alter the rules that enforce transaction approval. Give AI tools distinct service identities and grant each identity access to the resources it needs for its specific job.
AI phishing attacks and account takeover fraud
Mandiant investigated a series of compromises involving financial services, retailers and e-commerce companies in Brazil. It linked them to BREEZE COMET, a group that manipulates banking software and payment systems to make fraudulent transfers. Investigators found evidence that the group used generative AI to support malware development.
In a separate incident reported in September 2026, Google Threat Intelligence observed attackers use AI agents to prepare and launch a mass credential-harvesting campaign less than six hours after compromising a cloud resource. That is the timeline of one observed campaign. It illustrates how quickly activity can escalate after an initial compromise.
For payment teams, the consequences of account takeover depend on what the compromised identity can do. A stolen support account might expose customer data. A stolen operations account with broader privileges could affect where funds are sent. The distinction matters when designing alerts. A suspicious session that only views records and one that changes a merchant’s settlement account call for different responses.
Deepfake fraud and the limits of payment approval
In January 2024, a Hong Kong employee authorised transfers to five bank accounts after attending what appeared to be a video meeting with a senior finance executive. The company lost about HK$200 million. Police believed the video conference had been fabricated and recorded in advance. The employee had authority to make the payments and acted on a false instruction.
The FBI’s Internet Crime Complaint Center received 22,364 complaints containing AI-related information in 2025, with approximately $893.3 million in reported losses. Those figures cover multiple categories of cybercrime and fraud. The Hong Kong case gives a closer view of the payment mechanism behind one such incident.
Two people can approve a transfer and still rely on the same fabricated evidence. When a request changes settlement details or calls for an unusual transfer, apply three checks.
- Verify the request through an established contact channel using details already on file.
- Record what the approver verified and bind the approval to the beneficiary, destination account, amount and currency.
- Require a fresh approval if any of those details change.
Payment fraud prevention: What to test before money moves
Run an exercise in which an operations account has been compromised shortly before a large merchant payout. The attacker has submitted a beneficiary change, a colleague has received a convincing message asking for urgent approval, and some instructions in the batch have already reached the bank. Use the exercise to test four points in the payment flow.
- Access to payment controls. Verify that a compromised engineer’s session or internal AI tool cannot reach production signing services or change payment release rules. Test service identities as well as employee accounts. Apply the same scrutiny to production deployment permissions and access to secrets.
- Independent approval. Check that the identity that changes the settlement account cannot also approve the change and release the payout. Confirm that the release service enforces the same policy for back-office, API and batch payments. For a batch, verify that approval applies to the exact set of instructions sent to the bank or processor.
- An effective payment hold. Give security and payment operations a way to pause an affected merchant, batch or route. During the exercise, measure the time from the first alert to the point when the release service actually stops sending instructions. Identify which payments were held, which the partner had already accepted and which were eligible for recall. A new sign-in, a change to the beneficiary’s bank account and a scheduled payout can each look routine on their own. Link those events by merchant and timestamp so the team can review them together. If they occur close to the payout cut-off, test whether the team can place a hold before the instruction leaves the platform.
- Recovery without duplicate payouts.
- If the instruction is still queued, the PSP can place it on hold.
- If a bank or processor has accepted the instruction, check whether the partner can stop or recall it.
- If settlement is confirmed, reconcile the transfer and coordinate any recovery with the partner.
Before resuming, compare the approved instructions, ledger entries, outbound records and partner acknowledgements or settlement reports. Separate payments that never left the platform from payments with uncertain outcomes and confirmed settlements. Resolve uncertain outcomes before retrying. An acknowledgement can arrive late even when the partner has already accepted the payment.
Record four measures during the exercise.
- Time to an effective hold
- Value released before containment
- Number of payments with an uncertain outcome
- Time to verified recovery
Review the results with security, engineering, treasury and payment operations. A successful exercise should show which independent control stops the next unauthorised payout and what evidence lets the team account for every payment already in flight.
