Fintech jXchange Requirements and Readiness

Fintech Requirements Overview

The creation of this document was born out of the need to create a standard that all consumers should abide by. Its purpose is to prepare Fintechs to function within the boundaries of the Jack Henry (JH) integration environment. The requirements are simple but are designed to set certain technical expectations, enhance ease of support from all parties and allow consumers to be prepared/flexible for changes that are not considered breaking changes. Each requirement was added to address a shortcoming or issue previous consumers dealt with that created a roadblock either during development or production implementation.

Expectations

Fintechs are expected to plan for the tested topics section when developing applications that will use JH environments. At the end of a Fintech’s development life cycle and before deployment of the consuming product, an Integration Readiness Check (IRC) will be administered by Developer Relations personnel to gauge the product readiness and ensure proper steps and development practices have been followed. The product presented during the check should be in a completed stage and ready for implementation in a bank’s environment.

Failure to meet these requirements can result in a delay of access to a bank’s environments until these requirements have been met. This check is self service with evidence returned to JH.

Results

• Pass
  • Allows the product to be implemented and supported for bank environments.
• Fail
  • Prevents the implementation within bank environments. Retests may be performed at any time by following the IRC scripts and resubmitting the evidence packet.

Fintech Requirement Details: SOAP

Requirements

The following Items are required for successful passing of the IRC when developing using JH SOAP XML.

Public Private Key Pair and JWKS URL Usage

During development we allow for the use of a PEM public/private key pair to be used. In a bank’s environment we will require a JWKS URL to be setup and used to allow for less downtime and less overhead on bank, JH and Fintech resources when a credential change is required/needed.

While the check will allow for Public/Private key pair use to pass. It is recommended that a Fintech perform the test with the expected JWKS URL setup.

Soft Code Values

Required jXchangeHdr Elements Using GUID Values

With SOAP APIs the jXLogTrackingId should be provided with a unique GUID value with each call. As part of the IRC, we will be ensuring that a unique value is presented.

Schema Validation

All consumers are required to meet schema validation. Schema validation is the verification that the operations inside the SOAP Body match the contract created by Jack Henry in the XSD documents. It should be noted, that the VER_x tags are required in the requests to meet schema.

Error Handling: Provider, Integration Layer, and Communications

Demonstrate the ability to identify errors, manage each type and interpret their meaning. Fintechs developers and support staff should have basic familiarity with errors presented by JH providers, the integration layer environment and generic XML errors. Below are some examples of each type.

<FaultRecInfoArray>
<FaultMsgRec>
 <ErrCode>400028</ErrCode>
 <ErrCat>Error</ErrCat>
 <ErrDesc>Customer not found</ErrDesc>
 <ErrElem>CustId</ErrElem>
 <ErrElemVal>VAX0089</ErrElemVal>
 <ErrLoc>CFCUSTINQ</ErrLoc>
 </FaultMsgRec>
</FaultRecInfoArray>

 <s:Fault>
 <faultcode
 xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd">a:FailedAuthentication</faultcode>
 <faultstring xml:lang="en-US">Access is 
denied.</faultstring>
 </s:Fault>

 <FaultRecInfoArray>
 <FaultMsgRec>
 <ErrCode>100</ErrCode>
 <ErrCat>Error</ErrCat>
 <ErrDesc>No connection could be made because the 
target machine actively refused it 
172.16.4.10:40200</ErrDesc>
 </FaultMsgRec>
 </FaultRecInfoArray>
 </HdrFault>

Produce application Request/Response XML log

Ability to provide the unredacted, raw request and response XML is required. A key component for troubleshooting is the ability of the consumer to produce a properly formatted XML log for any individual operation request/response pair upon request by an institution or JH Support.

Other Considerations

The following Items are not part of the IRC, though they still need to be considered while developing within the JH environment.

Proper Parsing

Treat the XML or JSON as XML/JSON and interpret it with an appropriate parser instead of treating it as text or searching for strings.

Custom Elements

Each Service Gateway operation provides a means for meeting additional non-standard operation requirements accomplished through the availability of Custom/ elements in requests and responses. Each Custom/ node can contain any number of additional complex and simple hierarchical structures. Please be aware these types of elements may be in use within an bank’s institution(s). The bank should be able to provide the Fintech development team with the appropriate means and logic to utilize the customized elements as granted from the JH core development team.

Since custom fields are specific to a bank’s specialized requirements, JH is unable to offer them within the DMZ development institutions though a product’s code should be flexible enough to allow for the addition of these elements if they exist within an bank’s environment.

Example IRC Scripts

Example IRC Script for SOAP

Below is a sample IRC that might be administered for a Fintech’s product. Checks are tailored specifically to the Fintech’s relationship and as such JH might not check all items listed below during every IRC, but all items should be taken into consideration as there will be no communication prior to the check as to what items will be involved.

Request An IRC

If you have reviewed the information above and have completed your development, your may request an IRC for your solution by submitting an Integration Readiness Check Request Form.