Developer Resources

Details

Operation Summary

The Account History Search (AcctHistSrch) operation allows consumers to obtain account transaction history information associated with a specific account.

The AcctHistSrch operation can be used to find an amount, check number, or date number range of transaction history as well as a specific transaction type for a given account by passing in the following identifiers as elements:

Special Considerations

With AcctHistSrch, the <MemoPostInc> element determines the behavior searching history for memo posted items. Canonical values are Excl and Only. The default value will be Excl (Exclude). Consideration should be given to the use of the two values meaning that the AcctHistSrch operation could have to be used twice depending on if the business rules call for the functionality to either exclude or include memo posted items in the account transaction history.

CIF 20/20 Interface Change

Record Identifier Change: HistRecId (ACTION REQUIRED)

The generation logic for the unique historical record identifier (HistRecId) has been changed to leverage the unique row identifier from the new tables, which will not align with historical “Relative Record Number” values. This new method will be implemented with the CIF 20/20 yearly release for 2026.

This change affects consumers of the AcctHistSrch API via jXchange on the CIF20/20 core system. This change introduces an update to the historical record identifier generation that had previously been implemented for Silverlake, aligning CIF20/20 behavior with our Silverlake core system.

XML Examples

AcctHistSrch Date Based 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>
    <AcctHistSrch
      xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <SrchMsgRqHdr>
        <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>
        <MaxRec>350</MaxRec>
        <Cursor>0</Cursor>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </SrchMsgRqHdr>
      <InAcctId>
        <AcctId>8318033</AcctId>
        <AcctType>D</AcctType>
        <Ver_1/>
      </InAcctId>
      <StartDt>2017-04-22</StartDt>
      <EndDt>2018-05-23</EndDt>
      <LowAmt>0.00</LowAmt>
      <HighAmt>20000.00</HighAmt>
      <MemoPostInc>only</MemoPostInc>
      <SvcPrvdInfo/>
      <Custom/>
      <Ver_1/>
      <XferKey/>
      <Ver_2/>
      <IncXtendElemArray/>
      <Ver_3/>
      <TrnRcptId></TrnRcptId>
      <Ver_4/>
    </AcctHistSrch>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

AcctHistSrch Transaction ID 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>
    <AcctHistSrch
      xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <SrchMsgRqHdr>
        <jXchangeHdr>
          <JxVer/>
          <AuditUsrId>{Insert}</AuditUsrId>
          <AuditWsId>{Insert}</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>
        <MaxRec>35</MaxRec>
        <Cursor>0</Cursor>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </SrchMsgRqHdr>
      <InAcctId>
        <AcctId>5500</AcctId>
        <AcctType>L</AcctType>
        <Ver_1/>
      </InAcctId>
      <MemoPostInc>Only</MemoPostInc>
      <SvcPrvdInfo/>
      <Custom/>
      <Ver_1/>
      <XferKey/>
      <Ver_2/>
      <IncXtendElemArray/>
      <Ver_3/>
      <TrnRcptId>JVDBC75MD8</TrnRcptId>
      <Ver_4/>
    </AcctHistSrch>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

AcctHistSrch FAQ

How can I determine if an account is currently delinquent?

To identify delinquency, review the loan account status and the field:

Loan Status Codes: The following status codes are relevant for delinquency determination: 5, 6, 7, and 8.

1. Active – Transactions accepted
2. Closed – Transactions not accepted
3. Matured – Advances not allowed
4. New Today – Transactions accepted
5. Open but not accruing – Transactions accepted
6. Accruing but frozen – Transactions not accepted
7. Frozen and not accruing – Transactions not accepted
8. Charged off (not accruing) – Transactions accepted

Past Due Indicator: The field specifies the number of days past due. Each institution defines its own threshold for delinquency, so confirm your FI’s policy.

How can I identify payment transactions using the Account History Search API?

Payments are a subset of transactions, but there is no dedicated field that explicitly flags a transaction as a payment. Common approaches:

• Transaction Codes (TranCodes): TranCodes are core-parameter driven and vary by financial institution. To retrieve all possible TranCodeCode values for your system, use the ParmValSrch service with ParmName = TranCodeCode.
• Descriptions: In sample data, TrnCodeDesc often includes the word “payment.” While helpful, this is not guaranteed across all institutions.

