Developer Resources

Details

Operation Summary

When a “Success” response is received from a WireTrnAdd request, this means that the core has accepted the wire, but will not be processed immediately. You will need to call WireTrnInq with the TrnRcptId received in the WireTrnAdd response to get the status of the wire. Please see the Developer Resources for WireTrnInq to understand the different wire status codes.

XML Examples

WireTrnAdd Request

 <?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SOAP-ENV:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <wsse:Username>{Insert}</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{Insert}</wsse:Password>
        <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-01-11T21:30:27Z
        </wsu:Created>
      </wsse:UsernameToken>
    </wsse:Security>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <WireTrnAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <MsgRqHdr>
        <jXchangeHdr>
          <JxVer></JxVer>
          <AuditUsrId></AuditUsrId>
          <AuditWsId></AuditWsId>
          <AuthenUsrId></AuthenUsrId>
          <ConsumerName></ConsumerName>
          <ConsumerProd></ConsumerProd>
          <Ver_1/>
          <jXLogTrackingId>{Insert}</jXLogTrackingId>
          <Ver_2/>
          <InstRtId>011001276</InstRtId>
          <InstEnv>TEST</InstEnv>
          <Ver_3/>
          <BusCorrelId></BusCorrelId>
          <Ver_4/>
          <WorkflowCorrelId></WorkflowCorrelId>
          <Ver_5/>
          <ValidConsmName>{Insert}</ValidConsmName>
          <ValidConsmProd>{Insert}</ValidConsmProd>
          <Ver_6/>
        </jXchangeHdr>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </MsgRqHdr>
      <ErrOvrRdInfoArray>
        <ErrOvrRd>
          <ErrCode></ErrCode>
          <Ver_1/>
        </ErrOvrRd>
      </ErrOvrRdInfoArray>
      <WireAcctId Rstr="">8318033</WireAcctId>
      <WireAcctType>D</WireAcctType>
      <WireTrnInfoRec>
        <WireAmt>4.33</WireAmt>
        <WireStat>IN</WireStat>
        <WireType>10</WireType>
        <WireSubType>10</WireSubType>
        <WireRecvFinInstRtId>011001276</WireRecvFinInstRtId>
        <WireRecvFinInstName>Cornerstone</WireRecvFinInstName>
        <WireOrignName>
          <ComName>{Insert}</ComName>
          <MiddleName/>
          <LastName/>
        </WireOrignName>
        <WireOrignAddr>
          <StreetAddr1>123 Orig</StreetAddr1>
          <StreetAddr2>Hartford, CT</StreetAddr2>
          <City/>
          <StateProv/>
          <StateCode/>
          <PostalCode/>
          <DlvryPt/>
          <County/>
          <Cntry/>
          <CntryType/>
          <BusAddr/>
          <FornAddr/>
          <InvAddr/>
          <Ver_1/>
          <StreetAddr3/>
        </WireOrignAddr>
        <WireBenfInfoRec>
          <WireBenfId>4333333333</WireBenfId>
          <WireBenfIdType>DepAcct</WireBenfIdType>
          <WireBenfFinInstIdType />
          <WireBenfFinInstId />
          <WireBenfFinInstName />
          <WireBenfFinInstAddr>
            <StreetAddr1/>
            <StreetAddr2/>
            <City/>
            <StateProv/>
            <StateCode/>
            <PostalCode/>
            <DlvryPt/>
            <County/>
            <Cntry/>
            <CntryType/>
            <BusAddr/>
            <FornAddr/>
            <InvAddr/>
            <Ver_1/>
            <StreetAddr3/>
          </WireBenfFinInstAddr>
          <WireBenfName>Bene Test</WireBenfName>
          <WireBenfAddr>
            <StreetAddr1>123 Bene</StreetAddr1>
            <StreetAddr2>Hartford, CT</StreetAddr2>
            <City/>
            <StateProv/>
            <StateCode/>
            <PostalCode/>
            <DlvryPt/>
            <County/>
            <Cntry/>
            <CntryType/>
            <BusAddr/>
            <FornAddr/>
            <InvAddr/>
            <Ver_1/>
            <StreetAddr3/>
          </WireBenfAddr>
        </WireBenfInfoRec>
        <WireOrignInfoRec>
          <WireOrignFinInstIdType />
          <WireOrignFinInstId />
          <WireOrignFinInstName />
          <WireOrignFinInstAddr>
            <StreetAddr1/>
            <StreetAddr2/>
            <City/>
            <StateProv/>
            <StateCode/>
            <PostalCode/>
            <DlvryPt/>
            <County/>
            <Cntry/>
            <CntryType/>
            <BusAddr/>
            <FornAddr/>
            <InvAddr/>
            <Ver_1/>
            <StreetAddr3/>
          </WireOrignFinInstAddr>
        </WireOrignInfoRec>
      </WireTrnInfoRec>
      <WireUsrId></WireUsrId>
      <WireVerifId></WireVerifId>
      <WireTmpltCrt></WireTmpltCrt>
      <AvlBalCalcCode></AvlBalCalcCode>
      <Custom></Custom>
      <Ver_1/>
    </WireTrnAdd>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

