Playing the Numbers: Assigning EFT Testing Priorities

Priority 1 events represent testing standard functionality of the system, including withdrawals, transfers, authorizations, purchases, returns, PIN checking, cardholder verification, and reversals.

A financial institution stands to suffer the greatest losses should something go awry here, such as when the system functions, but in a compromised condition. The financial institution can be assessed switch penalty fees for non-availability, or a compromised system can dispense money in violation of normal safeguards, resulting in substantial losses. When ATMs are dispensing "free money,” or when unlimited POS purchases are approved, there will always be dishonest consumers ready to quickly take advantage of the situation.

Tests for these events guard against failures that can result in loss or corruption of data, or partial or complete loss of application functionality. These tests should be run during the development process and on the final build, and should always be executed prior to deploying an application in production. Regression scripts should also include these tests.

Problems during everyday standard operations will have the greatest financial impact on the institution, and so must be assigned the greatest focus or largest share of test resources.
Priority 2 events test system functionality involving velocity limits, hot cards, or address verification. As these are some of the major avenues of fraud, these events can also have a significant financial impact on an institution. While incorrect functioning of an application during these events will not normally stop system operation, problems here can cause substantial financial losses.

Priority 2 tests guard against failures that will result in an unacceptable loss of functionality. They must be run as soon as practicable. When development is complete, they should be run again. Priority 1 and 2 tests should be executed immediately before deploying the application in production.
Priority 3 events place a financial institution's customer applications in an operationally compromised condition, with a diminished capacity to process transactions. Perhaps an ATM or kiosk is declining all transactions, or a fault has occurred that may not be fatal, but the defective terminal-driving application takes the unit out of service. Similarly an institution may experience periodic communications failure to a POS/ATM authorization network, and its stand-in algorithms fail due to inadequate testing. Although the institution may not suffer as great a financial loss as from fraud events, it can experience a loss of revenue nonetheless—and to some degree, loss of customer confidence, which may result in financial losses which are more difficult to measure.

Tests for Priority 3 events guard against failures that may result in minor loss of functionality, but can likely be remedied by intervention by support staff. These tests should be run after development in this area is complete.

Page 4 of 6

< Previous Page 1 2 3 4 5 6 Next >