India’s Computer Emergency Response Team has issued a critical advisory describing an AI-assisted campaign against banking, financial services and insurance organisations. The advisory names the threat actor Crafty Falcon and says the activity centres on abusing payment and disbursement APIs to make unauthorised transfers. The warning is more specific than a general alert about phishing or malware: it describes attackers using the victim organisation’s own transaction interfaces. That makes API authorisation, transaction controls and operational monitoring central to the response.
CERT-In identifies Crafty Falcon activity
CERT-In Advisory CIAD-2026-0058, issued on 4 November 2026, updates an earlier advisory dated 9 October. It says the agency’s financial-sector incident response team continued to receive reports from affected entities, including non-banking financial companies, digital lending platforms, fintech businesses, payment aggregators, payment service providers and cryptocurrency or virtual-asset service providers. CERT-In describes Crafty Falcon as an AI-assisted actor that surveys targets with machine intelligence, operates at machine speed and invokes the victim’s own payment and disbursement APIs.
Payment APIs sit at the centre of the campaign
Financial platforms commonly connect mobile applications, web portals, partner integrations, internal ledgers and payment gateways through APIs. Each connection adds a trust boundary that must be enforced. A service should not assume that a request is authorised simply because it came from a familiar application, passed an initial login or used a valid token. The system must also confirm that the account is permitted to perform the specific action, on the specific beneficiary, for the requested amount and under the relevant business rules.
The advisory calls for tighter transaction controls
CERT-In’s description of machine-assisted reconnaissance and rapid execution points to a threat that can automate parts of target discovery and transaction abuse. AI assistance may help an attacker inspect exposed interfaces, adapt scripts or move quickly between repeated steps. It does not mean the campaign is autonomous in every stage, nor does the advisory establish that every targeted organisation has been compromised. The important operational point is that defenders should expect attempts to scale and adapt rather than assume a fixed, manually operated attack pattern.
Organisations should inventory public and partner-facing payment APIs, identify the business owner for each endpoint and confirm that authentication and authorisation are enforced consistently. Review whether tokens are short-lived, whether scopes are narrowly defined, whether secrets are rotated and whether staging or test credentials can reach production. Separate development, UAT and production environments, and verify that administrative or service accounts cannot bypass normal transaction approvals.
Review transaction logs for unusual beneficiary changes, unexpected disbursement patterns and repeated low-value requests that could be used to test a route. Preserve relevant logs and evidence before changing systems, and coordinate security, fraud, engineering, legal and compliance teams. Where an incident is suspected, follow CERT-In reporting obligations and the instructions in the advisory. A hurried change that disables a control without checking downstream effects can create new exposure, so test mitigations and maintain a clear rollback plan.
Customers should treat unexpected payment notifications, beneficiary changes and requests to approve transfers as potential warning signs. They should contact the financial institution through a known channel rather than using a link or phone number in an unsolicited message. Businesses that connect to payment providers should review API keys, webhook validation, partner permissions and the process used to reconcile settlement records. A supplier integration should have only the permissions it needs, not broad access to unrelated accounts or transaction functions.
The advisory’s restricted technical annex is not available in the public notice, so organisations should avoid treating public summaries as a complete indicator list. CERT-In says the detailed version, including infrastructure fingerprints and detection rules, has been shared with relevant financial entities. That distinction matters: defenders should obtain the current restricted indicators through the appropriate channels and combine them with behavioural monitoring, rather than rely on static public indicators alone.