Developer Resources
Details
SoapAction | http://jackhenry.com/ws/AcctSrch |
Input Name | AcctSrch |
Output Name | AcctSrchResponse |
Input Namespace | http://jackhenry.com/jxchange/TPG/2008 |
Group Name | Inquiry |
Container | TPG_InquiryMaster.xsd |
Operation Summary
OperationSummary-AcctSrch
Account Search (AcctSrch) is a jXchange service designed to search for the accounts that are related to a customer and provide that information to a consumer.
Element Name | Description |
Person Name | A complex element containing name information. The simple elements within this complex are as follows: ComName (Common name, full text name like John Doe) FirstName LastName MiddleName |
TaxId | The tax identifier |
CustId | The identifier attached to a customer |
Special Considerations
With AcctSrch, some customers may not have SSN/TIN information stored in core (i.e. foreign customers). If this information is not available, other search criteria can be used in its place (i.e. <PersonName> or <CustId>). Additional filtering may be performed by interrogating the response elements.
XML Examples
AcctSrch-XML
<?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-12-30T20:21:11Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<AcctSrch xmlns="http://jackhenry.com/jxchange/TPG/2008">
<SrchMsgRqHdr>
<jXchangeHdr>
<JxVer/>
<AuditUsrId></AuditUsrId>
<AuditWsId></AuditWsId>
<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/>
<Ver_5/>
<ValidConsmName>{Insert}</ValidConsmName>
<ValidConsmProd>{Insert}</ValidConsmProd>
<Ver_6/>
</jXchangeHdr>
<MaxRec>20</MaxRec>
<Cursor/>
<Ver_1/>
<Ver_2/>
<Ver_3/>
</SrchMsgRqHdr>
<CustId JHANull="" Rstr="">NAA0317</CustId>
<AcctType JHANull="" Rstr="">D</AcctType>
<SvcPrvdInfo>
<JHAConsumer>
<AvlBalCalcCode/>
<Ver_1/>
</JHAConsumer>
</SvcPrvdInfo>
<Custom/>
<Ver_1/>
<PersonName>
<ComName SrchType=""/>
<FirstName SrchType=""/>
<MiddleName SrchType=""/>
<LastName SrchType=""/>
<x_PersonName>
<TitlePrefix/>
<NameSuffix/>
<LegalName/>
<SalName/>
<Ver_1/>
<AbbName/>
<Ver_2/>
</x_PersonName>
<SvcPrvdInfo/>
<Ver_1/>
</PersonName>
<TaxId JHANull="" MaskVal="" SrchType=""/>
<AcctId JHANull="" MaskVal="" Rstr="" SrchType=""/>
<Ver_2/>
<IncXtendElemArray>
<IncXtendElemInfo>
<XtendElem>x_DepAcctInfo</XtendElem>
<Ver_1 />
</IncXtendElemInfo>
<IncXtendElemInfo>
<XtendElem>x_DepBalDtInfo</XtendElem>
<Ver_1 />
</IncXtendElemInfo>
<IncXtendElemInfo>
<XtendElem>x_DepInfoRec</XtendElem>
<Ver_1 />
</IncXtendElemInfo>
</IncXtendElemArray>
<Ver_3/>
<AvlBalCalcCode/>
<Ver_4/>
<BrandCode/>
<Ver_5/>
</AcctSrch>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
FAQ
AcctSrchFAQ
Q: What elements reference amounts?
A: In AcctSrch there are 2 elements that reference amounts, Amt and AvlBal. Amt refers to the Current Balance and AvlBal refers to the Available Balance.
Q: When we used the TaxID parameter 243519909 to call AcctSrch search we receive the error message below: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.
A: The TaxID 243519909 response has 5255 lines and is approximately 133kb in size.”
We were able to locate the meaning of the message from your system by performing a Google search, though there could be other causes unknown to us. Per the Google search your system message bus is set at 64kb incoming size limit. The amount of information being returned exceeds your message bus settings per the error message provided from your system. Jack Henry does not control the size of the message bus on outside systems, this is controlled by you. Since the issue exists outside of Jack Henry’s control, we cannot give you direct steps to correct the issue, only recommendations on how you can handle via programmatic, environmental or jXchange request changes. The recommendations were provided within the initial response.
“Here are some options:
- Increase your message buffer. (Though it is our understanding that this could increase the opportunity of successful denial of service attacks. So it is not recommended.)
- Reduce the
<MaxRec>
from 200 to a lower number until the message falls below your message buffer limits. - Use XML pagination.
- Reduce the amount of data being requested by reducing the XtendElem data being called at one time. If you need all the data types you are requesting, you could make multiple calls until you receive all of your requested data. (We have eliminated this as a root cause via our exchanges.)”
Q: Currently, the service AcctSrch provides the list of accounts associated with the given CustId and we allow access to all the transactions for that customer.
We want to determine the restrictions on transactions for a given customer based on his owner status (primary or joint) for that account. Are there any services which we can use to determine the same.
A: SilverLake and CIF 20/20 The best service to use for this would be the ParmValSrch function on utilizing AcctRelCode. This could tell specifics about each Relationship Code that is set up on the FI.
A: Core Director AcctSrch by CustId will return back the Accounts associated with that CustId. In Core Director there can be four names directly defined on an account.
If the record in the AcctSrchRecArray matches on the fields below, it will be returned with an AcctRelCode of “PR1” to indicate that this matched the primary name information on the account.
- Field 6 First Name
- Field 7 Last Name
- Field 13 SSN/EIN
If the record in the AcctSrchRecArray matches on the fields below, it will be returned with an AcctRelCode of “PR2” to indicate that this matched the second name information on the account.
- Field 84 2nd First Name
- Field 85 2nd Last Name
- Field 82 2nd SSN/EIN
If the record in the AcctSrchRecArray matches on the fields below, it will be returned with an AcctRelCode of “PR3” to indicate that this matched the third name information on the account.
- Field 72 3rd First Name
- Field 73 3rd Last Name
- Field 905 3rd SSN/EIN
If the record in the AcctSrchRecArray matches on the fields below, it will be returned with an AcctRelCode of “PR4” to indicate that this matched the third name information on the account.
- Field 75 4th First Name
- Field 76 4th Last Name
- Field 907 4th SSN/EIN
In addition to the four name fields on an account, relationships can also setup by the bank (the relationship codes are bank-defined values so they’ll differ from bank to bank). Examples of some bank-defined relationship codes that could be returned in AcctRelCode could be:
2 – Co-Borrowers
A – Authorized Signor
B – Business Owner or officer
F – Family Member
S – Sole Proprietor
T – Trustee
Etc.
For example. A relationship could be added on CustId to indicate that another CustId is a Co-Signor (C) on their account. If this is the case, the AcctSrchRecArray would return the account with an AcctRelCode of “C” to indicate Co-Signor.
Unfortunately, there is not a standard way for banks to specify which of the account records that are returned via AcctSrch that they allow transactions on, as each bank may configure how they want to do this differently. For example, the PR1’s would be the Primary on the account and would normally have access. Some banks may setup an AcctRelCode to signify signor that would be used to indicate this.
Q: SilverLake and CIF 20/20 In a production environment will it be possible that there are two accounts with the same account number belonging to two different customers?
A: Account numbers can be reused across different account types with different customers. So it is possible to see an account number 1234567/D for John Doe and 1234567/S for a Jack Smith.
Q: Where can I find the
<AcctStat>
codes?
A: There are three pages within the jXchange Environment section of this portal labeled jXchange and Core Director, jXchange and CIF 20/20 and jXchange and SilverLake that has the status codes for each core type.