Each TranCode returned in the ParmValSrch record of the response has an Affects child that points out the Transaction Affects Code associated with the TranCode:

 <ParmValSrchRec>
  <ParmValCode>10</ParmValCode>
  <ParmValDesc>Regular Payment with Computer Split</ParmValDesc>
  <ParmValInfoArray>
    <ParmValInfo>
      <ParmValDetail>L,O</ParmValDetail>
      <ParmValTxt>Account Type</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>C</ParmValDetail>
      <ParmValTxt>Debit/Credit</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Q</ParmValDetail>
      <ParmValTxt>Affects</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Y</ParmValDetail>
      <ParmValTxt>Affects Next Pay Date</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Computer Split</ParmValDetail>
      <ParmValTxt>Affects Description</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
  </ParmValInfoArray>
  <Ver_1>
  </Ver_1>
</ParmValSrchRec>

In the example above, a TranCode of 10 is a loan payment with a Transaction Affect Code of ‘Q’, which represents a “Regular Payment – Computer Split”.

How can a consumer retrieve the bank routing number, account number, and check transaction code using AcctHistSrch? Also, what input parameter limits check transactions in AcctHistSrch?

Check trancode is going to be different for every FI. You would have to know what tran code that specific FI uses for checks. Routing # and account # would not appear in the response using AcctHistSrch. To search for only check transactions, the user would need to utilize ChkNumStart and ChkNumEnd.

• Routing number and account number are not returned in the AcctHistSrch response.
• Check transaction codes vary by financial institution (FI); you must know the FI-specific code for checks.
• To filter for check transactions, use the parameters:
  • ChkNumStart
  • ChkNumEnd

How does a consumer know if a transaction increases or decreases the balance? Is there an indicator in the response?

Check the TrnType element:

• D = Debit
• C = Credit

For IncXtendElemInfo, can a consumer get the full list and descriptions, or retrieve it themselves?

Refer to the AcctHistSrch API documentation. As for any *Srch or *Inq API, the message brief lists all XtendElem values available for returning specific data elements.

Transactions in the AcctHistSrch response don’t have a unique ID. Can a consumer get unique IDs, or is there another service that provides them?

A: SeqNum is not unique to the provider’s history file; however it is unique for a given account number / account type. Passing the AcctId (account number) and AcctType (account type) in the AcctHistSrch request will return transaction history for that specific account. The response will include the assigned SeqNum value for a given transaction which would be unique to the account number / account type. An item to be aware of is an FI could potentially issue a memo post only record(s) to an account during a given business day. In this scenario, a SeqNum would not be assigned to the transaction until after the FI’s end-of-day (EOD) processing. The AcctHistSrch response will be returned; however the SeqNum element would be empty.

SeqNum is not globally unique, but it is unique for a given account number and account type. The response will include SeqNum for each transaction, unique within that account.

How can a consumer show only transactions that will definitely post at EOD? Is there a unique value to differentiate them?

There is no guaranteed way to confirm if a memo-posted transaction will hard-post.

• All memo-posted items enter the system, but some may not process.
• MemoPostOnly = ‘Y’ does not guarantee posting. Recommendation: Display all memo-posted transactions (using MemoPostInc = Only) as Pending until the next processing cycle.

SilverLake and CIF 20/20 How do I determine transaction grouping?

• BatchNum and SeqNum is the same for all transactions in a group.
• PostSeq increments by 1 for each transaction in the group.

SilverLake and CIF 20/20 Does PostSeq reset per batch or per day?

PostSeq numbers reset daily.

What is the sort order of AcctHistSrch response? Is it deterministic?

SilverLake and CIF 20/20 For deposits (AcctType = D, S, or X), if SrtMthd is not specified:

• Default sort: TrDate, PstSq#, then Serial.
• Records are returned in LIFO (Last In, First Out) order for date-sensitive searches, showing the most recent activity first.

SilverLake and CIF 20/20 Does AcctHistSrch provide a running balance for loan accounts, including memo-posted transactions?

Yes. When MemoPostInc = true, memo-posted items are reflected in the running balance .

SilverLake and CIF 20/20 Why does sometimes show current-day balance for past transactions? How is the running balance calculated?

