# CERT-In Names Crafty Falcon in AI-Assisted Payment API Attacks

A November 4 advisory warns of repeat attacks on financial firms. The practical issue is whether payment controls still hold after a system is compromised.

By Paras Madan | 2026-11-05


India's CERT-In issued [critical advisory CIAD-2026-0058 on November 4](https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIAD-2026-0058&pageid=PUBVLNOTES02), naming an AI-assisted financial threat actor it calls CRAFTY FALCON. It describes an active campaign against financial services and digital-asset businesses that abuses their own payment and disbursement APIs.

For engineering teams, the important question is whether a compromised application can move money without passing the checks that normally protect a transaction. That question reaches beyond the security of any individual model or chatbot.

## What changed since the October warning

The new advisory updates an October 9 alert. CERT-In now reports repeat attacks after incomplete remediation, including incidents timed for holidays and weekends. It describes misuse of cloud-management services and movement from exposed testing environments into production through shared access.

The agency attributes AI-assisted tooling to the campaign. Its public notice does not name victims, quantify losses or establish what proportion of each incident was automated. Detailed indicators and detection rules were shared separately with affected-sector recipients under restricted distribution.

Those limits matter when interpreting headlines. The public evidence supports reporting CERT-In's assessment. It does not support assigning every recent financial-sector breach to this actor or assuming that AI was the sole cause of a loss.

## A valid API call can still be an unauthorized payment

The [October 9 advisory](https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIAD-2026-0046&pageid=PUBVLNOTES02) described attackers obtaining payment credentials and invoking fund-transfer APIs from the victim's approved infrastructure. That could bypass application checks such as beneficiary verification and transaction limits.

Its recommended controls included binding transaction stages together, verifying payouts against approved records, requiring a second approval for fund movement and enforcing limits at the payment API itself. It also called for short-lived credentials, secure secret storage, transaction monitoring and prompt reconciliation with bank or payment-provider records.

The architecture lesson is straightforward. A payment service should be able to determine why a transfer is authorized without relying only on the fact that the request came from a familiar server. Source identity, business approval and transaction validity answer different questions.

An incident review should therefore trace the complete path from the original business instruction to the final movement of funds. If a required check exists only in a user interface or an earlier application step, establish how the downstream service verifies that the check actually happened.

## The operational response needs an owner

[I4C has also urged banks, NBFCs and fintech firms to implement CERT-In's measures](https://newsonair.gov.in/i4c-cautions-banks-and-fintech-firms-against-ai-driven-cyberattacks/), according to the November 5 report from public broadcaster Akashvani. That report reiterates incident reporting to CERT-In within six hours of detection, with banks and NBFCs also reporting through the RBI's DAKSH portal within the same period.

Security and compliance teams should confirm the obligations that apply to their institution and rehearse the reporting path before an incident. The person able to disable a payment integration, the person reviewing suspicious transfers and the person notifying authorities may be in different teams. Waiting to connect them during an attack adds avoidable delay.

A useful internal review can start with three questions:

1. Can the payment service reject a transfer that lacks a valid, approved business record?
2. Can responders determine which credentials, services and transactions were affected without relying on logs from a compromised host alone?
3. Does the incident plan define who can interrupt fund movement and how legitimate activity resumes safely?

These are concrete checks that can produce evidence, rather than a general assurance that the organization has deployed AI security tools.

The November update makes the warning more immediate. The underlying work remains disciplined payment authorization, verifiable incident recovery and a response process that can operate when the usual team is unavailable.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain security and AI products through clear writing and distribution.

[Book a 30-minute call](https://cal.com/paras-madan/30min).