Steps to overcoming core banking integration challenges
Integrating a new solution into your core banking system brings significant complexity and risk.
A good result relies on both the bank and their technology partner having robust governance and the right people and structures in place. Processes and communication channels must be grounded in one source of truth and the bank must be able to trust in the deep experience of their chosen technology partner.
Experience shows that setting a project of this nature up for success starts on day one, when the first decisions are made.
1. Asking the right questions up front
The first consideration when modernising a core banking system must always be: what are the bank’s goals? From the outset all parties need to understand what the organisation is trying to achieve, identify the success factors, and be able to measure them through the process.
Following that, you need a clear plan of how the objectives will be achieved. Everyone needs to know how they’re going to work together; how you will manage change, risk and testing, while working from a single source of truth.
Another key consideration for the bank initially is who will oversee the entire project and bring all parties together: will it be external consultants or will you use the expertise you have within your organisation?
Bearing in mind that the third-party option can be expensive, and your team often have a better perspective on the technology landscape and understand the development processes within the bank.
Sandstone recommends using industry standards for greater ease and adoptability when integrating solutions. The bank must decide whether to use a direct interface between the applications and the core banking system via API calls, or develop a new piece of middleware to sit in an enterprise bus between the systems.
Middleware gives you more flexibility should you need to change providers in future, either at the front-end or the back-end. It enforces the contracts between the front-end and the back-end systems. However, it can bring its own set of complexities and risks because it introduces a completely new technology layer.
This decision must be evaluated from a cost/risk/compliance standpoint before starting any planning or development.
2. Setting up structures, staffing teams
In our experience, the most successful projects start with a dedicated, overarching project team backed by executive sponsorship, which is then split out into subgroups.
Teams must work closely, having conversations and solving problems together. Developers from the technology company, the bank’s own developers, and any third-party technical people must work as one.
Pulling people out of BAU teams to form project teams can be challenging, given the bank’s day-to-day business must still be managed in parallel and without interruption. Another complication is that those BAU roles within project teams often need to be backfilled, and if you’re working with a legacy system, it can be hard to find the resources to do that.
All of these challenges must be examined in detail. It is highly recommended that you give your technology provider seats on your steering committee if you establish one. Having this voice early on enables technology providers or similar to call out risks as they arise – to the executive and program managers – and come up with alternative solutions or proposals. They can engage with their counterparts within the client organisation and have those – sometimes difficult – conversations.
3. C-suite and board holding up their end
Core banking integration projects need executive sponsorship, from both IT and business functions, otherwise the project is less likely to succeed.
Projects need a thorough program of change management to mitigate impacts on the bank’s processes, structures and employees. This is especially crucial when the new technology is a far-reaching solution like loan origination for instance, which has multiple touch points – from sales and operations to legal, marketing and product.
The whole organisation must be taken on the change journey, their concerns addressed, roadblocks removed. Employees need constant communication about the benefits of the program and how it’s progressing, and that needs to come from the top.
Security and privacy considerations are crucial here. Banks hold vast amounts of personally identifiable information (PII) in their core banking systems and that must be protected. To guard against security threats and potential privacy breaches during implementation and post go-live, security and privacy controls must be “baked in” from the program’s inception.
For example:
• Development teams must have secure development practices in place.
• The quality assurance team’s test data needs must be fulfilled using non-production data.
• Test environments must have the right level of security infrastructure in place with penetration tests carried out for critical releases.
• Third parties who access production environments for support purposes need to have appropriate separation of duties within their organisations.
Compliance is another core success factor for executive consideration. APRA and ASIC requirements in Australia (and equivalents around the world) impose strict obligations on financial institutions, and compliance must be built into the process.
4. Partnering with an experienced technology provider
Banks need a partner that has multiple core banking integrations under their belt and can foretell the risks and issues that frequently arise as you “hollow out the core”. These projects depend on top-level technical expertise, well-honed processes and products, as well as practical advice on common challenges. Those challenges might include:
Scope creep
This is something we raise during the RFI/RFP process: understand the scope of change and manage it carefully. Often the project scope isn’t as tightly contained as it should be, and costs and timeframes can spiral out of control very quickly.
We steer clients towards getting the base system working with a viable functioning solution, gradually improving it in a considered, governed way, rather than focusing on non-critical changes during the initial project. A mistake we often see is where the project uses up their contingency on non-critical functional changes. That contingency is there to cover unexpected complications and they are common in complex software projects.
Interface stability
Sandstone Technology has evolved stable OOTB interfaces that can be leveraged for integrating to a financial institution’s core banking system. Mature APIs help de-risk the implementation.
Taking the risk out of development
Our solutions have been engineered such that each individual API message in a core banking interface can be configured to utilise either a test harness (“fake host”), or a “real” API message. This means that the solution can be stood up and tested end to end as the core integration progresses, enabling the core banking interface to be developed without breaking the entire system. This facilitates continuous testing and business validation throughout the development phase resulting in a higher-quality end product.
Robust internal governance
Sandstone has its own internal governance sessions where we delve into detailed reporting for all current projects with our CEO and executive team. We bring in people with years of experience in delivering integrations with our solutions, who consistently drill down and ask the difficult questions, challenging the delivery team to ensure risks and issues are being managed.
With 30+ customers across Australia, New Zealand and the UK, and more than 50 core banking integrations completed to date, Sandstone is a tried-and tested-technology partner.
Read our Customer Success Stories and learn how Sandstone can help you achieve your banking transformation goals.