WireTrnAdd FAQ

Question: SilverLake What account types can be used with WireTrnAdd?

Answer: Account types D, S and X may be used for WireTrnAdd requests.

Question: I have a WireTrnAdd call previously built by someone else and I have been troubleshooting its various behaviors. They are currently having an issue when they need to specify a different Wire Originator Address than the one that is listed for the Primary Account holder (when dealing with a Joint Account Holder). In the Message Brief it listed a section for supplying an address under the WireOrignAddr node. However we discovered that it is not putting the address information we supply in WIreTranAdd on the actual Wire in SilverLake; it always uses the address of the Primary Account Holder. When I investigated the Mappings tab on the IDG portal, I see no mappings for the aforementioned WireOrignAddr section. That leads me to believe the Originator Address is not something we can supply in the WireTranAdd and that SilverLake must be doing an address lookup themselves based on the supplied Account ID/Type.

This needs to be able to specify the Wire Originator Address because there are legitimate uses for using the address off of a Joint Owner instead of always using the address of the Primary Owner on an account.

Is my interpretation of the Message Brief vs the Mappings tab correct? We cannot specify the Originator Address currently?

Answer: Correct you cannot specify the Originator Address currently.

Question: SilverLake We started adding new wires into JH via WireTrnAdd. Last night we added a wire and the Wire Sequence ID was populating according to the next sequence in line (Example: 5049). This morning the sequence for wires that we generate started from 1 and went onto 2, 3, 4, etc. But all other wires have sequence as 5097, 5098, etc. Why do you think we had a correct sequence last night (5049), but incorrect this morning 1, 2, 3, etc.?

Answer: Regarding the WTSEQ field within the WTTRAN file, when it assigns the sequence number, if there is nothing in WTTRAN, it starts with sequence “1”. If there are transactions in there for that account, it increments by “1”. So every day would start with a sequence of 1 depending on if something else has a different method of assigning a sequence, then it would be that sequence +1.

Account Number, Account Type, and Sequence are keys to the WTTRAN file. There cannot be records in the same file with the same key. Questions to ask on why the different sequence numbers include: Does the FI have custom on their wire service? Are the sequence numbers for the same account or different accounts? Is the FI generating wires from multiple sources?

Question: When using WireTrnAdd to add a wire, is the submission subject to wire system user security? Specifically, is the customer able to set separate security for the submitting user?

Answer: If utilizing AuthenUsrCred then when the request for WireTrnAdd is sent it should validate if the User ID has authorization to perform wires. If not utilizing AuthenUsrCred then the submission isn’t subjected to wire system user security.

Question: What are the fields that SilverLake fills in, without the user entering any values for the WireTrnAdd?

Answer: They are:

Question: We are getting warning 9920043 “The element’s value is greater than the provider allows. Element was truncated.” in WireTrnInfoRec.WireBenfInfoRec.WireBenfIdType. What are the proper values?

Answer: The WireBenfIdType is a single character element. Below is the letter that needs to be sent via the operational element with the corresponding values to remove the warning.

• B Bank

• U CHIPSId

• C CHIPSPart

• D DepAcct

• F Fed

Question: We were looking for the IMAD number to be returned back from the WireTranAdd call. Does the response include the IMAD number of the wire? If so, where would it be returned in the response object?

Answer: Only two items are returned by Silverlake in the WireTrnAdd response:

