Developer Resources

Details

Operation Summary

Transfer Add (XferAdd) provides the ability to transfer funds between accounts, make a loan payment, schedule a future transaction, create recurring transactions and transfer funds to an account held at another institution using ACH which requires the ACHXferRec complex to be included in the request.

The <XferType> element identifies the type of transfer operation. Canonical values are:

It designates whether the transfer is between accounts within the financial institution, between separate institutions, or to be performed in the future.

The <AcctIdFrom> and <AcctIdTo> complexes represent the account id and type of the source and destination accounts intended for the transfer.

If the transfer will be moving funds within the financial institution, then the <XferRec> complex will need to be included. This is the complex that details the transfer.

The <XferSrcType> element indicates the source of the transfer request. Canonical values are:

Trancodes are parameter driven and can vary institution to institution. To retrieve the list of possible TranCodes from a service provider for a given institution, the ParmValSrch operation should be called with TranCodeCode for the <ParmName> element value.

The FutXferRec complex provides a method for scheduling a transfer to occur between accounts on a semi-monthly basis by utilizing the following elements:

The Transfer Add API also provides the ability to transfer funds to an account held at another institution using ACH. The ACHXferRec complex will need to be included in the request. This complex defines a transfer through an ACH transaction.

The XferAdd API response will contain an <RsStat> element indicating the result of the operation, with a value of Success when completed normally or the operation will return an HdrFault if the service provider was unable to complete the transfer. It will also return a value in the <XferKey> element, which will be needed to modify or delete the transfer.

Special Considerations

The <RedPrinc> element is used to determine what transaction code should be used to post the transaction to a loan. If the transaction code is not furnished a transaction code is assigned that indicates the transaction is a transfer from DDA or from Savings-depending on the type of from account being debited. If the transaction code is furnished in the incoming message and the <RedPrinc> element is “Y”, the program verifies the transaction code is set up for principal reduction. If it is not set up as a credit that affects the principal an error of 500044 (Tran Code must affect credit to principal) is returned. If the transaction code supplied in the message is not a credit or a transaction code that allows the system to determine how to apply the transaction an error of 500045 (Tran code must affect credit to Q ) will be returned.

If the transfer to account is a loan then the value must be true or false. If it is not, an error 500016 (Principal reduction code must be Y or N when the to account is a loan) will be returned.

If the to account for the transfer is not a loan, then the value must be false or error 500036 (Principal reduction code must be N when the to account is not a loan) will be returned.

Depending on the transaction behavior indicated by the trancode, certain transaction requests may result in one or more faults. Faults that are categorized as a Fault can be overridden by specifying them in the complex, while those categorized as an Error cannot be overridden.

The API, Transfer Source Destination Search XferSrcDestSrch, provides consumers with a listing of accounts/drafts/loans that may be on the source and/or destination side of a transfer request. The response includes elements that could be of interest to the consumer in establishing the identity of the accounts/drafts/loans in a transfer relationship.

The XferSrcDestType element provides a filter by passing one of the following canonical values:

The core provider will return all Transfer Source Destination Types (XferSrcDestType) when the element is absent from the request.

The Transfer Add Validate XferAddValidate API allows the validation of the information without the creation of the actual transactions within the provider.

Additional Concerns

• XferAdd does not provide support for either the target or source accounts to be a Time Deposit or General Ledger Type. If a Time Deposit or GL transaction is required by the use case, the Transaction Add TrnAdd API will need to be used instead.
• XferAdd, XferMod and XferSrch APIs implement a store/forward function for in-house transfers only. If nightly process is in a state that prevents the current transfer from completing successfully, the transactions will be stored by SilverLake and CIF 20/20 and applied to the next business day. This will be transparent to the customer and to the consumer if the values pass the validation process with a Success will be returned in the response.

XML Examples

XferAdd One Time 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>
 </SOAP-ENV:Header>
 <SOAP-ENV:Body>
  <XferAdd
      xmlns="http://jackhenry.com/jxchange/TPG/2008">
   <MsgRqHdr>
    <jXchangeHdr>
     <JxVer/>
     <AuditUsrId>Test</AuditUsrId>
     <AuditWsId>Test</AuditWsId>
     <AuthenUsrId/>
     <ConsumerName/>
     <ConsumerProd/>
     <Ver_1/>
     <jXLogTrackingId>{GUID}</jXLogTrackingId>
     <Ver_2/>
     <InstRtId>011001276</InstRtId>
     <InstEnv>TEST</InstEnv>
     <Ver_3/>
     <BusCorrelId/>
     <Ver_4/>
     <WorkflowCorrelId/>
     <Ver_5/>
     <ValidConsmName>Redacted</ValidConsmName>
     <ValidConsmProd>Redacted</ValidConsmProd>
     <Ver_6/>
    </jXchangeHdr>
    <Ver_1/>
    <Ver_2/>
    <Ver_3/>
   </MsgRqHdr>
   <ErrOvrRdInfoArray>
    <ErrOvrRd>
     <ErrCode>500019</ErrCode>
     <Ver_1/>
     <BusSvcType/>
     <Ver_2/>
    </ErrOvrRd>
    <ErrOvrRd>
     <ErrCode>500005</ErrCode>
     <Ver_1/>
     <BusSvcType/>
     <Ver_2/>
    </ErrOvrRd>
   </ErrOvrRdInfoArray>
   <AcctIdFrom>
    <FromAcctId>5339</FromAcctId>
    <FromAcctType>D</FromAcctType>
    <Ver_1/>
   </AcctIdFrom>
   <AcctIdTo>
    <ToAcctId>1400262475</ToAcctId>
    <ToAcctType>D</ToAcctType>
    <Ver_1/>
   </AcctIdTo>
   <XferRec>
    <Amt>1.50</Amt>
    <EftDescArray>
     <EftDescInfo>
      <EftDesc/>
      <Ver_1/>
     </EftDescInfo>
     <EftDescInfo>
      <EftDesc>JHTEST</EftDesc>
      <Ver_1/>
     </EftDescInfo>
    </EftDescArray>
    <PrtRcpt/>
    <Fee>0.0</Fee>
    <RedPrinc>N</RedPrinc>
    <Ver_1/>
    <TrnCodeCode>9</TrnCodeCode>
    <Ver_2/>
    <DrTrnCodeCode/>
    <Ver_3/>
    <Ver_4/>
    <Ver_5/>
    <Ver_6/>
    <Ver_7/>
   </XferRec>
   <Ver_1/>
   <XferType>Xfer</XferType>
   <Ver_2/>
   <Ver_3/>
  </XferAdd>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

