Community Financial Institutions (CFIs) are in a race for their lives to modernize infrastructure, deliver compelling customer experiences, and provide customers with options for online digital transactions. This race is driven by big bank competitors spending billions on technology innovation, a savvy, younger group of customers demanding digital solutions, and now, a global pandemic accelerating the shift to contactless payments. For CFIs to compete in this environment, they must be able to integrate applications, services, and various systems of record with their banking core technology. However, this poses an enormous challenge.
Most banking cores are comprised of legacy technology that has evolved over the course of decades. Often, this starts as a simple ledger and expands into a suite of services. While originally intended to meet the needs of the CFI’s customers, this often results in a limited and inflexible solution. Unfortunately, core vendors rarely evolve technology fast enough for CFIs to keep pace with the demands of their customers. At the same time, integrating with the core is a painful, time-consuming process for a CFI’s IT team.
Thankfully, the era of API architecture introduces the flexibility CFIs need to escape the constraints of their core vendor. However, if core integration is on your organization’s roadmap, there are 10 fundamentals to consider before starting your integration project. We’ve surfaced these considerations after years of customer engagements with our community bank and credit union customers.
The core may be at the heart of your IT environment but it doesn’t have to burden innovation. How will your organization leverage the core without being handicapped by the vendor’s numerous constraints? Your core integration requires a strategy that addresses this. Here are three things to think through today.
1. Core Abstraction
The scope of any modern core integration project should include an approach that creates independence from the core while simultaneously leveraging the core for what it does best. To accomplish this, define your core integration requirements holistically and build an agility layer that abstracts the core’s data. This agility layer leverages the flexibility of modern APIs and enables developers and partners to easily access core data without having to integrate directly with the core.
2. Reuse Through APIs
One of the key benefits of this approach is that the APIs are reusable. The APIs you build for one project (for example, to expose customer or account data) can be reused on subsequent projects. This means that as you continue to build new APIs and reuse existing APIs, your development effort and costs shrink exponentially over time. By leveraging this approach and consistently following PortX’s best practices, our customers found that the amount of work to integrate with their core could be reduced from several months to a matter of days.
3. Legacy Modernization
In the long-term, abstracting your core with an API agility layer also enables you to add or remove systems with reduced risk and greater ease. For example, if you replace a service that exchanges data with your core, the new service simply calls the same APIs as the one that it replaced. Similarly, if you have a core migration planned for the future, merely wire the new core to the same APIs that currently abstract the incumbent core. This approach provides two critical advantages. First, it allows you to perform a phased migration with A/B testing. The organization can disconnect the incumbent core once you have verified that the replacement is performing properly. Second, it allows you to continue to integrate new products and services regardless of whether a core migration is taking place.
The level of difficulty, cost, time, and effort will vary depending on with which core you integrate. For this reason, there are a number of things to address before executing the core migration specific to your organization.
4. Data Access
You will want to understand the level of access the core vendor permits as early as possible in the discovery process. Some vendors provide interfaces, such as APIs, that make accessing core data relatively easy. Others provide this type of interface but subject both the integrator and CFI to a lengthy review and approval process. This can include signing NDAs at each review phase before granting access. In the worst cases, the vendor may prohibit integration with core data until the CFI purchases access to its proprietary interfaces. As a point of clarification, the term “vendor” can also be applied to a single core provider’s various business units. For example, Fiserv has individual business units for many of its cores, and the level of access, as well as the accompanying legal and financial requirements, vary for each.
5. Proprietary Interfaces vs. Accessible APIs
Many vendors provide what they call their “integration platform” with the core. However, this is often nothing more than a proprietary interface that enables access to the core through point-to-point connectivity. This promotes the tightly coupled “spaghetti” architecture that dramatically impedes speed of development, maintenance, and scalability. It also fails to provide a management plane for the CFI’s IT landscape that a true integration platform would. These proprietary interfaces will not provide the flexibility and reuse that you will achieve by building a true API layer that abstracts the core data. The solution is simply to build your agility layer on top of the vendor’s proprietary interface.
6. Viable Documentation
While documentation is a critical component of successful core integration, the quality of this documentation will vary among vendors – if it exists in the first place. A few vendors provide effective and accessible documentation. Unfortunately, many tend to invest little in this area, and, as a result, the integrator spends valuable time deciphering the system themselves. Our team once reverse-engineered an undocumented WSDL for the SOAP services that the vendor had provided for core access. In another project, the vendor’s documentation was riddled with gaps and inaccuracies. The core provider forced our customer to pay for “support” resources to walk them through simple information that should have been included in the documentation.
7. Comprehensive Timelines
Calculate the timeline for holistically completing the core integration project. Besides the technical effort needed to integrate with the core, one must also consider administrative requirements and how they factor into the implementation schedule. Many core vendors have a mandatory process for reviewing and approving third-party integrations before the integrator is ever allowed to look at the core interfaces. While some vendors have made this a quick and straightforward process, with others it can sometimes take two to three months to schedule and complete. The vendors with longer administrative processes often require a series of meetings between their various teams (Legal, Product Management, Sales, and Architecture), the customer, and the integrator.
8. Third-party Costs
Some vendors will charge connection costs for any third-party to access their core. These must be taken into consideration to determine the total cost of the integration and to accurately calculate the return on the organization’s investment.
9. Additional Core Development
In most cases, integration simply requires exposing core data to the systems that run business processes and transactions. However, Some third-party systems may have unique features that require additional development on the core. This must be factored into project scoping and planning as the level of restriction and duration of development will vary among core vendors.
10. Core Roadmap
What are the repercussions to your business if the vendor decides to sunset an older core that your organization currently utilizes? As long as this is a possibility, the longevity of the core is one of the considerations required for planning a successful core integration. The three fundamentals in the strategy section of this document effectively address core longevity issues. As long as you have built an agility layer on top of the core, you can replace it with little risk or disruption when needed.
In the coming weeks, we will publish a series of short reviews for the different cores with which we have integrated and share the top considerations for each. In the meantime, if you have any questions about your organization’s core integration, our team is happy to discuss your specific integration in more detail.
Visit our site if you would like to learn more about our approach to Banking Core Integration and PortX Payment Manager – our suite of simple and reusable APIs that integrate payment channels into your banking core.