• Transaction Receipt ID (TrnRcptId) – The receipt provided for a successful transaction entry • Pass/Fail Status (RsStat) – The status of the response. Canonical values are ~Fail~ or ~Success~.
• The IMAD number does not get returned in the WireTrnAdd response.

The good news however is that if you have the TrnRcptId of the wire transfer you can take it and pass it into the WireTrnInq service to get back the IMAD number.

Question: SilverLake I am having trouble successfully making a WireTrnAdd jXchange call using a general ledger account. I have verified that the data in my call is correct. The only thing I currently want to do is get rid of the following error, “Invalid account number”. I just need to get rid of the “Invalid account number” error.

Is it possible to make a WireTrnAdd call using a general ledger account? If not, what call should I be using?

Answer: WireTrnAdd doesn’t allow for general ledger accounts to be used for single wires.

WireTmpltAdd could be used to setup a recurring wire on a GL account. What this service will do is create a wire transfer based on a scheduled routine, much like an ACH or AFT. The business service will create a record in the WTRCUR (recurring wires) file based on the date, but a core option will need to be taken in order to place these wires in the WTTRAN file. There is no business service that will move these recurring wires from WTRCUR to WTTRAN.

However, the workaround for this would be in the Wire General Parameters file in core (WTPARG). There is a parameter within this file to bypass the bank having to manually move the records from WTRCUR to WTTRAN. The field in WTPARG is PGORCALLOW and when this field is set to Y, EOD processing will create the recurring wires and place them from WTRCUR into WTTRAN and advance the recurring dates.

So the FI can either manually move these recurring wires or they can have them done automatically.

Question: We get the error response with message “Waived can’t have a fee/counter” when we try to send domestic wire transfer using WireTrnAdd API with a fee amount. How do we know that wire transaction fee is waived for a customer/account? Is there a flag in another API call that can used to determine this? Or is it a global flag?

Answer: If it’s a recurring wire then WireTmpltInq could be used to find the value for <WireAnlysCode>. There is not another service that would provide that information. The error is populating because WireAnlysCode is being set to W and WireFeeAmt is not equal to 0. WireAnlysCode could be set to W for a few different reasons based on the Wire General Parameters set in core and/or if the account is set up with a company in Wire Company Maintenance also in core.

Question: What are the possible values for WireAnlysCode?

Answer: Here are the possible values for WireAnlysCode:

• B (Both) – The dollar amount in the Fee/Counter (WireTrnInfoRec.WireFeeAmt) field is assessed during end-of-day processing and the Enhanced Account Analysis item number is incremented
• E (Enhanced Account Analysis) – The counter number in the Fee/Counter (WireTrnInfoRec.WireFeeAmt) field is incremented
• N (Non-Analysis) – The dollar amount in the Fee/Counter (WireTrnInfoRec.WireFeeAmt) field is assessed during end-of-day processing.
• S (Standard Account Analysis) – The charge is handled through Standard Account Analysis
  • WireFeeAmt must be 0 or blank otherwise error 101001 “Value must be zero” will be returned
• (Waive) – The fee is waived. This value is not valid for Standard Account Analysis accounts.
  • WireFeeAmt must be 0 or blank otherwise error 101023 “Waived can’t have a fee/counter” will be returned

Question: We are trying to use jXchange to add new wires to SilverLake and trying to figure out how to determine the wire fee and/or analysis counter. Is there a way to do these lookups via jXchange?

Answer: Unfortunately, at present there is not a business service that will provide the values for Wire Fee and/or Analysis Counter.

Question: When we request a Wire using WireTrnAdd service, we inform all the Beneficiary Address and Beneficiary Bank Address attributes, but those are ignored by the system and we cannot see them in Xperience or in the Wire Inquiry request. Please, let us know how we can propagate those fields since are required fields for OFAC and AML.

Answer: The WireRecvFinInstAddr, WireBenfFinInstAddr, and WireBenfAddr address elements are not mapped and the information passed on for OFAC and AML are determined by SilverLake.

Question: How do wires generated in the DMZ flow through the processing workflow? We have been able to generate a wire but have not been able to get one to enter the “Processed” state after multiple days.

Answer: Wires can be generated in our DMZ test environment but they do not get processed.

Question: Does Core Director support WireTrnAdd, and is DirectLine Wires required for the service?

Answer: No, Core Director does not currently support WireTrnAdd or DirectLine Wires.