Wires API update

wires api updates as part of the industry wide transition to iso 20022, fedwire has adopted a new messaging standard on july 14, 2025 this migration enhances financial messaging, improves data quality, and increases efficiency across payment networks new api validations and default values as part of our wires iso 20022 implementation, we have added new api validations across different wire message types these validations ensure compliance, ensure data accuracy, and improve processing accuracy below is a breakdown of the new validations by message type, along with default values applied if certain fields are not populated 1\ originate customer transfers (pacs 008) endpoint post /v1/payments validation rules originator requirement if originator is null or empty, the system will use the configured account/product originator if the configured account/product originator contains any of the following id codes, the request will be rejected "u" (chips identifier) "c" (chips participant) "f" (fed routing number) error message account or product configuration error intermediary fi and beneficiary fi uniqueness if both are specified with the same identifier, the request will be rejected error message intermediaryfi and beneficiaryfi cannot be identical beneficiary validation must be validated as a person or organization errors follow the person/organization validation rules beneficiary fi validation must be validated as a financial institution errors follow the financial institution validation rules intermediary fi validation must be validated as a financial institution errors follow the financial institution validation rules default values beneficiary fi (if not explicitly provided — no id code or identifier specified) (note effective starting july 14, only when iso format is in use) derived from the receiver routing number id code "f" identifier routing number name participant’s customer name address1 participant’s city and state 2\ originate drawdown requests (pain 013) endpoint post /v1/payments/corporate drawdown requests validation rules beneficiary fi and intermediary fi not allowed if either field is populated, the request will be rejected error message {entityname} not available with iso format 3\ originate drawdown responses (pain 014) endpoint post /v1/payments/{id}/drawdown responses validation rules originator bic format if the originator id code is "b" (swift bic code) and the identifier is not in valid bic format, the request will be rejected error message originatoridentifier is not a valid bic default values beneficiary fi (if not provided in original drc) (note effective starting july 14, only when iso format is in use) derived from the receiver routing number id code "f" identifier receiver’s routing number name receiver’s customer name address1 receiver’s city and state originator fi (if not provided in original drc) (note effective starting july 14, only when iso format is in use) derived from the sender routing number id code "f" identifier sender’s routing number name sender’s customer name address1 sender’s city and state 4\ reverse payment (pacs 004) endpoint post /v1/payments/{id}/reversals validation rules reversible payment types only (note effective starting july 14, only when iso format is in use) if the referenced payment is not a transfer or drawdown response, the request will be rejected error message payment type cannot be reversed default values originator fi (if not provided in original payment customer transfer or drawdown response) (note effective starting july 14, only when iso format is in use) derived from the sender routing number of the original payment transfer or drawdown response id code "f" identifier sender’s routing number name sender’s customer name address1 sender’s city and state 5\ service messages endpoint post /v1/payments/{id}/service message validation rules type code defaulting if the type code is not specified, it will default to 1090 – customer transfer service message automatic conversion of type code if the type code is 1090 (customer transfer service message) or 1690 (bank transfer service message), and the referenced payment is an inbound investigation request , the type code will be automatically converted to 1099 – customer transfer investigation response 1699 – bank transfer investigation response service message reclassification service messages in the faim model have been replaced with iso equivalent message types faim type codes are mapped to iso messages as follows investigation requests (camt 110) — faim type codes 1090 , 1690 referenced payment must be investigable if the referenced payment is not one of the following pacs 008 – customer credit transfer pacs 004 – payment return pain 013 – drawdown request pain 014 – drawdown response error message payment type cannot be investigated referenced payment must be transmitted if the referenced payment does not have an imad (i e , it has not been confirmed as transmitted), the request will be rejected error message cannot investigate untransmitted payments service message line requirement if all servicemessageline fields are null or empty, the request will be rejected error message at least one line of text is required for the requested type code investigation responses (camt 111) — faim type codes 1099 , 1699 referenced payment must be an investigation request if the referenced payment is not an investigation request, the request will be rejected error message source payment is not an investigation request service message line requirement if all servicemessageline fields are null or empty, the request will be rejected error message at least one line of text is required for the requested type code return requests (camt 056) — faim type codes 1001 , 1007 referenced payment must be a transfer if the referenced payment is not a customer transfer or drawdown response, the request will be rejected error message payment type cannot be reversed referenced payment must be outbound if the referenced payment was not an outbound payment, the request will be rejected error message direction not outbound service message line requirement if all servicemessageline fields are null or empty, the request will be rejected error message at least one line of text is required for the requested type code 6\ person/organization validations name or identifier required both cannot be null/empty error message {entityname} must include either a name or an identifier allowed id codes must be one of "1" (passport) "2" (tin) "3" (driver’s license) "4" (alien registration) "5" (corporate id) "9" (other id) "b" (swift bic) "d" (demand deposit account) error message {entityname} idcode must be a valid customer code name requirement for non bic if id code is not "b" or "t" and name is null/empty error message {entityname} must include a name if idcode is not a bic bic format if id code is "b" or "t", identifier must be a valid bic error message {entityname} identifier must be a valid bic format 7\ financial institution validations name or identifier required both cannot be null/empty error message {entityname} must include either a name or an identifier allowed id codes must be one of "u" (chips identifier) "c" (chips participant) "d" (demand deposit account) "f" (fed routing number) "b" (swift bic) "t" (swift bic or bei) error message {entityname} idcode must be a valid financial institution code name requirement for non bic if id code is not "b" or "t" and name is null/empty error message {entityname} must include a name if idcode is not a bic address1 requirement for non bic if id code is not "b" or "t" and address1 is null/empty error message {entityname} must include an address if idcode is not a bic bic format if id code is "b" or "t", identifier must be a valid bic error message {entityname} identifier must be a valid bic format routing number format if id code is "f" and identifier is invalid error message {entityname} identifier is not a valid fed routing number