187 reported unauthorised transactions. 36 beneficiary banks. Approximately ₹14 crore in disputed transfers. One critical question: How can financial transactions occur without corresponding records in a bank's internal systems?

A reported banking incident involving the Central Bank of India has brought renewed attention to the cybersecurity of India's interbank payment infrastructure. According to media reports published on 24 October 2026, the bank reported 187 unauthorised transfers worth approximately ₹13.96 crore to ₹13.97 crore from its settlement account maintained with the Reserve Bank of India (RBI).

The transactions reportedly occurred between 15 and 17 October 2026, with funds routed to accounts across 36 banks. An FIR was registered against unidentified persons following a complaint by the bank.

The complaint, as described in media reports, alleged unauthorised access involving the Central Structured Financial Messaging System (SFMS) infrastructure operated by Indian Financial Technology and Allied Services (IFTAS), an RBI subsidiary. The bank reportedly could not identify corresponding records for the disputed transactions in its usual banking channels and internal systems.

However, the incident requires careful interpretation.

IFTAS issued a clarification dated 24 October 2026 stating that the Central SFMS system managed by it was safe and secure and that no compromise had occurred in the systems managed by IFTAS. It also stated that further investigation into the reported incident was ongoing at the concerned bank's end.

The exact technical mechanism behind the reported transfers has not been conclusively established in the sources reviewed. Therefore, the incident should not be treated as confirmation of a breach of the entire Central SFMS infrastructure.

Instead, it presents an important opportunity to examine the security controls, transaction validation mechanisms, reconciliation processes and incident response capabilities that underpin high-value interbank payments.

1. What Happened in the Central Bank of India Incident?

The bank's complaint described 187 allegedly unauthorised transactions over three days.

The reported transaction breakdown was:

Date	Reported transactions
15 October 2026	6
16 October 2026	88
17 October 2026	93
Total	187

The transfers reportedly routed funds to 36 bank accounts through the bank's settlement account maintained with the RBI.

The bank's internal examination reportedly failed to locate corresponding entries for the disputed transfers across its branch operations, internet banking, mobile banking, core banking system, RTGS settlement account and its own SFMS server.

Media reports also stated that partial traces associated with 10 accounts were found in SFMS database logs, but the corresponding transaction IDs were absent from the bank's records.

These reported discrepancies raise several technical questions:

• How were the disputed payment messages generated or introduced into the payment workflow?

• Did the relevant authorisation and validation controls operate as intended?

• Why were corresponding transaction records reportedly unavailable in the bank's internal systems?

• Could transaction-level reconciliation have detected the discrepancy earlier?

• What do the available logs establish about the origin, processing and settlement of the transfers?

These are investigation questions, not established conclusions about the cause of the incident.

The reported discrepancy between the bank's internal records and the disputed settlement activity is particularly significant because financial institutions must maintain reliable links between payment instructions, message processing, authorisation and settlement records.

2. Understanding the Technology: RTGS, SFMS and the Settlement Process

To understand the potential security implications, it is necessary to distinguish between the payment system, the financial messaging infrastructure and a bank's internal transaction-processing environment.

What is RTGS?

Real Time Gross Settlement (RTGS) is an electronic funds transfer system in which transactions are settled individually in real time rather than being accumulated and settled on a net basis.

The RBI operates India's RTGS system. Settlement takes place in the RBI's books, and completed RTGS payments are final and irrevocable under the system's operating framework.

RTGS is primarily designed for large-value transactions. According to the RBI's published RTGS FAQs, customer transactions have a minimum value of ₹2 lakh, with no RBI-imposed maximum amount.

For banks, RTGS is more than a payment channel. It is part of the financial infrastructure that supports high-value customer payments and interbank fund transfers.

What is SFMS?

The Structured Financial Messaging System (SFMS) provides a mechanism for exchanging structured financial messages between participating financial institutions.

In the payment workflow described in media reports concerning this incident, a bank's internal systems generate payment information that passes through its SFMS infrastructure to the Central SFMS system operated by IFTAS. The relevant payment and settlement processes then enable funds to be transferred through the RTGS framework.