XferAdd Future-MultipleDays 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>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <XferAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <MsgRqHdr>
        <jXchangeHdr>
          <JxVer/>
          <AuditUsrId></AuditUsrId>
          <AuditWsId></AuditWsId>
          <AuthenUsrId/>
          <ConsumerName/>
          <ConsumerProd/>
          <Ver_1/>
          <jXLogTrackingId>{Insert}</jXLogTrackingId>
          <Ver_2/>
          <InstRtId>011001276</InstRtId>
          <InstEnv>TEST</InstEnv>
          <Ver_3/>
          <BusCorrelId/>
          <Ver_4/>
          <WorkflowCorrelId/>
          <Ver_5/>
          <ValidConsmName>{Insert}</ValidConsmName>
          <ValidConsmProd>{Insert}</ValidConsmProd>
          <Ver_6/>
        </jXchangeHdr>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </MsgRqHdr>
      <ErrOvrRdInfoArray>
        <ErrOvrRd>
          <ErrCode>500000</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500005</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500006</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500011</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500014</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500019</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500029</ErrCode>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode>500031</ErrCode>
        </ErrOvrRd>
      </ErrOvrRdInfoArray>
      <AcctIdFrom>
        <FromAcctId>357459</FromAcctId>
        <FromAcctType>D</FromAcctType>
      </AcctIdFrom>
      <AcctIdTo>
        <ToAcctId>357384</ToAcctId>
        <ToAcctType>D</ToAcctType>
      </AcctIdTo>
      <Ver_1/>
      <XferType>Fut</XferType>
      <Ver_2/>
      <FutXferRec>
        <Amt>1.34</Amt>
        <TrnCodeCode>641</TrnCodeCode>
        <FutXferFirstDt>2020-07-14</FutXferFirstDt>
        <FutXferFreq>7</FutXferFreq>
        <FutXferFreqUnits>Days</FutXferFreqUnits>
        <Ver_1/>
        <FutXferOccr>6</FutXferOccr>
      </FutXferRec>
      <Ver_3/>
    </XferAdd>
    <Custom/>
    <Ver_1/>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

XferAdd Future-MultipleMonths 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>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <XferAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
            <MsgRqHdr>
                <jXchangeHdr>
                    <JxVer/>
                    <AuditUsrId></AuditUsrId>
                    <AuditWsId></AuditWsId>
                    <AuthenUsrId/>
                    <ConsumerName/>
                    <ConsumerProd/>
                    <Ver_1/>
                    <jXLogTrackingId>{Insert}</jXLogTrackingId>
                    <Ver_2/>
                    <InstRtId>011001276</InstRtId>
                    <InstEnv>TEST</InstEnv>
                    <Ver_3/>
                    <BusCorrelId/>
                    <Ver_4/>
                    <WorkflowCorrelId/>
                    <Ver_5/>
                    <ValidConsmName>{Insert}</ValidConsmName>
                    <ValidConsmProd>{Insert}</ValidConsmProd>
                    <Ver_6/>
                </jXchangeHdr>
                <Ver_1/>
                <Ver_2/>
                <Ver_3/>
            </MsgRqHdr>
            <ErrOvrRdInfoArray>
                <ErrOvrRd>
                    <ErrCode/>
                    <Ver_1/>
                </ErrOvrRd>
            </ErrOvrRdInfoArray>
            <AcctIdFrom >
                <FromAcctId>28399</FromAcctId>
                <FromAcctType>D</FromAcctType>
                <Ver_1/>
            </AcctIdFrom>
            <AcctIdTo >
                <ToAcctId>810</ToAcctId>
                <ToAcctType>S</ToAcctType>
                <Ver_1/>
            </AcctIdTo>
            <Custom/>
            <Ver_1/>
            <XferType>Fut</XferType>
            <Ver_2/>
            <FutXferRec>
                <Amt>2</Amt>
                <RedPrinc>false</RedPrinc>
                <TrnCodeCode/>
                <PrtRcpt>false</PrtRcpt>
                <FutXferFirstDt>2020-09-02</FutXferFirstDt>
                <FutXferDayOfMonth>2</FutXferDayOfMonth>
                <FutXferFreqUnits>Months</FutXferFreqUnits>
                <FutXferFreq>3</FutXferFreq>
                <EftDescArray>
                    <EftDescInfo>
                        <EftDesc>Just a transfer</EftDesc>
                        <Ver_1/>
                    </EftDescInfo>
                    <EftDescInfo>
                        <EftDesc/>
                        <Ver_1/>
                    </EftDescInfo>
                </EftDescArray>
                <SvcPrvdInfo/>
                <Ver_1/>
                <FutXferOccr>0</FutXferOccr>
                <Ver_2/>
                <FutXferMatPmtCode/>
                <Ver_3/>
                <RcptDlvryMthd/>
                <PrtPartRcpt/>
                <Ver_4/>
                <FutXferDayOfWeek/>
                <FutXferDayOfWeekOccur/>
                <Ver_5/>
            </FutXferRec>
            <Ver_3/>
        </XferAdd>
        <Custom/>
        <Ver_1/>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

