Developer Resources
Details
SoapAction | http://jackhenry.com/ws/IntnetFinInstIdAdd |
Input Name | IntnetFinInstIdAdd |
Output Name | IntnetFinInstIdAddResponse |
Input Namespace | http://jackhenry.com/jxchange/TPG/2008 |
Group Name | Customer |
Container | TPG_CustomerMaster.xsd |
XML Examples
IntnetFinInstIdAdd-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">2018-11-20T16:01:47Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<IntnetFinInstIdAdd 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>
<CustId>NAA0317</CustId>
<IntnetFinInstIdInfo>
<AllowIntnetIdDup>true</AllowIntnetIdDup>
<IntnetFinInstPswdId>David445886</IntnetFinInstPswdId>
<IntnetFinInstAcctIdArray>
<IntnetFinInstAcctId>
<AcctId>143453</AcctId>
<AcctType>D</AcctType>
<Ver_1/>
</IntnetFinInstAcctId>
</IntnetFinInstAcctIdArray>
<Ver_1/>
<IntnetFinInstACHXferArray>
<IntnetFinInstXferInfo>
<ACHDrName>Cassidy Norris</ACHDrName>
<ACHDrRtNum>123456789</ACHDrRtNum>
<FinInstDrName>Community First</FinInstDrName>
<ACHDrAcctId>146118</ACHDrAcctId>
<ACHDrAcctType>S</ACHDrAcctType>
<Ver_1/>
<AccessAlw>true</AccessAlw>
<Ver_2/>
<AliasAcctName/>
<Ver_3/>
</IntnetFinInstXferInfo>
</IntnetFinInstACHXferArray>
<Ver_2/>
</IntnetFinInstIdInfo>
<Custom/>
<Ver_1/>
</IntnetFinInstIdAdd>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
FAQ
IntnetFinInstIdAddFAQ
Q: My understanding is that this API call establishes a NEW On-Line Banking (OLB) User for the provided CustId. Is this correct?
A: Yes
Q: How does the process of establishing a new OLB User work? (the FI is using NetTeller, if that matters.) What is the user workflow once this IntnetFinInstIdAdd API call has completed? I want to understand what steps the user has to go through to begin using OLB after this API call successfully completes.
A: The IntnetFinInstIdAdd service can be used to register new users for NetTeller. Please note however that the service is not “real-time”. The NetTeller ID’s created through IntnetFinInstIdAdd are not available for immediate use in NetTeller OLB until an automatic sync occurs during nightly processing or performed manually. The FI has the option to perform the update manually from the back office tool. We’re looking at automating the update to something closer to real time.
Once available, the customer logs into the NT Application and is taken through first time log in. First time log in varies by FI and the installed products they have and the disclosures they’ve set up. NetTeller ID and PIN are a minimum. But for example, if a customer has our Electronic Statements Interactive (ESI) product and the end customer has an account that requires enrollment into ESI then an email address is necessary.
Q: How does setting field AllowIntnetIdDup to false cause the API call to behave? Would an error be returned from the API call if the CustId already has an IntnetFinInstId associated with the CustId?
A: Yes, an error 5008 is returned when a CustId already has a NetTeller ID associated with it and AllowIntnetIdDup is set to false. If you want to allow duplicates, you have to set AllowIntnetIdDup to true as well as pass in an override for error code 5066, “NetTeller ID already exists for customer.”
Q: Core Director I am getting an ErrCode = 1, "System error encountered", what does this error mean?
A: This error is a generic error returned by Core Director when something unexpected occurs in the business service. You may want to check if you are passing in AllowIntnetIdDup value, it is a required field for Core Director. Valid values for the field are:
- true - allow more than one NetTeller ID to be created for a CIF
- false - don't allow more than one NetTeller ID to be created for a CIF
Q: What is the use case for allowing a duplicate InternetId to be created?
A: We recommend this be limited to an override performed by the FI itself to limit the potential for fraud. The FI can have many reasons for doing this. Not limited to: Disabling an existing ID while reissuing a new ID because of fraud. Some end customer may have so many accounts that they organize their accounts across multiple IDs. A use case example of this is "I’m aware of a customer that does business with a large housing business. The business stores the deposits in tenant specific accounts (one account per tenant) so the business has hundreds of accounts."
Q: If we are working with an existing Customer in SilverLake and we want to determine whether or not the Customer already has access to OLB, is it adequate to check for a value in the CustSrchResponse.CustSrchRecArray.CustSrchRec.IntnetFinInstIdArray.IntnetFinInstArrayInfo.IntnetFinInstId field?
A: Yes, similarly you can also check for an existing IntnetFinInstId in the CustInq response.
Q: What does field IntnetFinInstIdAdd.IntnetFinInstIdInfo.IntnetFinInstPswdId actually contain? The information in the TPG_CustomerMaster.XSD file indicates that this is “the password used for the financial institution internet product”, but the field name contains “Id” which makes me think this is not the actual password, but rather an ID link to the password. If it is indeed an ID and not the password, what does this ID link to, and how is it used? If it is the password, what are the rules?
A: It contains the actual password, an alpha numeric PIN that’s 4 characters in length. This is what we refer to as original PIN. It allows the end customer to log in the first time and originally was also used to allow a user to reset their current password back to their original PIN. We now have additional mechanisms in place for password recovery that do not rely on original PIN. Original PIN isn’t a long term password and won’t follow the same validation requirements that passwords require. As far as rules, numeric is the only rule I’m aware of currently being enforced. This PIN can be altered by the FI if needed.
Q: What is IntnetFinInstIdAdd.IntnetFinInstIdInfo.IntnetFinInstAcctIdArray used for? Is this a list of the Accounts that the OLB User should have access to in OLB?
A: Yes, it is the list of accounts that you want to link the newly created NetTeller ID to. If no accounts are provided, they can be added later on using the IntnetFinInstAcctIdAdd service.
Q: If a customer with an existing relationship with the bank who does not yet have OLB access, the customer would need to have each of their existing accounts added to their new NetTeller ID in order to give them access to those existing accounts via OLB, correct?
A: It depends on how the FI has their NT IDs configured on the host. The inquiry service (IntnetFinInstIdInq) can be used to determine which accounts are currently attached to the NT ID.
Q: What is IntnetFinInstIdAdd.IntnetFinInstIdInfo.IntnetFinInstACHXferArray used for? Does this set up ACH arrangements with other FIs and make them available in OLB?
A: Yes, that is correct.
Q: What does field IntnetFinInstIdAdd.IntnetFinInstIdInfo.IntnetFinInstPswdId in the response actually contain?
A: According to the Message Brief for the IntnetFinInstIdAdd service, a password will only be returned if none was specified in the request and the service provider generated a random one. The customer must use the PIN to log into NetTeller the first time.
Q: When sending an IntnetFinInstIdAdd request and the response contains the following, is there another business operation available to retrieve the existing Netteller ID?
<FaultRecInfoArray>
<FaultMsgRec>
<ErrCode>5008</ErrCode>
<ErrCat>Error</ErrCat>
<ErrDesc>Customer already has a NetTeller ID not allowed duplicates.</ErrDesc>
<ErrElem>CustId</ErrElem>
<ErrElemVal>SAA3060</ErrElemVal>
<ErrLoc>HBMASTADD</ErrLoc>
</FaultMsgRec>
</FaultRecInfoArray>
A: The CustInq service can be used to retrieve the NetTeller ID that is associated with a customer record. The path being: CustRec.IntnetFinInstIdArray.IntnetFinInstIdArrayInfo.IntnetFinInstId