A simplified representation of the reported workflow is:

Payment instruction → Bank's core banking system → Bank's SFMS infrastructure → Central SFMS infrastructure → RTGS settlement processing

The precise implementation, validation steps and control boundaries depend on the participating systems and their configurations. The sequence above is a simplified illustration, not a complete technical specification of the RTGS or SFMS architecture.

Why are these distinctions important?

The core banking system, messaging infrastructure and settlement records serve different purposes.

• Core banking system: Maintains the bank's transaction and account records.

• Bank-side SFMS infrastructure: Supports the exchange of structured financial messages.

• Central SFMS infrastructure: Supports interbank financial messaging within the relevant payment workflows.

• RTGS settlement framework: Facilitates the settlement of eligible transfers in the RBI's books.

• Reconciliation systems: Compare transaction instructions, message records and settlement outcomes to identify inconsistencies.

These components must operate within clearly defined trust boundaries.

A valid-looking message should not, by itself, be treated as sufficient evidence that a transaction was properly initiated, authorised and recorded by the originating institution. Likewise, a successful settlement outcome must be reconciled against the relevant transaction records.

The investigation into the Central Bank of India incident will need to establish how the reported discrepancies arose and which controls, if any, failed or were bypassed.

3. The Critical Security Question: What Happens When Records Do Not Match?

The most important technical concern raised by the reported incident is the apparent mismatch between disputed transfers and the bank's internal records.

In a high-value payment environment, transaction integrity depends on more than securing individual servers. It also depends on the ability to establish that every payment has a legitimate origin, valid authorisation, traceable processing history and corresponding settlement record.

Several security and operational control areas warrant examination.

3.1 Payment instruction integrity

Payment instructions should be generated through authorised workflows and validated before they enter downstream processing.

Security teams should examine whether:

• Transaction instructions originated from approved applications and services.

• Message authenticity and integrity controls operated correctly.

• The relevant systems enforced transaction authorisation requirements.

• Changes to payment instructions were restricted, authenticated and logged.

• Duplicate, unexpected or inconsistent instructions were detected.

These are recommended control areas for financial messaging environments. The available reporting does not establish which of these controls may have been involved in the incident.

3.2 Privileged access management

Financial messaging systems require tightly controlled administrative access.

Excessive privileges, compromised credentials, weak service-account controls or inadequate separation of duties can increase the impact of a security incident.

Banks should assess whether privileged access is restricted according to least-privilege principles and whether sensitive operations require appropriate authorisation.

Recommended measures include:

• Multi-factor authentication for administrative access wherever supported.

• Separation of administrative duties from payment approval responsibilities.

• Restricted access for service accounts and automated processes.

• Regular reviews of privileged accounts and access permissions.

• Monitoring of unusual administrative activity.

• Secure management and rotation of credentials and cryptographic secrets.

Access controls should extend across application servers, databases, messaging infrastructure, supporting systems and administrative interfaces.

3.3 Transaction validation and authorisation

A robust payment workflow should validate the legitimacy of a transaction at the appropriate control points.

Depending on the architecture, this may include checks on transaction origin, message integrity, authorisation status, permitted transaction types, applicable limits and duplicate processing.

A critical principle is that authentication, authorisation and reconciliation are complementary controls, not interchangeable ones.

Authentication helps establish the identity of a user, system or service. Authorisation determines what that identity is permitted to do. Reconciliation helps establish whether recorded instructions and actual settlement activity correspond.

A secure system requires all three.

3.4 Logging, audit trails and transaction traceability

Logs are essential for determining what happened during a suspected cyber incident.

However, collecting logs alone is insufficient. They must be complete enough to support investigations, protected against unauthorised alteration, synchronised where appropriate and correlated across relevant systems.

For payment processing, security teams should be able to investigate:

• Transaction reference identifiers.

• Message creation and processing timestamps.

• Source application and service identities.

• Authorisation decisions.

• Administrative and configuration changes.

• Validation failures and rejected messages.

• Settlement acknowledgements and reconciliation results.

