Rating and Review: Integrating with Jack Henry’s Symitar Banking Core

PortX delivers critical integrations for our bank and credit union customers by implementing a flexible API layer to enable the rapid development of new products and services. A key benefit of this approach is banking core independence from vendor-lockin. We have developed many learnings and insights from our experiences integrating with several banking cores. 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 Jack Henry’s Symitar core for credit unions, which we examine in terms of the following:

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

We have provided details about our experience with each of these topics and then scored them based on quality and difficulty level. Skip to the end if you would like to see our overall score. We hope this information helps you assess the challenges and level of effort required to integrate with Symitar.

Customer prerequisites

Integrating with Symitar can be accomplished either through SymConnect (a TCP socket-based protocol) or SymXchange, a modern web service interface that enables organizations (including credit unions and vendors) to access the Episys® database. An API implementation that abstracts Symitar by employing reusable REST APIs will leverage the SymXchange service. Because setting up SymXchange can be challenging for many customers, we’ll share our lessons learned and insights about that process here.

SymXchange implementation survey

Jack Henry requires customers to complete a SymXchange Implementation Survey. Based on our experience, we recommend that you work with your integration vendor to complete this survey and call Jack Henry to review your responses before submitting the form. This simple step can save a lot of time by eliminating the back-and-forth process of exchanging the same information over email. Here, you can address all concerns in one call. Below are a few items for you to consider when filling out this survey.

1. SymXchange web server port range if vendor interface is hard-coded

The SymXchange service requires you to manage the actual instance of the service and account for the fact that there may be multiple instances. The console enables you to configure where the service is running and where it is pointing to when you connect to it.

2. SymXchange web server key configuration name / key alias

This section refers to certificates and keys. When setting up HTTPS, you must access another section of the console to establish the keys for managing the security layer. Symitar’s key requirements can be confusing, however, and, again, the simplest path forward may be to have Jack Henry set them up for you via a phone call.

3. SymXchange services to enable and version

Unless you are familiar with SymXchange, completing this column may prove to be challenging because it is poorly documented (we’ll cover that shortly). To start, you will need to know which release of Symitar you are on as well as the latest version installed. Next, you will need to consult the list of services for that specific release. Lastly, you will have to define the services you believe will be needed. 

In our client implementations, we have documented about 21 different Symitar Services available to access. Some, such as the Inventory service offering, require only a couple of operations. Meanwhile, others, like the Account service, can expose nearly 800 operations required to manage all aspects of an account. These can include but are not limited to preferences, loans, shares, cards, and portfolios.

The service list can be seen in the table below along with the associated number of operations per service that we have recorded in our integrations with Symitar.

4. Credential suggested by interface

The SymXchange SOAP UI interface provides a list of optional credentials that you can use to access each service or operation.

From the SOAP Service, there are several credential choices to use:

• Account Number
• Home Banking 
• Card
• MICR (magnetic ink character recognition)
• Lookup
• User Number
• Administrative

In general, our clients have chosen to work with the Administrative option because it is a more straightforward configuration. This option can be used in tandem with the allocation of a device configuration (type and number) per consumer and allows you to manage access restrictions to services and operations on a per device basis.

5. SymXchange client parameters

These are standard terms within Symitar and most banking systems. They are used to select the rules for the transactions you will post.

Administrative requirements

Symitar is one of the easiest cores with which to integrate when it comes to administrative requirements. We have chosen to leave this section of our evaluation of Symitar relatively void of content because third-party vendors are not required to go through lengthy legal, technical, or administrative reviews to get permission to integrate with this core. 

Technical effort

It can be daunting to confront a menu of 2,000 SOAP operations, sparse documentation, and a list of functional use cases that can only be satisfied by implementing a variety of SOAP requests into the core.

A key component for successful integration with the core is close collaboration between your integration partner and the financial institution’s technical team. PortX has been fortunate enough to work with knowledgeable and experienced technical staff who partnered with us to research the best available SOAP operations and parameters for each functional requirement. Based on this experience, we’ll cover the key areas to focus on for delivering a successful SymXchange integration project. 

Episys data model and batch processes

It is essential for your integration team to be comfortable with the credit union’s terminology and data model that has been implemented in the Episys core backend. Key to this understanding is the Episys Account Record Family breakdown and the Episys Database Record Families documentation. We recommend that you obtain this information from Jack Henry to familiarize yourself with the account structures, the model of loan and shares, portfolios, preferences, and other key structures relevant to your integration requirements.

Spend time getting comfortable with associating a member to an account, and member-related individual accounts being referred to as loans and shares. If you are not familiar with the credit union space, this may sound contrary to the banking terminology you are accustomed to.

If your use case involves moving money, it is important to understand the difference between ACH and wire transfers, as well as the type of backend processing required to support these.

It is also critical to have a high-level understanding of the day-end, month-end, and quarterly backend processing. The scheduled processing times can generate significant loads on the backend, and may also move increment dates related to transactions.

Our team experienced a scenario where a day-end process moved the transaction date forward to the next day prior to midnight. We had to account for this in our code. Otherwise, this would have generated errors when searching for all transactions on a given day. Consulting with the core administrator early in the process can provide insights of this nature and prevent avoidable design flaws prior to production go-live.

We recommend that you ask about the schedule of any external applications that may impact your design. When implementing integrations to support NCR DI Internet Banking, we found that it was important to understand the various batch transactions and new services consumed by the platform and to size the applications and infrastructure accordingly.

