One of the underlying principal advantages of Blockchain technology (which supports bitcoin) is the concept of distributed ledger (auditing). There is no single point of failure of the audit trail, with the multiple copies floating everywhere and hence it is tamper-proof. Long before this was introduced by Satoshi Nakamoto in 2008, this concept was successfully used for auditing a financial application and also help solve a crime. When I first read about this a few years ago it reminded me of my design back in the 90s. Finally, I got the time to write about it.
The Background/Context:
It was the late 1980s/ early 90s, and life went on happily without cell phones and the internet. We were building decentralized systems for unreserved train tickets. We were constrained in that they had to be decentralized, withstand power failure, and be tamper-proof. They used to collect over 200,000 rupees in an 8-hour shift on each booking window– all in cash. Thousands of such machines were spread out across hundreds of Indian Railway stations. (5 million tickets per day- the most in the world) To put it in perspective, in those days, Rs. 200,000 was about 10 years’ salary for the booking clerks and hence there was a significant incentive to break into those systems or somehow tamper them. Given the lack of any long-distance (computer) network, we had to settle for an RS232C serial connection between the ticketing system (which was a self-sufficient system, one per booking window) and the central accounting server (one per station) to transfer the end of shift data for consolidation of reports across the station for further transmission to the divisional headquarters accounting department.
The solution:
The system was an M68000 based standalone system for which we had written the 
software almost from scratch, a microkernel, device drivers, application code, global data tables, all “burnt” into an EPROM (we later started using flash drives in 1993). The station-specific data was stored in a separate pluggable sealed cartridge with its own EPROM – with an internal rechargeable battery. The transaction data was stored both on the main system as well the cartridge, so in case the main system went down for any reason, (Plan B) the booking clerk can plug it into another working system and continue their shift. As a further precaution (Plan C) in case the whole station loses power or is down for any reason, I designed it such that the cumulative cash collected until that point is printed in a simple codified way on top of the next (not yet sold) ticket. In this image (randomly picked up from Google) the code JFBA on the top-left indicates the cash amount of 9510 rupees collected in that shift until and including the previous ticket sold.
The purpose of this was so they can at least close their shift and remit the cash as shown by the code and go home. This is also how I built in the distributed auditing aspect into the system because when each ticket is sold to a passenger (with the cumulative cash collected in that shift recorded on the top of that ticket), they traveled with it to a far off station, where (many of) those tickets were collected by the station staff at the exit gates and stored. The majority of the booking clerks enjoyed the benefits of a quick shift closing with the click of a button and did not have to manually account for the card ticket stock, cutting down their shift closure from almost 30 minutes to just 2 minutes.
The fraud:
However, there were some black sheep who decided to defraud the system. The zonal railway authorities noticed the revenue significantly dropped In Surat railway station in 1996, (pic below) and started investigating. It was obvious that there was some fraud going 
on, but the railway officials were missing information to prove the exact amount embezzled and other specifics. On the surface, everything seemed perfect with the end of shift reports showing the (lower) amounts collected, which were deposited accordingly. We noticed that there was a gradual reduction of the amount over a period of a few months. (Apparently, the staff started small, and when no one caught them they became greedy and bolder as months went by- which incidentally caused a bigger dent in the revenues, big enough to get attention). Earlier there seemed to be a healthy mix of high value (long-distance) tickets and low value (short distance) tickets in a shift, depending on the train schedules. But recently, all tickets were reported to be sold for shorter distances and hence the low revenues. Prima facie the reports tallied, the ticket stock was properly accounted for. So they sealed all the systems in that station which they believed were somehow tampered and had replacement systems and staff to keep the show going on while suspending the supervisor and a few suspected clerks. Now they needed proof and specifics. As the designer of the system, I was asked to be on the investigation team and visit Surat along with other railway officials. We were provided police protection even before we reached Surat station given the stakes involved.
How I solved it and provided the proof:
Even before reaching Surat, I talked to the superintendents of train stations in Secunderabad, Bombay Central and other stations (which receive long-distance trains from Surat) to collect as many used tickets (originating in Surat during that period) as we could from their store. (remember they collect the tickets at the end of the journey)? We got them to our team who painstakingly collated the date /time stamps of the ticket issued, the machine id, the encoded cumulative cash collected on it, piecing together solid proof of how much cash was embezzled during those days and the discrepancy between the phantom shifts they created on those systems using non-ticket stock (dummy paper). As an undocumented feature, I also had a running counter of the total cash collected on each machine which was also being transmitted to the central report server (but I did not announce or report its existence until after this fraud). That total completed the puzzle to provide an exact total. The disciplinary process then took its course to punish the guilty. The leadership appreciated my tamper-proof design and cleared our systems for further usage.
Key Lessons:
- When temptation and stakes are high, fraud is a natural consequence- prepare to address it!
- Distributed auditing saved the day to provide indisputable proof of the audit trail.
- Always keep an additional ace up your sleeve when it comes to auditing so if the people who are supposed to check themselves resort to fraud, you have another level of checks unknown to them to fall back upon.
tvprasad 
Awesome – and well described Prasad!