Where technically feasible, audit records should be forwarded to a protected, centralised logging platform so that the compromise of one system does not automatically compromise the evidence needed to investigate it.

Centralised logging also provides an important foundation for continuous security monitoring. When identity, application, database and network events can be correlated, security teams have a better chance of recognising suspicious activity and investigating it promptly. Without sufficiently complete and accessible telemetry, even a well-designed monitoring operation may have blind spots.

The reported absence of matching transaction identifiers in some records makes cross-system traceability a particularly relevant area for examination. It does not, by itself, establish why the records were missing.

4. Why Transaction Reconciliation Is a Cybersecurity Control

Reconciliation is often treated primarily as an accounting or operational activity. In high-value payment systems, it is also an important detective security control.

Consider a simplified scenario.

A payment message appears in a downstream processing system, but the originating bank cannot find a corresponding authorised instruction in its core banking records.

That discrepancy should trigger investigation rather than be dismissed as a routine processing error.

A strong reconciliation framework compares records from independent stages of the payment lifecycle, such as:

1. The originating transaction instruction.

2. The core banking transaction record.

3. The outgoing financial message.

4. The downstream processing acknowledgement.

5. The settlement record.

6. The final transaction status.

The exact records and comparison rules depend on the payment architecture.

What should automated reconciliation detect?

A well-designed reconciliation process can flag:

• Settlement entries without corresponding authorised instructions.

• Payment messages without matching transaction records.

• Transaction identifiers that do not match across systems.

• Unexpected transaction volumes or values.

• Duplicate or repeated instructions.

• Unusual beneficiary patterns.

• Delayed, missing or inconsistent acknowledgements.

• Differences between expected and actual settlement totals.

Where appropriate, these discrepancies should generate alerts for investigation by operations and security teams.

For a bank processing large numbers of transactions, automated reconciliation is especially valuable because manual checks may not identify anomalies quickly enough.

Reconciliation and security monitoring should work alongside one another. Reconciliation identifies inconsistencies in transaction records and settlement outcomes; security monitoring can help investigate related activity across accounts, applications, infrastructure and networks. Neither replaces the other. Their combined value depends on clear escalation procedures and timely access to reliable evidence.

The objective is not simply to record transactions accurately. It is to detect when the same transaction tells different stories across different systems.

5. A Related Warning from CERT-In: Payment APIs and Unauthorised Fund Transfers

The Central Bank of India case is not the only reason financial institutions should examine payment-system security.

On 9 October 2026, CERT-In published Advisory CIAD-2026-0046, describing threat campaigns targeting financial services and related organisations through payment and disbursement APIs.

According to the advisory, attackers have compromised internet-facing applications, exposed APIs and privileged endpoints, obtained payment-related credentials, and invoked fund-transfer or disbursement APIs from within infrastructure considered trusted.

The advisory describes scenarios in which malicious transactions bypass application-level controls such as beneficiary verification and transaction limits.

This is a separate set of reported threat activities. It does not establish that the same techniques were used in the Central Bank of India incident.

Nevertheless, it illustrates an important architectural risk: a request originating from trusted infrastructure is not automatically legitimate.

Financial institutions should therefore review:

• API authentication and authorisation.

• Service-to-service identity verification.

• Credential storage and rotation.

• Network-level trust assumptions.

• Transaction-level validation.

• Beneficiary verification.

• Rate limits and transaction thresholds.

• Detection of abnormal API usage.

• Monitoring of privileged endpoints.

• Controls against replay and unauthorised transaction submission, where applicable.

These reviews should extend beyond the security of known applications. Internet-facing assets can include customer portals, mobile application backends, APIs, cloud services, remote-access systems and legacy services that may no longer be actively maintained. An overlooked or inadequately secured asset can create an entry point into a wider environment, depending on its connectivity and privileges.

External attack surface management helps organisations maintain visibility into these internet-facing assets and identify potential exposures that need assessment. This is particularly relevant for financial institutions with complex digital ecosystems, where assets and integrations can change faster than manual inventories are updated. Discovering an exposed asset does not prove that it has been compromised, but it gives security teams a starting point for investigation and remediation.

