This article explores the hypothesis that the UCO Bank fraud case, where ₹ 820 Crore was (temporarily) stolen from the bank through glitches in IMPS transactions is a coordinated retail cyber-attack which created money from thin air similar to printing fake currency notes.

Background

Modern banking is both fractional and digital. Fractional refers to the practice of all banks everywhere in the world, taking money from public in the form of deposits and keeping only a portion of it in cash form (Fraction) and lending the rest. This allows money creation by all banks which engage in lending as the deposits they took (referred to as liabilities in its accounting books) and the loans it issued (referred to as assets) taken together is more than the initial money (deposits) that was in the system [1].

The amount of money creation however is regulated by RBI through measures such as reserve requirement, capital adequacy ratio and interest rate mechanisms such as repo and reverse repo rates. Fake currency notes are one way in which this control by RBI as any unlicensed entity can create money from thin air, if they can master the currency printing process.

Modern economies however have become more digital than physical and hence money is simply more often than not bits in servers housed in data centers than paper. Now consider two persons (A and B), holding their money in UCO Bank in a savings account of ₹ 100 each. The bank holds this amount in separate liability ledgers specific to each of them. In the long-forgotten paper era, these ledgers are referred to as “passbooks” (a copy of the ledger from the depositors’ point of view and had corresponding physical ledgers on the bank’s side as well). However, in the digital era, the ledgers are nothing but rows in a giant database table as shown in the illustration below:

Transfers from one Savings bank account to another account is simply adding more rows in the database table as shown in the illustration below:

When accounts are held in the same bank, transfers are instantaneous as they are all executed within the context of a single database owned and operated by the same bank. But what if transfers are across two different banks?

That requires a more complex architecture because there could be several hundreds of banks in India and syncing database transactions across them would not be feasible at a technical level instantaneously. One (theoretical) solution to this problem is via message passing design with a trusted intermediary as described below:

1. Assume there are two banks in the ecosystem – UCO bank and State Bank of India which wants to transfer funds between their account holders.
2. They both appoint an intermediary (It could be anyone but for our purpose let us say it is the RBI).
3. When A in UCO bank wants to transfer money to the account of B in SBI, UCO bank withdraws the money from A’s account, and deposits it into an account it holds with RBI, along with a message which says “Please transfer 10 rupees to B’s Account in SBI identified by A/C number 1234).
4. RBI then withdraws the 10 rupees it got from the account it holds with UCO bank and deposits it in the account it holds with SBI and passes on a message to SBI which says “Please transfer 10 rupees to B’s account identified by A/C number 1234).
5. SBI then credits the 10 rupees to B’s account by withdrawing it from the account it holds with RBI.

The intermediary thus performs the following roles:

1. It validates the entities (banks) allowed to participate in the system and their fitment (For instance it can bar a bank from participating in the process either as a sender or a receiver or both based on regulatory actions).
2. It validates the messages and the message integrity and the transaction by acting as a counter-party guarantor by providing various intermediate bank accounts held for sending and receiving money from entities.
3. It routes the message between entities (similar to a post office) and may add additional tracking information for transaction tracing in the case of errors.

Note that there are several real-world optimizations that are possible in the theoretical model described above. For instance, the intermediary may not hold any counter-party bank accounts at all with participating banks, and instead just act as a message forwarder and router [2] in some cases.

A key aspect on this design is how often do these messages get sent? The answer to this question is dependent on the technical infrastructure made available by all the entities and the intermediary in the form of processing power (Compute, Storage and Network). Large banks would typically have several lakh transfer transactions every day, while smaller ones may have only few hundreds. Because of the time taken to process the messages, the intermediary may also impose periodicity concerns and divide the workload into batches for settlement efficiency.

Hence message processing architectures can have two variables on how the system operates – Batch Size and Periodicity of the settlement window. In the case of NEFT, the batch size is variable based on demand (number of transfers initiated by the bank customers), but the periodicity is fixed (every 30 minutes). In the case of RTGS, the batch size is always one (transactions are settled as they occur and not batched), but the periodicity is immediate and continuous with settlements managed by the RBI via accounts maintained with participating banks [3].

The management of bank accounts thus is not just possible by having only database servers but having dedicated software products which manage all these aspects including interfacing with other banks, intermediaries and logic processing including settlement, reconciliation, and customer interface channels such as Voice IVR, SMS, Internet, and mobile banking. These are referred to as Core Banking products within the banking industry.

Core Banking Product Architecture