XferAdd Future-OneTime 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>
         </SOAP-ENV:Header>
         <SOAP-ENV:Body>
          <XferAdd
              xmlns="http://jackhenry.com/jxchange/TPG/2008">
           <MsgRqHdr>
            <jXchangeHdr>
             <JxVer/>
             <AuditUsrId>Test</AuditUsrId>
             <AuditWsId>Test</AuditWsId>
             <AuthenUsrId/>
             <ConsumerName/>
             <ConsumerProd/>
             <Ver_1/>
             <jXLogTrackingId>9876543211</jXLogTrackingId>
             <Ver_2/>
             <InstRtId>011001276</InstRtId>
             <InstEnv>TEST</InstEnv>
             <Ver_3/>
             <BusCorrelId/>
             <Ver_4/>
             <WorkflowCorrelId/>
             <Ver_5/>
             <ValidConsmName>Redacted</ValidConsmName>
             <ValidConsmProd>Redacted</ValidConsmProd>
             <Ver_6/>
            </jXchangeHdr>
            <Ver_1/>
            <Ver_2/>
            <Ver_3/>
           </MsgRqHdr>
           <ErrOvrRdInfoArray>
            <ErrOvrRd>
             <ErrCode>500019</ErrCode>
             <Ver_1/>
            </ErrOvrRd>
            <ErrOvrRd>
             <ErrCode>100239</ErrCode>
             <Ver_1/>
            </ErrOvrRd>
           </ErrOvrRdInfoArray>
           <AcctIdFrom>
            <FromAcctId>402719</FromAcctId>
            <FromAcctType>D</FromAcctType>
            <Ver_1/>
           </AcctIdFrom>
           <AcctIdTo>
            <ToAcctId>98198</ToAcctId>
            <ToAcctType>D</ToAcctType>
            <Ver_1/>
           </AcctIdTo>
           <Ver_1/>
           <XferType>Fut</XferType>
           <Ver_2/>
           <FutXferRec>
            <Amt>0.99</Amt>
            <FutXferFirstDt>2024-05-28</FutXferFirstDt>
            <FutXferNextDt>2024-05-28</FutXferNextDt>
            <FutXferFreq>1</FutXferFreq>
            <FutXferFreqUnits>Days</FutXferFreqUnits>
            <Ver_1/>
            <Ver_2/>
            <Ver_3/>
            <Ver_4/>
            <Ver_5/>
           </FutXferRec>
           <Ver_3/>
          </XferAdd>
         </SOAP-ENV:Body>
        </SOAP-ENV:Envelope> 

XferAdd ACH 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>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <XferAdd 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/>
                <AuthenUsrCred>
                    <ns1:Security xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"></ns1:Security>
                </AuthenUsrCred>
                <Ver_2/>
                <AuthenProdCred>
                    <ns2:Security xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"></ns2:Security>
                </AuthenProdCred>
                <Ver_3/>
            </MsgRqHdr>
            <ErrOvrRdInfoArray>
                <ErrOvrRd>
                    <ErrCode></ErrCode>
                    <Ver_1/>
                </ErrOvrRd>
                <ErrOvrRd>
                    <ErrCode></ErrCode>
                    <Ver_1/>
                </ErrOvrRd>
            </ErrOvrRdInfoArray>
            <AcctIdFrom >
                <FromAcctId SrchType="" MaskVal="">28399</FromAcctId>
                <FromAcctType>D</FromAcctType>
                <Ver_1/>
            </AcctIdFrom>
            <AcctIdTo >
                <ToAcctId SrchType="" MaskVal="">810</ToAcctId>
                <ToAcctType>S</ToAcctType>
                <Ver_1/>
            </AcctIdTo>
            <XferRec/>
            <Custom></Custom>
            <Ver_1/>
            <XferType>ACH</XferType>
            <ACHXferRec>
                <ACHDrName>John Doe</ACHDrName>
                <ACHDrRtNum>011001276</ACHDrRtNum>
                <ACHDrAcctId>28399</ACHDrAcctId>
                <ACHDrAcctType>D</ACHDrAcctType>
                <ACHCrRtNum>011001276</ACHCrRtNum>
                <ACHCrAcctId>810</ACHCrAcctId>
                <ACHCrAcctType>S</ACHCrAcctType>
                <ACHXferAmt>1.0</ACHXferAmt>
                <ACHOneTime>Y</ACHOneTime>
                <ACHTermCnt>1</ACHTermCnt>
                <ACHTermUnits>Days</ACHTermUnits>
                <ACHNextXferDt>2020-09-22</ACHNextXferDt>
            </ACHXferRec>
        </XferAdd>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