These controls should be implemented according to the organisation's architecture and the threats relevant to its payment workflows.

6. IFTAS's Clarification: Why Accurate Incident Reporting Matters

Cybersecurity incidents involving financial infrastructure require careful technical communication.

In its clarification dated 24 October 2026, IFTAS stated that the Central SFMS system managed by it was safe and secure and that no compromise had occurred in systems managed by IFTAS. It also stated that the investigation into the reported incident was ongoing at the concerned bank's end.

This statement must be considered alongside the bank's complaint as described in media reports.

The complaint alleged unauthorised access involving Central SFMS infrastructure. IFTAS, meanwhile, stated that its managed systems had not been compromised.

These are materially different statements about an incident whose technical details were still being investigated.

The available information does not establish the complete attack path, the specific control that may have failed, or whether the final investigation will confirm the alleged mechanism.

This is why responsible cybersecurity reporting must distinguish among:

• Reported allegations: What a complainant or initial report says happened.

• Official clarifications: What the relevant organisation states about its systems.

• Technical findings: What forensic investigation establishes from evidence.

• Confirmed root cause: The explanation supported by the completed investigation.

This distinction matters for banks, customers, regulators and cybersecurity professionals.

Prematurely declaring an entire payment network compromised can create unnecessary alarm, while prematurely dismissing reported discrepancies can obscure legitimate security concerns.

The correct approach is to follow the evidence, preserve technical records and communicate verified findings.

7. A Technical Security Framework for Banks and Financial Institutions

The incident highlights the need for a defence-in-depth approach across payment applications, infrastructure, identity, monitoring and operational controls.

A practical security programme should not rely on a single audit, monitoring platform or perimeter control. It needs to identify weaknesses before they are exploited, detect suspicious activity as it develops, understand which digital assets are exposed, and independently verify that financial transactions are legitimate.

The following framework provides a practical starting point for financial institutions reviewing their security posture.

Layer 1: Identity and privileged access

Establish clear boundaries around who and what can access critical systems.

Recommended controls:

• Enforce least-privilege access.

• Apply multi-factor authentication where supported.

• Review privileged accounts and service identities.

• Separate administrative and transaction-approval duties.

• Monitor unusual access and configuration changes.

Layer 2: Application and messaging security

Protect the applications and services responsible for initiating, validating and transmitting payment instructions.

Recommended controls:

• Assess application and API security.

• Validate transaction origin and authorisation.

• Secure service-to-service communications.

• Protect credentials, keys and secrets.

• Review trust relationships between connected systems.

• Test security controls against relevant abuse scenarios.

Regular Vulnerability Assessment and Penetration Testing (VAPT) can help evaluate whether these safeguards work as intended. By testing applications, APIs, infrastructure, authentication mechanisms and relevant configurations within an authorised scope, organisations can identify weaknesses, assess their potential impact and prioritise remediation. A security assessment is most useful when findings are tracked through to resolution and fixes are validated, rather than treated as a one-time compliance exercise.

Layer 3: Transaction integrity and reconciliation

Ensure that payment instructions, processing records and settlement outcomes can be traced and compared.

Recommended controls:

• Reconcile transaction records across systems.

• Detect missing, duplicated or inconsistent entries.

• Establish alerts for unusual transaction volumes and values.

• Investigate unmatched settlement records.

• Preserve transaction-level audit trails.

• Test reconciliation procedures through controlled exercises.

Layer 4: Continuous monitoring and detection

Security operations teams should have visibility into critical infrastructure and the events that may indicate unauthorised activity.

Recommended controls:

• Centralise relevant logs.

• Correlate identity, application, database and network events.

• Establish alerts for suspicious privileged activity.

• Detect abnormal service-account behaviour.

• Monitor changes to critical configurations.

• Define escalation procedures for high-risk alerts.