A core banking product has several requirements spanning regulatory demands to customer expectations. Further every bank is different and does not exactly work the same. Hence the product has to be extensible and customizable. Typically, this is done via Service Oriented Architecture approach, where different concerns are extracted out into a service, which then interacts with other services through standards-based interfaces.  In the case of Finacle, the core banking solution used by UCO Bank, this standard based interface is via a messaging standard ISO-8583 for some components.

This then leads to the following (high level illustrative) design [4]:

The key component here is Connect-24, which connects other type of peripherals and frameworks to the Core banking App server via a standards-based message design (ISO-8583). Peripheral devices send transaction and other information to connect-24 via ISO-8583, which then processes them after validation and performs appropriate actions on the Finacle App Server.

It naturally follows then that if an ISO-8583 message can be inserted by a malicious component into Connect-24, it could have an impact on the core banking server. Hence end points which send these messages must be within the trust boundary and must be managed by the IT team under the CIO/CTO. This also applies for outsourcing providers who manage some of these components directly or indirectly because of outsourcing chains, as they all belong within the trust boundary.

UCO Bank’s IMPS Implementation

From the core banking product perspective, IMPS (Immediate Payment Service) is another delivery channel attached to Connect-24. The IMPS module takes into consideration, the specifics of the IMPS Protocol The (illustrative) architecture then looks as below:

The message flow between any two banks running Finacle is then as below:

1. Customer of any other bank wants to send ₹ 100 to a customer in UCO bank, identified through their IFSC Code and Account number (the most common method).
2. Once the request is validated, Sender’s bank deducts ₹ 100 from the sender’s bank account and routes the request to NPCI.
3. NPCI after validation, sends it to the IMPS delivery channel handler (It would be easier to call it as a Switch, a separate application server running within the premises of UCO bank).
4. The IMPS Switch then translates that message into ISO-8583 message and forwards that message to Connect-24.
5. Connect-24 then validates the ISO-8583 message and sends it to the Finacle app server, which then credits the UCO bank account with ₹ 100.

A key consideration while implementing a messaging architecture is that an IMPS transaction can fail because of non-delivery of messages on either banks (Sender or receiver) or NPCI. Given the number of entities involved and variances in the computing infrastructure, it is a given that a small number of transactions will fail.

There are two types of failures that can happen – Business failures and technical failures and these are tracked separately by NPCI in a public dashboard. Given that a percentage of IMPS Transactions can always fail, the IMPS protocol allows reversal of credit and debit from the beneficiary and sender’s bank accounts at various stages.

To understand the UCO bank fraud case, let us now consider an edge case where there is an infrastructure outage at the UCO bank side because of which the IMPS switch goes down and no incoming credit message can be processed. The message flow then becomes (additional steps in blue):

1. Customer of any other bank wants to send ₹ 100 to a customer in UCO bank, identified through their IFSC Code and Account number (the most common method).
2. Once the request is validated, Sender’s bank deducts ₹ 100 from the sender’s bank account and routes the request to NPCI.
3. NPCI after validation, sends it to the IMPS delivery channel handler, but the transaction does not go through because the bank’s servers are down. This triggers a debit reversal flow.
4. NPCI now sends a debit reversal request to the sender’s bank, which then processes it and credits ₹ 100 back to the sender’s bank account.

The message flow remains the same, when the beneficiary bank rejects processing of the credit request for various reasons (e.g. Frozen account, Lien marked account). Given this flow, a fraudster can imagine a scenario where the IMPS Delivery channel handler rejects an incoming credit request thereby triggering a reverse debit by NPCI, but somehow tricks the Connect-24 handler to process the credit request. Diagrammatically the desired end state the fraudsters want to achieve can be represented as:

What the Fraudsters did

The IMPS Switch is implemented as a separate product by many banks either on their own or through third party service providers. Given the frequent changes in the ecosystem, most of the banks use third party service providers who promise faster turnaround times, apart from measurable improvements such as increase in the number of transactions they can process per minute (a proxy for message throughput) by deploying their product in the cloud.

UCO bank signed up with one of these providers (in this specific case LCode Technologies Limited which incidentally advertises IMPS Switch and UPI Switch with specific interfaces to support Finacle and ISO-8583). A careful reading of the FIR [5] (specifically Annexure-A) points out details of the integration between IMPS Switch provided by LCode and Connect-24 middleware as described below:

1. The IMPS protocol supports only a small set of features around Instant Money Transfer such as Fund Transfer, Check Status of a transaction and name inquiry.
2. The IMPS Switch forwards these small set of messages to the Connect-24 Middleware by translating them to ISO-8583 messages via Port 49100, a dedicated TCP/IP Port for handling these types of messages.
3. Architecturally this means that all core banking features supported by Connect-24 middleware is grouped into feature buckets and are exposed as separate services running in different ports. While it is unclear if this improves performance, it is nevertheless a good practice as it allows separation of concerns.
4. Crucially however, there is no micro-segmentation [6] between the IMPS Switch and Connect-24. The IMPS Switch (maintained by LCode) can access all ports of Connect-24, while it should have been restricted to only port 49100 (Micro-segmentation is a very basic defensive approach to prevent rogue access. For instance, if there is app server and a database server, the app server should only have access to the DB port of the database server and not the SSH port).
5. Further the Connect-24 handler did not check message integrity at all. A typical message processing logic (expressed in Pseudocode) works as shown below:

   S1. Check all the Fields of the Incoming Message. 
   S2. If there is Field Mismatch or Field Errors, Reject Message and Send back Failed Response. 
   S3. Forward the Message to App Server.
   S4. Send back Success Response.

6. However, this is not how Connect-24 handler worked. The message processing logic (expressed in Pseudocode) works as shown below (Note the inversion from check-and-process to process-and-check):

   S1.        Forward the Message to App Server.
   S2.        Check all the Fields of the Incoming Message.
   S3.        If there is Field Mismatch or Field Errors, Reject Message and Send back Failed Response.
   S4.        Send back Success Response.

However, this is only the technical aspect. They still had to evade settlement controls. Unlike RTGS, which is directly operated by RBI, IMPS is operated via NPCI, which also has a detailed settlement process [8]. Broadly it operates as described below:

1. IMPS is settled between banks at an aggregate level basis by setting off credits and debits instead of individual transactions.
2. Since all banks have accounts with RBI for the purpose of settlement, Banks participating on IMPS, issue an authorization letter to RBI to allow NPCI to operate their settlement accounts.
3. To reduce counter-party credit risk at the aggregate level, NPCI hence imposes transaction limits on individual transfers, as settlement can be delayed for a while because of message processing latency and other issues.

Now consider how the scheme went undetected for 4 days (from 10-Nov-2023 to 13-Nov-2023) and why this was not flagged by settlement processes, after the switch from port 49100 to 46110 – Because the credit request was rejected by the IMPS server at UCO bank and the rejection was processed by NPCI, net to net, there are no aggregate settlements between UCO bank and the counter party banks (IDFC First, Jana Small Finance Bank, Suryoday Small Finance Bank, FinCare Small Finance Bank, Capital Small Finance Bank, Utkarsh Small Finance Bank, ESAF Small Finance Bank).

However, this still does not explain the synchronization between two distinct events – A exploitable vulnerability in Connect-24 and the large number of synchronized transactions that used the vulnerability.

There are two possible hypotheses how this could have happened.

• ·Intentional Change – The change was done deliberately.
• Accidental Glitch but Intentional exploitation via Virality – Employees of LCode made an accidental error, which created extra money on the receiver’s account. This was then noticed, and many users piled in as the news spread.

To evaluate the accidental glitch hypothesis, let us consider the data from IMPS dashboard maintained publicly by NPCI. The table below shows 17 months of data about UCO bank.

Clearly Nov – 2023 stands out, in term of Volume of transactions as they were 2.2X of previous months, even though IMPS server was made offline after 13^th November. While the FIR maintains that the error code generated is “Business Decline” (3X more than normal), technical declines were several times higher. One reason why this could have happened is that the IMPS switch would have been flooded with transactions at a small time, as word spread, which would have overwhelmed its capacity to handle incoming traffic.

Further proof for this line of reasoning can be found by looking at day-to-day volumes available in the FIR.

The first day after the deployment of the change, the volumes are far smaller after which it had spread like wildfire (The FIR indicates several social media influencers writing posts about the vulnerability). Further news reports indicate that out of a net total of 820 Crore, only 171 Crore needs to be recovered [9], which is pretty close to the sum of money defrauded on the first 3 days (170.35 Crore)

Hence the most likely explanation would be a mix of these two hypotheses. The first few hours perhaps belonged to a cartel, and then word spread about the vulnerability, and everyone piled on. If this were the case, what approach could have been used by the cartel to pull it off?

One possible way the cartel could have used to siphon off money is to simply use existing money-mule accounts widely used for laundering cyber-crime proceeds. As has been first pointed out by a DeepStrat Study (published 3 years ago), there exists a Fraud-Stack (a shadow stack mirroring India Stack that has Identity-Mobile-Bank account Trinity) used by Fraudsters to create bank accounts at scale because of broken KYC [10] Processes. These bank accounts are controlled by crime cartels without the owners of the bank accounts either being unaware of their identities being mis-used or being party to the process [11].