XferAdd IntraFITransfer Request

<!-- The following example shows how to perform an Intra-Financial -->
<!-- Institution transfer between two DDA accounts belonging to --> 
<!-- two separate customers. -->

<XferAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
 <MsgRqHdr>
  <jXchangeHdr>
   <JxVer/>
   <AuditUsrId>PA</AuditUsrId>
   <AuditWsId>IDG</AuditWsId>
   <AuthenUsrId/>
   <ConsumerName/>
   <ConsumerProd/>
   <Ver_1/>
   <jXLogTrackingId/>
   <Ver_2/>
   <InstRtId  >011001276</InstRtId>
   <InstEnv>TEST</InstEnv>
   <Ver_3/>
   <BusCorrelId/>
   <Ver_4/>
   <WorkflowCorrelId/>
   <Ver_5/>
   <ValidConsmName>CONSUMER NAME</ValidConsmName>
   <ValidConsmProd>CONSUMER PRODUCT</ValidConsmProd>
   <Ver_6/>
  </jXchangeHdr>
 </MsgRqHdr>
 <ErrOvrRdInfoArray>  
  <ErrOvrRd>
   <ErrCode>500019</ErrCode>
  </ErrOvrRd>
 </ErrOvrRdInfoArray>
 <AcctIdFrom>
  <FromAcctId>46635</FromAcctId>
  <FromAcctType>D</FromAcctType>
 </AcctIdFrom>
 <AcctIdTo>
  <ToAcctId>2645</ToAcctId>
  <ToAcctType>D</ToAcctType>
 </AcctIdTo>
 <XferRec>
  <Amt>1.00</Amt>
  <RedPrinc>N</RedPrinc>
  <Ver_1/>
  <TrnCodeCode>9</TrnCodeCode>
  <Ver_2/>
  <DrTrnCodeCode>1</DrTrnCodeCode>
 </XferRec>
</XferAdd> 

XferAdd Response

<XferAddResponse
  xmlns="http://jackhenry.com/jxchange/TPG/2008"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <MsgRsHdr>
    <jXchangeHdr>
      <JxVer>R2016.2</JxVer>
      <AuditUsrId>PA</AuditUsrId>
      <AuditWsId>IDG</AuditWsId>
      <AuthenUsrId/>
      <ConsumerName/>
      <ConsumerProd/>
      <Ver_1/>
      <jXLogTrackingId>7AA9492C-237E-CA75-EFD2-1E1A5E98C70D</jXLogTrackingId>
      <Ver_2/>
      <InstRtId>011001276</InstRtId>
      <InstEnv>TEST</InstEnv>
      <Ver_3/>
      <BusCorrelId>577287da-e725-4fca-9568-40f0458e4f58</BusCorrelId>
      <Ver_4/>
      <WorkflowCorrelId/>
      <Ver_5/>
      <ValidConsmName></ValidConsmName>
      <ValidConsmProd></ValidConsmProd>
    </jXchangeHdr>
    <Ver_1/>
  </MsgRsHdr>
  <XferKey>JV26ADEFXT</XferKey>
  <RsStat>Success</RsStat>
  <Ver_1/>
</XferAddResponse> 

XferAdd FAQ

General Questions

(SilverLake and CIF 2020) What account types work with XferAdd?

• XferType
  • Xfer/blank
    • DSXLO
      • Can be used for both
        • AcctIdFrom.FromAcctType
        • AcctIdTo.ToAcctType
  • Fut(Creates an AFT)
    • DSG
      • AcctIdFrom.FromAcctType
    • DSXTGLO
      • AcctIdTo.ToAcctType
  • ACH
    • For the on us side of the ACH
      • DSXTGLO
        • Can be used for both
          • ACHXferRec.ACHDrAcctType
          • ACHXferRec.ACHCrAcctType

Changed the <RedPrinc> to “Y” when using the code 7 (principal only) and it worked, but for code 30 (escrow only) still not working.

The XferAdd message isn’t designed to support all payment types. It’s the JX version of Telephone Transfer. Normally a person wouldn’t call the bank and ask to have their mortgage escrow balance increased. XferAdd will support a regular loan payment and a principal only, but that’s all it should be used for. Anything beyond those two loan transaction types need to use the TrnAdd message. TrnAdd is one sided, meaning it does not support both the credit and debit information in one message call so you’ll need to make two calls to the service.

We are worried about ensuring the data integrity. I know we have a Batch Number property available in the TrnInfo_CType inside the TrnAddRequest. For this use case we could end up having 6 transfer calls:

1. Regular Payment Debit 2. Regular Payment Credit 3. Principal Debit 4. Principal Credit 5. Escrow Debit 6. Escrow Credit

- Is it safe to assume that we can/should set the same batch number for those 6 transactions? Is there a way to determine this number? - If one of the transactions fail, do we need do something in our side to undo the ones that worked or this is handled correctly in JxChange side? - Is there another mechanism to group those 6 transactions?

