When an India-based global bank decided to sell a Caribbean operation serving small business customers, a large indigenous conglomerate saw a strategic opportunity to broaden its customer base. It looked like a win for both parties. A deal to acquire the retail operation by the Ansa Merchant Bank was soon reached.
After the acquisition secured regulatory approval, the new bank became a subsidiary of a much larger merchant bank with a mission to expand its scope beyond retail operations to include a variety of corporate and wealth management financial services. But it needed a complete revamp of its retail and commercial banking application systems on a deadline that many reasonable IT professionals would consider impossibly tight.
There was no core platform to support the bank’s needs. The software in use at the bank was provided by a data center based in India, and when the cutoff date arrived, all of it would disappear at once.
Functionally, the new bank was a startup—but one that already had customers who were depending on it to seamlessly deliver trustworthy services.
The bank needed to put in place a reliable, compliant, well-integrated system for handling customer data, card systems, a digital marketing platform, collaboration tools, fraud prevention and risk management tools, and contact center support—in short, all the technology a full-service bank would require. The transformation needed to happen fast, and at the helm was the bank's Chief Information Officer (CIO), Kirk Henry.
Before changing hands, the bank had primarily serviced loans, outsourcing its operations to a private cloud-based data center in Hyderabad, India. The new bank could continue using those services for a time while it established its own infrastructure—but when he took the job, Henry did not know that transition time was a scant 12 months.
“Effectively, my team and I had to figure out how to migrate the customer data and create new business processes that would align with the existing technology as well as the new system,” Henry recalled. “We had to do all of the life cycle activities, including testing. We had to verify all the change-management procedures associated with bringing new users into the environment. We had to take all the existing customers and bring them across. And we were looking to grow at the same time.”
The team sought mature banking solutions from vendors who could work in tandem with the in-house staff to implement a system that would meet the specifications for their unique environment.
The board chair recognized that a core banking migration would need to be executed. He described it as “akin to performing open heart surgery while you’re on a treadmill.” Henry pointed out that his team would have to carry out the delicate operation while approaching a cliff. Even though they had managed to negotiate an additional six months, the drop-dead date for the implementation was looming.
“If we didn’t get this done on time, we would have had to resort to running the bank on spreadsheets and notebooks,” Henry said. “Core card services, including the debit card that was part of the bank’s main loan product, would cease to operate. It was all hands on deck.”
Remote Implications
To make matters more interesting, all of this was taking place when COVID-19 restrictions were just beginning to ease. For the most part, Henry’s team operated remotely, except for the implementation week, when he brought certain staff onsite to support the branches that had to be open (with limitations).
“We did the entire project—95%, I would say—using remote teams,” he noted. In some respects, that worked out better because of the hours the team kept. When the pressure was most intense, they worked until after midnight, only to start again as early as 4 a.m.
However, the pandemic also interfered with their ability to access legacy customer banking data. There were employees willing to work at the data center in India, but because of traveling protocols, they could not access it.
Without the customer data, they could not start the migration in earnest. All the work Henry’s team had done until that point, planning the move from one system to another, was theoretical. In business terms, the stakes were high. They needed to get digital Internet banking up—the website and the mobile applications for both Android and iOS—and the debit card management system online. Everything had to be tested, and assuming there were no system glitches, Central Bank approval would still be required to proceed.
Compliance Constraints
Due to time constraints, the work did not proceed in a calm, linear fashion; there was overlap. It was necessary to ensure that the new systems would be compliant with enterprise policies, so assurance activities were sometimes carried out while negotiations were underway with providers for financial systems. They had to demonstrate to auditors that there were good governance practices in place around the implementation methodology.
“A lot of us wore multiple hats,” Henry said. “I was involved in negotiating with vendors about deliverables and pricing, making design and hiring decisions, and delivering the steering committee reports to the board. I conferred with consultants to develop a security strategy.”
The team sought mature banking solutions from vendors who could work in tandem with the in-house staff to implement a system that would meet the specifications for their unique environment.Henry also worked closely with the program manager to keep the trains moving in terms of vendor management. He described their working relationship as arguably the most crucial element of the program’s success.
The main priority on which the entire team was laser-focused was to have continuity of banking operations when the system support of the previous owners ended—essentially, to get the core up and running, with users trained well enough to maintain existing services on day one. And, of course, they had to be compliant with regulatory requirements.
Risk vs. Reward
The risk involved was significant. The team had to comply with the policies of the large conglomerate and the requirements of the Central Bank. Internal audits were conducted throughout the course of implementation to make sure that all necessary details were captured. At the end, an external audit was conducted.
Because Henry’s team was taking a cloud-first approach to establish the new banking infrastructure, there were many third-party dependencies. Delays attributable to the COVID-19 pandemic were a major risk factor because vendors were having the same personnel problems as the bank itself.
“The possibility that vendors wouldn’t be able to do what was necessary within our timeline was a concern that materialized frequently, and we had to make adjustments to treat the risk and bring it to an acceptable level,” Henry said.
For a financial institution, cybersecurity is always a critical priority, but in this case, it was especially challenging because the team was building a new environment and making several changes at high speed.
“I’m not sure that the stakeholders fully understood at the time what they were getting into,” Henry said. “The time frame was short, the scope was massive, and the bank itself was a nascent organization, new to the group. The group had a merchant bank, but retail and commercial banking is vastly different from merchant banking.”
They were adding personnel to handle new business that was flowing into a rapidly changing environment. The team was changing systems, people, and processes all at once. On top of it, they needed to implement the usual technology and process controls to authenticate access to the system based on role, function, rationale, timing, etc. Then they had to add another secure layer to ensure that access for remote personnel was in line with their authorized roles and activities.
Inflexibility Meets Innovation
The undertaking required a balancing act between meeting requirements that were inflexible—such as compliance with regulator guidelines and enterprise policies—and getting creative with aspects of the project that were more amenable to innovative thinking.
Before Henry joined the bank, the plan was to take a traditional Waterfall approach to the changeover—even with the vendors. He realized that if that methodology were followed, it would not have been possible to finish the project in the short timeframe available to the team.
It was important to identify the key components that had to be in place to support business operations on day one. Although governing in stable times is different from governing in project startup mode, the same principles apply. It is essential to understand the risk and strategize to deliver benefits at the appropriate level of risk. “ISACA’s CRISC® and CGEIT® certifications really sharpened my risk awareness and boosted my ability to work on challenging projects and manage uncertain environments,” Henry said.
Certified in the Governance of Enterprise IT® (CGEIT)1 practices address demand and supply, Henry noted. On the demand side, it is important to establish strong communications in order to manage and deliver on stakeholder expectations. On the supply side, it is essential to collaborate with the team and make sure vendors supply what is needed to cross the finish line.
Understanding the body of knowledge underlying the Certified in Risk and Information Systems Control® (CRISC)2 certification increases risk intelligence, according to Henry. “There’s a difference between risk and issues,” he pointed out. “Risk is always there. Issues come up from time to time, and you deal with them.”
One of the aspects he focused on with the bank’s change implementation team was reducing the negative risk while promoting the positive risk. They adopted an Agile methodology, paying very close attention to planning and obtaining requirements. They communicated relentlessly. That approach increased the likelihood—or the risk—of the project succeeding.
On the flip side, the team relied on internal audits to ensure that they were putting in place the required disciplines around data security and data governance—for example, proper data cleansing methods.
Risk Amplification
Aside from the ongoing audits, the project team documented requirements and had them evaluated by the operations team. They undertook significant rounds of testing, which they documented and reviewed to provide evidence.
They also held change management sessions to prepare users for what to expect when working with the new system. They held labs, dry rehearsals, and dress rehearsals to explain the new system, test it, do a walkthrough, and be as prepared as possible for day one.
The project team established milestones and documented everything from testing to training to rehearsals, but according to Henry, “We were constantly re-baselining because things were changing.”
Among the most daunting obstacles the team faced was a lack of access to the encryption keys for the debit cards the bank’s existing customers were using. The previous owner had been using legacy plastic cards with magnetic stripes. There was not enough time to replace them with the newer Europay, Mastercard, and Visa (EMV) technology cards, so the team had to go through the entire process twice: first distributing new cards with the now-outdated stripe and then, some months later, new EMV cards. Replacing the cards twice doubled the risk, Henry noted.
Another hurdle was getting regulatory approvals for the Internet banking system the team had built, which included web functionality as well as iOS and Android mobile apps. It was a long, drawn-out, and understandably rigorous process. The Central Bank asked for specific things to be done, Henry recalled, “and we did have some challenges with the operations of the bank around that time, and I suspect those things caused them to ask for further things from us.”
Training of personnel could not wait either. There was a dedicated group of frontline staff responsible for training everyone else, including temp staff who were called in to fill relief roles, and they mainly carried that out on off-hours and weekends when the bank was closed.
They could have used more people than they were able to bring in, he recalled, but there was also pressure to keep costs down, as there was an established budget for the implementation. “We didn’t have an open checkbook,” said Henry, “but budget didn’t turn out to be an issue.”
Trust and Technology
One of the main positive outcomes of the implementation, in Henry’s view, was validation of the approach the team took to achieve the implementation. Technology often gets a bad rap when an implementation runs into problems, but usually it is something else at fault. “Technology is often the easy part,” he said.
As the deadline approached, a cloud gathered over the bank. “I think the general consensus—except for myself and my team—was that we would flip the switch, and everything would just explode,” Henry recalled. Instead, the outcome demonstrated the value of using a true Agile methodology and relentlessly prioritizing what had to be done. The deadline was met, the bank went live as planned, and customers experienced no disruption in services.
Within the compressed timeframe, the team implemented a new card management system, deployed risk management systems, established payment interfaces, and launched a new Visa card. They also deployed web and mobile banking capabilities on the bank’s new platform, thus ensuring that customers could access modern, integrated services. The project not only secured regulatory approvals and kept the bank running but also earned industry recognition, winning awards for the core system implementation and for the digital onboarding process built on top of it.
Trust was a major factor. The bank leadership gave Henry and his team the space to execute. “I remember, just before going live, getting a series of phone calls from directors asking me, ‘Kirk, are we going to make this?’ At that point, it was too late to change anything, but the worry was there.”
Delivering a fully functioning bank on time under such intense constraints provided proof that disciplined governance, risk management, and Agile execution can achieve results even in high-risk environments. The success of the implementation infused the organization with confidence, not only in the team’s abilities, but also in the approach they used to deliver the results. The staff developed a kind of muscle memory from the experience, Henry said, which should carry over into other areas of the organization. “I think it will benefit many future projects. It worked out well—and that’s why I wanted to tell this story. There are so many rich learnings from having to take a risk.”
Reflecting on the experience, Henry noted that his grounding in ISACA’s professional disciplines was critical to navigating the uncertainty and complexity of the project. “As a CGEIT, CRISC, and Certified Information Systems Auditor® (CISA®)3 holder, I naturally drew from those principles of governance, risk management, and assurance to guide decision making, align stakeholders, and maintain compliance. These disciplines provided the guardrails that allowed us to deliver securely on time and with confidence.”
Endnotes
1 ISACA®, “What Is the CGEIT Difference?”
2 ISACA, “What Is the CRISC Difference?”
3 ISACA, “What Is the CISA Difference?”
Mick Brady
Is a freelance technology communicator with decades of experience editing and writing for technology-focused publications.