FAQ

Jack Henry recognizes that the FED ISO 20022 Wire Standards change is raising numerous questions within the banking and fintech sectors. To foster transparency and collaboration, we have established this page to share the inquiries we have received along with our responses. We strongly encourage you to visit this page often and to review the questions/answers below before submitting a case related to the ISO 20022 change.

Question: Will the current wire templates (or recurring wires) automatically convert to ISO20022, or will they need to be rebuilt?

Answer: The existing templates and recurring wires will need to be rebuilt.

Question: Shall we send InstrAmt and WireAmt with the same value as both are mandatory?

Answer: The InstructedAmount and InterbankSettlementAmount in the ISO 20022 pacs.008 message can differ due to several reasons:

1. Currency Conversion - If the payment involves different currencies, the InstructedAmount (the amount specified by the debtor) will be in one currency, while the InterbankSettlementAmount (the amount settled between banks) will be in another. The exchange rate used for this conversion will be specified in the message.
2. Charges Deduction - When transaction charges are deducted from the payment amount, the InstructedAmount remains the same, but the InterbankSettlementAmount is reduced by the charges. This ensures that the creditor receives the full instructed amount, while the charges are settled between the banks
3. Intermediary Bank Fees - If intermediary banks are involved in the payment chain, they may deduct their fees from the InterbankSettlementAmount. The InstructedAmount remains unchanged, ensuring the final recipient gets the full amount instructed by the debtor.

CBPR+ Charges Reference Link

Example Scenario In this scenario, the exchange rate and any fees deducted by intermediary banks would be detailed in the message to maintain transparency.

InstructedAmount: USD 1000 (amount instructed by the debtor) InterbankSettlementAmount: EUR 940 (after currency conversion and deduction of intermediary bank fees).

Question: What should be enumeration value of LocalTrfType for different wire types as it is mandatory?

Answer: These values will be returned in the SvcDictSrch API.

Question: Does the WireTrnISOAdd API supporting remittance info?

Answer: Yes, within the WireRemitInfo complex.

Question: For “Bank To Bank Info”, Jack Henry field /WireTrnInfoRec/WireFinInstToFinInstInfoRec/WireFinInstToFinInstRmkArray/RmkInfo/Rmk was mapped before. What will be corresponding field in new ISO message?

Answer: There are party and agent tables/fields where the data may be entered. A consumer/developer will need to understand the ISO specifications and rules to know where to move the data. It is not a simple mapping exercise.

Question: OrignFinInstRtId and DestFinInstRtId are blank in sample file provided.

1. Is it fine to send the values as blank in those fields?
2. If we want to send values, can we send OrignFinInstRtId value as the same as SndrFinInstRtId?
3. Which other Bank field value will be same as DestFinInstRtId?

Answer:

1. Yes, it can be blank as it relates to the question.
2. Yes, the values can be the same, it will not cause an issue. Though, the values being different is also acceptable.
3. The use case for the values being different, is if the bank is acting a correspondent, then the sending and origin banks would be different.

Question: What are the enuemration values of Debtor AcctType?

Answer: This is sent in the WireAcctType element and corresponds to the account type on the JH banking core. The values can be retrieved with the SvcDictSrch API.

Question: What is the enumeration value of Creditor AcctType? In existing WireTranAdd API, we are sending WireTrnAdd.WireTrnInfoRec.WireBenfInfoRec.WireBenfIdType.

Answer: This maps to WireAgentInfoArray.WireAgentRec.WireFinInstAcctInfo.AcctIdCat.

Question: How will the different bank types be mapped in each host field of the new WireTrnISO APIs?

Answer: There is not an easy mapping between original FAIM and new ISO formats and some data cannot be mapped. The Federal Reserve Board (FRB) has the best mapping data we have seen and would recommend a consumer review the FRB information as Jack Henry cannot provide a decision on where to put the information when the FAIM and ISO fields are not one for one.