Yes, you can use the same batch number. Batch numbers are not assigned so you can use any numeric value. The type of failure would determine next steps. These are just a few examples. You will want to think through others so you have a complete set of un-happy path behaviors.

• If the transaction failed due to SilverLake Business Service validation, then the values could be corrected and the message resent. If it continues to fail, then you can either keep retrying or you can use TrnMod to delete the first transaction.
• If there is an interruption in communication, then you’ll want to verify if the transaction made it to SilverLake and if it was successful or not, then determine next steps.

There isn’t any current message that would allow you to group all transactions into one method call. I would recommend using the <BusCorrelId> element. This allows you to group items according to a unit of work. It doesn’t impact the core values nor provide any grouping mechanism there but if there is a situation where you need to search for associated transactions in the JX or iAdapter logs, this would provide a list of all the messages with that value.

I noticed in the XfrAdd Request that there is a field <RedPrinc> for principal payment. Is that used for PrincipalOnly? If we would like to make a regular payment with an addition to principal in a single transfer, is that supported and how should we formulate the request?

Yes, <RedPrinc> is the element for PrincipalOnly. Making an additional Principal payment would require 2 calls because there’s no way to distinguish in one test that a portion of the amount should be split between principal and the rest to regular payment which would include late fees, interest, etc. For more information see the Operation Summary tab.

Can you tell us whether it is possible the use the <XferAdd> operation but memopost the two account instead of “hard-posting”? The <TrnAdd> operation allows us to specify “MemoPostOnly” but we do not see the same capability for <XferAdd> Transfer Funds.

Unfortunately the XferAdd operation does not have MemoPostOnly capability. The XferAdd transaction will memo post until the EOD occurs for the bank, then it is hard posted. Only TrnAdd has the MemoPostOnly option.

So just to confirm. The XferAdd will turn into a hard post without requiring a posting file?

Yes, XferAdd will hard post without requiring a posting file.**

SilverLake We are attempting to do a loan payment and we are receiving a 500045 error “Tran code must affect credit to ‘Q’”. How can we fix this?

The XferRec.RedPrinc element is used to determine what transaction code should be used to post the transaction to a loan. If the transaction code is not furnished a transaction code is assigned that indicates the transaction is a transfer from DDA or from Savings-depending on the type of from account being debited.

• If the transaction code is furnished in the incoming message and the RedPrinc element is ‘Y’ the program verifies the transaction code is set up for principal reduction. If it is not set up as a credit that affects the principal an error of 500044 (Tran Code must affect credit to principal) is returned. If the transaction code supplied in the message is not a credit or a transaction code that allows the system to determine how to apply the transaction an error of 500045 (Tran code must affect credit to ‘Q’) will be returned.
• If the transfer to account is a loan then the value must be true or false. If it is not an error 500016 (Principal reduction code must be Y or N when the to account is a loan) will be returned.
• If the to account for the transfer is not a loan then the value must be false or error 500036 (Principal reduction code must be N when the to account is not a loan) will be returned.

After performing a XferAdd doing a loan payment, the information in AcctInq for the loan remains the same. Does the EOD need to process for the information to be updated?

As for AcctInq, I am seeing balances change when I run the same XferAdd. The date of next payment stayed the same because of the transaction code used is a 349 (which defaulted in because TrnCodeCode was set to 0). A 349 transaction code in LNPAR3 has field ‘Affect Next Pmt Date’ set to No, so that’s why next payment date stayed the same.

Can we use XferAdd to make escrow payment to the loan?

Short answer is they can’t use XferAdd for escrow-only debits/credits. The only tran codes from LNPAR3 (Loan Transaction Code Parameter file) that can be used for one-time transfers must have Affects Code (L3AFFT) of either P (Principal), I (Interest), or Q (Regular Payment-Computer Split).

Based on what I’m seeing available in business services, <TrnAdd> would be the only way I can see making escrow-only payments.

Can I use XferAdd to pay Credit Card?

No, you would need to use the CrCardTrnAdd service (listed under the CPS RTP provider).

I get errors when doing a XferAdd with a General Ledger (GL) account. What do I need to do to correct the errors?

XferAdd does not work with General Ledger accounts. You MUST use <TrnAdd>.

Core Director What fields in XferAdd operation do we use to pass the debit trans code description and credit trans code description?

For XferType = Xfer we currently parse the description out of the EftDescArray. We place the first entry in the array in the 1st suspense description and the second entry in the array in the 2nd suspense description, for example:

 <AcctIdFrom>
  <FromAcctId >10003606</FromAcctId >
  <FromAcctType>10</FromAcctType>
  <Ver_1 />
</AcctIdFrom>
<AcctIdTo>
  <ToAcctId>2110011</ToAcctId>
  <ToAcctType>10</ToAcctType>
  <Ver_1 />
</AcctIdTo>
<XferRec>
  <Amt>1.23</Amt>
  <EftDescArray>
    <EftDescInfo>
      <EftDesc>Test Description 1</EftDesc>
      <Ver_1 />
    </EftDescInfo>
    <EftDescInfo>
      <EftDesc>Test Description 2</EftDesc>
      <Ver_1 />
    </EftDescInfo>
  </EftDescArray>

When we use XferAdd (Intra-FI example) to transfer money from an account of Saving type to another account of DepositType the AvlBal property on the Saving account is not updated immediately (on deposit acct it is updated immediately). Can you tell us what transfer codes (TrnCodeCode and DrTrnCodeCode) should we use so the AvlBal property will be updated immediately and the transfer will be processed with success?

