CERT-In's Fund-Safety Checklist: 13 Controls Payment and Fintech Firms Must Enforce Now
CERT-In has set out 13 controls for banks, NBFCs, fintechs and payment firms after attackers hijacked payment and disbursement APIs to make unauthorised fund transfers. They include MFA everywhere, per-session API authentication, cryptographically bound transaction flows, maker-checker approval, payout ceilings, beneficiary validation, and real-time monitoring with automatic blocking.
The Indian Computer Emergency Response Team (CERT-In) has listed the controls financial entities should enforce to stop unauthorised fund transfers through payment and disbursement APIs.
The list comes from its advisory CIAD-2026-0046.
The measures target the forgotten APIs, static tokens and unchecked payout flows that attackers have abused.
Lock Down Access
- Enforce multi-factor authentication (MFA) on payment platforms, admin portals, payment and bank APIs, and remote access services.
- Store all API keys and credentials in secret management solutions or hardware security modules (HSMs), and rotate them regularly.
- Restrict outbound traffic from production servers to an allow-list.
Secure the APIs
- Keep a complete API inventory, and formally decommission deprecated and unused APIs.
- Require per-session authentication on every API, and get rid of long-lived static tokens.
- Cryptographically bind multi-stage transaction flows, so debit-stage APIs cannot be called without the earlier validation stages.
Control Every Payout
- Require maker-checker or second-level approval for all fund movements.
- Check every payout against approved records, and reject reference IDs that have no matching record.
- Apply per-transaction and daily cumulative limits at the API and payment stage.
- Validate beneficiaries with penny-drop and name-to-account matching, and set velocity limits on all disbursement paths.
Watch in Real Time
- Monitor fund transfers in real time with velocity, amount-band and new-beneficiary checks, and block or hold suspicious ones automatically.
- Reconcile system records against bank and aggregator statements in near real time.
- Centralise logging and keep logs for at least 180 days.
What Banks Should Do About Fintech Clients on Their APIs
When a fintech moves money through a bank's API, a breach at the fintech becomes the bank's loss too.
Banks should not assume the partner's security is enough:
- Vet before onboarding: Audit the fintech's API security, key storage, MFA and logging before giving it access, and repeat the audit every year.
- Least-privilege access: Give each client only the API scopes it needs, such as payouts but not account lookups, and bind access to allow-listed IPs and mutual TLS certificates.
- Short-lived credentials: Issue tokens that expire, require rotation, and revoke them at once on any suspicion.
- Bank-side limits: Apply each client's own per-transaction, daily and velocity caps at the bank's end, whatever limits the fintech sets.
- Independent beneficiary checks: Run penny-drop and name-match checks at the bank, and hold payouts to new or unusual beneficiaries.
- Watch for anomalies: Flag sudden spikes in volume, off-hours bursts, calls that skip stages, and reference IDs with no matching record.
- Kill switch: Be able to suspend a single client's API access within minutes, without affecting others.
- Contract terms: Require incident reporting to the bank within hours, the right to audit, and logs kept for at least 180 days. Agree in advance who pays for losses from a breach.
- Shared drills: Run joint incident-response exercises so both sides know who freezes what, and how fast.
Why It Matters
CERT-In's newer advisory CIAD-2026-0049 warns that AI agents now find and exploit exactly these weaknesses, such as exposed keys, dormant APIs and weak access controls, within hours rather than days.
For payment firms, an unenforced control can mean money gone before anyone notices.