Wires postal address update (November 2026)

overview the federal reserve is updating the fedwire funds service to require structured postal addresses, effective november 16, 2026 this change aligns fedwire with the iso 20022 international messaging standard instead of three unstructured address lines, you will provide address components in clearly defined fields this ensures address information is transmitted more clearly and accurately, reducing errors and manual intervention across the payment chain action required all cross river partners must update their integrations by october 20, 2026 to allow sufficient time for testing before the federal reserve's go live date what's changing federal reserve timeline milestone date testing opens may october 2026 fedwire go live date november 16, 2026 cross river timeline milestone date status sandbox environment available now ✅ available for testing partner integration deadline october 20, 2026 ⚠️ required federal reserve go live november 16, 2026 upcoming how cross river is implementing this change the new postaladdress object we're adding a new postaladdress object to replace the current address1 , address2 , and address3 fields instead of this { "address1" "123 main street, suite 400", "address2" "new york, ny 10001", "address3" "" } use this { "postaladdress" { "adrline1" "123 main street", "adrline2" "suite 400", "city" "new york", "state" "ny", "postalcode" "10001", "country" "us" } } required fields field description example adrline1 street address (up to 35 characters) "123 main street" city city or town name (up to 35 characters) "new york" country two letter country code (iso 3166 1) "us" optional fields field description example adrline2 additional address info (up to 35 characters) "suite 400" state state, province, or region (up to 35 characters) "ny" postalcode postal or zip code (up to 16 characters) "10001" future enhancement character limits for adrline1 and adrline2 expand from 35 to 70 characters in a future release to match the federal reserve's full capacity where this applies the new postaladdress object is used anywhere you currently provide address information in wire transfer requests wire transfer docid\ mc0d1w1u80umazo85meiz you must provide addresses for originator the party sending the wire originator financial institution the bank sending the wire (if different from originator) beneficiary the party receiving the wire beneficiary financial institution the receiving bank intermediary financial institution any intermediary banks (optional) drawdown request docid\ dorha8h1ksr9 m ct3ac addresses are required for originator (creditor) the party requesting funds originator financial institution the requesting bank drawdown debit account holder (debtor) the party from whom funds are drawn beneficiary financial institution the debit account holder's bank drawdown response docid\ coz5emucrfzlgzd59rdna addresses are required for originator the party responding to the drawdown request webhook events wires docid\ oa3cg apkn 510vpq2yye all webhooks containing wire transfer information will also include the new postal address information for all parties in the transaction (as there are no embedded objects in webhooks, the new fields are listed migration guide step 1 review (now) review this documentation and understand the new postaladdress structure identify all systems that send wire transfer requests or process wire webhooks note that three fields are now required street address, city, and country step 2 update your code (now must be complete by october 20, 2026) replace address1 , address2 , address3 with the postaladdress object ensure you provide all three required fields adrline1 , city , country update webhook handlers to read from postaladdress instead of address1/2/3 add validation to ensure required fields are present before sending requests step 3 test in sandbox (now) use cross river's sandbox environment to test your changes test all wire transfer types standard transfers, drawdown requests, drawdown responses verify webhooks are processed correctly with the new format test with both domestic (us) and international addresses step 4 deploy to production (by october 20, 2026) deploy your updated integration to production monitor for any validation errors confirm webhooks are processing correctly step 5 monitor after go live (november 16, 2026) monitor for any fedwire rejections related to address formatting ensure payments continue to process successfully transition period during transition (now through november 16, 2026) cross river accepts both old and new formats you can use the old format for some parties and the new format for others in the same request we recommend migrating all parties to the new format as soon as possible after november 16, 2026 the federal reserve will reject wire transfers using the old unstructured format payments fail after november 16, 2026 all partners must use the new postaladdress format common questions q can i continue using address1, address2, address3 during the transition? a yes, cross river supports both formats until november 16, 2026 however, after that date, the federal reserve will reject wires with the old format q what if my address doesn't fit in 35 characters? a cross river will expand the character limit to 70 characters in a future release for now, abbreviate as needed or split the address across adrline1 and adrline2 q what if i only have street address and city, but no state or postal code? a that's fine only adrline1 , city , and country are required the adrline2 , state , and postalcode fields are optional q how do i format international addresses? a use the appropriate 2 letter country code (e g , "gb" for united kingdom, "ca" for canada) and format the address according to that country's conventions the state field can be used for provinces or regions q what are valid country codes? a use iso 3166 1 alpha 2 codes (2 uppercase letters) examples us (united states), gb (united kingdom), ca (canada), de (germany), fr (france), jp (japan) see the full list here https //en wikipedia org/wiki/iso 3166 1 alpha 2 q can i test the new format now? a yes! our sandbox environment is already live and supports the new format we encourage you to begin testing as soon as possible api changes request examples wire transfer request before (current format) { "accountnumber" "1234567890", "businessfunctioncode" "ctr", "receiverroutingnumber" "021000021", "amount" 1000000, "purpose" "invoice payment", "originator" { "idcode" "d", "identifier" "1234567890", "name" "acme corporation", "address1" "456 business blvd", "address2" "new york, ny 10002", "address3" "" }, "beneficiaryfi" { "idcode" "d", "identifier" "021000021", "name" "jp morgan chase bank", "address1" "270 park avenue", "address2" "new york, ny 10017", "address3" "" }, "beneficiary" { "idcode" "d", "identifier" "9876543210", "name" "example llc", "address1" "789 commerce ave", "address2" "los angeles, ca 90001", "address3" "" } } after (new format required by october 20, 2026) { "accountnumber" "1234567890", "businessfunctioncode" "ctr", "receiverroutingnumber" "021000021", "amount" 1000000, "purpose" "invoice payment", "originator" { "idcode" "d", "identifier" "1234567890", "name" "acme corporation", "postaladdress" { "adrline1" "456 business blvd", "city" "new york", "state" "ny", "postalcode" "10002", "country" "us" } }, "beneficiaryfi" { "idcode" "d", "identifier" "021000021", "name" "jp morgan chase bank", "postaladdress" { "adrline1" "270 park avenue", "city" "new york", "state" "ny", "postalcode" "10017", "country" "us" } }, "beneficiary" { "idcode" "d", "identifier" "9876543210", "name" "example llc", "postaladdress" { "adrline1" "789 commerce ave", "city" "los angeles", "state" "ca", "postalcode" "90001", "country" "us" } } } webhook example as partners and other fedwire users adopt the new structured postal address elements the following additional fields can be populated potentially before and after november 2026 originator country originator state originator postalcode originator city beneficiary country beneficiary state beneficiary postalcode beneficiary city in addition, the following webhook fields will continue to exist and be populated as follows originatoraddress1 – populated from originator address1 if present or originator postaladdress adrline1 if present originatoraddress2 – populated from originator address2 if present or originator postaladdress adrline2 if present originatoraddress3 – populated from originator address3 if present otherwise not populated (null) beneficiaryaddress1 – populated from beneficiary address1 if present or beneficiary postaladdress adrline1 if present beneficiaryaddress2 – populated from beneficiary address2 if present or beneficiary postaladdress adrline2 if present beneficiaryaddress3 – populated from beneficiary address3 if present otherwise not populated (null) { "eventtype "wire payment processed", "eventid" "evt 12345", "timestamp" "26 06 30t10 12 130z" { "paymentid" "9d63d00b ba29 4102 9298 b4790091c7e4", "accountnumber" "358449449133", "direction" "outbound", "imad" "20260630mfp00057000347", "omad" null, "paymenttype" "transfer", "purpose" "coinbase wallet usd withdrawal", "amount" "100", "clientidentifier" null, "originatingfiname" "cross river bank", "originatingfiidentifier" "021214891", "originatorname" "coinbase inc", "originatoridentifier" "358449449133", "originatoraddress1" "100 pine street", "originatoraddress2" "suite 1250", "originatoraddress3" "san francisco ca 94111 us", "beneficiaryfiname" "cross river bank", "beneficiaryfiidentifier" "021214891", "beneficiaryname" "synth fedwire payin", "beneficiaryidentifier" "000043400588", "beneficiaryaddress1" "123 main st apt 4b", "beneficiaryaddress2" "arvada co 80001", "beneficiaryaddress3" "us", "beneficiaryreference" "rtl 7w4624tz", "senderreference" "75f1novn045", "originatortobeneficiary1" null, "originatortobeneficiary2" null, "originatortobeneficiary3" null, "originatortobeneficiary4" null, "coretransactionid" "6eb8c8a6 9145 485b 9513 b4790091c7e4", "senderroutingnumber" "021214891", "originalpaymentid" "9d63d00b ba29 4102 9298 b4790091c7e4", "originatorcountry" null, "originatorstate" null, "originatorpostalcode" null, "originatorcity" null, "beneficiarycountry" null, "beneficiarystate" null, "beneficiarypostalcode" null, "beneficiarycity" null } } during migration all webhook address information will continue to be provided in the old format while the new structured postal address elements will be provided with null values validation rules the api validates the following rule result if not met adrline1 is required, max length 35 request rejected (400 bad request) city is required request rejected (400 bad request) country is required request rejected (400 bad request) country must be a valid 2 letter code (e g , us, gb, ca) request rejected (400 bad request) adrline2 cannot exceed 35 characters, cannot be provided unless adrline1 is provided request rejected (400 bad request) cannot use both old format ( address1/2/3 ) and new format ( postaladdress ) for the same party request rejected (400 bad request) important you cannot use both the old format (address1/2/3) and the new format (postaladdress) for the same party in a request choose one format per party related resources support for questions or assistance with this migration, contact your cross river representative