API security

As discussed previously, these are the various credential options available in Symitar for each SOAP request:

• Account Number
• Home Banking 
• Card
• MICR
• Lookup
• User Number
• Administrative

You will likely need to share the following information with your integration partner for each environment (Development, Testing, and Production) that you work with:

• Admin Password
• Device Type
• Device Number

This information can easily be placed into the request body of each SOAP request: 

<Credentials com:ProcessorUser="?">
              <AdministrativeCredentials>
                  <Password>assignedPassword</Password>
               </AdministrativeCredentials>
 </Credentials>
 <DeviceInformation DeviceType="assignedType" DeviceNumber="assignedNumber"/>

Because you are not requesting any tokens or performing any hash-based message authentication, there is no need to cache any information or perform complex pre-processing prior to executing a SOAP request into SymXchange.

You can administer the user (device type/number) profile in the core to manage access control to the various services and operations.

If your API calls return HTTP 403 – Forbidden at any point, this will indicate that you do not have the required permissions to access the particular service and operation you have attempted.

SOAP services – consumption

In our experiences, there has been little or no access to any SymXchange documentation other than the WSDL.

Additionally, because the Quest CRM does not consume the SymXchange services, there is no option to trace XML over HTTP from the Quest CRM into the core to mimic functionality.

Unfortunately, this leaves few options other than to progress by trial and error. This is another reason why close collaboration between your financial institution’s technical team and the integration partner is critical. Fortunately, however, the naming of the SOAP services and operations are very intuitive, and the request/response parameters should be meaningful to your resources familiar with the Symitar core.

API patterns

For create operations, you will be able to find the specific object in the account hierarchy you want to create. Each of these operations will return a unique locator that will allow you to reference that particular object in subsequent calls. 

For update and delete operations you will likely have to pass the unique locator back in for the specific object, and optionally, some other key data to allow the backend to uniquely identify the target.

For read operations, you will see a host of getXXXXX operations, which generally fall into the following categories:

• get[Object]
• get[Object]SelectFields
• get[Object]PagedList
• get[Object]PagedListSelectFields

These operations provide some very flexible retrieval options as follows:

get[Object]

For this operation, the request object is relatively simple and straightforward. However, this API call will retrieve ALL response parameters from the core for the requested object, which can be thousands of lines of XML to be parsed and passed over the network to your client.

get[Object]SelectFields

Here, the request object increases in complexity, as it will allow you to selectively choose the fields you wish to retrieve in the response from the core. There is an option to include all fields, but this would essentially mean that you are using a full get[Object] call.

This SelectFields operation is far more efficient than the full get[Object] call. In our examinations, the backend processing required to execute and prepare the response is not much different from that of the full get[Object]. However, performance gains are experienced in the network layer, passing back the XML as bytes. By restricting the response to only the essential fields, you will minimize the number of bytes in the XML per record and realize increased performance – especially when returning multiple rows of data. This method also improves performance in the integration layer, considering the data transformations applied to this data.

get[Object]PagedList

With these APIs, you are able to provide a PagingRequestContext into the API request object. This can be used in tandem with the Token of the paged response to allow you to control repeated calls into the API to retrieve smaller data sets.

Of course, these APIs will still return ALL parameters pertaining to the object requested, but you can minimize bandwidth by restricting the number of records per request/response sequence.

get[Object]PagedListSelectFields

This is similar to the PagedList option described above. However, it allows you to combine the optimization options of the SelectFields API to restrict the number of response parameters you will receive, and at the same time control how many records per request/response sequence.

PowerOn 

In some scenarios, the Symitar-provided APIs lack adequate efficiency, or the APIs you need to implement contain gaps. 

The powerOn service offers a set of operations that allow you to call into custom powerOn scripts on the backend server to pass parameters in and out. The powerOn scripts and configuration will have to be performed by your financial institution’s technical developers who can share the input and output parameters for calling the service with the integration partner.

This has been essential in engagements where our team has needed custom customer identification APIs and when handling transaction history information where the out-of-the-box SymXchange APIs were not able to provide the granularity of search needed nor the response times required.

Documentation quality

In our experience, we have found little documentation available for our Symitar implementations. That being said, a couple of artifacts have proven very useful. The first, as mentioned earlier, is the Episys Database Record Families documentation. It enables you to become familiar with the account structures, the model of loan and shares, portfolios, preferences, and other key structures relevant to your integration requirements. The second is the SymExchange service list and associated WSDLs. However, one of our customers shared that they had to reverse engineer the WSDL to successfully understand its contents – something that requires a developer’s skillset.

Support & troubleshooting

In our experiences, Jack Henry has been one of the more accommodating core vendors for support and troubleshooting. Customers are assigned a Customer Relationship Manager who addresses their needs and facilitates the support process for troubleshooting issues. On the occasions that we have worked with our customer and Jack Henry to resolve an issue, the Client Relationship Manager facilitated the process. We were able to do screen-sharing sessions with Jack Henry’s technical support to resolve the issue. 

While researching another Jack Henry core, we found published documents with the contact information for some of its senior technical resources. When we reached out to them, they graciously made time to meet with us to answer our questions about the product.

Overall evaluation 

Based on our experience with the Jack Henry Symitar 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 Symitar:

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.