This paper payments. faster, and of controls investigates the operational risks associated with the processing of It also clarifies why traditional controls are no longer adequate to handle in some cases, real-time processing cycles, and recommends a new series – known as Parallel, Autonomous Audit – as the solution to these problems.
Operational Risk – A Definition
Operational Risk is one of the more recent additions to the “risk” family, and therefore one of the least well understood. However, we have known about some of the components of Operational Risk for many years. The Bank of International Settlement (BIS) Glossary gives the following definition of Operational Risk: “The risk that deficiencies in information systems or internal controls could result in unexpected losses.” A similar definition of Operational Risk appears in the Federal Reserve System Trading Activities manual: “ …the risk of human error or fraud or that systems will fail to adequately record, monitor, and account for transactions or positions.” These definitions show that although Operational Risk may give rise to incorrect financial information, it is not quite the same
as Financial Risk, which encompasses Settlement, Liquidity, Credit, and Exchange Risk. A number of regulatory authorities are beginning to focus on Operational Risk, now that they are beginning to get Market and Credit Risk under control. Operational Risk appears as one of the cornerstones of Basel ll, and is found or implied in Corporate Governance regulations such as Sarbanes-Oxley section 404. ISACA has done much work to provide a framework for Operational Risk through its COBIT approach. (For more information about COBIT, please visit www.isaca.org.)
Where Operational Risk Exists in Payment Systems
Operational Risk arises in a number of areas within Payment Systems: Processing risks. Authorization risks. Computational risks.
Whether a bank handles a payment transaction manually or via a computer system (or a combination of both), there is a risk that it will not reach its intended destination either within an acceptable timeframe – or at all. The effect of this may be small if a 24 hour delay of a retail customer’s payment does not result in a financial penalty. However, the customer’s dissatisfaction may find expression at a later date when there will be a definite impact on the bank’s business (e.g., if the retail customer ever becomes a Corporate customer). In addition, if the payment is: A High Value time-critical payment, such as a domestic RTGS payment or an international CLS Payment, the bank may face fines of many millions of dollars for not meeting its Service Level Agreement with the customer. It may also lose the Corporate account to a rival bank. In addition, under the SarbanesOxley regime, a Board Member might face prison time, and in the United States at least the customer may sue the bank for Consequential Liability, the penalties for which could put the bank out of business. A domestic Low Value payment such as an “on us” payment check, may get lost in the Back Office of a bank. Likewise, an inter-bank payment may not reach the Clearing House, the Clearing
House may not send it correctly to the Central Bank for Settlement, the Central Bank may not return it correctly to the Clearing House after Settlement or the Clearing House may not send it correctly to the intended receiving bank. An inter-bank High Value payment, the transaction path may be shorter (going from the originating bank directly to the Central Bank for Settlement and then to the destination bank). However, the payment may still go astray, and since it is High Value, it must reach the correct destination within a specified length of time (often measured in minutes, if not seconds). If it fails to do so, it will become quickly evident to the customer that something is wrong. An International payment, the transaction path is often more complex. For example, a payment routed through a correspondent bank network might pass through as many as 10 intermediate banks. In the same way, a payment that a Corporate customer initiates and intends to settle through CLS Bank may go from Corporate to a Third Party bank, to a Settlement bank, to CLS Bank, and then onward via another Settlement bank, another Third Party bank, and finally to the receiving Corporate customer. Therefore, the more links in the transaction chain, the more chances of a processing error. Again, if the payment is a High Value payment, any error becomes quickly visible to the customer.
Payments for more than a certain value have always needed a specified level of authorization within a bank. Banks generally check for this within a computer system. However, with the increasing emphasis on straightthrough processing and the automated detection and correction of data errors, there is a need to ensure that corrections that require re-authorization receive it. This is possible using a new type of control, called Parallel Automated Audit. A bank can embed a rule in its business database to verify that a correction receives the same level of authorization as the original transaction. Parallel, Autonomous Audit uses an independent piece of software that “sits on top of” an application or applications and monitors each transaction using a database of business rules. These rules specify
the path that each transaction should take, and how long it should take the payment to reach its destination. Historically, banks have used this type of control to monitor an individual computer system. However, as payment transactions become more complex and can follow a number of paths, there is a growing realization that customers hold a bank responsible for its own processing – and for speedily detecting when an error occurs elsewhere in the transaction chain. Banks generally accept that payment transactions always follow pre-determined routes, and that the participants are part of a Closed User Group. The banks involved know that they are part of a chain, and as a result, they unwillingly enter into a spoken dialogue to try and trace a missing payment. However, banks must now automate this dialogue to detect errors in real – or near real-time.
There have always been controls such as batch totals, trial balances, and statement reconciliations to detect the corruption of an item of data – whether intentional (fraud) or unintentional (software or hardware error). These controls will continue to play an important role in payment systems. The problem with such controls is that the errors detected only become visible after a period of time (e.g., at the end of the day or even at the end of a month). This delay in detecting and correcting an error increases the chance that the customer will find out about it. As it becomes easier to move an account from one bank to another, and customers no longer have the same traditional loyalty, they are less likely to accept mistakes by their bank. Even though retail payments are of lower priority to banks, the increasing frequency of clearing cycles (e.g., Interpay in the Netherlands clears retail payments every 30 minutes) requires banks to detect errors faster. This is even truer for High Value payments that banks are now processing in realtime, where batch-type controls are less useful.
The Parallel Automated Audit approach allows a bank to define the profile of each individual payment transaction. It also enables the detection and correction of errors in real-time across a Closed User Group.
How Such Errors Occur
A data capture error where a valid, but incorrect, BIC or IBAN destination code is entered. An error in the middleware or application software that sends a transaction to an incorrect destination. In many banks, a different application system handles each type of payment instrument. Therefore, if a direct debit is miscoded as a standing order, the wrong application will process it. The failure of a processing node or a communications link may fail. This type of failure can delay a payment for an unacceptable length of time – without giving the customer any warning.
The Use of Controls
In a payments scenario, banks use controls to detect an error in the operational sequence of the process. These controls should detect when a transaction is mis-routed to an incorrect destination – or when it fails to reach its destination.
As the processing cycle for both Low Value and High Value payments becomes shorter, there is no longer enough time for a bank to detect and correct processing errors quickly enough for the customer to remain unaware that a problem exists. Even when the customer becomes aware of a problem, he is increasingly unlikely to accept a tardy response from his bank. To address this scenario, banks need to: Automate the detection and correction of errors.
Supplement traditional batch controls with real-time monitoring of individual transactions against a profile defined in a Rules database. Automate the diagnosis and correction of errors right along the transaction chain – and not just in their own computer systems. Technological solutions exist to address all of these issues. Banks that implement these solutions will be able to: Assure regulators that the bank is handling its customers’ money in a responsible fashion. Increase the chance of retaining customer accounts when errors do occur (as they always will).
About the Author
Jim Jones has worked in the computer industry for the last 40 years, with the last 20 of those focused on Payment Systems and Risk Management. He has consulted with a number of countries on the strategic development of their Payment Systems, and has managed the implementation of some 20 national systems. Jim has also worked to re-architect the Back Office of a number of major international banks. He is a regular speaker at international conferences on Payment Systems.