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:

Values	Description
Xfer	Intra-Financial Institution transfer
ACH	Inter-Financial Institution transfer
Fut	Future transfer

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:

Values	Description
ATM	ATM
InPerson	Teller
Intnet	Internet
Tele	Telephone

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 Parameter Value Search 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:

Element Name	Description
SemiDay1	This is the day of month for first semi-monthly payment.
SemiDay2	This is the day of month for second semi-monthly payment.
FutXferFirstDt	This is the first date to start a future transfer request.
FutXferExpDt	This is the expiration date of the transfer request.
FutXferFreqUnits	The units of frequency for the transfer request.

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:

Values	Description
Src	Source account that is the source of the funds transfer
Dest	Destination account that is to receive the funds transfer
Both	Both source and destination accounts

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.

Note: 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.

Note: 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 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">2020-07-22T19:55:09Z</wsu:Created>
      </wsse:UsernameToken>
    </wsse:Security>
  </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>

<?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">2020-07-22T19:55:09Z</wsu:Created>
            </wsse:UsernameToken>
        </wsse:Security>
    </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 Rstr="">
                <FromAcctId>28399</FromAcctId>
                <FromAcctType>D</FromAcctType>
                <Ver_1/>
            </AcctIdFrom>
            <AcctIdTo Rstr="">
                <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>

        <?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>Redacted</wsse:Username>
            <wsse:Password
             Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">Redacted</wsse:Password>
            <wsu:Created
           xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2023-07-28T14:40:04Z</wsu:Created>
           </wsse:UsernameToken>
          </wsse:Security>
         </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>
    

        <!-- Minimal fields -->
<?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">2020-07-22T20:14:45Z</wsu:Created>
            </wsse:UsernameToken>
        </wsse:Security>
    </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 JHANull="" Rstr="">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 Rstr="">
                <FromAcctId SrchType="" MaskVal="">28399</FromAcctId>
                <FromAcctType>D</FromAcctType>
                <Ver_1/>
            </AcctIdFrom>
            <AcctIdTo Rstr="">
                <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>

		<!-- 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 JHANull="" Rstr="">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>

<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>

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

A: 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.

---

Q: 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?

A: 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.

---

Q: 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?

A: 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.

---

Q: 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.

A: 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.

---

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

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

---

Q: 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?

A: 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.

---

Q: 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?

A: 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.

---

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

A: 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.

---

Q: Can I use XferAdd to pay Credit Card?

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

---

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

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

---

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

A: 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>

---

Q: 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?

A: 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.

---

Q: 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?

A: 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.

---

Q: 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?

A: Yes, the DrTrnCodeCode relates to the from account.

---

Q: 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?

A: 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.

---

---

ACH Questions

Q: How do I get values for the ACHStdEntryClass element?

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

---

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

A: 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 JHANull="" Rstr="">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>

---

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

A: 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, . . .).

---

Q: 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?

A: 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.

---

Q: 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?

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

---

Q: 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?

A: 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.

---

Q: 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?

A: Please refer to the ACHFileAdd FAQ for information.

---

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

A: 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.

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

A: XferAdd has a number of override codes available:

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 overridable, then they can simply include the ErrCode that was returned in the response in the ErrOvrRdInfoArray in the request to override. Also, they can send 9999 to override all overridable conditions.

---

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

A: 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.