Either way, a simple metric would be able to point out, how long had the fraudsters have known about the vulnerability – The opening date of the accounts used in UCO bank and the counter-party banks for money that could not be recovered. If they had been opened recently (< 9 months), it most probably implies that the scheme had been planned recently. If they are older than 1 year or more, it most probably implies that existing bank accounts used for Cyber-crime money laundering had been deployed, knowing very well that they would be burnt, once the scheme has been uncovered.

IMPLICATIONS

The first implication of the UCO bank fraud is that it is similar to printing currency notes by unauthorized entities. Consider the following:

1. Assume that UCO bank had a deposit of ₹ 8,200 Crore and a reserve requirement of 10%. This implies that it can lend ₹ 7,380 crore, while keeping ₹ 820 Crore as reserves.
2. Since no money from counter party banks were received by UCO Bank, but ₹ 820 crores were nevertheless created in the bank accounts of beneficiaries of UCO bank, this is the same as creating a new loan book of ₹ 820 crore (which in theory is uncollectable as it is only fraud and hence has to be fully provisioned).
3. Hence not only UCO bank’s reserve requirement norms would be violated, but there could also be a potential P/L impact (because of provisioning) and hence an impact on the balance sheet affecting Capital adequacy ratio.
4. The only cold comfort is that the amounts defrauded were not that big to have created the above effects, but it could have been (as lien marking left only 171 Crore to recover). Perhaps it was just luck that the attackers were not as bold as adversarial nation states could be in times of war because they were simply members of a crime cartel (and over-enthusiastic public trying to make a quick buck), who wished to profit but not bring down a bank.

The second implication is that given the widespread use of third-party service providers offering IMPS switch as a component and banks buying these services [12], have made all these third-party service providers and their employees, directors, and support engineers, come inside the trusted boundary of the banking system. As the UCO bank case indicates, all it requires is a simple configuration file switch to create enough harm.

Further it is well known that smaller banks (including co-operative banks) lack technical controls compared to larger public sector banks. If a simple defensive step like Micro-Segmentation and port control has not been implemented by UCO bank, it is a given that controls on these banks would be sub-par. Given the inter-dependence between the banking systems, it would be far easier to pull the IMPS trick on these smaller banks, by originating IMPS transactions from a few hundred mule accounts from larger banks. Given that these smaller banks, may not be well capitalized to handle losses caused by these transactions, they could even end up insolvent, after a single day of coordinated attack.

Given that most of the banks only self-certify their IMPS infrastructure compliances [13], there is a reasonably high probability that the IMPS attack would be repeated.

References

[1] For a detailed treatment on why this allows money creation, refer to https://open.lib.umn.edu/principleseconomics/chapter/24-2-the-banking-system-and-money-creation/

[2] Kant, Shashi & Dhal, Sarat. (2019). Network Analysis of NEFT Transactions in India.

[3] For a full treatment on RTGS design choices, refer to https://www.bis.org/cpmi/publ/d22.pdf

[4] Refer to Finacle Core Architecture Document for more details.

[5] Refer to the Full FIR available at https://cbi.gov.in/assets/files/fir/994350021FIR%20RC%2029%202023.pdf

[6] Reviewers have pointed out that unlike in Cloud where Virtual machines can have security groups that provide L3 isolation (Ports and IPs), on-premises data centers only connect to application servers via L2 switches, which does not support L3 isolation. This is deeply problematic because a third-party having access to the App server (IMPS) practically has network access to other assets.

[7] Reviewers have pointed out that it is quite possible that this could be an unintentional glitch. While this is a possibility, a configuration change from port 49100 to 46110 is a deliberate act, as it requires changing what is already working to something else. Further numbers 9 and 6 are not adjacent and neither are 0 and 1 in standard qwerty board format, which rules out typographic errors in deployment scripts as a possibility. Hence on balance of probabilities, intentional change is more likely than unintentional change.

[8] Refer to IMPS Settlement process by NPCI at https://www.npci.org.in/PDF/npci/others/IMPS-Settlement-Process.pdf

[9] https://www.business-standard.com/finance/news/uco-bank-recovers-79-of-wrongly-credited-amount-after-imps-glitch-123111600218_1.html

[10] It often bears repeating that KYC is a complex issue and going digital via eKYC does not solve much, contrary to common opinion.

[11] CloudSek recently published a research about how Cartels operate money-mule accounts at scale. https://www.cloudsek.com/blog/shadow-banking-in-your-pocket-exposing-android-app-used-by-money-mules

[12] The list of banks asking for RFPs can be found quickly via a google search.

[13] NPCI Circular – https://www.npci.org.in/PDF/npci/upi/circular/2024/Product-Compliance-001-FY-24-25-Initiation-of-Self-Attestation-for-Q4-FY-23-24.pdf