TL;DR
- What happened: On November 3, 2026, the RBI sent banks a confidential advisory tightening security for API-based fund transfers, as reported by The Head and Tale.
- Why: Smaller NBFCs reportedly lost close to Rs 300 crore to cyber fraud in two months after attackers abused payout APIs and loan origination systems.
- Who it covers: Scheduled commercial banks and urban co-operative banks offering API fund transfers, plus the NBFCs, fintechs, payment aggregators and banking correspondents that connect to them.
- What’s due: Transaction limits and incident procedures apply immediately. Beneficiary whitelisting or maker-checker on existing integrations is due by December 3, 2026. CERT-In audits of existing NBFC clients are due by February 3, 2027.
- The bigger point: The checklist sets a minimum. The attacks behind it used valid-looking API calls, so banks also need to understand how each API that moves money is supposed to behave.
What the RBI API security advisory is
The RBI’s November 2026 advisory makes banks responsible for securing every API arrangement that can move money, including the ones their NBFC and fintech clients use. Specifically, the advisory was issued on November 3, 2026, by the Cyber Security and IT Risk (CSITE) Group of the RBI’s Department of Supervision. Because it is confidential, its contents are known through The Head and Tale, which first reported them on November 5.
Who it applies to
- Banks: Scheduled commercial banks (SCBs) and urban co-operative banks (UCBs) that offer API-based fund-transfer services.
- NBFC clients: NBFCs that use bank APIs, whether they connect directly or through a third-party service provider (TPSP). A companion advisory sets cybersecurity requirements for NBFCs themselves.
- Non-NBFC clients: Banking correspondents, payment aggregators, payment service providers and other fintechs that call bank APIs.
Why the RBI acted
The advisory follows a wave of attacks on the systems that start fund transfers and disbursements. According to the report, attackers compromised transaction-originating systems such as Loan Origination Systems (LOS). In addition, they changed beneficiary account details inside payout API requests, so the money went to accounts they controlled. What’s more, some of the attacks used AI-powered tools.
As a result, the losses were significant. The Economic Times reported close to Rs 300 crore in cyber fraud at smaller NBFCs over two months, with single incidents typically running between Rs 3 crore and Rs 15 crore. For example, one mid-sized bank reportedly received more than 20 attack alerts in four days. It stopped most of them, but one of its NBFC clients was hit.
Meanwhile, the RBI advisory lands alongside CERT-In’s warnings about CRAFTY FALCON, an AI-assisted actor abusing payment and disbursement APIs. We break down how those attacks work in our analysis of the Crafty Falcon advisory.
What changes for banks
Until now, many banks treated an NBFC’s API security as the NBFC’s problem. The advisory ends that. From now on, a bank must know every API client it serves, cap what each one can move, verify where the money goes, and watch API transactions for fraud the same way it watches other channels.
RBI API advisory deadlines
Three requirements apply immediately. However, the biggest technical change, whitelisting or maker-checker on existing integrations, is due December 3, 2026.
| Requirement | Deadline |
|---|---|
| Per-transaction and daily limits for every API client | Immediate |
| Incident reporting and recovery procedures | Immediate |
| Risk assessment of non-NBFC API clients | Immediate |
| Intra-day and velocity limits | Within one month |
| Beneficiary whitelisting or maker-checker on existing integrations | December 3, 2026 |
| Technical changes to existing API set-ups | December 3, 2026 |
| CERT-In-empaneled audit of existing NBFC clients | February 3, 2027 |
| Periodic audit of non-NBFC clients | Within three months |
| Threat briefings for non-NBFC clients | Every three months |
The RBI API security compliance checklist
In total, the advisory asks banks for ten controls across inventory, transaction controls, monitoring and response. Some are process changes. Others, however, need real-time visibility into API traffic, which is where most banks have gaps today.
- API client inventory: Banks must have a complete inventory of every API client today, covering business profile, services used, transaction limits and key contacts.
- Transaction limits: Per-transaction and daily limits must already be in place for every API client. This requirement took effect immediately.
- Velocity limits: Intra-day or velocity limits have to be live within one month, so banks need to configure them now.
- Beneficiary whitelisting: Banks must let clients pre-register verified beneficiaries and reject payouts to any other account, with changes routed through a separate, MFA-protected channel. Existing integrations must comply by December 3, 2026.
- Maker-checker or out-of-band confirmation: Where whitelisting isn’t used, API debits need extra authorisation, for all transactions or above a risk-based threshold. Every client must be on at least one of these two safeguards by December 3.
- CERT-In audits: Existing NBFC clients need a CERT-In-empanelled audit by February 3, 2027, and new NBFCs need one before onboarding. Non-NBFC clients need an audit within three months, so banks should book auditors now.
- Fraud monitoring with client baselines: API transactions belong in fraud monitoring from today. Banks must flag volume spikes, near-limit amounts, off-hours activity, bursts of new beneficiaries, mule-account patterns and repeated failed or invalid requests.
- Technical fingerprints: Banks should be tracking changes in the user-agent, app version, operating system and network attributes of every API caller.
- Incident response: Reporting and recovery procedures apply immediately. Banks must be ready to restrict access or revoke credentials the moment a client reports a compromise, and to restore access only after investigation.
- The bank’s own infrastructure: Access management, segmentation, patching and monitoring need tightening now, because the RBI warns that attackers may use a compromised client as a stepping stone into the bank.
Beyond these ten controls, two items sit mostly outside any tool: briefing non-NBFC clients on threats every three months, and documenting exceptions. The advisory allows narrow exceptions for highly automated processes where neither whitelisting nor maker-checker is practical. Clients must apply in writing, and banks must record their risk assessment.
How AppSentinels supports the checklist
While several of these controls are policy and process changes, many depend on knowing how APIs are actually being used. That is where AppSentinels can help.
- Client inventory: To start, AppSentinels helps discover APIs and map which clients call which endpoints, including undocumented ones.
- Transaction and velocity limits: It also gives visibility into each client’s typical API usage, which can inform where limits are set. At the same time, it helps surface unusual call rates and bursts of activity on sensitive APIs.
- Beneficiary whitelisting and maker-checker: In addition, it can help flag payout requests that deviate from expected flows, such as an unexpected beneficiary change or a request that bypasses an approval step.
- CERT-In audits: Between audits, API security testing can help find business logic flaws before attackers do.
- Fraud monitoring and technical fingerprints: Moreover, behaviour-based monitoring can help detect several of the anomalies the RBI lists as they happen, and it adds context on the software calling each API.
- Incident response: When something does go wrong, it can help contain suspicious activity and provide API activity records to support investigation.
- Partner traffic: Finally, visibility into partner API traffic can help spot abuse arriving through a trusted client.
Why the checklist alone won’t stop the next attack
Every control on the RBI list works against a known pattern. However, the attacks behind the advisory were built to look normal. Consequently, static controls will catch some of them and miss the rest.
- Limits get gamed. The RBI itself lists transactions just below limits as an anomaly to watch. In practice, an attacker who learns the threshold simply stays under it.
- Valid calls carry the abuse. A payout request with a changed beneficiary, or a small test transfer before a large one, is a well-formed API call that passes a WAF or gateway. Our Crafty Falcon analysis explains how AI-assisted attackers exploit this.
Instead, what catches these attacks is context: knowing how each API that moves money is supposed to be used, by which client, in what sequence and for what amounts. With that baseline in place, a test transfer followed by a large payout, or a beneficiary edited mid-request, stands out the moment it happens.
In short, this is business logic security. It is the layer AppSentinels was built for, and it is what gives each control on the RBI checklist its full protective value.
Get ready for December 3
With the deadline close, AppSentinels can help banks and NBFCs discover the APIs that move money, understand how each client uses them, and spot business logic abuse as it happens. Book a demo to learn more.
Frequently asked questions
What is the RBI API security advisory?
It is a confidential RBI advisory dated November 3, 2026, that tightens security for API-based fund transfers. It requires banks to inventory API clients, set transaction and velocity limits, enforce beneficiary whitelisting or maker-checker, audit clients and monitor API transactions for fraud.
Who does the RBI API advisory apply to?
It applies to scheduled commercial banks and urban co-operative banks that offer API-based fund transfers. It also covers the NBFCs, payment aggregators, payment service providers, banking correspondents and fintechs that use those APIs.
What is the deadline for beneficiary whitelisting or maker-checker?
Banks must put beneficiary whitelisting or maker-checker in place on existing API integrations by December 3, 2026. Transaction limits and incident procedures apply immediately.
How does AppSentinels help banks meet the RBI API security advisory?
AppSentinels helps banks discover the APIs that move money, understand how each client uses them, and spot activity that departs from expected business flows. That supports several items on the RBI checklist, including the client inventory, velocity limits and fraud monitoring with client baselines.
Can AppSentinels help detect beneficiary tampering in payout APIs?
It can help. AppSentinels focuses on business logic security, so it can flag payout requests that depart from the expected flow, such as a beneficiary changed mid-request or a new beneficiary that skips registration.
Do NBFCs and fintechs need to act on the RBI advisory?
Yes. Banks must audit, limit and monitor their API clients, so NBFCs, fintechs and payment aggregators that use bank APIs should expect CERT-In audits, transaction limits and beneficiary controls. A companion advisory also sets cybersecurity requirements for NBFCs directly.
