Data Issues Complicate Core Conversion for Credit Union

SafeAmerica Credit Union is coming into the homestretch of a large project it undertook in May: updating its core from Fiserv to Corelation.

At a time when core overhauls are few and far between in the banking industry, and with a rollout date looming a few short months away, sister publication Credit Union Journal visited with the SafeAmerica's IT guru in Pleasanton, Calif. for a second time to see how the plan was unfolding.

"I had initially planned on managing the entire conversion process myself, as I have managed system conversions previously. I expected it to be a full-time-plus commitment," said SafeAmerica Credit Union's Vice President of Technology John Gracyalny. "Our CEO convinced me to bring on board a professional project manager to free up enough of my time to be able to continue to contribute to both day-to-day operations as well as [the conversion]. As it turns out, he was more perceptive than I was."

SafeAmerica Credit Union's journey from due diligence to discovery to implementation has been cumbersome and taxing, though ultimately rewarding.

In June 2014, Gracyalny provided a behind the scenes look at undertaking a core conversion. 

While the process has gone smoothly to date, what surprised Gracyalny is the amount of time and oversight required to ensure a streamlined transition. He refers to the hired project manager as more of a "people person" who handles coordination issues, both with third parties and internally between departments.

"Even with a project manager to handle much of the paperwork and coordination issues, I find myself putting in close to a full week tending to conversion issues on top of maintaining normal operations and planning," said Gracyalny. "I try to focus my time on the most pressing technical issues, such as writing specifications for the conversion programs and testing interfaces, as that plays to my technical strengths."

The Decision to Upgrade

When CU Journal last visited with SafeAmerica CU in June, the $310 million credit union, supporting 25,000 members in eight locations, was using Fiserv's DataSafe as its core operating system. Gracyalny, who has worked in the field of IT since 1967, said the 32-year-old operating system served the credit union well, but was showing signs of age.

With the aide of ICI Consulting, the credit union issued a request for proposal and eventually selected Corelation, which uses IBM's version of the UNIX operating system and DB2 database and is written in Java and C++.

In recent months, SafeAmerica, in conjunction with Corelation, has also undertaken an exhaustive coding process. "We are the first credit union using our existing legacy core system to convert to Corelation, so the conversion program has to be written, rather than just pulled off a shelf," said Gracyalny.

The SafeAmerica CU core conversion team has multiple responsibilities.

These include coordination and project management, which entails arranging with its current core vendor the installation of a de-conversion program. Additionally, team members have to provide documentation from the current vendor on file layouts to the new vendor so the files are interpreted correctly. Next, the team had to transfer test de-conversion files from the Fiserv core server to Corelation core server.

Gracyalny also oversees database clean-up and standardization. This includes performing an address extract, running the files through the postal system's software to standardize all addresses and then re-importing the data into the legacy core, he noted.

"It also involves running custom reports to let us look at data fields that are either pure unformatted text, such as comment fields, or fields that we have created to store information on the core not supported by its native mode database," said Gracyalny.

The SafeAmerica CU team is also in the process of writing specifications for text and user defined fields allowing Corelation to integrate data into fields in their system.

This first test was skeletal in form, meaning that it did not contain every data field that the credit union will need in the final conversion. "The goal with the first drop was to build basic records such as customer records, share and loan account records, among others," said Gracyalny. "And generally speaking, only the standard fields were converted, the programmers are still working on all our custom data."

Making Records Match

In January, the credit union expects to have the database close to finalized so that the team can start testing various external transaction sources, such as posting share drafts and ACH payments, and connecting from internet banking and posting transactions.

"When we get this data drop we will have a formalized process of validating that the data was translated correctly, with lists of test accounts covering all products and services, checklists of exactly which fields on the new system we compare to the old system and a reporting mechanism for discrepancies," said Gracyalny. "We will be using workstations with two monitors each for this task, so that we can show member X's data on the legacy system on one screen, while the other screen will display the same person's information on the new system."

With a go-live date of March 1, 2015, Gracyalny feels confident this milestone will be met. Hurdles remain, including coordinating testing between the third parties and the new core system.

"Until the conversion programming is complete, it is very hard for third parties to do effective testing. This means that most of our testing will not be completed until the last six weeks before we go live," said Gracyalny. "To mitigate this we have tried to stay with third parties who already had an interface into our core system established and in production use at another credit union."