The ₹9.60 Lakh RTGS and Three Clocks That Disagree

Convert everything to one reference (IST).

• CBS entry: 12:47:31 UTC + 5:30 = 18:17:31 IST.
• CCTV: overlay 18:12 minus 7 minutes of clock drift = 18:05:00 IST - the manager physically left about 12 minutes before the transaction.
• Door swipe: 18:11:52 IST, already about 5.5 minutes before the entry was made.
• Session re-activation note: 18:17 IST, consistent with the CBS timestamp.

Deduction. The manager was outside the branch, with an independent NTP-synced record corroborating it, when the session was re-activated and the RTGS was pushed. He cannot have keyed it. Two corroborating clocks that disagree with each other in raw form but agree once corrected is stronger than either alone - which is exactly why the drift had to be established first, not assumed away.

Therefore: an unidentified person on the branch LAN used a live, unattended session. That is a control failure, not merely a possible insider act. Note the timeline's precision limit: the terminal note records only the minute, so treat 18:17 as a window and rely on the CBS log for the second-level fact.

The chain that must be built is: application user ID → IP address → MAC address → physical switch port → room → person. A user ID alone proves nothing here, because it was a shared, inherited session.

Ranking:

1. (ii) is the strongest single item. The CBS log ties the transaction to an IP; the DHCP lease table maps that IP to a MAC at that moment, and the switch's MAC/ARP table maps the MAC to one port - one desk, one room. This is objective, time-stamped and not dependent on anyone's memory.
2. (iii) adds the human element: a console logon (event 4624, logon type 2), an unlock (4800) or a workstation-lock event at the relevant second tells you whether someone sat down or the machine was remotely driven.
3. (iv) corroborates identity - but only after applying the −7 minute correction to the recorder and pulling the corridor camera that covers the desk, not just the entrance.
4. (i) ranks last and is close to worthless alone. "Everyone knew the password" widens the suspect pool to the whole branch and proves no act by any individual; it is context for the control failure, not proof of who did it.

Judgement point: never let (i) contaminate the investigation - once staff believe suspicion rests on rumour, statements harden and the objective chain becomes the only reliable record.

Preventive (these would have stopped the debit):

• Workstation auto-lock within a short idle period, enforced by policy, not by habit; the manager leaving a live CBS session unattended is the root cause.
• Elimination of generic/shared IDs and strict one-user-one-ID discipline; the moment an ID can be borrowed, every log becomes deniable.
• Mandatory maker-checker for RTGS, with the checker's credentials entered on a different terminal and the checker physically present - a second pair of eyes on the same machine is not a control.

Detective (these would have caught it fast):

• Time synchronisation of CBS, CCTV, door access and workstation clocks to one NTP source, with drift monitoring. This case was solvable only because one record was independently accurate.
• Session anomaly alerts: ID used outside the user's shift or during approved leave.
• Log retention long enough to survive a dispute, and log review - logs that no one opens detect nothing.

Response: treat it as a reportable cyber incident to RBI within the prescribed reporting window, preserve forensic images before re-imaging the terminal, and notify the customer in writing. Do not quietly close the ticket because the amount is small.