How 187 reported unauthorised RTGS transfers raise critical questions about SFMS security, payment message integrity, settlement account reconciliation, cyber risk monitoring and RBI technology governance requirements.
India’s banking system depends on interconnected technology platforms to process payments, exchange financial messages and settle transactions securely.
While customer-facing digital banking channels receive considerable attention in cybersecurity discussions, the infrastructure connecting banks’ core banking systems, financial messaging interfaces and settlement accounts is equally critical.
A recent incident involving Central Bank of India has highlighted why these interconnected payment systems require strong transaction controls, independent reconciliation, continuous monitoring and effective incident-response arrangements.
According to media reports of a police complaint, 187 unauthorised transactions involving approximately ₹13.97 crore were reported between 15 and 17 October 2026. The transfers reportedly involved the bank’s settlement account with the Reserve Bank of India (RBI) and 36 beneficiary accounts.
The case raises questions about transaction authenticity, payment message validation, settlement-account oversight and the ability to detect discrepancies between financial messaging and internal banking records.
Importantly, the bank subsequently clarified that the issue involved its local RTGS server interface, that its core banking system remained secure and that no customer accounts were affected.
For banking risk professionals, the principal lesson is that payment system security must be assessed across the entire transaction lifecycle, not only at the customer account or application level.
1. Central Bank of India RTGS Incident 2026: What Happened?
According to reports published on 24 October 2026, Central Bank of India approached the Mumbai Nodal Cyber Police regarding suspected unauthorised transactions involving its RBI settlement account.
The reported complaint contained the following details:
| Incident detail | Reported information |
|---|---|
| Financial institution | Central Bank of India |
| Incident period | 15–17 October 2026 |
| Number of transactions | 187 |
| Reported amount | Approximately ₹13.97 crore |
| Beneficiary accounts | 36 |
| Payment infrastructure involved | RTGS / SFMS environment |
| Investigation | Mumbai Nodal Cyber Police |
| Technical root cause | Not publicly established |
Reported Transaction Timeline
| Date | Reported unauthorised transfers |
|---|---|
| 15 October 2026 | 6 |
| 16 October 2026 | 88 |
| 17 October 2026 | 93 |
| Total | 187 |
The complaint reportedly stated that these transactions could not be traced through the bank’s usual branch, internet banking, mobile banking or core banking transaction records.
Reports also indicated that partial traces associated with 10 accounts were identified in SFMS database logs, but corresponding transaction identifiers were absent from the bank’s records.
The complaint alleged unauthorised access involving the central SFMS messaging environment operated by Indian Financial Technology and Allied Services (IFTAS).
However, this allegation should not be treated as confirmation that IFTAS infrastructure was compromised.
What Did Central Bank of India Clarify?
On 19 October, the bank reported a technical issue in its RTGS outward payment system and stated that affected systems had been isolated while investigations were undertaken.
In a subsequent clarification reported on 26 October, the bank stated that:
- A technical issue had been observed in the interface environment of its localised RTGS server.
- Its Core Banking System (CBS) remained secure.
- No customer accounts had been affected.
- RTGS services had been fully restored across channels.
These statements are significant because they distinguish the reported irregularities in the payment environment from any confirmed compromise of customer accounts or the core banking system.
The complete technical sequence, authorisation mechanism and cause of the reported transactions remain matters for investigation.
2. How Do RTGS, SFMS and Bank Settlement Accounts Work?
To understand the risk implications, it is important to distinguish the different components of India’s large-value payment infrastructure.
What Is RTGS?
Real Time Gross Settlement (RTGS) is a payment system operated by RBI in which funds-transfer instructions are settled individually, in real time, through the central bank’s books.
Because RTGS payments are settled individually and are generally final and irrevocable once settled, effective controls before and during payment processing are particularly important.
What Is SFMS?
The Structured Financial Messaging System (SFMS) provides structured financial messaging between participating financial institutions.
It supports the exchange of payment-related messages and acts as an important communication component of India’s banking payment infrastructure.
SFMS and RTGS perform different functions:
- SFMS: Supports the secure exchange of financial messages.
- RTGS: Facilitates the actual settlement of qualifying fund transfers.
- Core Banking System: Maintains customer accounts and banking transaction records.
- Settlement Account: Supports the movement and settlement of funds through the central bank’s payment infrastructure.
Simplified RTGS Transaction Flow
Customer Payment Instruction → Core Banking System → Bank Payment Interface / SFMS → Central Messaging Infrastructure → RTGS Settlement → Beneficiary Bank → Transaction Confirmation
In a properly controlled environment, each material stage should generate information that can be authenticated, traced and reconciled with the underlying authorised transaction.
For example, a bank should be able to establish:
- Which authorised customer or banking process initiated the transfer?
- Was the payment instruction authenticated and approved?
- Does the payment message match the original instruction?
- Was the transaction settled through the authorised settlement mechanism?
- Is there a corresponding entry in the bank’s internal records?
- Can the settlement and beneficiary confirmation be independently verified?
The central risk arises when the records from these different stages cannot be reliably matched.
3. Why Missing CBS and SFMS Records Represent a Significant Payment Systems Risk
One of the most important details in the reported complaint was the apparent absence of corresponding transactions in the bank’s ordinary banking records.
This is significant because banking payment systems operate through multiple connected applications, databases and communication interfaces.
A discrepancy between these environments can create risks involving financial integrity, settlement accuracy, transaction traceability and operational control.
A. Payment Message Integrity Risk
A financial message must accurately represent an authorised payment instruction.
Banks should examine whether their systems can detect:
- Messages without corresponding approved transactions.
- Unexpected modifications to transaction details.
- Invalid or inconsistent transaction identifiers.
- Payment instructions outside authorised processing workflows.
- Duplicate or improperly sequenced messages.
The objective is to ensure that a payment message cannot be treated as sufficient evidence of authorisation merely because it has entered a trusted messaging environment.
B. Settlement Account Reconciliation Risk
Settlement-account movements should be reconciled against authorised transactions and payment-system records.
A reconciliation process should identify:
- Settlement debits without corresponding customer or treasury instructions.
- Transactions without matching CBS references.
- Unexpected changes in settlement balances.
- Unmatched transaction identifiers.
- Unusual aggregate payment values or volumes.
The absence of a reliable match between an authorised instruction and settlement movement should trigger investigation.
C. Payment Interface and Application Control Risk
The interface connecting a bank’s internal systems with external messaging or settlement infrastructure is a critical control point.
Banks should assess:
- Authentication between connected systems.
- Message validation and integrity checks.
- Access permissions for payment applications.
- Change-management controls over interface software.
- Security and completeness of transaction logs.
- Mechanisms to detect unexpected processing behaviour.
D. Cybersecurity and Privileged Access Risk
Critical payment systems require strong governance over both human users and machine-to-machine access.
Relevant safeguards include:
- Privileged Access Management (PAM).
- Strong authentication and secure credential management.
- Segregation of duties.
- Restricted administrative access.
- Monitoring of service accounts.
- Independent logging of privileged activities.
These safeguards are important areas for review, but the available information does not establish that privileged-access controls failed in this incident.
4. What Are the Key Early Warning Indicators for RTGS and Settlement Account Risk?
Payment-related risk monitoring should extend beyond individual transaction amounts to include patterns, mismatches and processing anomalies.
The following indicators can support a risk-based monitoring framework.
| Early warning indicator | Why it matters |
|---|---|
| Settlement debit without matching CBS entry | May indicate an unexplained or unauthorised settlement movement |
| Payment message without a verified originating instruction | Raises questions about transaction authenticity |
| Sudden increase in outward RTGS volume | May signal unusual system or transaction behaviour |
| Multiple payments to newly observed beneficiaries | Can indicate concentration or suspicious payment patterns |
| Missing or inconsistent transaction identifiers | Weakens traceability and reconciliation |
| Unexpected payment activity during unusual operating patterns | May indicate processing anomalies requiring review |
| Unexplained differences between SFMS and settlement records | Suggests an interface, processing or reconciliation discrepancy |
| Unexpected changes to payment system access or configuration | May indicate increased technology or security risk |
These indicators should be calibrated to each bank’s operating profile, transaction volumes and risk appetite.
A monitoring alert is not proof of fraud. It is a signal requiring timely validation and appropriate escalation.
5. RBI Guidelines Relevant to RTGS, Payment Security and Settlement Account Controls
The incident is particularly relevant in the context of RBI’s consolidated regulatory directions issued on 31 July 2026.
Three frameworks deserve attention.
A. RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026
The Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, updated on 1 October 2026, address several control areas relevant to payment infrastructure.
Important provisions include:
IT and Information Security Risk Management: Paragraphs 39–40
Banks are required to incorporate technology and cybersecurity risks into their risk management arrangements and maintain appropriate governance, controls and oversight.
Straight-Through Processing: Paragraphs 141–142
These provisions address secure and appropriately automated data transfers between critical applications, supported by authentication, checks and audit trails.
For payment systems, the practical implication is the need to evaluate the integrity of information moving between connected applications.
Cyber Incident Management: Paragraphs 180–183
The directions address containment, investigation, root-cause analysis, corrective measures and reporting.
They include reporting of cyber incidents through RBI’s DAKSH platform within six hours of detection, along with proactive notification to CERT-In.
The applicability of specific cyber-incident reporting requirements depends on the nature and classification of the event; a technical fault should not automatically be labelled a cyberattack.
Risk-Based Transaction Monitoring: Paragraph 209
Banks are required to implement risk-based transaction monitoring or surveillance as part of their fraud risk management arrangements across delivery channels.
Cyber Security Operations Centre: Chapter VI
The framework addresses continuous security monitoring, incident analysis, escalation, investigation and coordination.
B. RBI Digital Payment Security Controls Directions, 2026
The Reserve Bank of India (Commercial Banks: Digital Payment Security Controls) Directions, 2026 also contain relevant requirements concerning transaction security and reconciliation.
Paragraph 57 provides for a real-time or near-real-time reconciliation framework for applicable digital payment transactions, with an outer limit of 24 hours from receipt of settlement files.
For banks reviewing their payment ecosystem, this reinforces the importance of effective reconciliation between banking systems and relevant payment participants.
However, the scope and applicability of these provisions must be assessed carefully rather than assuming every settlement-account activity is subject to identical processing requirements.
C. RBI Fraud Risk Management Directions, 2026
The Reserve Bank of India (Commercial Banks: Fraud Risk Management) Directions, 2026 reinforce the importance of fraud prevention, early detection, timely reporting and governance.
The framework includes Early Warning Signals for banking transactions beyond traditional credit accounts.
For payment-system risk teams, this supports a coordinated approach involving Fraud Risk, IT Risk, Treasury Operations, Cybersecurity and Internal Audit.
The regulatory lesson is clear: technology security, financial transaction monitoring and operational controls should not operate as isolated functions.
6. How Should Banks Investigate an Unexplained RTGS Settlement Transaction?
The available information does not establish precisely how the Central Bank of India incident occurred.
Nevertheless, the reported circumstances provide a useful basis for a practical investigation framework.
Step 1 – Validate the Settlement Discrepancy
The investigation team should identify every unexplained settlement movement and compare it with authorised payment instructions.
This may include checking:
- Settlement account statements.
- CBS records.
- Payment application records.
- SFMS messages.
- Transaction identifiers and timestamps.
- Beneficiary account details.
Step 2 – Reconstruct the Payment Message Lifecycle
Investigators should determine where each transaction first appears in the available records.
Questions include:
- Was a valid originating instruction recorded?
- Was a corresponding payment message generated?
- Which system processed or transmitted the message?
- Does the transaction appear in the central settlement record?
- Were any messages rejected, altered or retransmitted?
Step 3 – Review Access and System Activity
The review should examine relevant application logs, service-account activity, privileged access, authentication events and configuration changes.
Investigators should preserve evidence before taking actions that might overwrite relevant records.
Step 4 – Assess Potential Processing and Control Failures
Possible explanations requiring investigation may include:
- Payment application or interface malfunction.
- Message-processing inconsistencies.
- Incorrect system configuration.
- Compromised credentials or unauthorised access.
- Incomplete or inconsistent transaction logging.
- Reconciliation or exception-management weaknesses.
These are alternative investigative hypotheses, not established findings about Central Bank of India.
Step 5 – Contain, Report and Recover
The incident-management process should coordinate technical containment with the bank’s payment operations, settlement functions and relevant authorities.
Depending on the facts and applicable requirements, this may involve:
- Isolating affected systems or interfaces.
- Restricting compromised access.
- Preserving logs and forensic evidence.
- Notifying relevant payment-system stakeholders.
- Coordinating investigations and potential recovery efforts.
- Assessing regulatory reporting obligations.
- Documenting root causes and corrective actions.
7. Practical RTGS and SFMS Control Checklist for Banks
Banks can use the following questions to review the governance of their payment infrastructure.
| Control area | Practical review question |
|---|---|
| Payment authorisation | Can every settled payment be traced to an approved originating instruction? |
| Message integrity | Are payment messages authenticated and protected against unauthorised modification? |
| CBS reconciliation | Are unmatched payment messages or settlement entries automatically identified? |
| Settlement monitoring | Are settlement-account movements independently monitored and reconciled? |
| Access management | Is privileged access to payment interfaces restricted, approved and monitored? |
| Technology logging | Are relevant transaction and administrative logs complete, protected and retrievable? |
| Transaction monitoring | Are unusual volumes, beneficiary patterns and settlement anomalies monitored? |
| Third-party oversight | Are responsibilities and incident procedures clear across connected service providers? |
| Incident response | Can the bank rapidly isolate an affected interface and coordinate with stakeholders? |
| Internal audit | Are payment system interfaces, reconciliation controls and exception processes independently tested? |
This is an illustrative risk-review checklist, not an assertion that Central Bank of India failed these controls.
8. Scenario Analysis: Could Automated Reconciliation Detect Unauthorised RTGS Transfers?
Consider a hypothetical bank with the following daily records:
| System | Transactions recorded |
|---|---|
| Core Banking System | 4,000 authorised outward payments |
| Bank payment interface | 4,005 transmitted payment messages |
| RTGS settlement records | 4,005 settled transactions |
| Unmatched items | 5 |
In this hypothetical example, the bank has five payment messages and settlement entries without matching authorised CBS transactions.
An effective control framework would not automatically conclude that the five items were fraudulent.
Instead, the system should:
- Generate reconciliation exceptions.
- Validate transaction references and timestamps.
- Check whether legitimate adjustments or processing differences explain the items.
- Escalate unresolved or suspicious transactions.
- Assess whether additional payment processing should be restricted.
- Preserve investigation evidence and document the final resolution.
The essential principle is that settlement success must not be confused with proof that an originating payment was authorised.
Because RTGS settlement is final, timely prevention and early exception detection are particularly important.
9. Questions for Banking CISOs, CROs, Treasury Teams and Internal Auditors
The reported incident provides a useful opportunity for banking professionals to evaluate the effectiveness of their own controls.
For CISOs and Technology Risk Teams
- Are critical payment interfaces included in enterprise technology risk assessments?
- Can security monitoring detect unusual payment-interface activity?
- Are machine credentials and privileged access independently reviewed?
For Treasury and Payment Operations
- Can settlement-account movements be independently reconciled with authorised instructions?
- How quickly are unexplained settlement differences identified and escalated?
- Are exception-monitoring responsibilities clearly assigned?
For Fraud Risk and Operational Risk Teams
- Are settlement anomalies included in fraud-related early warning indicators?
- Are suspicious payment patterns reviewed across system boundaries?
- Are significant payment incidents assessed for financial, operational and reputational impact?
For Internal Audit
- Does the audit plan cover the complete RTGS payment lifecycle?
- Are payment interface controls independently tested?
- Can the institution demonstrate timely detection and resolution of unexplained transactions?
For Boards and senior management, the broader question is whether technology controls provide sufficient assurance over the integrity of critical financial transactions.
10. Strengthening IT Risk and Payment Systems Governance Capabilities
Incidents involving complex payment infrastructure illustrate why financial institutions require more than basic cybersecurity awareness.
Professionals responsible for IT Risk, Technology Governance, Treasury Operations, Compliance, Fraud Risk and Internal Audit need to understand how critical systems interact and how weaknesses at the interfaces can translate into financial and operational exposures.
Relevant professional capabilities include:
- IT risk assessment and risk registers.
- Application and interface controls.
- Transaction integrity and reconciliation governance.
- Privileged-access and information security oversight.
- Technology risk indicators and management reporting.
- Incident management and operational resilience.
- IT audit, control testing and assurance.
- Third-party technology risk management.
To support these capabilities, the Risk Management Association of India (RMAI) offers its professional programme, IT Risk & Technology Governance in Financial Institutions, through its training arm, Smart Online Course.
The programme covers seven specialised modules addressing IT governance, RBI regulatory expectations, risk assessment, operational resilience, outsourcing, IT audit, cloud technology and AI governance.
Participants also receive practical implementation resources, including IT risk registers, governance assessment checklists, KRI dashboards, vendor risk assessments and IT audit work programmes.
Conclusion: What Does the Central Bank of India RTGS Incident Teach Banking Risk Professionals?
The Central Bank of India RTGS/SFMS incident provides an important case study in payment-system technology risk and settlement-account governance.
The reports concerning 187 unauthorised transfers worth approximately ₹13.97 crore raise significant questions about payment message integrity, transaction traceability and reconciliation controls.
At the same time, the bank’s clarification that its core banking system and customer accounts remained secure must be considered alongside the allegations under investigation.
The full technical explanation cannot be established from the public information currently available.
For the wider banking industry, the principal lesson is that critical payment infrastructure must be governed as an interconnected system of applications, messages, accounts, controls and responsibilities.
Banks should be able to demonstrate that every material settlement movement is supported by an authentic payment instruction, that discrepancies are identified promptly and that incident-response arrangements can contain potential financial and operational consequences.
Effective payment-system risk management depends not only on protecting individual systems, but also on ensuring the integrity, traceability and independent assurance of the transactions moving between them.
Sources and Regulatory References
- NDTV Profit — Central Bank of India Flags ₹13.97 Crore Unauthorised Transactions, 24 October 2026
- Central Bank of India — Official Press Releases, including RTGS clarification
- The Economic Times — Central Bank of India Clarifies Customer Accounts Are Safe, 26 October 2026
- RBI — RTGS System Frequently Asked Questions
- RBI Commercial Banks — Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026
- RBI Commercial Banks — Digital Payment Security Controls Directions, 2026
- RBI Commercial Banks — Fraud Risk Management Directions, 2026
Information reviewed as of 27 October 2026. Reported police allegations, bank statements and hypothetical risk scenarios are distinguished throughout. The article is intended for professional education and does not constitute a forensic determination or legal finding.