Question: On our interface we have Beneficiary Bank, Intermediary Bank, and Receiving Bank. Can you provide guidance on where this information will exist in the new WireTrnISO APIs?

Answer: There is not an easy mapping between original FAIM and new ISO formats and some data cannot be mapped. The Federal Reserve Board (FRB) has the best mapping data we have seen and would recommend a consumer review the FRB information as Jack Henry cannot provide a decision on where to put the information when the FAIM and ISO fields are not one for one.

Question: Will there be any change to WireTrnInq message at field level from for ISO message WireTrnISOAdd versus WireTrnAdd?

Answer: Yes, there will be significant differences in field size, additional fields, and data differences. We strongly suggest a complete review of the mapping pages for each API. e.g. WireTrnISOAdd - Mapping

Question: Can we map:

• Beneficiary reference number at field /WireTrnISOAdd/WirePmtTypeInfo/InstrId?
• Unique Payment Identifier at /WireTrnISOAdd/WirePmtTypeInfo/InstrTrnId?
• Sender Reference ID at /WireTrnISOAdd/WirePmtTypeInfo/WireRefId?

Answer: Please review the ISO 20022 standards and JH ISO Gap Analysis

Question: Can we get Fedtax sample as ISO uses different fields for Fedtax?

Answer: No, it is not currently available.

Question: What is the field/Key to use for Intermediary bank?

Answer: “Intermediary banks will be included in the WireAgentInfoArray, with WireAgentInfoArray.WireAgentRec. WireAgentType = IntmdAgent (A consumer can find all canonical values for WireAgentType in the SvcDictSrch API response).

Question: What are enumeration values of Country ?

Answer: Provided in the SvcDictSrch API response.

Question: What is field to use for District Name?

Answer: The PstlAdr object can be populated with this information.

Question: In schema we see AddrISO/FreeFormAddrArray/AddrLineInfo/AddrLine which could be used for addresses. But, we do not see it in sample provided. Shall we use it for addresses?

Answer: Yes.

Question:

• What are the field lengths for the fields: City/BldgName/Dept/SubDept/BldgId/BldgFloor/BldgRmId/PostOffBoxId/Street1/SubDivName/City/County/StateProv/PostalCode?
• What are the field lengths for the field: “EntityName” (Debtor/Creditor Name)?
• What are the field lengths for the field: “FinInstName” (Bank Name)?

Answer: Mappings may be found here: WireTranISOAdd.

Question: What field should we use for Sending Bank Name and Receiving Bank Name?

Answer:

• Sending Bank Name (Debtor Agent): WireAgentInfoArray.WireAgentRec.WireFinInstInfo.FinInstName (A consumer must also pass in the WireAgentInfoArray.WireAgentRec.WireAgentType = DrAgent)
• Receiving Bank Name (Creditor Agent): WireAgentInfoArray.WireAgentRec. WireFinInstInfo.FinInstName (Must also pass in the WireAgentInfoArray.WireAgentRec.WireAgentType = DrAgent)

Question: That is the host field provided for FedTax Form Mapping?

Answer: Tax information will be held within the remittance info - see WireRemitInfo.RemitStructureArray.RemitStructureRec.DocAmtRec.TaxAmtArray

Question: How do I inquire on an ISO20022 pacs.008 wire?

Answer: You will need to utilize the WireTrnInq API and include the TrnRcptId value from a successful WireTrnISOAdd response in your WireTrnInq request. Additionally, set the WireISOType to CustXfer.