There are bank settings that affect certain types of credits and debits that the bank can select that will allow the AvailBal to be updated or not when those events occur. Items such as Add Memo Credits, Add ACH Credits, Add POD Credits, etc. This is basically a Y/N switch. Since it is configurable at the bank level, you may need to be prepared to handle a scenario where you will not see updates to AvailBal elements if certain events occur. Since the effect is set at the core level, you will not be able to affect a change via the jX calls to reverse the effect. This may be something you will need to discuss with each bank to understand their settings. If the bank is unfamiliar with the settings, inform them that it is found on the Service Charge Parameter Maintenance core screens.

If we want to transfer money from one Deposit account to another Deposit account, can we use the same codes, or do we need to use some other codes? If not what codes should we use for these kinds of transfers?

As a vendor, normally the bank will inform you what transfer codes for you to use. If they do not, you are able to pass in the operation with those fields blank and the system will enter the codes that are set as default into the operation.

Core Director It is my understanding that the DrTrnCodeCode field is the tran code that will be used to withdraw (debit) the money from the “from” account. True or False?

Yes, the DrTrnCodeCode relates to the from account.

Core Director If I only pass the TrnCodeCode (aka the credit TranCode), what TranCode will be used on the debit side? Once I get a list of the defined TranCodes to use for this instance of Core Director, can I pass both fields (DrTrnCodeCode and TrnCodeCode), with proper values, in the same request?

You can send both the TrnCodeCode and the DrTrnCodeCode. But if you do not, there are parameters that can be defined for that interface/vendor in MNTJXC for default TranCode’s (both debit and credit). If defined, these defaults will be used if the TrnCodeCode/DrTrnCodeCode is not sent in on the request.

XferAdd with an XferType of blanks or Xfer is showing “Telephone Transfer” when posting to core history. What drives the description?

The value in XferRec.XferSrcType determines what description the core displays when the transfer posts. Behavior by value:

• Mob or Intnet → Displays Home/Digital Banking
• Tele, blank, not passed, InPerson, or ATM → Displays Telephone Transfer

In short, XferSrcType is the controlling field for how the transfer source is labeled in core history.

SilverLake - Why is a fee being assigned to our transfer when using XferTyp of Xfer or blank?

This occurs because the financial institution has a default transfer fee configured in their core parameters. When no fee value is passed in the request, the system automatically applies this default fee. To override the automatically assigned fee, explicitly pass: XferRec.Fee = 0 . This ensures that no fee is charged for the transfer.

SilverLake - When passing XferRec.Fee = 0, we receive ErrCode 9 – Officer code is required. What is needed?

ErrCode 9 is a Fault, meaning it can be overridden, but it indicates that by passing a zero value for XferRec.Fee, the core requires identification of who authorized the fee override. In many financial institutions, charging a fee below the configured parameter amount triggers a rule requiring an officer code.

To resolve this the FI can decide to:

• Allow the override without an officer code
• Provide an officer code by passing: XferRec.OffCode = a valid officer code

SilverLake - When using XferAdd with an XferTyp of Xfer or blank, we are getting ErrCode 500019 – The CIF number for from‑account and to‑account are different. What is the cause?

This error occurs when the primary account holder (CustId) on the from‑account and to‑account do not match. The primary customer is identified by:

The CustId with an AcctRelCode P(Primary) relationship returned in CustAcctRelInq, or The primary CustId returned in the AcctInq response.

ErrCode 500019 is a Fault, meaning it can be overridden. Its purpose is to alert the user or system that the transfer is being made to an account where they are not the primary owner, acting as a protection or confirmation check.

How do you support payments that follow a bi‑weekly transfer frequency? This needs to work for both ACH and FUT XferType values.

There is no dedicated Bi‑Weekly frequency option in the transfer setup. However, you can achieve bi‑weekly behavior by configuring:

Units: Days Frequency: 14

This results in a transfer repeating every 14 days, which functionally matches a bi‑weekly schedule. This setup works for both ACH and Fut XferType.

Example:

<FutXferFreq>14</FutXferFreq>
<FutXferFreqUnits>Days</FutXferFreqUnits>

When we initiate a transfer after the cutover time using the future‑dated transfer APIs (XferAdd with FutXferRec), how can we confirm that the transaction is scheduled to post on the correct future date? Is it possible to verify future‑dated transfers using AcctHistSrch, and what should we look for in the response?

Future‑dated transfers (XferType = Fut) are treated as AFTs (Automated Funds Transfers). An AFT posts on its scheduled transfer date, provided that day is a processing day.

If the scheduled transfer date falls on a non‑processing day, the behavior depends on the financial institution’s configuration:

• The FI may choose to post before the non‑processing day
• Or post after the non‑processing day
• Non‑processing days include weekends, holidays, or any custom dates configured by the FI in their processing calendar

Let’s say you submitted a request on June 13 with an effective date of June 14, but when you checked it using AcctHistSrch, the effective date appears as June 16.

In the case of the DMZ bank environment, AFTs are configured to post after non‑processing days. Because the transfer date you selected, June 14, fell on a non‑processing day, the system automatically rolled it forward to the next processing day—June 16.

Yes, you can verify future‑dated transfers using AcctHistSrch, but note:

