Developer Resources

Details

Operation Summary

The Stop Check Add (StopChkAdd) operation provides the ability to issue a stop/hold order on a specified account held by a customer.

The StopChkAdd request requires passing in an <InAcctId> complex containing the id and type of the account that the check belongs, a <StopHldType> of SP, and a <StopChkInfo> complex defining the stop/hold to be added to the account. If the check number is known, it should be included in the <ChkNumStart> element.

The StopChkAdd operation also supports adding a Hold to the specified account by providing a value of HD in the <StopHldType>.

The StopChkAdd 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 provider was unable to complete the request. A stop sequence number assigned to the stop/hold request will also be returned in the <StopSeq> element, which can be used to reference the stop/hold in future inquiry or modification requests.

Additional Behavior Considerations

When creating a stop for a Deposit account type (D, S or X), a consumer may receive a fault scenario with the following error.

 <FaultMsgRec>

  <ErrCode>9</ErrCode>
    
  <ErrCat>Fault</ErrCat>
    
  <ErrDesc>Officer code is required</ErrDesc>
    
  <ErrElem>StopChkInfo.OffCode</ErrElem>
    
  <ErrLoc>DDSTHDADD</ErrLoc>
    
    </FaultMsgRec>

The error is generated by the provider when expected fees are waived.

If the request contains <StopChg>0.0</StopChg>, then the provider assumes any predetermined fee is being waived. There are several options available to resolve this:

• Request a valid officer code to populate the <OffCode/> element from the Institution
• Remove the <StopChg> element from the request and allow the provider to assess the predetermined fee
• Include the <<ErrCode> value of 9 in the request in the <ErrOvrRdInfoArray/> since the <ErrCat/> value is Fault

It is important to note that all three require the approval of the specific institution and may vary from institution to institution.

XML Examples

StopChkAdd 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>
    <StopChkAdd
      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>9</ErrCode>
          <Ver_1/>
        </ErrOvrRd>
        <ErrOvrRd>
          <ErrCode/>
          <Ver_1/>
        </ErrOvrRd>
      </ErrOvrRdInfoArray>
      <InAcctId>
        <AcctId>8318033</AcctId>
        <AcctType>D</AcctType>
        <Ver_1/>
      </InAcctId>
      <StopHldType>SP</StopHldType>
      <StopChkInfo>
        <OffCode/>
        <ExpDt JHANull="true">2018-05-23</ExpDt>
        <LowAmt>0.0</LowAmt>
        <HighAmt>0.0</HighAmt>
        <ChkDt>2017-03-23</ChkDt>
        <ChkNumStart>23</ChkNumStart>
        <ChkNumEnd>23</ChkNumEnd>
        <StopChg>0.0</StopChg>
        <PayeeName/>
        <ACHCompId/>
        <ACHStdEntryClass/>
        <ACHDrCRAll/>
        <RmkArray>
          <RmkInfo>
            <Rmk>TEST</Rmk>
            <Ver_1/>
          </RmkInfo>
          <RmkInfo>
            <Rmk/>
            <Ver_1/>
          </RmkInfo>
        </RmkArray>
        <Ver_1/>
        <HldEntireBal/>
        <Ver_2/>
        <StopNotCode/>
        <EffDt>2018-05-22</EffDt>
        <Ver_3/>
        <RelAcctId/>
        <RelAcctType/>
        <PostAdvCode/>
        <Ver_4/>
        <AvlBalEffDt>2018-05-22</AvlBalEffDt>
        <Ver_5/>
      </StopChkInfo>
      <Custom/>
      <Ver_1/>
    </StopChkAdd>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

StopChkAdd FAQ

Our request is getting success the majority of the time and only fails occasionally with error 1002 for the same StopChkAdd request for CIF/2020 and is working fine for SilverLake and Core Director. We checked in our logs and determined that we are sending 2 requests within 1 second.

If the file is locked for some reason, error 1002 is just a generic message used in all business services if for any reason it can’t write to a file. If the first request still had a lock on the file, regardless of the environment, a failure could occur.

We are trying to create a stop payment for Checks using the service StopChkAdd with account Number = 98754 and Check Number = 123456. The transaction was successful and it generated a StopSeq number in response. We are able to fetch this stop payment created using the StopChkSrch service.

After creating the stop payment, we tried to debit using the same check details and account Number using the TrnAdd service. The debit transaction was successful.

In this scenario, if we are issuing stop payment for check number = 123456, then as per our understanding, it shouldn’t allow to withdraw money with that Check which is being allowed. Can you help us understand the expected behavior?

What should happen in this scenario is the transaction would not be post and have to be worked to either post the transaction to the account or reject it. Was the transaction entered today (i.e. after the most recent EOD processing)? If so, it wouldn’t hard post to the account and would show up in Exception Item Processing to be worked the next business day. Assuming the transaction was entered today, we think it should be looked at the next business day to make sure it didn’t hit the account.

What are the <StopHldType> values for the different cores?

(CoreDirector) The StopHldType field length is 1 character, below are the values supported:

• S - Stop Payment
• U - Stop ACH Credits
• T - Stop ACH Debits
• H - Hold
• C - No Credits
• D - No Debits
• W - Warning
• M - Message
• N - No Post

(SilverLake and CIF 20/20) The StopHldType field length is 2 characters, below are the values supported:

• AT - Alert
• HD - Hold
• SI - Special Instructions
• SP - Stop Pay