<WireTrnInq xmlns="http://jackhenry.com/jxchange/TPG/2008">
            <MsgRqHdr>
                <jXchangeHdr>
                    <JxVer />
                    <AuditUsrId>{{X-AuditUser}}</AuditUsrId>
                    <AuditWsId>{{X-AuditWorkStation}}</AuditWsId>
                    <AuthenUsrId />
                    <ConsumerName />
                    <ConsumerProd />
                    <Ver_1 />
                    <jXLogTrackingId>{{$guid}}</jXLogTrackingId>
                    <Ver_2 />
                    <InstRtId>{{X-InstitutionRoutingID}}</InstRtId>
                    <InstEnv>{{X-Environment}}</InstEnv>
                    <Ver_3 />
                    <BusCorrelId>{{$guid}}</BusCorrelId>
                    <Ver_4 />
                    <WorkflowCorrelId />
                    <Ver_5 />
                    <ValidConsmName>{{X-ValidConsumerName}}</ValidConsmName>
                    <ValidConsmProd>{{X-ValidConsumerProduct}}</ValidConsmProd>
                    <Ver_6 />
                </jXchangeHdr>
                <Ver_1/>
                <Ver_2/>
                <Ver_3/>
            </MsgRqHdr>
            <TrnRcptId>JXK6E3IIBY</TrnRcptId>
            <Ver_1/>
            <WireCorrelId></WireCorrelId>
            <Ver_2/>
            <WireISOType>CustXfer</WireISOType>
        </WireTrnInq>

Question: Can you change the processing status of an existing wire to send to the Fed?

Answer: While there is an element to support this function (WireProcActType), only the bank’s users can perform this action through the Xperience user interface.

Question: How can we relate Party, Agent, Remittance, Tax Remittance, and Charges files with the WITRAN file?

Answer: A GUID value is assigned and shared across relevant files to enable data correlation between the WITRAN file and other wire 20022 files. Each of the listed files has a field name ending with ‘*GUID’ (e.g., WITRAN.WITRGUID, WITPARTY.WITPGUID, WITPACCT.WITPAGUID, etc.), which will contain the assigned GUID value. The GUID can be obtained through the WireTrnInq operation and will be returned in the response element.

The following representations are in the format FILE.FIELD.

• Party: WITPARTY.WITPGUID, WITPACCT.WITPAGUID, WITPFFAD.WITPFGUID
• Agent: WITAGENT.WITGGUID, WITAGTCI.WITCIGUID, WITAACCT.WITGAGUID, WITAFFAD.WITAFGUID
• Remittance: WITRMLDL.WITRLDGUID
• Tax Remittance: WITSRTXR.WITTXRGUID, WITSRTXC.WITTXCGUID
• Charges: WITCHGIF.WITCGGUID
• Wire 20022 Transaction General Information: WITRAN.WITRGUID

Question: In the WireTrnISOAdd operation, DestFinInstRtId is a required field. For a wire transfer with a domestic destination FI, I am able to set this to an ABA. For an international destination FI, they do not have an ABA, as they have a SWIFT Code/BIC. When I try to use the SWIFT Code in this field, I get an error as SWIFT Codes are alpha numeric and the field only allows numbers. I tried leaving this field blank in this situation, and the API returns an error that its required. What should I enter in this field if my destination FI is international and has no ABA and only a SWIFT Code?

Answer: For information, our ISO20022 solution does not process international wires directly. Silverlake wires/DLW is domestic only, so none of our institutions are going to be sending international wires directly. Each of them would have a correspondent bank that would perform the final delivery on their behalf. The correspondent bank is considered an intermediary agent.

In this scenario, where a domestic bank uses another domestic bank in the US as a correspondent to send funds internationally, the “To.FIID.FinInstnId.ClrSysMmbId.MmbId” would typically contain the correspondent bank’s information. This is because the correspondent bank is the immediate recipient within the clearing system and is responsible for forwarding the funds to the final international institution.

So, the “ClrSysMmbId.MmbId” would identify the correspondent bank within the relevant clearing system, ensuring the payment is routed correctly through the correspondent before reaching the international institution. DestFinInstRtId maps to To.FIID.FinInstnId.ClrSysMmbId.MmbId.

You would then use the InstBIC field to put the foreign bank’s information into the call so the clearing house will know where the final bank destination for the wire is intended.

