Why Banks Must Find Dupes Sooner
By Frank Stokes A rising tide of duplicate items threatens the growth of remote deposit capture, one of the most popular forms of electronic payment ever offered. The solution? Much earlier dupe detection at banks, says Frank Stokes. When enacted six years ago, Check 21 explicitly promised to facilitate check truncation, foster innovation in the check-payment system, and improve the overall payment system. Although the industry has embraced image exchange and realized many of its greatest benefits, Check 21 has added risk and created operational complexity in the form of new exception types and an increase in existing types of exceptions. This spike in exception items has been an unintended consequence, limiting the explicit mission of Check 21. Inadvertently, Check 21 has challenged the banking industry to respond with innovation not merely to improve the over-all payment system but, in a more compelling way, to fundamentally transform it.
Specifically, the persistence of exception items in the form of duplicate payments from remote deposit capture (RDC) implementations has restrained banks from pushing RDC beyond branch and corporate- or merchant-capture environments. In 2006, a CONIX Systems internal customer survey indicated that banks expected five to seven duplicates per million items from RDC. Today, we know that high-volume banks are actually intercepting between 40 and 100 duplicates per million payments processed. Factor in a $50-to-$100-per-item cost for duplicate resolution, and the inherent risk and cost burden of Check 21 to banks begins to crys-tallize. The reluctance on the part of financial institutions to make larger-scale commitments to merchant and consumer RDC deployment makes good sense. According to information aggregated by the CheckImage Collaborative (www.checkimage central.com): "On an average day during December 2009, over 59 million check images were received for posting. When the December volume is annualized, it totals 15.1 billion checks for $17.6 trillion. Also, another 2.9 million checks per day were sent as images and delivered to paying institutions as substitute checks. These totaled 752 million checks per year and $864 billion." Sticking Point Given these figures and the duplication rate that banks are experiencing, it truly boggles the mind to consider the impact of broadening banks’ corporate- or merchant-capture offerings. Even more unsettling are the predictions of the media and industry pundits regarding the imminent adoption of consumer and mobile-device capture.
It isn’t that the duplicate-payment dilemma was unexpected. Even the FDIC, in a Financial Institution Letter in 2004, warned of the potential risk: "The lack of access to original checks necessitates the need for revised check review procedures and employee training, and a review of check security features ... Additionally, a new potential risk of double posting will be created (i.e., both the original check and the substitute check enter the processing stream). A reconverting bank must warrant that it is not requesting payment on items already paid." According to i3G’s May, 2010 Industry Best Practices Document – Incoming Returns Report: "Similar to the industry’s experience with forward collection and pre-sentment, duplicate files and items also impact the image exchange of return items. Although the volumes would be lower, financial institutions should be prepared to receive duplicate files and duplicate items in their incoming returns ICLR files. The risk of not identifying duplicate items would likely result in erroneous charges to the bank’s customer and impact the reputation of the bank. In addition, mistaking represented items as duplicates and erroneously submitting adjustment cases to the returning bank creates opportunity for delayed returns and operational losses." The sticking point, as we have come to understand it, is not with whether the duplicate item will be found, but when. Banks should identify the duplicate before it has a chance to cause a cascade of repercussions—some easier to quantify and resolve than others. According to some institutions that are fully engaged in RDC, the major-ity of duplicates are currently not fraud but systemic errors made by other banks. However, the rapid proliferation of RDC options to a wider swath of users is predicted to turn that tide. The issue of whether systemic error, human error, or fraud causes a duplicate item is secondary. Of primary concern is the speed with which a bank can identify and terminate duplicate items, thereby minimizing their impact. When duplicate payments are discovered on Day 2 or later, after posting to a customer account, their ripple effect is costly and time consuming to correct, and erodes customer trust. If a dupli-cate payment is identified on Day 1, or, even better, when presented for deposit, virtually all of the costs are eliminated, resolution is a non-issue, and there is no impact on customers or bank partners. By preventing duplicate payments from posting, banks can minimize RDC risks and begin to maximize the benefits of including check-image payments in the electronic payments stream. What would Day 1 image-duplicate detection entail? Technically, since the same payment can process through multiple channels, an enterprise duplicate-detection solution must have the capability to examine all payment channels. Most banks will want their RDC duplicate-identification system to integrate with their legacy payment platform(s). Further, duplicate detection must be performed at the item level, not just at the file level. Unfortunately, the problem of duplicate items has exposed financial institutions to unforeseen operational risks inadvertently created by Check 21. On the other hand, the duplicates dilemma is forcing banks to acknowledge and contend with the fact that catching a duplicate—or any exception item, for that matter—is best done sooner rather than later. |
|
|||
Privacy Policy |
Conditions of Use |
|
||||
