November 4, 2021

Rating and Review: Integrating with Fiserv’s XP2 Banking Core

by Charles Colt and Eugene Berman in Banking Core Integration , Fintech , Payment Management 0 comments

ModusBox works with banks and credit unions to eliminate dependency on their banking core vendor and enable the organization to leverage its core for what it does best. We do this by creating a flexible API layer on top of the banking core that unlocks the ability to quickly innovate new products and connections to third-party fintechs and other solutions. If you are evaluating a new core solution for your financial institution, start with our blog: 10 Fundamentals to Avoid Catastrophe on Your Next Banking Core Integration.

In this article, we share our perspective on integrating with the Fiserv XP2 Core based on the following criteria:

  1. Customer Prerequisites 
  2. Administrative Requirements
  3. Technical Effort
  4. Documentation Quality
  5. Support & Troubleshooting

Below, we detail our experience with each of these core integration elements and then score them based on quality and ease of use. The goal is to enable you to assess the challenges and level of effort required to integrate with Fiserv XP2 based on our experience.

Customer Prerequisites

As a Fiserv XP2 customer, you will have to manage various integration fees. These include direct integration costs for each of your vendor solutions or an SDK that enables you to build and manage the integrations. If you are working with an integration partner, then you may also need to provide them with VPN access and credentials to connect their solutions to the core.

Licensing per vendor

As a financial institution, you will likely have multiple vendors that require integration with the core. Fiserv provides you with the option to pay for these individual connections, sells them by the package, and offers a discount when purchasing them in bulk. When you purchase the integration connections in bulk, you also have the flexibility to swap out one vendor for another. 

One challenge with this approach is that the individual vendor integrations are not driven by your specific requirements. Instead, they are based on the cumulative feature requests of the financial institutions whose integration needs preceded yours. As a result, you must either accept the vendor integrations that Fiserv has built to date or pay to update them to meet your requirements. Paying to close a requirements gap on an integration that you have purchased will likely result in that solution becoming part of Fiserv’s basic package. Essentially, you are helping to fund the development of Fiserv’s integration package. While some of our customers have found the up-front cost per license to be reasonable, they have also noted that the ongoing cost of adding more connections or custom features can be significant. 

SDK

Another approach is to purchase the Fiserv XP2 SDK so that you can build your own integrations as needed. This will enable you to build a customized solution based on what your customers need. ModusBox builds the integrations and makes them available as a library of reusable connections for customers who do not yet have the in-house expertise to build custom integrations. As the customer builds its own team, ModusBox can provide training to leverage these reusable integrations and build new ones of their own. 

The SDK represents a significant investment because it can cost up to five times more than the individual integrations. When considering the SDK, you will want to perform an ROI exercise to determine when the investment will pay itself off. This is especially true if you plan to build integrations that are required more urgently than Fiserv’s typical delivery timeline. 

It’s important to also factor in vendor management. Many vendors advertise that they are able to connect with Fiserv XP2 but lack the ability to do so, or are unwilling to pay Fiserv’s integration costs. The SDK addresses these issues by enabling you to build your own API interface to XP2. This simplifies connectivity for the vendors and eliminates Fiserv’s per-vendor integration cost. It also better positions you for strategic initiatives such as mergers and acquisitions.

Administrative Requirements

Fiserv XP2 administrative requirements are extremely lightweight. Fiserv will provide training sessions for customers that leverage the SDK. While the training is helpful, our experience has shown that a skilled developer can successfully connect to Fiserv XP2 utilizing the documentation alone. Our team was able to connect quickly to Fiserv XP2 by reading the documentation and doing a bit of trial and error.

Technical Effort

We have found that most of the technical effort consists of designing and building an API that will enable systems and applications to exchange data with Fiserv XP2. Fiserv provides a WSDL that describes all data structures in the core. They also provide reference documentation that clarifies which messages to implement in their solution. The WSDL and the messages are very clean, but it can be challenging to understand how to handle security – specifically which SOAP headers to implement. While Fiserv could have done a better job explaining the security options, it is possible that this information lives in a document that we have not yet accessed. 