• The Transfer Date in the AFT is the date you intend for the transfer to occur
• The Effective Date shown in AcctHistSrch will reflect the actual posting date, after any calendar adjustments
• Therefore, if the transfer date fell on a non‑processing day, AcctHistSrch will display the adjusted posting date, not the originally requested date

ACH Questions

How do I get values for the ACHStdEntryClass element?

The ACHStdEntryClass is a parameterized element. You may obtain the values by utilizing the ParmValSrch operation passing in ParmName = ACHStdEntryCode.

Still get the same error “Next transfer date is invalid” by substituting <ACHNextXferDt >2019-02-13</ACHNextXferDt> with <ACHNextXferDay xsi:nil="true"/>

ACHOneTime is throwing us off here. It’s mapped to ACTMST/ACTARC and the description for this field is “Auto Recurring entry”. So by putting a Y in this element we are saying ‘Yes’ this is an auto-recurring entry. There’s reverse logic here, so this element needs to be set to N for one time transfers. When you run the test with ACHOneTime changed to N, another error will occur saying that ACHTermUnits needs to be blank. If you input NA for ACHTermUnits, then run the test, you should get a success.

Incorrect:

   <ACHXferRec>
    <ACHDrName>John Doe</ACHDrName>
    <ACHDrRtNum>161788444</ACHDrRtNum>
    <ACHDrAcctId>332456</ACHDrAcctId>
    <ACHDrAcctType>D</ACHDrAcctType>
    <ACHCrAcctId>1717</ACHCrAcctId>
    <ACHCrAcctType>D</ACHCrAcctType>
    <ACHXferAmt>0.01</ACHXferAmt>
    <ACHFeeAmt>0.01</ACHFeeAmt>
    <ACHOneTime>Y</ACHOneTime>
    <ACHNextXferDt  >2019-02-13</ACHNextXferDt>
    <ACHFeeDrAcctId>332456</ACHFeeDrAcctId>
    <ACHFeeDrAcctType>D</ACHFeeDrAcctType>
  </ACHXferRec>

Correct:

   <ACHXferRec>
    <ACHDrName>John Doe</ACHDrName>
    <ACHDrRtNum>11001276</ACHDrRtNum>
    <ACHDrAcctId>1234</ACHDrAcctId>
    <ACHDrAcctType>D</ACHDrAcctType>
    <ACHCrAcctId>1717</ACHCrAcctId>
    <ACHCrAcctType>D</ACHCrAcctType>
    <ACHXferAmt>0.01</ACHXferAmt>
    <ACHFeeAmt>0.01</ACHFeeAmt>
    <ACHOneTime>N</ACHOneTime>
    <ACHTermCnt>0</ACHTermCnt>
    <ACHTermUnits>NA</ACHTermUnits>
    <ACHNextXferDay xsi:nil="true"/>
    <ACHFeeDrAcctId>1234</ACHFeeDrAcctId>
    <ACHFeeDrAcctType>D</ACHFeeDrAcctType>
  </ACHXferRec>

Sometimes there is an error with the message “Master account number cannot be duplicated”, but we are not sure what it means.

The AcctIdFrom.FromAcctId in XferAdd for ACH represents the ACH master account number that will be used to create the actual ACH entries when the core processes ACH. It is a number that will be used for modifications in the ACH Master file. It is not necessarily the debit account number in the transfer (ACHXferRec.ACHDrAcctId), however many banks use the on-us account number for this value.

Since this is the key to the ACH Master file it must be unique for each transfer that is set up in the ACH master and can only occur in the file one time. If this number is not unique the business service will issue the “Master account number cannot be duplicated” error you see. It might be helpful to think of FromAcctId being used as a primary key for the ACH transfer.

If you have multiple ACH entries for the same transaction account already, you could use a sequential method for assigning these number. Maybe start out with the first one being the account number (10987654321) and then append a ‘1’, ‘2’, ‘3’ . . . . on the next entries (109876543211, 109876543212, . . .).

SilverLake We are trying to add a new ACH transfer using XferAdd. The response has errors for fields ACHCompEntryDesc, ACHCompName and ACHCompId (They cannot be blank). We check the SvcDictSrch and these fields are set as not required. We tested this same request in the test environment and XferAdd accepts blank for these fields. Is there any configuration to change that behavior in the XferAdd? Or what would be valid values for these fields in this case?

These fields can be used to match a company setup in ACH Company Maintenance for those entities that send ACH transfers frequently. These fields must be populated regardless of whether the ACH is coming from a company or not. If the ACH is coming from a company, they may want to use ACHCompMultiInq or ACHCompSrch to obtain the values for these elements. If not coming from a company they can input any value they want. If the values passed in do not match a company setup in ACH Company Maintenance the records will still be processed, they just wouldn’t cross-reference a company setup in ACH Company Maintenance. In ACH General Parameters, those fields can be used to match against a company for purposes such as item counters and exposure limits.

SilverLake One of our customer requirement is to implement the indefinite recurring transfers. Can we achieve this by sending end date as empty data elements?

Yes, in order to achieve an indefinite transfer the user would not populate ACHXferExpireDt (for ACH) or FutXferExpDt (AFT).

SilverLake Can federal tax payments be sent via ACH through the XferAdd service? And if so, are there any special parameters etc. that need to be passed into the request?