A Managed Security Operations Centre (SOC) can help provide continuous monitoring, investigate alerts and correlate events across connected systems. Its effectiveness depends on the quality of available logs, the systems integrated into the monitoring environment, the detection rules in place and the response procedures agreed with the organisation. Monitoring is not simply about generating alerts. It is about ensuring that meaningful signals reach the right people and lead to timely investigation.

Monitoring rules should be based on the organisation's architecture and known threat scenarios. They should not assume that every suspicious event indicates a confirmed compromise.

Layer 5: External exposure management

An organisation cannot adequately manage risks it does not know exist. Financial institutions should maintain an up-to-date view of their internet-facing assets, including websites, applications, APIs, cloud services and remote-access infrastructure.

Potentially exposed services should be assessed, prioritised and remediated according to their risk.

External Attack Surface Management (EASM) supports this process by helping organisations discover and monitor external digital assets and identify potential exposures. It complements internal vulnerability assessments and security monitoring by focusing on what can be observed from outside the organisation. Dark web and brand monitoring can provide additional context about potential information exposure or impersonation. These capabilities support risk identification, but do not replace application testing, access controls or transaction-level validation.

Layer 6: Incident response and recovery

Banks should maintain tested procedures for investigating suspected unauthorised transfers.

These procedures should define:

• Who has the authority to initiate containment measures.

• How relevant systems and evidence will be preserved.

• How transaction discrepancies will be investigated.

• How the organisation will coordinate with its banking and infrastructure partners.

• When regulators and appropriate authorities must be notified.

• How the integrity of critical systems will be validated before normal operations resume.

Incident response plans should be tested through realistic tabletop exercises and technical simulations.

Together, these layers create a more complete security lifecycle: assess weaknesses, monitor for suspicious activity, identify external exposure, verify transactions independently and prepare to respond when something goes wrong. Each layer addresses a different risk, so effectiveness depends on how well the controls work together.

8. Applying These Controls to the Banking Security Challenge

The security measures discussed above address different parts of an organisation's risk. Their value lies in how they complement one another, rather than in any single tool or service.

VAPT helps identify vulnerabilities in applications, APIs and supporting infrastructure. Continuous SOC monitoring helps security teams investigate suspicious activity across the systems and logs available to them. External attack surface management helps organisations discover internet-facing assets and identify potential exposures that might otherwise be overlooked. Payment authorisation and reconciliation remain responsible for validating transactions and matching instructions with processing and settlement records.

For example, an exposed API may require remediation following an external exposure review, followed by an authorised security assessment to evaluate its weaknesses. Monitoring can then help identify suspicious activity involving that service, provided relevant telemetry and detection rules are in place. If a payment discrepancy occurs, transaction-level reconciliation and the associated audit trails remain essential to determining what happened.

These capabilities can be supported by specialised security services and tools. TechOwl's VAPT and Managed SOC capabilities address security testing and monitoring, while TechOwl Shield supports external attack surface visibility alongside dark web and brand monitoring. Their relevance depends on the organisation's environment, required integrations and security objectives. They complement, rather than replace, payment-specific safeguards.

It is equally important to recognise their boundaries. VAPT cannot guarantee that future attacks will not occur. A SOC cannot independently verify the legitimacy of every payment without the appropriate transaction data and controls. External attack surface management does not authenticate SFMS messages, validate RTGS instructions or reconcile settlement records.

For a financial institution, the practical objective is to build a connected programme in which identified weaknesses are remediated, suspicious events are investigated, external exposures are managed and critical transactions remain independently verifiable.

9. The Larger Lesson: Payment Security Requires End-to-End Trust

The Central Bank of India incident, as reported, raises questions that extend beyond an individual server or payment application.

Modern financial systems depend on multiple interconnected components. A transaction may pass through several applications, messaging services, validation mechanisms and settlement processes before reaching its destination.

Every transition creates a need for clearly defined trust boundaries and verifiable records.

Financial institutions should therefore avoid relying on a single security mechanism as the foundation of payment integrity.

A resilient approach combines:

• Strong identity and access management.

• Secure messaging and application architecture.

• Transaction-level validation.

• Independent reconciliation.

• Centralised, tamper-resistant logging.

• Continuous security monitoring.

