A Guide to Avoiding ‘Gotchas’ During Payments Migration 

A Guide to Avoiding ‘Gotchas’ During Payments Migration

A Guide to Avoiding ‘Gotchas’ During Payments Migration

It is not news to anyone that the pandemic has accelerated digital change in the payments industry. Support for ISO 20022 is growing, real-time payments are gaining traction, and banks are looking toward cloud adoption and APIs to deliver better payment capabilities to their customers.  How can payments migration help?

While traditional financial institutions were once resistant to change, their wariness of shifting away from hosted infrastructure in favor of a cloud approach is beginning to crumble. This is particularly true given their fintech competitors’ eagerness to embrace a platform approach.  

Despite a willingness to migrate payments, only 14% of the 150 banks and payment service providers surveyed in 2021 had deployed any cloud solutions. Across a range of payment capabilities, only around one-third of financial organizations believe their organization is delivering, at best, the minimum expected standards of products and services.  

There is a case for payments migration. Banks need to embrace innovation to provide customers with new ways of interacting with banks and payments. Failing to do so comes with the risk of not meeting consumer expectations for a modern payment experience. “Risks associated with maintaining a legacy or hosted approach to payments include further pressure on operating margins as well as competitive product disadvantages, leading to potential relationship issues,” said Steve Murphy, Director of the Commercial and Enterprise Payments Advisory Service at Mercator Advisory Group. 

However, there are obstacles that come with migration. Knowing this, Diebold Nixdorf compiled a list of key “gotchas” in payments migration–challenges that can impede migration efforts–and advice on how to avoid them.  

Migration Gotcha #1: Not taking proprietary message protocols into consideration 

Legacy payment systems often rely on proprietary message protocols to communicate with external devices and systems. Continued use of these protocols will require permission from both incumbent and new suppliers. A customer code will be necessary to replicate those message protocols.  

Migration Gotcha #2: Not storing transactional data  

Historic payments data must be stored to manage disputes. While transactional data is likely already stored in the incumbent system, migration efforts involve replacing and shutting down that system. To make sure that important data is not lost, organizations should ensure that at least 180 days of transaction data is replicated in any new system before the old system is shut down.    

Migration Gotcha #3: Not checking on security key and certificate expiration dates 

Security keys are crucial to protecting data. Security keys enable secure access to other devices, systems, and applications. Security certificates are data files that establish the authenticity, reliability, and identity of a website. When certifications expire, browsers will display a warning on the webpage informing the entrant that the security certificate has expired. This can chip away at a customer’s trust level and leave financial institutions more vulnerable to security threats. The migration process is an ideal time to refresh security keys and certifications. By doing so, organizations avoid facing an unexpected key expiration mid-migration, which adds to the risk and stress the process.  

Migration Gotcha #4: Not ensuring operational readiness 

Operational readiness means being ready to deploy, operate, and maintain a payments migration project without significant issues. Projects designed without operational readiness in mind are more likely to fail. This includes ensuring compliance with any relevant rules and regulations. By not taking operational readiness into consideration, organizations could find themselves missing something vital as they approach their go-live date.  

Migration Gotcha #5: Not understanding SLAs and OLAs at the onset of the project 

A service level agreement (SLA) is an external contract between a vendor and its customers that outlines the services a contractor will provide and at what level. An Operational Level Agreement (OLA) is an internal agreement outlining the roles and responsibilities of a service provider’s team. Both agreement types are crucial during migration, especially when external vendors are involved. By clearly establishing expectations and terms, organizations can have more success in meeting critical business controls and, eventually, deploying an operational system.  

Migration Gotcha #6: Not remembering RTO and RPO objectives 

Recovery Point Objectives (RPOs) measure how frequently data is backed up, helping to avoid data loss. Recovery Time Objectives (RTOs) define how long it takes to recover IT infrastructure following an incident. Ideally, organizations will have a short RTO and RPO to minimize productivity losses, recovery costs, reputational damage, and other detrimental effects of going offline.  

Migration Gotcha #7: Not keeping non-functional items in view  

When financial institutions choose to migrate their payments software, they are primarily focused on the core capabilities. However, there is more to migration than those big cost items. There is an entire ecosystem surrounding core payment infrastructure, including monitoring and automation tools. During migration, these peripheral systems cannot be ignored. If non-functional items are not in view and replaced, organizations will not maximize the benefits that come with a holistic payments approach.  

Migration Gotcha #8: Not involving all parties in transition planning 

Chances are that the list of departments that interact with your new payments solution is longer than you initially think. Leaving out any of these parties can significantly delay the ability to go live if they are not prepared for a change. Transition planning needs to involve all these parties for a seamless migration to occur. 

Migration Gotcha #9: Not establishing clear and concise transitional criteria 

For each transition to the next stage of the migration progression, all stakeholders should agree on a well-defined set of entry and exit criteria. This means ensuring there is sufficient governance around moving on to the next phase of the process.  

Migration Gotcha #10: Not planning for pilots and shadow processing  

Pilot projects and shadow processing are ways to identify any potential problems with the system. Pilot projects are initial, small-scale implementations designed to prove that a project is viable. They rely on real-time data processing that responds immediately to commands or the entry of data. Shadow processing, or batch processing, involves the execution of a workflow with little to no human interaction. 

Migration Gotcha #11: Not booking certification slots in advance  

When financial institutions change a core banking system, that system must go through significant compliance control and auditing. Large auditing organizations such as Visa and Mastercard are incredibly busy, and it can take months to obtain the certification slot needed before a new system can go live. Financial institutions need to book these certification slots well in advance–at least six months out–or risk facing significant delays in their system’s launch date.  

Migration Gotcha #12: Not allowing enough time  

Migration should not be rushed; no detail can be overlooked. Pilots and shadow processing, transition planning, certification slots, and the other important components of migration take time, and understanding that can help organizations develop a realistic timeline.  

The takeaway  

Banks need to embrace a platform approach to payments to meet the demands of the modern consumer. Migrating away from legacy systems is no simple task, but it is necessary to remain competitive in today’s world.  

“It is time to encourage core solution providers to openly partner with a wide range of service providers to enable the processing efficiencies that trickle down to an improved customer experience. Cloud-native solutions providers know they become stronger as more third-party service providers add value to their core offerings and welcome valid third-parties that wish to integrate to their solution,” said Tim Sloane, VP of Payments Innovation at Mercator Advisory Group. 

The best bet for banks is to migrate to a modern platform that supports scalability, flexibility, and automation. Choosing an experienced partner can help organizations avoid falling victim to the many ‘gotchas’ that can come with a poorly planned payments migration strategy.  

Exit mobile version