This article appeared in the September, 2007 issue of the Indian Banker published by the Indian Bank''''s Association (IBA).
The article was authored by me. A summary follows.
"Show must go on", the oft-quoted phrase in Business Continuity Planning (BCP) owes its origin to the entertainment industry from an era when Information and Communication Technologies ICT) were not much developed. Shows were live and booked in advance, and a cancelled show meant absolute doom for the business. However modern day ICT has enabled this business to separate production and distribution, and eased the
anxieties that marked the theatre era. Of course, devoted groups are keeping the theatre alive, anxieties and ICT solutions notwithstanding.
However in case of banks there were no such neurotic anxieties until the centralized Core Banking Solutions (CBS) made their debut. The distributed branch network whether working manually or using stand-alone software on PCs or using a Total Branch Automation software, ensured that no disaster could impact a bank as a whole. A distributed branch network, each with its own data, also affirmed a banker''''s avowed policy of not keeping all its eggs in one basket.
However the advent of CBS changed the picture forever. It madee the bankers do the unthinkable, putting all their eggs in one basket. And the eggs in this case happen to be probably one of their most valued, and irreplaceable asset, namely, the data! The promised advantages got the better of them. These were many and included enabling alternate channels and providing a single view across all of them, providing a single version of truth in the form of central and real-time MIS and BI, separation of front and back office activities, enabling processes for catering to the massive Retail segment, catering to customers’ requirements round the clock and around the globe.
It is indeed ironical that the very same
technology that helped entertainment industry get rid of its anxieties, induced anxieties of the same order in Banking industry. What compounds this irony is the fact that the fallouts of such intensive and centralized implementation of technology can only be countered through another equally massive dose of technology in the form of a Disaster Recovery Centre (DRC).
The centralized deployment of technology is extremely complex, a veritable Pandora’s Box indeed, containing multiple hardware and software systems, and wide global reach through multiple channels. The industry has been forced into creating yet another role, namely, that of a System Integrator, who can liaise with the multiple technology vendors and provide a single point for enforcement of all SLAs. The complexity of the agreement required to enforce the SLAs can be easily visualised. These SLAs provide the ultimate bulwark for BCP.
Many bankers devote large sections in the BCP to security policies and vendor management thinking that once these are firmly in place the chances of a disaster will be mitigated and the objective of BCP served. This is fallacious and adds unnecessary bulk to the BCP. The whole point of having a BCP is to take care of the tail in probability density curve, that represents low probability but high impact incidences. Accordingly BCP should focus only on this area leaving other said matters to separate security and outsourcing policies.
The article cautions that even with a full-fledged DR, there are possibilities of things going wrong. One is that of a "rolling disaster" propagating to the Disaster Recovery site. The other relates to transactions taking place through Alternate Deliver Channels (ADCs) for which no paper records are available. As the systems driving these channels are likely to be collocated with the CBS, records for the period of agreed RPO (Recovery Point Objective) may become unavailable for reconstruction of data.
The article notes that currently Data Centres and DR sites do not require a license from the