Over the next five years, there will be a seismic move in the enterprise software space. By the end of the decade, the majority of companies will be running their ERP in the cloud. This will surely create a surge in revenue for the ERP firms and many of the system integrators poised to capitalise on this massive undertaking and reap the benefits of years of migration project work – many of which will be global in nature and need to tackle the complexity of global banking integrations.
We assist companies in their cloud migration projects and keep hearing the same thing over and over again from those who have already started the migration process, “We had no idea it would be this complex or time-consuming.” In fact, many system integrators we work with consistently tell us that bank integrations are one of the riskiest components of their projects.
The complexity does not necessarily come from the development of the bank interface but is due to the fact that you are at the mercy of the bank’s timelines. Today’s corporate IT teams are well experienced in building interfaces between back-office systems, but these are typically stagnant interfaces and do not require additional resources. When working on a bank interface, the IT team typically needs multiple resources to coordinate with the bank. These can include IT, treasury, AP, the connectivity team, SWIFT Service Bureau and the bank’s tech team. Once the specs have been developed, they rarely pass the first test and the dev team often has to rebuild and re-test it; and then they have to work through the coordination effort yet again. We have seen instances where this can take two to five times the effort to have the test format approved by the bank.
Once the bank has approved the format, IT then needs to work through their internal procedures to release to production including dev > test > QA > non-prod > prod. In fact, it is not uncommon for a single payment format to take 6+ months to be developed, tested and released into production to be utilised by the business owner.
A common mistake we often see when assisting the bank integration projects is the assumption that SWIFT is the standard message type utilised by each bank. Although SWIFT is moving from MT to XML, this does not negate the fact that every bank will have its own unique variances on how they accept incoming files. With every bank requiring its own unique format – and most clients needing multiple formats per bank such as low value, high value, check, transfer, etc. – many companies will need hundreds of formats to be developed and tested across their banks. We routinely see IT firms taking more than two years to work through all of the bank connections and payment format testing.
Once the formats are in production, the IT infrastructure team then has to manage these moving forward. We find that most corporations require extra resources to manage these connections to troubleshoot bank issues, edit formats as required by the bank and implement new banks when required. Headcount can vary from two to five persons on average, depending on the company’s banking footprint.
One new issue companies are facing is the new SWIFT requirements being mandated for 2020. Due to an $81 million SWIFT fraud attack on a Bangladesh Bank in 2016 by hackers who used malware targeting the SWIFT software, SWIFT has not only increased the security around their infrastructure but also for the mandates required by corporations controlling their own BIC. Many companies looking to manage their own SWIFT connection will look to adopt Alliance Lite2 (AL2). But under the new requirements for 2020, the internal IT support team will need to go through annual certifications and testing for up to 12 tests to keep their validation for SWIFT. This imposes a huge risk and additional costs for many internal IT teams as they now have to have internal SWIFT domain expertise and need annual re-certifications. One risk is that many companies will have no more than one or two resources certified. What happens if/when this new resource leaves the company? Who is the back-up? What is the cost and time to retrain a new resource?
In order to mitigate these key person risks, accelerate ERP migrations and simplify global bank connectivity, many organisations are looking to Kyriba for connectivity. With 20 years of experience and roots embedded in connectivity, we can help. Our bank adapters to our network of more than 600 connected banks provide bolt-on connectivity to most ERPs and banks, eliminating the daunting task of development and testing, and accelerating the time-to-value for the ERP by cutting bank integration work by more than 80 percent. This white glove delivery service also eliminates the need for internal IT to support the bank integrations or the required SWIFT domain expertise.
To learn more about our bank connectivity services and how you can accelerate your ERP migration project, talk to one of our connectivity advisors.