It is always that one weak-link in the chain that snaps to bring a whole institution to its knees. The recent instance of $1.7 Bn fraud reported at public sector bank in India on account of a fraudulent SWIFT transaction, and the instances of hacking related loss of $81Mn reported by Bangladesh Bank in 2016, and a similar incident with a $6 Mn impact reported by a Russian bank last year, are bringing two core issues to the fore. The first is the fact that there are innate vulnerabilities that banks are exposed to, most of which yet remain potentially unnoticed. The second is the urgent need for a holistic review of the operational risk, particularly where the exposures are related to millions of dollars being transacted across the SWIFT network.

This CedarView note provides a quick overview of the operational risks that are inherent in the way transactions get posted using the SWIFT network, and 8 key principles that can help in minimizing this risk. It's time to act, and get your Operational Risk under control, swiftly!

What is the nature of the financial transactions that banks execute using SWIFT?

Every international trade transaction needs to be settled, and banks play the role of transferring funds across borders on behalf of their respective customers involved in the trade transaction. While not all are necessarily to do with an underlying financial transaction, trade finance operations require banks to also exchange other types of messages related to instruments such as Letter of Credit or Guarantee.

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is the secure and encrypted platform that allows for all banks, across the globe, to transfer messages and facilitate financial transactions. SWIFT is used by over 11,000 financial institutions in more than 200 countries, with more than 15 million messages being exchanged each day.

How does SWIFT postings typically get operated by banks globally?

SWIFT does not execute the funds transfer itself, but acts as the medium to send payment orders, that gets settled by correspondent banks. Banks have a SWIFT terminal that is used for connecting with the network, which links with all other banks across the global network.

In essence, the SWIFT transactions get to be posted in two ways:

  • Most Core Banking and Back Office Systems such as Trade, Treasury and Payments have the capability to directly integrate with SWIFT and send straight-through-processing (STP) transaction instructions. Here the transaction posted in a core banking or other back office systems automatically generate a SWIFT message, and have it relayed through the SWIFT network to the correspondent bank.
  • Manual posting on the SWIFT terminal is the other mode of transaction, which is typically done where there are no direct core banking or back office system connectivity, or where there is no STP protocol for that transaction type, or where banks look for an additional manual maker-checker validation by an authorized person.

What is the operational risks that banks are exposed in this context ?

Banks can be typically exposed to two types of operational risk in the context of SWIFT payment, in addition to the cybersecurity risk and related vulnerabilities. The first is the risk of erroneous postings and the second is that of fraudulent transactions. Both are operational risks driven by organizational, process, and technology environment, and both of which can result in significant losses. The recent example of a public sector bank in India illustrates this core issue of a fraudulent transaction.

While SWIFT is a critical platform for every bank, the actual financial transactions are initiated in their Core Banking and other back-office systems and driven through STP. Banks also prefer to have an alternative mode of manual posting where there is a need for additional validations. In essence, there is a context, linked with merits and challenges with either approach:

  • STP allows for the whole transaction going through without any manual intervention, and therefore minimizes events of fraud. However, a glitch in Core Banking Systems or an error in the posting of the transaction could lead to erroneous transactions getting initiated/ posted. Also, since the core banking platform and other back-office systems are used by a large base of employees, enforcing the controls in the authorization process and controls would need to be done across all systems.
  • The alternative is where banks post the entries in SWIFT without an STP, where a select set of authorized and trained people get to post the transactions. These also include nonfinancial transactions that create a contingent liability. This approach comes with the operational risk of giving access to a few individuals on a critical platform, and hence fraught with a higher risk of fraud.

In the real world, it is generally a combination of both situations that exist. While most financial transaction types generally tend to be posted using an STP, there are a set of non-financial transactions that get to be posted directly (manually). Also, all exception situations involving free format and enquiry messages usually tend to be managed outside the STP flow, with a manual intervention.

How can banks minimize such operational risks ?

The real solution to drive higher controls is not only about integration of systems, but also about having a strong process workflow, prudent organizational controls and a well monitored compliance framework. Here are 8 key principles that are fundamental to minimize operational risks around SWIFT:

  • Workflow: An automated workflow for each type of transaction, with pre-enabled STP and approval levels and compliance norms across core and back-office systems.
  • Access Control: Manual interface with the SWIFT network being remediated with redefined access controls enabled through all such connected systems.
  • Approval levels: Approval level definition with 2 to 3 levels of control being maker-checker-verifier, based on the underlying transaction value.
  • Job Rotations: Enforcing employee job-transfers and periodic rotations. Critical to avoid collusion, and fraudulent transaction risk.
  • Authority Matrix: Authority matrix aligned with responsibilities. Both SWIFT and Core Banking Systems should be configured accordingly.
  • Fraud Analytics & Reporting: Use of analytical tools to monitor fraud, Know your Customer (KYC) and AntiMoney Laundering (AML) compliance. Exception reporting resulting in immediate, high intensity investigation and action.
  • Limit Management: Definition and measurement of direct capital exposure, contingent liabilities and collateral management driven by credit policies.
  • Audit Reviews: Periodic, institutionalized audit reviews to confirm compliance to policy norms and adherence to all above. This is fundamental and most critical.

How can Cedar help ?

Cedar Management Consulting International, LLC (www.cedarconsulting.com) is a leading global consulting and research (www.ibsintelligence.com) firm with a significant financial services practice.

With deep experience in business, operations and technology transformations, Cedar has deep understanding of operational risk and process controls to be put in place, and has advised global banks in the design and deployment of a risk management framework built around the key principles defined above. Typical assistance areas that Cedar offers include:

  • Diagnostic Review: Assessment of current risk exposure & key vulnerabilities related to the process flow, technology deployment including STP and controls.
  • Process Design & deployment: Design and implementation of automated workflow framework that identifies points of vulnerability and build a higher degree of controls.
  • Risk Management Framework: Design and implementation of a risk management framework that helps in driving compliance, aligned to industry best practices.

Talk to our Consulting leaders about how we can add value
Contact us to make strategy & innovation work for you

Relevant CedarViews