Question: I’m trying to process a payment meant to go to a Japanese CreditorAgent and although I get a successful response when I use the BrCode, I can’t seem to clear the ErrCode 103065 - “Agent Branch ID should only be used when Agent is located in Japan” Warning message. I get the same message even if I send the payment to other countries. (Canada as an example). The contract document didn’t provide much guidance on what type of data we should input for the BrCode.

Answer: ErrCode 103065 is a warning, not an error, that is return to inform the consumer of the proper use of the branch code ID. Per Fed “CreditorAgentBranchIdentificationGuideline”, Rule 65 of the pacs.008 states, ‘’This should only be used when the Creditor Agent is located in Japan to identify the account to be credited.’’ This means that an user could use this field if the Creditor Agent is not located in Japan as well. There is no way of identifying valid Japan branch codes. Even if the consumer does use the branch code ID properly, which seems to be the case here, the core would still send the warning.

Question: We are aware of several fields that were optional in the old Fedwire format (Beneficiary City, Beneficiary Country are two examples). They are now required fields in the new ISO20022 format.

Some of our clients do not have Beneficiary City or Beneficiary County identified in their templates since they are currently optional. To work around this issue, we have updated our Database to pass, “Not Provided” in those fields if nothing has been provided by the User. This is being done to ensure the wire does not fail during processing.

We have used this same solution in the past for other items that were not stored in our DB but were mandated by the Fed; do you guys see any issues with this solution and the new jXchange Wire ISO API?

Answer: The JH API will accept those values though whether or not the FED will accept them on the backend or if it will cause exceptions for the bank, JH cannot say and you will need to do your own due diligence.

Question: We’re looking for help understanding the new ISO20022 values for WireStat, when returned from a WireTrnInq call. What do those values represent?

Answer: Here are the values with descriptions –

• Complete – Sent to the Fed and successful response received on send.
• Error – Sent to the fed but there was a communication error, and the fed did not actually receive the wire.
• Exception – Something is wrong with the wire package, and you will need to do an exception search to get a list of issues.
• Post Ready – Post Ready is the status an incoming wire has to be to 1) memo post and 2) post in EOD. This status is the equivalent to IN status on an incoming wire in FAIM.
• Reject – Sent to the Fed and the Fed received the wire but it was rejected by them during their validation. Usually this is due to missing key elements in the request.
• Review – Jack Henry has added the wire to the wire room, and it has passed initial validation it is now ready to be reviewed by the wire personnel.
• Send Ready – Send Ready goes through the final validation by the wire room and is ready to be sent to the Fed.

Question: My application is currently consuming Silverlake EES event 760 for Wire and ACH Audited Transaction Activity. Will that event change after migration to the new standard?

Answer: No, EES event 760 will remain the same after the update. If you are consuming that event now, then no changes are needed to consume it after the switch.

Question: I’m being prompted to supply a value for WireUETR with my XML request. What value should I use?

Answer: You should provide a unique, 36-character UUID for WireUETR.

Question: I’m running a WireTrnISOAdd call and am getting the following error messages back. What do these error mean?

                        <FaultMsgRec>
                            <ErrCode>103323</ErrCode>
                            <ErrCat>Error</ErrCat>
                            <ErrDesc>Changed By UserID Cannot be blank</ErrDesc>
                            <ErrElem>WITRCHGUSR</ErrElem>
                            <ErrLoc>WITRISADD</ErrLoc>
                        </FaultMsgRec>
                        <FaultMsgRec>
                            <ErrCode>103322</ErrCode>
                            <ErrCat>Error</ErrCat>
                            <ErrDesc>Entered UserID Cannot be blank</ErrDesc>
                            <ErrElem>WITRENTUSR</ErrElem>
                            <ErrLoc>WITRISADD</ErrLoc>
                        </FaultMsgRec>

Answer: We see these two errors when AuditUsrId and AuditWsId, located in the jxchangeHdr section of the request, are sent without values, or are omitted from the request. You will need to populate those two values with appropriate User ID and Workstation ID values, as described in our jXchangeHdr Information guide.