Background
Assume there are two banks in the ecosystem – UCO bank and State Bank of India which wants to transfer funds between their account holders.
They both appoint an intermediary (It could be anyone but for our purpose let us say it is the RBI).
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).
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).
SBI then credits the 10 rupees to B’s account by withdrawing it from the account it holds with RBI.
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).
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.
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.
Core Banking Product Architecture
UCO Bank’s IMPS Implementation
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).
Once the request is validated, Sender’s bank deducts ₹ 100 from the sender’s bank account and routes the request to NPCI.
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).
The IMPS Switch then translates that message into ISO-8583 message and forwards that message to Connect-24.
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.
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).
Once the request is validated, Sender’s bank deducts ₹ 100 from the sender’s bank account and routes the request to NPCI.
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.
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.
What the Fraudsters did
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.
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.
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.
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).
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.
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.
IMPS is settled between banks at an aggregate level basis by setting off credits and debits instead of individual transactions.
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.
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.
·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.
IMPLICATIONS
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.
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).
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.
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.