Of the many thousands of businesses that will be affected by year-2000 issues, banks may be the most vulnerable, because their systems are so reliant upon date-sensitive information.
Most if not all of the largest banks are well along in preparing their systems to avoid the so-called Y2K programming glitch.
But many midsize and small banks have just started this costly and labor-intensive task.
Many of these are counting on their service providers and software vendors to help them fix their systems-a risky and incomplete approach at best. Some, daunted by the scope of year-2000 fixes, are positioning themselves for sale rather than assuming the cost burden of these initiatives.
The regulators are clear about what they expect from bankers and about who should be addressing this problem.
The Federal Financial Institutions Examination Council issued a statement in December saying that year-2000 preparation "is not only an information systems issue but an enterprise-wide challenge that must be addressed at the highest level of the institution."
Comptroller Eugene A. Ludwig, chairman of the exam council, said "Financial institutions that treat Y2K only as a technology issue will be caught short."
He emphasizes that senior management and boards of directors should be addressing these issues, allocating sufficient resources to ensure they get the attention they deserve.
The board must oversee the institution's year-2000 efforts and require quarterly reports from management that detail progress and identify roadblocks.
Dean Debuck of the Office of the Comptroller of the Currency applauds the regulatory community's joint efforts in issuing safety and soundness guidance on the businesswide risk posed to financial institutions by the year-2000 problem.
"We have put together time lines and milestones for banks to adhere to," said Mr. Debuck. "The OCC guidance states that by September 30, 1997, banks were to have identified effected applications and data bases."
Mission-critical applications should have been identified and an action plan set for year-2000 work.
The OCC guidance requires that computer code enhancements and revisions, hardware upgrades, and associated changes should be largely completed by December 31, 1998. In 1999 "banks should be testing and implementing their year-2000 conversion program."
Mr. Debuck emphasized the OCC will do "whatever it takes to ensure that banks get ready, including enforcement action." He warned banks to correct their thinking and not to rely on vendors alone. "You must test yourself and the vendor and take the responsibility yourself."
Frank Hartigan, program manager for year-2000 initiatives at the Federal Deposit Insurance Corp., echoed Mr, Debuck. "We expect all institutions to be diligent in monitoring the progress that their software vendors and data-processing service providers are making in providing a Y2K solution," he said.
Mr. Hartigan points out that "under the Bank Service Company Act the FDIC has authority to examine and regulate bank service companies." In short, the performance of vendors is subject to regulation, just like the banks they serve.
John Hull of the American Bankers Association said his organization is working on program to help community banks organize year-2000 products by lines of business.
The program will include "work plans for program management, telephonic seminars, membership alliances, white papers, and best practices-all to drive the promotion of industry readiness."
Rather than fix the code problems in their existing systems, some banks are looking to convert to new year-2000-compliant software.
But time is getting short for banks in the market for a new core system, and available conversion dates are filling up quickly. Several factors are contributing to this situation.
First, many banks with older core systems are facing significant year- 2000 risk. The cost and risk of modifying these systems is huge, and many banks who use them are moving to convert to new systems to avoid these pitfalls.
Second, the rush of bank mergers and acquisitions has increased the vendor conversion work load. Merging banks face a myriad of system issues before even considering year-2000 issues. Add year-2000 compliance and it is no surprise that they will want to convert all subsidiaries to a single core system to reduce the systems risk they face over the next two years.
Third, there are always, in any year, hundreds of banks considering new systems because contracts are expiring, strategies are changing, or they are dissatisfied with their current solutions. The number of banks changing core systems has grown in recent years, and there is no reason to think this will change in 1998 and 1999.
This already is affecting vendor conversion schedules. Many vendors now are saying the first available conversion slots for their systems are in September or October. No bank will want to risk converting to a new core system later than September 1999.
Even banks following an aggressive time line in making a core systems decision-four months being quite aggressive-will need to start the process within the next few months.
The good news is that there is still time to make a well-reasoned selection if your bank starts now and stays focused on the decision.
Here are some tips to expedite the process:
Decide if a core system conversion is really required for your year- 2000 compliance. If not and you can delay conversion until after December 1999, you may be better served. More conversion slots and better financial deals may be available then.
Determine how broad your look at systems will be. Will it include systems such as branch automation, loan origination, and call center as well as core processing? If so, selection will take longer and needs to start earlier.
A broad review also makes you a more attractive potential client. Many vendors now offer ancillary systems in addition to core processing. They will be motivated to sell you a package. Installing interfaces with existing branch or loan systems could add to conversion time and cost.
Focus on systems and vendors that have a real chance of winning your business. Vendors will be swamped with requests for proposal in the next two years, and they will be concentrating on banks they feel are the best prospects. Less-than-serious buyers are unlikely get much attention.
Set a schedule and stick to it! The CEO should sponsor this project, make sure that employees can allocate appropriate time to it, and set time expectations for a decision.
Set the criteria for your decision at the beginning of the selection process, not the end. Decisions can get emotional and heated near the end. Pick for benefit, and not just price. In the long run, a vendor that can help you apply a system effectively to a business need is far more valuable than a cheaper that who can't.
Avoid the "War and Peace" request for proposals. Remember that the point of an RFP is to narrow down the list of vendors you want to bring on site to demonstrate systems. In your RFP, ask questions that are important to you, and make sure you get clear answers. Don't fill hundreds of pages with thousands of detailed questions-vendors won't read them. Banks choose systems when users and managers see the system demonstrated. Maximize that time, not the time writing documents.
Get started! If you don't decide to look at alternative core systems in the next few months, you may have effectively decided not to look at them for the next two to three years.