The messages in the WSDL are described very intuitively (For example, “Account Update”) with verifiable fields (Name, Address, etc.).

While integrating with Fiserv XP2 is easy for experienced architects and developers, it will likely be problematic for anyone unfamiliar with banking. We recommend following this approach:

  1. Design a canonical data model to suit your requirements. This is a subset of what Fiserv XP2 exposes, but it is presented in a smaller, cleaner manner with better naming convention. This is the heart of the API that abstracts Fiserv XP2.
  2. Create a CXF SOAP client with the Maven plugin that generates client code from the WSDL.
  3. Use DataSonnet to map the request from the canonical data model to the SOAP message and call the SOAP service.
  4. The Service returns the response in a SOAP message format.
  5. Map the response from the SOAP message to the canonical data model using DataSonnet and return it.

If you need to return account data, it helps to understand how financial systems work in terms of account numbers, balance, returning balance, etc. 

Documentation Quality

Fiserv provides four XP2 guides, of which we have found the XML guide to be most useful. It lists all elements in a table with detailed descriptions. This is in stark contrast to Jack Henry’s Symitar, which provides none. The documentation also contains useful code examples such as the one below for updating an address:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"                 xmlns:mes="http://xpsystems.com/services/apex/messages"                 xmlns:typ="http://xpsystems.com/services/apex/types">     <soap:Header/>     <soap:Body>         <mes:IndividualAddressUpdateRequest>             <mes:IndividualId>123456</mes:IndividualId> //REQUIRED FIELD//              <typ:AddressDetail>                 <typ:AddressId>444444</typ:AddressId> //USING ZERO/NOT SENDING THIS FIELD WILL CREATE A NEW ADDR//                 <typ:Line1>405 Any Dr</typ:Line1> //REQUIRED FIELD//                 <typ:City>Any City</typ:City> //REQUIRED FIELD//                  <typ:State>CA</typ:State> //REQUIRED FIELD//                  <typ:ZipCode>11111</typ:ZipCode> //REQUIRED FIELD//                  <typ:Country>USA</typ:Country>                  <typ:AddressType>Home</typ:AddressType> //REQUIRED FIELD//                  <typ:IsInternational>false</typ:IsInternational> //IF NOT SENT WILL BE DEFAULT TO FALSE//                 <typ:IsPrimary>true</typ:IsPrimary> //REQUIRED FIELD//             </typ:AddressDetail>         </mes:IndividualAddressUpdateRequest>     </soap:Body> </soap:Envelope>

Support & Troubleshooting

To date, we have had no need to leverage Fiserv Support and can provide little commentary on this criteria. However, for the few things we required from Fiserv in terms of training and documentation, they were very responsive.

Scoring & Recommendations

Based on our experience with the Fiserv XP2 core, we have scored each area of the integration experience on a scale of 1 (very poor) to 5 (excellent). Here is the breakdown for integrating with Fiserv XP2:

ConsiderationScoreSummary
Customer Prerequisites5Prerequisites limited to the basic administrative requirements and establishing VPN between the developer environment and XP2. These processes are straightforward and easy to manage.
Administrative Requirements4The administrative requirements are light but there are also associated integration costs.
Technical Effort4Good documentation, easy access to WSDL and core data. Very easy to understand data and build solutions. The implementation effort is easier than several of the other banking cores with which we’ve worked.
Documentation Quality4Good clean documentation easily provides context for the WSDL, and provides detailed information you need.
Support & Troubleshooting4ModusBox had few requirements for support or troubleshooting and cannot effectively evaluate this process. In terms of providing access to the SDK and scheduling training to answer questions, Fiserv was available and collaborative.
Final Score4.2Generally easy to get started, to obtain required information, and to build an integration between the target system and XP2.

 

If you would like to learn about our approach to Banking Core Integration, visit our site or contact our team today. We can also answer your questions about Payment Manager – our suite of simple and reusable APIs that integrate payment channels into your banking core.


Leave a comment