Wire Services FAQ

Q: Does the customer name and originator name need to be the same value?

A: Customer info (in general) is the info that is validated against the core (ie, customer found for account number, etc.), whereas Originator info is sent as-is on outgoing FAIM tags. By convention, these will typically be the same, but they don’t have to be.

Q: Is Notes field for logging purpose only or is it transferred to recipient side?

A: The Notes field is for internal use only. This field will not be used to populate any Fedwire-based fields for purposes of transmitting a wire . Notes may be maintained only by the person who added them, and a wire may have multiple note entries.

Q: Do we need to populate originator fields (OriginatorName, OriginatorAddress, OriginatorReference, OriginatorIdType, OriginatorBeneficiaryRemarks) when calling API endpoint to add a Wire?

A: The need for these originator fields will vary based on the type of wire being sent and is ultimately governed by the Fedwire specification. Some of these fields (Originator Name, Originator Address, Originator Id Type, and Originator Reference) are considered part of the Originator tag (5000). For most wires, the Originator (5000) tag is considered optional, but for some (ex: CTP, DRW), Fedwire requires Originator information.

The Originator-to-Beneficiary Remarks fields are considered part of Fedwire’s 6000 tag, and are considered optional for wires messages.

Q: Please provide a sample json input to update status of a wire to “Canceled”.

A: To cancel a wire, modify the step-state to Process-Canceled (step Process / state Canceled):

status": {
        "processStep": "Process",
        "state": "Canceled",
        "lastChangedBy": "api-user",
        "timeDate": "2023-09-14T16:13:10.639Z",
        "errors": []
    }

The transactions/{WireId}/status POST operation can be used to request this state change.

Q: What fields are used to determine a duplicate wire?

A: An outgoing wire is considered a duplicate if the fields Amount, Originator Identifier, and Beneficiary Identifier all match on any wire that has been sent that business day or is scheduled to be sent that business day.

Please define the following fields: 

• accountAnalysisTransactionCode – An account is considered “on analysis” when transactions are accumulated in a billing period to be used in setting fees. The account analysis transaction code is used to communicate a specific analysis type used in this accrual. The Jack Henry Wires product interfaces with the Episys (Symitar) Member Business Services (MBS) Account Analysis module for commercial accounts and will communicate the transaction counts using the accountAnalysisTransactionCode for Wire Transfers. The actual calculation of the fees happen at Symitar.
• type/subtype – This is part of the Fedwire specification. Along with the business function code, these specify the type of Fedwire message to be created. The JH Wires user interface guides selection of type and subtype so that only valid values may be selected, and the Fedwire specifications can be considered a complete guide.
• productDescription – This field is part of customer identification, and refers to the type of account.
• remittanceTransferRule and isRemittanceTransferRule – There are a set of fields that apply to wires indicated to be foreign wires. When selected, this field will enable additional fields in the user interface to collect remittance information.
• sourceType – This field is used to indicate a category or label for API transactions. Under the guidance of developer relations, an API user sets this value to distinguish one type of API traffic from another, where applicable.
• taxId – For non-customer wires, this is an identifying field used to verify the wire participant.
• productDescription - (duplicate field)
• isRemittanceTransferRule – see remittanceTransferRule.
• sourceStatuses - This structure is provided for an integrating system to record status changes from the external system. Within JH Wires, this is carried for documentation purposes only.
• effectiveDate – This date can be changed by an integrating system, and is provided as a user-defined value. JH Wires does not modify processing based on this value at present
• transferDate – This date is the processing date (system date) of the FI. The system date has no time component, and it changes when End-of-Day is run at the FI. This value populates in a wire record at the time a wire is added, and will update to the date the wire is sent in cases of next-day wires.