I was curious if jXchange Silverlake had a function that placed a hold on an account as opposed to a check?

It’s not apparent, but the StopChkAdd service is what you would use to place a hold on an account. You would pass in the account number, the hold amount, and a StopHldType = HD. No check number is required.

Our goal is to place a hold that’s effective immediately (EffDt = current day), but expires at the end of the day. If I set the ExpDt to the current day, will it expire at the end of the day, or will it expire immediately? (or, in other words, is the ExpDt inclusive or exclusive)

It should expire when processing occurs. It will stay on the account through the expiration date. So if it expires today it will expire in processing tonight. If it expires tomorrow, then it will expire in processing tomorrow night. It covers the day they expire until processing.

(SilverLake and CIF2020) Is the expiration date (ExpDt) for a hold allowed to fall on a business day or any day of the week?

The expiration date (ExpDt) relies on core processing (EOD). If an ExpDt is scheduled for a non-processing day (such as Sunday, when most financial institutions do not process), then the hold will expire during the subsequent night’s processing (e.g. Monday night).

(SilverLake) How does the ACHCompID and ACHStdEntryClass/ACHDrCRAll affect a stop for an ACH?

The stop will need to use either the ACHCompId or the ACHStdEntryClass/ACHDrCRAll but cannot use both. When using these elements, it will only affect incoming ACH items.

Below are some examples of combinations and what would happen:

• Hit will go to non-post.

• Suspect will either go to non-post or post to the account and the FI will review a Suspect report to further decide. The Suspect path for the ACH is dependent on parameters set forth by each FI.

• Nothing means the stop does not have any affect.

• ACH Stops

  • ACH Stop entered with company ID and amount/range
    • Item matches company ID and amount/range = Hit
    • Item matches company ID but not the dollar amount/range = Nothing
    • Item matches dollar amount/range but not company ID = Nothing
  • ACH stop entered with company ID and no dollar amounts
    • Item matches company ID = Suspect
    • Item does not match company ID = Nothing
  • ACH stop entered with ACHStdEntryClass/ACHDrCRAll
    • Item matches dollar amount/range = Suspect
    • Item does not match dollar amount/range = Nothing

(SilverLake) When creating a stop for a check, how do the dollar amounts and the check numbers affect the stop?

Below are some examples of combinations and what would happen:

• Hit will go to non-post.

• Suspect will either go to non-post or post to the account and the FI will review a Suspect report to further decide. The Suspect path for the ACH is dependent on parameters set forth by each FI.

• Nothing means the stop does not have any affect.

• Check Stops

  • Stop entered with check number/range and dollar amount/range
    • Item matches check number/range but dollar amount is wrong = Hit
    • Item matches dollar amount/range but check number is wrong = Suspect
    • Item matches dollar amount/range but has no check number = Suspect
  • Stop entered with check number/range but no dollar amount
    • Item matches check number/range = Hit
    • Item does not match check number/range = Nothing
  • Stop entered with dollar amount/range but no check number/range
    • Item matches dollar amount/range = Suspect
    • Item does not match dollar amount/range = Nothing

(SilverLake) We are trying to place a hold for a particular amount and we were told to use the StopChkAdd jXchange API and passing the value “HD” in the StopHldType element. However, when making this API request, we are getting an error (shown below). Would you please let us know where we pass the amount in this API?

<FaultHdr>
<FaultRecInfoArray>
<FaultMsgRec>
<ErrCode>100034</ErrCode>
<ErrCat>Error</ErrCat>
<ErrDesc>Check hold amount required for type 'HD'</ErrDesc>
<ErrElem>StopHldType</ErrElem>
<ErrElemVal>HD</ErrElemVal>
<ErrLoc>DDSTHDADD</ErrLoc>
</FaultMsgRec>
</FaultRecInfoArray>>

The API requires that the StopChkInfo.LowAmt and StopChkInfo.HighAmt elements be passed in with the request. The request should look like this: (both the high and low amounts may be the same.)

</MsgRqHdr>
<InAcctId Rstr="">
<AcctId>0001</AcctId>
<AcctType>D</AcctType>
<Ver_1/>
</InAcctId>
<StopHldType>HD</StopHldType>
<StopChkInfo>
<LowAmt>1.00</LowAmt>
<HighAmt>2.00</HighAmt>
<Ver_1/>
<Ver_2/>
<Ver_3/>
<Ver_4/>
<Ver_5/>
<Ver_6/>
</StopChkInfo>
<Ver_1/>
</StopChkAdd>

(Core Director) How can I place a hold on a Core Director DDA or Savings account to block outgoing transactions while still allowing credits?

To prevent outgoing transactions (such as debits, transfers, or wires) while keeping the account active for incoming credits, place a Full Balance Hold on the account. This can be accomplished using the StopChkAdd operation in the jXchange SOAP API.

Implementation Details: When calling StopChkAdd, configure the request as follows:

• AcctId/AcctType: Specify the DDA or Savings account on which the hold should be placed.
• StopHldType: Set to “H” to indicate a Hold.
• LowAmt and HighAmt: Set both values to 0.00 to apply a Full Balance Hold, which blocks all outgoing transactions.
• ExpDt (optional): Provide an expiration date for the hold, if applicable.
• Desc: Include a descriptive reason for the hold (for auditability and operational clarity).

This approach safely restricts outgoing activity while ensuring the account remains open and able to receive incoming credits.