CERT-In CRAFTY FALCON advisory: harden fintech payout APIs before the reported 3 Dec 2026 RBI deadline

Summary. CERT-In advisory CIAD-2026-0058, issued on 4 November 2026 and rated Critical, names the actor behind a campaign against India's payout APIs: CRAFTY FALCON, which CERT-In's finance-sector team CSIRT-Fin describes as an AI-assisted financial threat actor that attacks by calling the victim's own payment and disbursement APIs. It updates CIAD-2026-0046 of 9 October 2026, also Critical. Targets include NBFCs, digital lenders, fintechs, payment aggregators and crypto exchanges, and CERT-In says attacks are still succeeding, including at firms that had remediated. Attackers test routes with ₹1 transfers, get past IP allow-lists through shared third-party fetcher pools, and call disbursal APIs with stolen credentials from the victim's own whitelisted servers. Separately, MediaNama reported on 6 November that a confidential RBI advisory dated 3 November asks banks to require beneficiary whitelisting or maker-checker on existing API payout integrations by 3 December 2026, and CERT-In empanelled audits of existing NBFC API clients by 3 February 2027. RBI has not published that advisory, so both dates are reported. Our verdict: put a second control on every debit now; the plan below gets there by 3 December, 22 days away.

About this article. For CISOs and payments engineers at NBFCs, lenders, payment aggregators and fintechs that call bank payout APIs. On 11 November 2026 we checked CERT-In facts against both advisories (via Internet Archive copies of 5 November, as CERT-In's server refused automated requests), RBI facts against its 5 November Master Directions, and technical claims against IETF, OWASP, Google, Apple and AWS documentation. RBI dates are press-reported and labelled so. This is not legal or regulatory advice, and no company paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What CERT-In published, and what changed in November

CERT-In has two public advisories on this campaign. A fuller restricted version, with indicators of compromise, infrastructure fingerprints and detection rules, has gone to BFSI entities under the traffic light protocol. If your security team has not seen it, ask your sponsor bank or CSIRT-Fin. The public texts compare as follows.

The November text is blunt. CSIRT-Fin still receives reports of successful attacks, including from NBFCs and fintechs that had the earlier restricted TLP:AMBER advisories and had remediated. Attackers deliberately return to the same entities, sometimes after incomplete clean-up, and time attacks for holidays, weekends and other quiet windows.

On tooling, CERT-In names the ARTEX family of LLM-based tools, the PentAGI autonomous multi-agent penetration testing system, the Cairn attack search engine and the CyberStrikeAI framework, all publicly available. These tools run whole attack chains on their own, and the supporting infrastructure changes IP addresses within hours to days, so an IP blocklist will not keep up. The October advisory had already noted that the gap between first compromise and fraudulent transfer was shrinking, and that attacker IPs mostly traced to hosting providers.

How CRAFTY FALCON reaches the money

Combining the two advisories, the chain runs in seven steps.

1. Entry. Vulnerable internet-facing applications and middleware; deprecated, unauthenticated or unused APIs that allow unrestricted file uploads; long-lived static API tokens hard-coded in source; forged commits into repositories; plaintext credentials; and services without MFA (0046). The November advisory adds that newly published file-upload and deserialisation flaws are exploited as soon as they are public, ending in web shells on PHP and Node.js applications.

1. Non-production side door. Internet-facing UAT, staging and test environments are the way in; shared credentials, tokens or network paths then carry the attacker into production (0058).

1. Cloud control plane. Cloud management services, AWS Systems Manager and Lambda among them, are abused to run commands and drop files, so the activity looks like routine administration (0058).

1. Credential theft. Attackers study payment databases and integrations, then take payment aggregator, gateway and bank API credentials (0046).

1. Probe. A micro-value transfer, such as ₹1, confirms the route before large transfers (0058).

1. Cash-out. Disbursal or fund-transfer APIs are called directly from the victim's whitelisted servers with valid credentials, using dummy loan or transaction reference numbers that match no record. Several high-value IMPS or NEFT transfers go out in quick succession to mule accounts at several banks, where the money is withdrawn at once (0046). Payment aggregators' merchant settlement APIs are also abused to move funds (0058).

1. Cover-up. Logs are deleted or truncated, EDR tools tampered with and forensic traces cleaned (0046).

These calls skip every application-level check, from KYC and sanction to balance and per-transaction limits, and the fraudulent transfers exceeded those limits. Controls that lived only in the application did nothing.

The two assumptions that failed

Most payout stacks rest on two beliefs, and the advisories break both.

Only our servers can call the bank's payout API. Banks and aggregators allow-list a client's egress IPs. CRAFTY FALCON runs from inside those servers, so the allow-list approves the attack. CERT-In also found allow-lists bypassed through whitelisted third-party fetcher pools, such as content-acceleration and app-store review fetchers, which any internet user can make fetch an arbitrary URL. If you allow-listed a CDN or a store-review range, you allow-listed the internet.

Only our app calls our API. Attackers reverse-engineered application code, then sent unauthorised API calls from altered or repackaged app builds, defeating controls that assumed only the genuine client would call. Any rule enforced only in the app (loan sanctioned, KYC done, limit checked) can be skipped.

The fix for both: the payout call must carry proof of who is calling and that the earlier steps happened, checked on the server at the point of debit. OWASP files this class of weakness under API6:2023, unrestricted access to sensitive business flows.

What RBI reportedly told banks

Everything in this section comes from MediaNama's report of 6 November 2026, which cites an exclusive by Head and Tale. The RBI advisory is described as confidential and dated 3 November 2026; it was not on RBI's notifications or press release pages on 11 November. Treat each line as reported until your sponsor bank confirms it in writing.

MediaNama adds that whitelisting means pre-registered, verified end-customer accounts per client, with changes only through a separate MFA-protected channel; that narrow exceptions for highly automated payments need a written application and risk assessment; and that banks should flag transactions just below limits, holiday activity and bursts of new beneficiaries. A banker quoted in the report put individual frauds at ₹3 crore to ₹15 crore.

The home ministry side moved too. All India Radio reported on 5 November 2026 that the Indian Cyber Crime Coordination Centre (I4C) had told banks, NBFCs and fintechs to apply CERT-In's measures urgently and to report such incidents to CERT-In within six hours.

If you call a bank's payout API, expect your bank to ask before 3 December which safeguard you run.

Payout API hardening plan

Ten controls, mapped from CERT-In's recommendations to the systems that own them.

1. Put a second control on every debit

CIAD-2026-0046 asks for maker-checker or second-level verification on all fund movement, plus penny-drop and name-match beneficiary validation. Pick whitelisting, maker-checker, or both.

• Whitelisting fits lending disbursals to the borrower's own verified account: register it at KYC and reject payouts to anything unregistered.

• Maker-checker fits vendor payouts, refunds and settlement runs: the API call creates a pending instruction, and a second person or system approves it on a separate channel. CERT-In asks for exactly this on merchant settlement instructions sent through aggregator APIs.

• Either way, adding or changing a beneficiary goes through a separate MFA-protected flow, never the API key that sends money.

2. Bind the payout to its approval

CERT-In wants multi-stage flows bound cryptographically, so a debit API cannot run unless the validation stages before it did, and every payout checked against sanctioned records, rejecting reference IDs that match nothing. In practice, the sanction service issues a short-lived signed approval covering payout ID, beneficiary, amount and expiry, and the disbursal service refuses any call without one.

            def authorise_payout(req, store, keys, now):
    # 1. Caller identity: signed request with timestamp and nonce
    if abs(now - req.signed_at) > 300:
        reject("stale request")
    if not store.claim_nonce(req.nonce, ttl=600):
        reject("replayed nonce")
    if not keys.verify(req.key_id, req.signature, req.signed_fields()):
        reject("bad signature")

    # 2. Proof the earlier stages happened
    approval = keys.verify_approval(req.approval_token)
    if (approval.payout_id, approval.beneficiary, approval.amount) != \
       (req.payout_id, req.beneficiary, req.amount):
        reject("approval does not match payout")
    if not store.sanction_exists(req.reference_id):
        reject("reference has no sanctioned record")

    # 3. Beneficiary and limits
    if not store.beneficiary_registered(req.client_id, req.beneficiary):
        reject("beneficiary not whitelisted")
    store.check_limits(req.client_id, req.beneficiary, req.amount)  # per-txn, daily, velocity
          

3. Replace IP allow-listing with identity

CERT-In recommends identity-based controls in place of allow-listing shared fetcher pools: mutual TLS, cryptographically signed requests, or scoped API keys on dedicated vendor endpoints. The October advisory adds per-session authentication on all APIs, no long-lived static tokens, and keys held in a secrets manager or HSM with enforced rotation. Keep IP allow-lists as one layer, then add mutual TLS to the bank or aggregator (RFC 8705 defines certificate-bound OAuth tokens for this), request signing with the created, expires and nonce parameters defined in RFC 9421, and short-lived credentials issued per session.

4. Treat the client app as untrusted

CERT-In asks for server-side validation of every transaction and business rule, request signing with nonce and timestamp, and app attestation plus certificate pinning to catch altered or repackaged apps. Google's Play Integrity API lets your backend check that a request comes from your unmodified app on a genuine, certified device, and Apple's App Attest does the same on iOS with a hardware-backed key that signs server requests. Move every eligibility and limit check to the server, and treat requests that fail attestation as hostile.

5. Limits, velocity and the ₹1 probe

CERT-In wants real-time monitoring to flag a micro-value transfer to a new beneficiary followed by high-value transfers, to treat that pattern as a strong precursor of fraud, and to hold or review such flows. It also asks for velocity rules, cooling periods for new beneficiaries and amount-band anomaly detection on every payment and disbursement path. The October advisory adds per-transaction and per-day ceilings enforced at the API or payment stage, and near-real-time reconciliation against bank and aggregator statements.

6. Wall off non-production

Allow no shared credentials, tokens, API keys, databases or direct network paths between UAT, staging or test and production. Give internet-facing non-production systems production-grade hardening and monitoring, and alert on any access from non-production to production systems, credentials or data.

7. Watch the cloud control plane

Alert in real time from cloud audit logs on remote command execution, serverless code updates and new roles, users or access keys. Limit cloud management and serverless execution to approved principals, enforce instance metadata protections and least-privilege roles, deny wildcard egress in security groups, and give serverless functions no internet egress by default. On AWS, setting IMDSv2 to required means metadata requests without a valid session token get a 401 error.

8. Secrets, supply chain and patching

Ban hard-coded tokens in source and build code, run secret scanning across repositories and CI/CD, use short-lived least-privilege tokens, and rotate every build and deployment token. Enforce branch protection, commit signing and mandatory review on production branches, and alert on token use from unusual IPs, user agents or locations. Make deployment directories read-only for the runtime user, add file-integrity monitoring to catch web shells, and set a fast patching deadline for internet-facing apps, with file-upload and deserialisation flaws in PHP and Node.js first and WAF virtual patching as a stopgap. Keep a live API inventory and retire deprecated endpoints, the gap OWASP lists as API9:2023.

9. Default-deny egress

Both advisories ask for outbound allow-listing. CERT-In found that unrestricted HTTPS egress carried command-and-control traffic and stolen data, and recommends routing server egress through allow-listed proxies, with TLS inspection that alerts on self-signed certificates over non-standard ports.

10. Detection at machine speed, staffed at weekends

CERT-In asks for 24x7 monitoring with more staff and lower alert thresholds over holidays and weekends; SIEM correlation tuned for parallel, multi-technique, machine-speed attacks; SOAR-based automated containment; and honeypots, decoy admin panels and canary credentials, because autonomous agents enumerate everything and tend to touch decoys. Two items are new for most SOCs: watch for AI coding-agent processes running with permission checks off, and treat LLM API traffic from servers as a possible attack rig. CERT-In also wants written approval and scope for every penetration test, and crypto platforms to keep wallet keys in HSMs or cold custody with multi-signature withdrawals. Our guide to CERT-In's October 2026 advisory on AI agents covers agent controls in more depth.

Worked example: what limits do to a weekend attack

The figures are hypothetical. An NBFC disburses through a bank API with a per-transaction cap of ₹5 lakh and no other controls. At 01:10 on a Sunday, an attacker with stolen credentials sends ₹1 to a new mule account, sees it land, then fires 40 payouts of ₹4.9 lakh each, just under the cap, over 12 minutes.

• Per-transaction cap only. 40 × ₹4.9 lakh = ₹196 lakh, or ₹1.96 crore.

• Add a daily cumulative ceiling of ₹50 lakh per client. Ten payouts clear (10 × ₹4.9 lakh = ₹49 lakh); the eleventh would take the total to ₹53.9 lakh and is refused. Exposure: about ₹49 lakh.

• Add a 4-hour cooling period for new beneficiaries. No large payout to the mule can clear before 05:10 (01:10 plus 4 hours), and the ₹1-then-large pattern trips CERT-In's precursor rule and a hold. Exposure: the ₹1 probe.

• Add beneficiary whitelisting. The mule account was never registered, so even the ₹1 probe is rejected. Exposure: nil.

Against the ₹3 crore to ₹15 crore per incident that a banker described to MediaNama, the cheapest control here is the daily ceiling and the strongest is whitelisting.

A three-week plan to 3 December

3 December 2026 is 22 days from 11 November. The reported audit date for existing NBFC API clients, 3 February 2027, is 84 days away.

Reporting, and where this meets RBI's 5 November directions

RBI's Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators (RBI/DPSS/2026-27/475, 5 November 2026) are the standing rulebook for payment aggregators and other PSOs. Aggregators are classed as large non-bank PSOs, so the directions applied to them from the day RBI placed them on its website; small PSOs have until 1 April 2028. Paragraph 24 requires API controls that establish the identity of communicating applications and identify anomalous activity; paragraph 22(d) requires cyber-attacks and internal fraud to reach RBI within 6 hours of detection, with any cyber incident also reported to CERT-In. Our guide to RBI's cyber resilience directions covers the rest.

For this campaign, CERT-In asks entities to report to CERT-In and CSIRT-Fin at incident@cert-in.org.in with all relevant logs, and to report bulk fraudulent transactions to I4C through the CFCFRMS portal. CERT-In's directions No. 20(3)/2022-CERT-In of 28 April 2022 already require reportable incidents to reach CERT-In within 6 hours of noticing them, and ICT logs to be kept for a rolling 180 days within India. If customer personal data is touched, breach intimation under Rule 7 of the DPDP Rules applies from 13 May 2027, eighteen months after the Rules were published; see our DPDP Rules checklist. For the wider rule set, see the RBI rules that shape fintech architecture.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can inventory your payout APIs and build the whitelisting, maker-checker, signed-request and non-production isolation controls described above. Talk to us at /contact-us/.

Last updated: 11 November 2026.

References

1. CERT-In Advisory CIAD-2026-0058, Escalation of AI-Driven Attacks on BFSI Entities by Threat Actor CRAFTY FALCON, 4 November 2026 — CERT-In

1. CERT-In Advisory CIAD-2026-0046, Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities, 9 October 2026 — CERT-In

1. RBI meets bankers amidst rising AI cyber-attacks, mandates security audits, 6 November 2026 — MediaNama

1. API6:2023 Unrestricted Access to Sensitive Business Flows — OWASP API Security Top 10

1. I4C cautions banks and fintech firms against AI-driven cyberattacks, 5 November 2026 — News On AIR (All India Radio)

1. RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, February 2020 — IETF

1. RFC 9421, HTTP Message Signatures, February 2024 — IETF

1. Overview of the Play Integrity API — Android Developers (Google)

1. Establishing your app's integrity — Apple Developer Documentation

1. Use the Instance Metadata Service to access instance metadata — Amazon EC2 User Guide (AWS)

1. OWASP Top 10 API Security Risks, 2023 — OWASP

1. Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators, RBI/DPSS/2026-27/475, 5 November 2026 — Reserve Bank of India

1. Directions under sub-section (6) of section 70B of the IT Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022 — CERT-In

1. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), Gazette of India, 13 November 2025 — Ministry of Electronics and Information Technology