How to avoid another loot like Punjab National Bank fraud
SWIFT must be linked to the core banking system so that scam don't go undetected for long.
- Total Shares
There is a cruel irony in the name of the technology that enabled the fraud at the Punjab National Bank (PNB) - Society for Worldwide Interbank Financial Telecommunications (SWIFT). Essentially a communication network used by trusted financial institutions worldwide to securely send trillions of dollars every day to each other at "message" speed.
A synonym for swift is fast. Money indeed left the coffers of PNB at great speed. It is beyond doubt that speed money was paid to make that happen. Be that as it may, let's see what the key questions before us are in the light of the current scam.
How come after over two decades of automation and computerisation of 21 public sector banks, the combined market capitalisation, minus the State Bank of India, is today less than one private sector newbie HDFC Bank alone? Some basic housekeeping, accounting and reporting are still amiss.
The chief financial officer of any bank will tell you what keeps her awake at night is matching of assets and liabilities, which is central to the banking system and crucial to it remaining solvent.
What systemic issues in public sector banks (PSU) enable these loots to take place with sickening regularity?
One is technology, or rather the lack of it. It's not that PSU banks don't use or spend on technology. They are by and large on a par with their private sector counterparts in the use of technology. But while private sector banks fuss over every rupee spent and strive to match it with their results, public banks don't really show the same efficiency.
Though a few were nimble and became the first movers in upgrading their systems to recent technological advancements such as mobile banking, moving to cloud, early adoption of SMS/IVR payments, the basic hygiene blocks at the larger backend level remain amiss.
Many of these systems remain in silos or on paper if not absent all together. In many cases the interlinking of systems is absent. So the core banking system (CBS) in public banks may not be "linked" to SWIFT, which may not "talk" to a MIS/reconciliation module or be able to "match" un-reconciled Nostro accounts with general ledger or trade finance; or cash flow statements don't quite tie in with current assets/contingent liabilities because of these systems could be ridden with gaps.
Ideally, banks should be able to harmonise and knit together day-to-day retail, corporate, financial inclusion and off balance sheet (OBS) software and modules, and cull key data in a user friendly format - a daily dashboard with the red flags visible to the chain of command, risk and audit teams.
For example, a slice of such a read out will typically include status of contingent liabilities such as unsecured guarantees, non-funded commitments and advances, value of and number of rollover letters of credit (LC) and letters of understanding (LoU) outstanding with their tenure and maturity periods. It should also reflect income recognition, both unearned and actual from fees taken from providing LoU and LC. This will assess the bank's risk appetite such as margin shortfalls, and collaterals among others.
Let's accept it, most bank frauds are plain robberies rather than a clever scam. About 5,200 PSU bank officials have been caught and punished in just last two years itself, which translates into one every four hours. This figure exceeds the number of criminals arrested in Uttar Pradesh over the same period.
All banks must link SWIFT with the trade finance system and the core banking system. The link must exist even if it doesn't operate on a real time basis. This system must have a log in authentication for the physical device from where these entries are made just like the one used by customers of mobile banking applications.
As a measure of abundant caution an OTP or formal verification email link could be added to go to a super user who is not part of the maker-checker chain. Programmed red flag indicators should also be provisioned with some trigger parameters visible to people outside the chain.
SWIFT access (log in password) should also be rewired to lock out and reset every few months. This will ensure a forced review of the person(s) authorised to make entries in the system.
The SWIFT board in India also needs to be recast. It currently has too many representatives from the banks itself. The board needs to be both diverse and independent.
Lastly, SWIFT has been prone to hacking where the local bank network is bypassed and SWIFT accessed by cyber criminals to transfer funds illegally. Several countries have been so hit due to this, including India, Bangladesh, Philippines, Taiwan, Ecuador, Sri Lanka, Nepal, Vietnam and Russia.
It's a cottage industry for cyber criminals in North Korea and other parts of the world. A long-term solution needs to be found given the frequency of these hacks. SWIFT should actually move to use of blockchain over the next five years for a more transparent and secure banking.
Blockchains also can't block out scams completely, however, it will help in easy detection of frauds.