No, the XferAdd – ACH does not support ACH Federal Tax Payments entries via this operation. Core does not allow/support ACH Federal Tax Payments entered via the ACH Auto Transfers which is equivalent to the XferAdd – ACH operation. There are special codes and information that has to be entered to build the ACH NACHA record that is not supported within ACH Auto Transfers.

When we send ACH transfers using XferAdd API or sending NACHA file using ACHFileAdd API how are they processed to send to ACH network? Is there a daily cutoff time for this processing?

Please refer to the ACHFileAdd FAQ for information.

What values do I use for FromAcctId and ToAcctId for ACH transfer types?

When it comes to ACH transfer types, the FromAcctId is considered a unique record identifier and should be a unique value for every transfer request. There is a maximum of 15 digits to be used in this field. The ToAcctId should be omitted. The account numbers for the debit and credit accounts are supplied in the ACHXferRec.

Core Director We are trying to execute transactions that require override through xferAdd API. Is there documentation on the override transaction codes?

XferAdd has a number of override codes available:

• Closed – If Account Status is “C” error returned in 1004.
• Dormant - If Account Status is “D” error returned is 1005.
• Inactive - If Account Status is “I” error returned is 1006.
• Employee - If Employee Code is 1 thru 5 error returned is 1007.
• Charged Off - If the DDA/SAV/LON is charged off error returned is 1008.
• Stop Payment - If Stop Payments exist on the account error returned is 1009.
• Hold - If Holds exist on the account error returned is 1010.
• Warning - If Warnings exist on the account error returned is 1011.
• Message - If Messages exist on the account error returned is 1012.
• Ach Stop Payment- If ACH Stop Pays exist on the account error returned is 1013.
• No Post Debit - If No Post Debits exist on the account error returned is 1014.
• No Post - If No Post exists on the account error returned is 1015.
• No Post Credit - If No Post Credits exist on the account error returned is 1016.
• Insufficient - If Account is Insufficient error returned is 1017.

There are host parameters that control if the specific vendor/product has the ability to override the error codes listed above (these are located in the MNTJXC vendor parameters). If they are setup as capable of override, then they can simply include the ErrCode that was returned in the response in the ErrOvrRdInfoArray in the request to override.

Is there a way to add remarks that will get sent to receiving FI?

There is not a way for the ACH to be created with remarks that would be sent to the receiving FI through a 7 record following the 6 record in the NACHA format. The remarks that can be passed in the XferAdd are for the account that is at the originating FI.

How do you obtain a list of valid ACHCrTrnCodeCode and ACHDrTrnCodeCode values?

ACHCrTrnCodeCode and ACHDrTrnCodeCode relate to the NACHA standard trancodes, not the core application transaction codes. To retrieve these ACH Transaction Codes you can use the ParmValSrch API while passing in <ParmName>ACHTrnCode</ParmName>.

(SilverLake) When using the XferAdd with XferType ACH we are getting the error 100364-Bank Routing Number is not valid . What is causing the error?

The ABA that is being passed in the XML path returned in the ErrElem needs to pass the checksum/check digit validation. The first eight digits are used to calculate what the nineth digit should be and then compared. This is not unique to JHA and can be researched to make your own check digit routine or how the calculation is performed.

Why are details like ACHCompDiscrData, ACHCompEntryDesc, ACHCompName, and ACHCompId automatically added to the ACH transfer request?

These values are being pulled from defaults the FI can setup. If non-default values are needed they can be passed into the elements and the non-default values will be used instead. You can use the SvcDft with an XferType of ACH to view default values for those elements.

How do you apply a principal‑only or interest‑only loan credit for ACH?

Principle Only For principal‑only reduction payments you must include: ACHXferRec.RedPrinc = true. This flag instructs the core to apply the ACH credit directly to principal rather than treating it as a standard blended loan payment.

Interest Only There is not a way to direct ACH XferAdd to be interest only. The loan may be an interest only loan, so the payment would be applied only to interest, but a payment through XferAdd for ACH would not be able to be directed to interest only.

When using XferAdd with XferTyp = ACH, a fee is being assigned even though ACHXferRec.ACHFeeAmt is not passed. What is the cause?

This behavior typically occurs because the financial institution has a default ACH fee amount set in their ACH parameters. When no fee is provided in the request, the system automatically applies the default fee from the ACH parameter settings. To override this behavior and prevent a fee from being assessed, explicitly pass: ACHXferRec.ACHFeeAmt = 0 . This instructs the core to override the default fee and charge no ACH fee for the transaction.

Is ACH Addenda added by using the ACHAddendaArray_AType element in XferAdd?

No. The ACHAddendaArray_AType element is not currently mapped to any core system. While message briefs may document what could be supported according to the contract, the actual implementation depends on how each core maps those elements. After reviewing all three cores, none of them currently use or consume this array. This means ACH Addenda via ACHAddendaArray_AType is not available or implemented at this time. This does not rule out future support, but for now, the field has no effect when passed to XferAdd.

We’re testing XferAdd for ACH transactions, and are seeing EES event 840 being sent, but we are not seeing any corresponding EES event 730 transactions posted to the accounts. Is this normal behavior?

Core will create different EES event numbers based on the type of transfer. Using the XferAdd API for a wire transfer will trigger a 730 Transaction Occurrence event, while using the same API for ACH transfers triggers an 840 Incoming ACH Transactional Activity event.