IMPORTANT: Wires updates

transition from fedline advantage® to fedline direct® cross river has transitioned from fedline advantage® (fla) to fedline direct® (fld), enhancing our wire processing capabilities key benefits of fedline direct (fld) extended processing hours to improve flexibility and efficiency faster turnaround times with our direct access to fedwire greater reliability via fedline direct’s robust infrastructure processing window improvements wires can now be processed from 9 00 pm (previous day) through 7 00 pm (current business day) note that if a wire is placed on hold, it must be manually cleared by our internal team, who are available from 9 00 am – 5 00pm et (monday–friday) wire requests received after 3 00 pm et may be processed on the next business day while we work to release as many as possible on the same day, we cannot guarantee that all wires will be reviewed and cleared up until 5 00 pm et iso 20022 messaging standard as part of the industry wide transition to the iso 20022 messaging standard, fedwire has adopted this standard on july 14th, 2025 migration to iso 20022 enhances financial messaging, improves data quality, and increases efficiency across payment networks during cross river's transition to the iso 20022 standard we will maintain existing functionality the older messaging standard will be mapped to iso 20022, with all changes occurring in the backend as primarily technical updates these backend changes will not impact partner facing functionality , ensuring that transaction initiation and processing remain consistent within our system read more about it https //www frbservices org/resources/financial services/wires/iso 20022 implementation center?campaignid=21251711917\&adgroupid=161928101459\&keyword=fed%20iso%2020022\&matchtype=e\&network=g\&device=c\&adposition=\&gad source=1\&gclid=cj0kcqia 5a9bhcbarisacwmkj7tc0ekfvls6x3vmlsgaopgzrxe4oflunykip2djpfiqk8pakfhve4aal7realw wcb what you need to know while cos functionality will largely remain unchanged, we are managing iso 20022 compatibility in the backend to ensure a seamless transition with minimal impact to partners while the message format will be updated, we will provide clear guidance to help ensure accurate data input and prevent errors we are introducing docid utngko5vrx e3rob id8 due to the migration we have updated the docid\ mm yqgvcwntsgdlnnx og to reflect these changes here are a few examples of how transactions will be handled post migration ctrs (customer transfers) → will continue to be processed as ctrs, though they will be converted to pacs 008 in the backend svcs (service transfers) → will retain their current functionality with the following mappings svc 1090 → mapped to camt 110 (investigation requests) and camt 111 (investigation responses) in the backend svc 1001 and 1007 → mapped to camt 056 (return requests) in the backend drcs (drawdown requests) → will still be processed as drcs, though they will be converted to pain 013 in the backend drws (drawdown payments) → will remain drws, with responses to incoming drawdown requests handled as follows negative responses → mapped to pain 014 in the backend positive responses → mapped to pacs 008 in the backend we will also be making updates to the docid\ vrbjrchnvqf5kqizxzloe and introducing the docid\ qkw9psknysstzpjqbb3k8 feature , which will take effect on july 14th, 2025 summary of changes include the request service message button will be relabeled respond to return request this option will be used exclusively to respond to incoming return requests (svc 1001 or svc 10077 / camt 056) you can initiate all returns (full and partial) using the reverse wire option this provides a simplified and consistent way to process returns the new respond to service message feature will support replies to non return related service messages , such as investigation requests (svc 1090 / camt 110) note the following fields have been expanded under iso for incoming wires only these expanded lengths are not applicable to outgoing wires while not all fields may be visible to partners via webhooks, they are supported within the system beneficiary reference – 35 characters originator to beneficiary 1 – 140 characters originator to beneficiary 2 – 140 characters sender reference – 35 characters originating fi name – 140 characters originator name – 140 characters intermediary fi name – 140 characters beneficiary fi name – 140 characters beneficiary name – 140 characters if you have any questions or need further assistance, reach out to your relationship manager