This guide summarises public advisories and regulatory documents as at 2 November 2026. It is not legal advice. Where a statement is our own analysis rather than a source’s, we say so.
1. What CERT-In reported
CIAD-2026-0046, “Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities”, was issued on 9 October 2026 with a Critical severity rating. It says CERT-In and CSIRT-Fin observed multiple campaigns against non-banking financial companies (NBFCs), digital lending platforms, fintech entities, payment service providers and wallet operators.
It describes three stages.
- Initial compromise. Exploitation of internet-facing applications and application server middleware; abuse of deprecated, unauthenticated or unused APIs with unrestricted file upload; stolen long-lived static API tokens hard-coded in source code; supply-chain compromise of source-code repositories through forged commits; plaintext credentials in configuration files, source code or databases; and applications and remote services without multi-factor authentication (MFA).
- Post-compromise. Web shells and backdoors for persistence, reconnaissance of payment databases and API integrations, and theft of payment aggregator, gateway and bank API credentials.
- Fund movement. Direct calls to disbursal and fund-transfer APIs using valid credentials from whitelisted infrastructure. The advisory says the fraudulent transactions carried dummy reference identifiers, exceeded per-transaction limits and moved money to mule accounts at several banks over IMPS and NEFT, with immediate withdrawal. Attackers also deleted or truncated logs and tampered with EDR tools.
CERT-In adds that the analysis points to the possible use of AI-assisted offensive tooling, and that the time between initial compromise and fraudulent transfer has been getting shorter in recent incidents. ETCISO reported on 16 October 2026, citing unnamed people familiar with the development, that as many as 20 financial institutions had been affected and that banks, NBFCs and fintechs had restricted payment and disbursement APIs in response. ETCISO said the losses could not be independently established. We treat the figure as reported, not confirmed.
CERT-In’s later advisory CIAD-2026-0049 (15 October 2026, Critical) lists “Payment-API keys stored in plaintext and readable from application runtimes” among the conventional weaknesses behind recent incidents, and tells BFSI and fintech entities to also implement the payment and disbursement API measures in CIAD-2026-0046.
2. Why a typical API pentest can miss this
The core problem is a design assumption, not an exotic bug: that the only way to reach the payout API is through the application that performs the checks. Once an attacker holds the payout credential and a foothold on a whitelisted server, IP allow-listing on the partner-bank side stops being a control.
In our experience, many fintech VAPT scopes are written around the customer journey: the mobile app, the web portal and the APIs they call. They tend to test whether a customer can abuse the flow, for example by changing an amount, skipping a step or reading another borrower’s loan. The advisory describes a different question: what happens when someone calls the last step directly, with the platform’s own credentials? That question often sits outside the agreed scope. This paragraph is our analysis, not a statement from CERT-In.
The OWASP API Security Top 10 (2023) gives useful names for parts of the problem: API2 Broken Authentication, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API9 Improper Inventory Management and API10 Unsafe Consumption of APIs. Our research on BOLA, API authorisation chains and business-logic flaws covers the customer-facing side of the same problem.
3. Turning the advisory into test objectives
CIAD-2026-0046 ends with a list of recommended actions, and one of them is to “conduct regular VA/PT including API security testing”. The others are controls. Each control can be turned into a question a tester can answer with evidence. This mapping is our suggestion.
| CERT-In recommended action (CIAD-2026-0046) | Test objective you can scope |
|---|---|
| Maintain a complete API inventory; formally decommission deprecated and unused APIs | Compare the declared inventory with what is reachable: old versions, staging hosts, callbacks, upload endpoints. |
| Enforce per-session authentication on all APIs; eliminate long-lived static tokens | Find where payout credentials live and how long they stay valid; search repositories, build variables, configuration and client bundles for keys. |
| Bind multi-stage transaction flows cryptographically so debit-stage APIs cannot be invoked without preceding validation stages | From an assumed foothold, call the disbursal step without a bound record from the creation, KYC and sanction steps. The debit stage should reject it. |
| Implement maker-checker or second-level verification for all fund movement | Check whether a single identity, a service account or a direct API call can complete a payout without the second approval. |
| Validate every payout against sanctioned or approved records; reject reference identifiers with no corresponding records | Submit references that do not exist, belong to another borrower or were already paid. Each should fail closed. |
| Enforce per-transaction and per-day cumulative ceilings at the API or payment stage | Test limits at the payout API, not only in the user interface. Include split transactions that stay under the per-transaction limit but exceed the daily one. |
| Beneficiary validation (penny-drop, name-to-account matching) and velocity limits on all disbursement paths | Confirm that every disbursement path, including manual and bulk ones, applies the same beneficiary validation, and that new-beneficiary bursts are throttled. |
| Restrict outbound (egress) traffic from production servers through allow-listing | From the assumed foothold, test which external destinations a production server can reach. |
| Store API keys and credentials in secret management solutions or HSMs; enforce rotation | Check whether a compromised application identity can read the payout secret in plain text, and whether rotation actually invalidates the old value. |
| Enforce MFA for payment platforms, administrative portals, payment and bank APIs and remote access | Confirm MFA on every internet-reachable admin, remote-access and partner interface. |
| Real-time monitoring of fund transfers; near-real-time reconciliation; centralised logging with at least 180 days’ retention; EDR with tamper protection | Did test transactions raise alerts or holds, did reconciliation flag them, and can central logs reconstruct the test? |
The assumed-foothold rows are important. They are the part most often left out. An assumed breach assessment, where the tester starts with the kind of access the advisory describes, tests them directly.
4. Testing money-moving APIs without moving money
A careful engagement handles live disbursement APIs with agreed rules, not by leaving the payout path out of scope. These are our recommended rules of engagement, with sources named where they apply.
- Get written approval for each environment. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (CISG-2025-02) say appropriate written approvals must be obtained before any penetration test. For payout testing, name the endpoints, the accounts and the maximum test amount in that approval.
- Prefer a production-like environment, and record the differences. The RBI’s Master Direction on IT Governance, Risk, Controls and Assurance Practices says post-implementation VA/PT should be performed on production. If it has to be done in a test environment, that environment’s version and configuration should resemble production, and any deviation should be documented and approved. CERT-In’s audit guidelines also require a report limited to staging to say clearly that production was not audited.
- Use partner sandboxes and designated test beneficiaries. Agree with your payment aggregator or partner bank which sandbox or low-value test accounts may be used. Never point a test at a real customer account.
- Agree a stop rule and a contact. If a test reaches a state where a real debit could happen, the tester stops and calls the named contact, and does not try to “prove” it. CERT-In’s audit guidelines already require critical and high findings to be notified as soon as they are found, not only in the final report.
5. What Indian regulators already expect
CIAD-2026-0046 is an advisory. Its recommendations are not a new legal obligation in themselves. The duty to test, though, already exists for many of the entities it names.
| Source | Who it covers | What it says about testing |
|---|---|---|
| RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, in effect from 1 April 2024), paragraph 26 | Commercial banks (excluding regional rural banks), small finance banks, payments banks, NBFCs in the Top, Upper and Middle Layers, credit information companies and named all-India financial institutions | For critical systems and those in the DMZ with a customer interface: VA at least once every six months and PT at least once every 12 months, and across the lifecycle (pre-implementation, post-implementation, after major changes). Testing by trained, independent experts. Vulnerabilities to be fixed in a time-bound manner, with compliance sustained so known vulnerabilities do not recur. A documented approach covering scope, coverage and a scoring mechanism such as CVSS |
| SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), as applied in NSE circular NSE/INSP/74185 (14 May 2026) | SEBI-regulated entities, including trading members | VAPT through a CERT-In empanelled auditor. The comprehensive scope lists API security testing, mobile application VA and PT, cloud VAPT, network segmentation and configuration audit, among others. Detailed reports and proofs of concept retained for at least three years |
| CERT-In Comprehensive Cyber Security Audit Policy Guidelines (CISG-2025-02, 25 July 2025) | Auditing organisations and auditee organisations | “API Security Audit” is one of the audit types a scope should name. Follow-up audits should be in the original scope, and the final report should be issued after closure and the follow-up audit |
Many fintechs and lending platforms are not themselves covered by the Master Direction but integrate with entities that are. Whatever your own status, the RBI paragraph is a reasonable benchmark for a customer-facing payout system: test at least yearly, test again after major changes, and fix to a timetable. That is our reading, not an RBI statement about unregulated firms.
Two more dates are worth knowing. For SEBI-regulated trading members outside the QSB and protected-system categories, the NSE and BSE circulars set 30 November 2026 as the due date for the ATR or revalidation report on FY 2025–26 VAPT, through the same CERT-In empanelled auditor. And the DPDP Rules’ security-safeguard duty in Rule 6 applies, on a plain count, from 13 May 2027. Our October guide covers that timeline in detail.
6. Retest and closure evidence that holds up
CIAD-2026-0049 makes the case for retesting bluntly. CERT-In says victims in the campaign it analysed that “remediated incompletely were attacked again within days, at greater scale”, and that agents re-used the same exposed credential in separate operations. Its recommended actions include: “Rotate any exposed credential, purge it from history and verify the fix externally”, and “Retest after remediation. Expect repeat attempts within days to weeks.”
For a payout API finding, “fixed” should mean more than a ticket marked done. The checklist below is what we suggest keeping for each finding.
Before you mark a finding closed
0 checked
Ticks stay in this browser. They are not saved anywhere.
For trading members, NSE attaches penalties to closure: a charge for each vulnerability not closed by the closure due date, up to ₹50,000 per Critical or High finding for a Qualified Regulated Entity. If a High, Critical or Medium vulnerability is still open 21 days after the compliance report was due, new client registration is prohibited and a seven-day disablement notice follows. Even without a penalty schedule, the lesson holds: the retest matters more than the report.
7. Six clauses to add to a fintech VAPT scope
Our VAPT RFQ guide covers the basics. For a lender, wallet or payment platform, we recommend adding these.
- Name the payout path. Every disbursal, refund, settlement and fund-transfer API, the partner integrations behind them and the credentials they use.
- Include an assumed-foothold phase. Start from a compromised application server or service account.
- Test business checks at the debit stage. Sequence binding, maker-checker, reference validation, ceilings and beneficiary checks, called directly.
- Hunt for secrets in what you ship. Repositories (including history) you make available, CI/CD variables, configuration and mobile and web client bundles.
- Validate detection. Agree in advance whether monitoring is in scope, and report what was caught.
- Put the retest in the price. CERT-In’s audit guidelines say the follow-up audit belongs in the original scope.
8. What this costs
As a planning reference, our penetration testing cost guide for India publishes indicative ranges, all excluding GST: API security from ₹25,000 to ₹60,000; web and API from ₹55,000 to ₹1,10,000; mobile from ₹35,000 to ₹80,000 per platform; external network and infrastructure from ₹25,000 to ₹65,000; cloud security review from ₹35,000 to ₹90,000; and internal and Active Directory from ₹55,000 to ₹1,35,000. These are planning bands, not fixed packages. The cost guide states that a retest is included within six months of the test.
9. Where PoCForge fits
PoCForge is an offensive-security firm based in Delhi NCR. We deliver VAPT remotely across India and work on site when an engagement needs it. For fintech and lending platforms we test APIs, web applications, mobile apps, cloud environments and external infrastructure, and run assumed breach assessments that start where this advisory’s attackers did.
We do not claim CERT-In empanelment. SEBI’s CSCRF VAPT and the ATR revalidation must be carried out by a CERT-In empanelled auditor, so we are not the right firm for those submissions. Where empanelment is not required, for example a lender’s own payout-path test, a partner-bank evidence request or an engineering-led retest before a formal audit, we are happy to scope against this guide. See Do you need CERT-In empanelled VAPT? Start from VAPT services in India or send us your draft scope.
Sources
- 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 Advisory CIAD-2026-0049: AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets, 15 October 2026
- Cyberattacks on 20 financial institutions prompt CERT-In advisory on API security vulnerabilities, ETCISO, 16 October 2026
- Comprehensive Cyber Security Audit Policy Guidelines, CERT-In, CISG-2025-02, version 1.0, 25 July 2025
- Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices, Reserve Bank of India, 7 November 2023
- NSE circular NSE/INSP/74185: Submission of VAPT Report for the FY 2025-26, 14 May 2026
- BSE Notice 20250926-63: Clarifications regarding VAPT timelines for FY 2025-26, 26 September 2025
- OWASP Top 10 API Security Risks – 2023
- Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), Gazette of India, 13 November 2025
Frequently asked questions
Is CIAD-2026-0046 mandatory?
It is a Critical advisory with recommended actions, not a new rule in itself. For entities covered by the RBI Master Direction, periodic VA/PT and time-bound fixes are already required; the advisory shows what those tests should now cover.
We already had an API pentest this year. Is that enough?
Check the scope. If it tested only what a customer could do through the app, it probably did not test a direct payout call from inside your infrastructure with valid credentials, which is the path the advisory describes. A short assumed-foothold test of the payout path can answer that.
Can you test a disbursement API without risking real money?
Yes, with care: a production-like environment or partner sandbox, designated test beneficiaries, written approval naming endpoints and a maximum amount, and a stop rule if a real debit becomes possible.
How often should payout APIs be tested?
For entities covered by the RBI Master Direction: VA at least every six months and PT at least every 12 months for critical and customer-facing systems, plus after major changes. A new partner bank, changed payout logic or a credential exposure are good reasons to retest early.
Can PoCForge do our SEBI VAPT or ATR revalidation?
No. The exchanges’ circulars require a CERT-In empanelled auditor, and PoCForge does not claim CERT-In empanelment. We can help where empanelment is not required, such as an internal payout-path test or remediation verification before the formal audit, provided that does not conflict with your auditor’s independence rules.
PoCForge publishes research and buyer guides to help organisations scope and buy security testing well. This article summarises public advisories and regulatory documents as at 2 November 2026. It is not legal advice, and it does not describe a named client engagement.
