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 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 = CrAgent)

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, I’m able to populate the DestFinInstRtId field with an ABA routing number when the destination financial institution is domestic. However, for international institutions that do not have an ABA and instead use a SWIFT Code (BIC), it’s unclear what value should be provided.

Answer: The DestFinInstRtId and OrignFinInstRtId elements are hardcoded to return predefined values and are not actively used by the business service. Because of this, they can be left empty in the WireTrnISOAdd request. Instead of focusing on the DestFinInstRtId element, you should direct your attention to the RecvFinInstRtId element. This represents the Instructed Agent and maps to the ISO 20022 element CdtrfTxInf.InstdAgt.FinInstnId.ClrSysMmbId.MmbId.

Our ISO 20022 solution does not support direct international wire transfers. SilverLake wires / DLW is designed strictly for domestic transactions. Therefore, institutions using this system must route international wires through a domestic correspondent bank, which handles the international leg of the transfer. In this scenario, the RecvFinInstRtId element should contain the routing number of the domestic correspondent bank. This is because the correspondent bank acts as the immediate recipient within the U.S. clearing system and is responsible for forwarding the funds to the final international destination.

To specify the final international agent, use the InstBIC and InstRtId elements within the WireAgentInfoArray.WireAgentRec.WireFinInstInfo complex. Both elements should be populated with the SWIFT BIC of the international financial institution, and the WireAgentInfoArray.WireAgentRec.WireAgentType element should be set to CrAgent. This ensures the clearing system can correctly identify and route the wire to its intended international destination.

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.

Question: I am getting an error indicating WITRCHGUSR and WITRENTUSR cannot be blank. I cannot find either of these fields on the mapping spreadsheet. Please assist.

Answer: Within the jXchangeHdr the AuditUsrId and AuditWsId elements must be populated for the WireTrnISOAdd API.

Question: What is the defined limit on the # of CrAgentInstrInfoArray.InstrRec that can be sent? Researching the associated SvcDictSrch, JH online documentation, and WSDL info does not show a limit.

Answer: Jack Henry supports the Instruction for Creditor Agent elements, which are allowed to repeat 2 times. It will write to the Core DB into file WITAGTCI/WITCICODE - Creditor Agent Instruction Code and WITAGTCI/WITCIINFO - Creditor Agent Instruction Info. This is compliant with the FRB regulatory requirements. • Xpath = WireTrnISOAdd/WirePmtTypeInfo/CrAgentInstrInfoArray/InstrRec/WireInstrCode. • Xpath = WireTrnISOAdd/WirePmtTypeInfo/CrAgentInstrInfoArray/InstrRec/WireInstrInfo.

Question: What ODI files are available in relation to ISO 20022?

Answer: The following extracts are available. See the ODI page for more information.

• WireAgent: Contains Financial Institution-level info including the Creditor, Debtor, and Intermediate financial institutions performing a wire transfer.

  • The WireAgentSeq column is the unique key for each transaction, and will be used to join the data in these extracts (see FornKey and SrcKey columns).
  • FornKey is the same unique ID, and SrcKey is a composite of that ID followed by agent type.

• WireEntity - Contains account-level information about ISO 20022 wires transactions.

  • FornKey is the same unique key as listed above.
  • SrcKey is a combination of that value, plus Creditor or Debtor.

• WireEntityInst - Contains account-level information plus additional info about the institution.

  • FornKey is the same unique key as listed above.
  • SrcKey is a combination of that value, plus WireEntityType and a sequence number.

• WireISOHistDetail - Contains specific ISO wires transaction history, including customer, account, transaction, and FI information.

  • The WireCustId column is the same unique transaction key as above, as is SrcKey.
  • There is no FornKey currently in WireISOHistDetail.

  ---

Question: We are constructing an ISO Wire Workflow, but we happen to notice the WireAnlysCode variable to be different within ISO compared to FAIM. FAIM is a single character string, and ISO is up to a three character integer.

Answer: The one being referred to in ISO is the actual counter that is bumped if the account is on EAA, which can be up to 3 positions. The other one being referred to in FAIM is the canonical code to determine ‘how’ to charge.

Question: In the WireTrnISOAdd request, the OrignFinInstRtId and DestFinInstRtId elements were left blank. However, the WireTrnInq response for that same wire includes values for those elements. What is the reason for this discrepancy, and what process or logic is populating that data in the response?

Answer: The OrignFinInstRtId and DestFinInstRtId fields are hardcoded to return predefined values. These fields are not actively used by the business service logic. Instead, a global ABA routing number is applied—either for Jack Henry (611363259) or the Federal Reserve (021151080)—based on whether the wire is incoming or outgoing.

Question: Regarding the updated ISO 20022 format, it requires a Country Code. Currently, Jack Henry’s foreign address format does not include a specific field for this requirement. There is a “Foreign Country” field that allows free‑text input, but ISO 20022 mandates a standardized country code in the new API.

Answer: For the WireTrnISOAdd API, Country Codes are mapped to the CntryType elements. While CntryType is a free‑form element, the contents are validated by the core business service against the ISO 3166 standard country abbreviations. Using an invalid code results in the following error:

ErrDesc - Invalid Country

Question: We’re looking for a list of FAIM tags to ISO20022 elements. Does that exist?

Answer: The Fed has provided several documents detailing FAIM to ISO 20022 mappings, but the most relevant is the FAIM TAG to ISO20022 Data Elements document.