Shopping for Software (6 Action Steps)

When you purchase software, it isn't enough to take the salesman's promises at face value. In fact, believing the salesman's promises could be a problem. The salesman's goal is to make the sale. After that, what the product does or doesn't do is your problem. And that's exactly the problem with purchasing software.

Too often, financial institutions have been taken for a ride when purchasing software. It doesn't do what was promised, or it causes a problem that wasn't anticipated. When the purchasing institution complains to the software vendor, the vendor acts surprised, indicates that all their other customers are fully satisfied, and they can't possibly fix the problem.

An institution's goal in purchasing software should be to avoid this bind. The FDIC has just published guidance on ways to avoid this problem. In FIL-121-2004, the FDIC provides guidance on steps banks should take when shopping for software.

The issuance of the FIL is the result of concerns that FDIC examiners have raised with software they have encountered in institutions. Some software that banks have purchased does not enable the institution to comply with required laws. Specific concerns have been raised in the context of the Bank Secrecy Act, including the 2001 amendments.

Management Responsibility
As with any purchase, the motto should be caveat emptor, or let the buyer beware. The first concept in this principle is not to believe what the salesman tells you. Those responsible for the purchase of appropriate software are those in management.

FDIC's FIL directs management to ensure that due diligence is taken when purchasing software. The need for due diligence increases regularly with advances in computer systems, remote access capability, and regulatory changes.

The FDIC expects institutions to take two approaches. One is to validate the process by which the software has been developed. The second is to evaluate the quality and functionality of the final product. And this means doing much more than asking questions of the salesman.

Testing
There are always technical issues, such as whether the proposed software purchase will be compatible with existing software and hardware. This is a job for the IT staff.

Ensuring product quality involves more than technical issues. The question here is really whether and how the software gets the job done. This involves several important steps and it must involve more than the IT and budget considerations. FDIC identifies eight steps.

First, be clear in establishing the specific function of the product. Know what you need the product to do. Include the full scope of the job to be accomplished. This usually means thinking through the needs for and uses of the software before even shopping.

Second, identify areas where the product does not meet selection criteria (from the first step) and determine what or whether anything can be done to remedy the shortcoming. This means knowing the weaknesses of the software as well as the bells and whistles explained by the sales rep.

Third, determine risks associated by each criteria not met by the product. What will you be unable to do with this software and how much of a problem will that be?

Fourth, prepare and review your plan for dealing with any of the software's deficiencies. You can expect your examiner to review this.

Fifth, a key part of due diligence is finding out how the software works for others. Get a list of current uses and contact them. Ask questions, especially about how the software works in problem situations you have identified. If possible, talk with software users who have other systems that you also use and find out about any interaction problems.

Sixth, test first. Any software purchase should include a test. Design a test that will run the software through the needs you have identified. While testing, determine how the software works with other systems you already have in place.

Seventh, review the product's security. Evaluate how secure it is and what could happen if the security is breached. This involves more than protecting customer information. This should include an assessment of whether anyone can hack in and manipulate the system.

Finally, find out about the support for the products. Conduct a due diligence on the vendor, including their financial and professional stability. Also find out from other customers whether the product is supported in ways that meet your needs.

Compliance
In addition to the software issues, the software should be vetted for compliance. This involves two approaches. First, determine that the software is consistent with regulatory requirements.

Second, determine whether the software will enable your institution to produce compliant services and products. In short, does the system work within your compliance procedures. If not, you need to go shopping again.

It is the financial institution rather than the vendor that is ultimately responsible for compliance and security. However, the financial institution is the customer. Don't forget that when asking questions or asking for solutions to problems. The vendor should produce what you need.

ACTION STEPS

Take steps to ensure that compliance is part of the selection team. Be included and be constructive.
Establish a team and a protocol for testing software. The team should include the users and all concerned functions, including IT and compliance.
Determine the needs. Have a clear list of what you want and need the software to do. The list can include "must haves" and "nice to haves."
Go shopping. Look at lots of products.
Obtain a list of users from the vendor and contact those users. Speak compliance manager to compliance manager to be sure you get the compliance spin on any problems with the software.
Ask questions and demand answers - in writing.