Resolved - INC215862 - outgoing\incoming wires Central 1 unable to send or receive

Update timeline

1. investigating Jan 27, 2026, 04:15 PM UTC

   Central 1 continues to investigate technical issues with wires. We are still unable to process any incoming or outgoing wires. Wires can still be created and reviewed in PSD-Wires; they will remain in pending status. Technical teams are actively working to restore full service and will provide an update by 9 a.m. PT (12 p.m. ET). Central 1 – [email protected] - 1.888.889.7878, press 1

2. investigating Jan 27, 2026, 05:13 PM UTC

   Central 1 wires continue to experience technical issues with outgoing and incoming wires. Wires can still be created and reviewed in PSD-Wires; they will remain in pending status. Technical teams are actively working to restore full service and will provide an update by 10 a.m. PT (1 p.m. ET). Central 1 – [email protected] - 1.888.889.7878, press 1

3. resolved Jan 27, 2026, 06:04 PM UTC

   This incident is now resolved. Central 1 can process all incoming and outgoing wires. Central 1 – [email protected] - 1.888.889.7878, press 1

4. postmortem Feb 20, 2026, 10:30 PM UTC

   On January 27, Central 1 experienced a wire processing disruption affecting both incoming and outgoing wires across all currencies. Wires could be created; however, transactions became stuck in downstream processing queues and were not completing end-to-end. The disruption began at 4:32 a.m. PT and lasted approximately four hours. The issue followed firewall maintenance performed by Fiserv, which caused a loss of TCP connection \(Transmission Control Protocol\) state between Central 1 and our vendors queuing service. Although Fiserv restarted their firewall, Central 1 was required to manually restart our service APIs and related integration components before wires successfully resumed flowing through the SWIFT gateway. We apologize for the disruption and appreciate our clients’ patience while service was restored. We also acknowledge that earlier clarity in our monitoring and recovery procedures would have reduced recovery time on the first occurrence. **Point of Failure:** The root cause in both incidents was a TCP connection between Central 1 and Fiserv following firewall maintenance activities. The Central 1 connection does not currently recover gracefully when a firewall loses its TCP connection state table mid-session. When this occurs, the TCP socket becomes stale and remains in a “frozen” state. The application appears healthy, but the Message Queue session no longer processes messages. This results in transactions accumulating in queues and cascading downstream failures until manual restart API gateway components forces re-establishment of the connection. Contributing factors included lack of vendor notification prior to firewall maintenance \(January 27\), absence of a documented recovery SOP \(Standard Operating Procedure\), and monitoring alerts that were component-level but did not clearly indicate end-to-end client impact. **PRB011663 - Actions & Lessons Learned** The incident highlighted the need to monitor and declare wires health based on end-to-end processing, not individual component status. While alerts were generated, there was no single authoritative “wire health” signal or clear green criteria to determine recovery. * PTASK0010482 - MQ Connector auto-recover enhancement – End of Q1 2026 * PTASK0010483 - Fiserv change communication notification improvements – End of Q1 2026 * PTASK0010486 - Alerting Enhancements – End of Q1 2026 * PTASK0010484 - SOP for the starting and stopping of all MuleSoft applications/playbook improvements – End of April 2026 * PTASK0010485 - Wires Flow Training – End of April 2026 We apologize for the delay this caused to your operations and your members. If you have any questions or would like additional detail, please contact Support. Central 1 – Support | [[email protected]](mailto:[email protected]) | 1.888.889.7878, press 1