• updates only with transactions affecting principal.
• Sort order and running balances match the green screen account history view.
• Default SrtMthd is PostDt if not defined.
• Records are returned in LIFO order.

Using AcctHistSrch with x_EFTCardHistSrchRec for EFT card transactions, where is the MOTO indicator?

MOTO is determined by PAN entry mode, returned in EFTCardCapType:

• Keyed
• MagRead
• BarCode
• OCR
• ChipRead
• Trak
• ElecMer
• CertMagRead
• UnCertChipRead

SilverLakeWhy is the Posting Sequence not populated for deposit accounts, but it is for loans?

AcctHistSrch for deposits (DDHISTSRCH) does not include a PostSeq element. This is expected behavior.

SilverLake and CIF 20/20 How can a consumer pull deposit transactions with an effective date equal to the current business date?

StartDt and EndDt filter by posted date, not effective date.

To work around this:

• Expand the date range in your request.
• Use SrtMthd = EffDt to sort by effective date. This applies LIFO (Last In, First Out) sorting against the effective date.

SilverLake and CIF 20/20 Why does only appear when Cursor = 0 in the request? Can a consumer get it for all calls?

This is the normal behavior. is only returned when Cursor = 0.

Why is the field populated with a confirmation number for a NetTeller transfer?

This is expected. represents a reference/check number, not strictly a physical check number. For NetTeller transfers, the confirmation number is used as the reference.

We call AcctHistSrch for memo-posted items, but is blank. Does the requester need to call AcctMemoPostSrch to get the check number?

No. Whether the check number is available during memo posting depends on the image provider. If the provider supplies the image number during memo posting, NetTeller can display it—provided the image provider supports this.

CIF 20/20 Why do memo-posted transactions from teller and kiosk both show TrnCode = 980 before EOD?

This is expected behavior. CIF 20/20 assigns temporary transaction codes for memo-posted items:

• Memo Debit → TrnCode = 980
• Memo Credit → TrnCode = 920
• True transaction codes (e.g., 981 for kiosk) are applied after EOD processing.

Core Director Is there a field to uniquely identify each transaction record?

Yes. Use HistRecId in AcctHistSrch.

Why is x_EFTCardHistSrchRec not returning results in AcctHistSrch?

For EFT card history to populate:

• The DDA transaction must have SourceCode = ‘T’.
• The associated TranCodeCode must have EFT type = ATM.
• The bank must be a JH Card Processing Services (CPS) customer with CPS enabled in their environment.

What do TrnStat values in AcctHistSrch represent?

Core Director: TrnStat is not mapped.

SilverLake and CIF 20/20: Represents the state of a monetary transaction:

• Deposit
  • A = Active
  • D = Delete
  • L = List Post
  • X = Reversal
• Loan
  • A = Active
  • D = Delete
  • F = Fee
  • R = Reversal

Can a requester get SEC Code and ACH Company ID for ACH transactions via AcctHistSrch?

Yes. Use ACHTrnSrch.

• ACHTrnId (from ACHTrnSrch) and EFTTrnId (from AcctHistSrch) can be matched to retrieve:
  • ACHStdEntryClass (SEC Code)
  • ACHCompId (ACH Company ID)

Are transactions made via jXchange immediately reflected in AcctHistSrch?

Yes, history updates immediately, but memo-posted items remain only until EOD processing.

• To include memo-posted items: MemoPostInc = true
• To show only memo-posted items: MemoPostInc = Only
• Default: MemoPostInc = Excl (hard-posted only)

Does the AcctHistSrch API provide a unique transaction identifier?

Yes. The HistRecId element serves as the unique identifier. It combines the account number/type and a unique number, separated by a comma (e.g., 1234D,99999). Note that the second part of the identifier is essentially a row number, which can change under certain conditions—such as when a transaction moves from memo-posted to hard-posted (two different files) or if tables are rebuilt. Rebuilding the tables would ultimately change the row numbers, therefore changing the HistRecId for all transactions.

When using AcctHistSrch with sorting and cursor-based pagination, how does sorting work across multiple pages? For example, if page 1 is sorted by amount in ascending order, why do some records on page 2 appear smaller than those on page 1?

The API supports only one sorting method, and it will use the first method specified.