Exception Item Processing Business Rules Workflow or Fraud Rules Scoring
  • Print
  • Share

Making the Exception in Item Processing less Painful and more Meaningful

A story about enabling a bank to follow their own rules for payments, about optimizing risk control and loss prevention, and about customer relationship.

When processing cheques or other kind of banking transaction, there will be always a few that need further scrunity. A bank cannot post transfers from or to a closed account, allow transactions that exceed the boundaries of a given contract, or simply ignore insufficient funds. There are many rules that will turn a cheque item into an exception item if violated. Do those violations just need to be detected and then automatically leading to reject/return of an item? There is also the customer to consider. Did he made that type of error that should be pointed out politely instead of rudely rejected with an automated reason code? Was his objective incorrectly read during banks operations and the rule actually not broken? Did that customer maybe try to break the rule on purpose? Or, was a transaction in reality a fraud attempt from a third person?

Is it good to reject a fraudulent item for insufficient funds? In some countries such a reject can negatively affect a customer's credit record. The customer can sometimes sue the bank for damages in such cases. But even without that lawsuit this is not an exsample for outstanding customer care. If a fraudulent item is missed and thus drains an account, so that the life insurance premium cheque cannot be payed due to insufficient funds, then the situation can turn into a public relations desaster. On the other hand, finding a fraudulent cheque really early and calling the customer before teh cheque is even posted will usually result in one happy customer.  

The task at hand for exception item processing is logically divided into three aspects. First, the aspect of the definition of an exception item. Logically that definition would simply mean: "an item that does not meet the pass criteria". If it is about insufficient funds, the situation is easily detected. But fraud attempts can sometimes fit perfectly within the standard borders of the pass criteria. Identifying exception items should always consider all kinds of criteria that are useful indicators for detecting questionable transactions. The various interfaces of SOFTPRO's SignCheck main module provide for a platform that truely allows one to consider all those criteria. The second aspect is narrowing down the selected exception items to the truely problematic subset. This is the most difficult part, and it requires an intelligently-defined set of filters. This is the task that the FraudOne Solution Packages family is mainly focused on. The last aspect is the question on how to handle the findings of the exception items process. A bank's policy should always include a process in which the final pay/no-pay decisions are made in combination with the right reject reasons. Whether this results in a special backoffice-workflow or a branch-level decision queue, all options are supported by the capabilities of the SignCheck CRS and Workflow engines.