• Regular security assessments.

• External attack surface visibility.

• Tested incident response and recovery procedures.

The incident also demonstrates why technical investigations must remain evidence-led. The bank's reported allegations and IFTAS's clarification need to be considered together, and the final technical findings will be necessary to establish what happened.

For financial institutions, the immediate priority is not speculation about a particular attack path. It is ensuring that critical transactions remain authorised, traceable, monitored and independently verifiable.

Achieving that level of resilience requires both strong internal controls and visibility into the wider digital environment. Organisations reviewing their security posture can explore how capabilities such as VAPT, Managed SOC and external attack surface management, including TechOwl Shield, may support a broader, risk-based cybersecurity programme.

In high-value payment infrastructure, trust must be engineered into every layer of the transaction lifecycle.

Frequently Asked Questions (FAQs)

1. What happened in the Central Bank of India cyber incident?

According to media reports published on 24 October 2026, Central Bank of India reported 187 allegedly unauthorised transfers worth approximately ₹13.96 crore to ₹13.97 crore between 15 and 17 October 2026. The funds reportedly went to accounts across 36 banks. An FIR was registered against unidentified persons, and the precise technical mechanism remained under investigation in the reporting reviewed.

2. Was ₹13.97 crore stolen from the RBI?

The reports describe disputed transfers through Central Bank of India's settlement account maintained with the RBI. They do not establish that the funds were lost from the RBI's own funds. The exact financial impact and the final outcome of the investigation should be confirmed through subsequent official statements.

3. Was IFTAS's Central SFMS server compromised?

The bank's complaint, as described in media reports, alleged unauthorised access involving Central SFMS infrastructure. However, IFTAS's clarification dated 24 October 2026 stated that the Central SFMS system managed by it was safe and secure, with no compromise in systems managed by IFTAS. The final technical cause has not been established by the sources reviewed.

4. What is the difference between RTGS and SFMS?

RTGS is a real-time gross settlement payment system operated by the RBI. SFMS is a structured financial messaging system used to exchange financial messages between participating institutions. They serve different purposes but interact within relevant interbank payment workflows.

5. Why are missing transaction records a security concern?

When a reported settlement or payment event cannot be matched to an authorised transaction record, investigators must determine why the discrepancy occurred. Potential explanations may include processing failures, record inconsistencies or unauthorised activity. Missing records alone do not establish a cyberattack, but they make reliable logging, reconciliation and forensic analysis especially important.

6. How can banks prevent unauthorised transactions?

No single measure can eliminate every risk. Banks should implement strong access controls, transaction authorisation, secure messaging, application and API security, independent reconciliation, centralised logging, anomaly detection and tested incident response procedures. Controls should be tailored to the institution's architecture and applicable regulatory requirements.

7. Can VAPT help secure banking payment systems?

Yes. Properly scoped Vulnerability Assessment and Penetration Testing can help identify weaknesses in applications, APIs, network configurations, authentication mechanisms and supporting infrastructure. VAPT should be conducted with appropriate authorisation and safeguards. It complements, but does not replace, continuous monitoring, transaction validation and reconciliation.

8. How can a Managed SOC help a bank?

A Managed SOC can monitor security telemetry, investigate suspicious activity, correlate events and support incident response. Its effectiveness depends on the availability and quality of relevant logs, system integrations, detection rules and clearly defined response procedures. It should complement the bank's payment-specific controls.

9. How does external attack surface management help financial institutions?

External Attack Surface Management helps organisations discover and monitor internet-facing assets such as websites, applications, APIs and cloud services, then assess potential exposures. It complements VAPT, continuous monitoring and payment-specific controls, but it does not validate RTGS transactions, authenticate SFMS messages or reconcile settlement records.

10. What should financial institutions prioritise after an incident like this?

Financial institutions should review access controls, payment-message integrity, transaction authorisation, reconciliation procedures, audit-trail completeness, monitoring coverage and incident response readiness. They should also review externally exposed assets, preserve relevant evidence and coordinate with the appropriate infrastructure providers, regulators and law enforcement authorities.