SASE Solutions Supporting Legacy Financial Application Protocols

We'd first recommend that you build a complete picture of existing legacy protocol flows (including source and destination addresses, ports and current paths). For each flow, document key attributes:

• Typical and peak bandwidth
• Latency budgets
• Encryption status
• Session duration
• Regulatory constraints

Map which transport types are currently in use, including MPLS, private leased lines, data centre cross-connects and internet VPNs. This allows you to segment flows by criticality and by suitability for early migration.

With a clear inventory, deploy SD-WAN edges alongside existing routers in a parallel-run model, integrating SD-WAN overlays with underlay circuits and validating reachability.

For each legacy protocol, create custom application signatures based on the discovery data, then define SLA classes in line with the tolerances identified:

• Loss thresholds
• Latency ceilings
• Jitter limits

You should then test application-aware routing using lab or non-production traffic, simulating link failures, brownouts and congestion to tune failover thresholds and path-selection policies. We'd also recommend validating packet replication and FEC settings for flows that will later carry FIX or ISO 8583 in production.

Once the SD-WAN fabric is stable, begin enabling SASE security services. A common pattern is to start with the following for internet-bound and SaaS traffic, keeping legacy financial protocols on existing paths during early stages:

• Secure Web Gateway (SWG)
• Cloud Access Security Broker (CASB)
• Firewall-as-a-Service (FWaaS)

This builds confidence in the cloud enforcement model without putting critical protocols at risk.

As familiarity grows, add Layer 3/4 ZTNA controls for legacy protocol access, using device and user identity to restrict which endpoints can initiate TN3270, MQ, or FIX connections.

You should then configure TLS inspection bypass lists for flows that must not be decrypted (such as SWIFT connections and card scheme links) and validate that overlay encryption does not breach latency thresholds for time-sensitive flows (using synthetic tests).

The final phase shifts legacy protocol traffic from MPLS and private circuits onto the SASE overlay, starting with the least sensitive flows. We'd recommend the following to be the first you migrate:

• AS2 and EBICS traffic (batch-oriented and latency-tolerant, provided that S/MIME and TLS requirements are met)
• TN3270/TN5250 and MQ once early migrations are stable
• ISO 8583, then FIX as the final workloads, retaining MPLS as a backup throughout

For the most critical flows, enable packet replication or FEC and verify behaviour under real-world conditions, including partial outages and brownouts. You should monitor performance and error rates closely, correlating them with SASE and SD-WAN telemetry to fine-tune policies. Only once all stakeholders agree that performance, stability and compliance obligations are fully met, should you consider decommissioning legacy access routers and circuits for those protocols.

In most cases, yes, but not immediately and not without careful preparation. MPLS provides deterministic routing, strict SLAs, and no shared-medium contention. Modern SD-WAN overlays can match or exceed those characteristics for many workloads using BFD-based path monitoring, SLA class steering, and packet replication across dual underlays. The challenge is that legacy financial protocols such as FIX and ISO 8583 have very tight latency and loss budgets that leave little room for error during the transition. A phased approach that keeps MPLS as a fallback while progressively migrating lower-sensitivity flows is the safest route. Full replacement of MPLS for the highest-criticality flows such as FIX and SWIFTNet is achievable, but it requires thorough testing and performance validation under real-world conditions before cutover.

DORA Article 11 sets expectations around encryption of data in transit for critical ICT services, and the associated regulatory technical standards reinforce the principle that all sensitive data exchanged across networks should be protected. In practice, this means that legacy protocols which transmit data in plain text, such as unencrypted TN3270 or SNA, need to be wrapped in a secure transport layer. SASE overlays using IPsec can satisfy this requirement without changing the application itself. For protocols that already use application-layer encryption, such as MQ over TLS or EBICS over HTTPS, the SASE overlay provides an additional network-level layer. Firms should document their encryption approach for each protocol flow as part of their ICT risk management framework and be prepared to demonstrate this to regulators on request.

TLS inspection works by acting as a man-in-the-middle, decrypting traffic, inspecting the payload, and re-encrypting it before forwarding. For many web and SaaS applications this is acceptable, but several legacy financial protocols explicitly prevent it. SWIFTNet connections use SWIFT's own PKI with certificate pinning, meaning that any attempt to substitute the certificate during inspection causes the connection to fail. Card scheme links frequently have similar restrictions. Beyond technical constraints, there are regulatory and contractual reasons to avoid inspection of these flows: SWIFT's Customer Security Programme (CSP) and card network security standards impose strict controls on how traffic may be handled. The practical approach is to configure explicit TLS inspection bypass rules for these flows, classify them using IP, port, and certificate metadata instead, and apply compensating controls such as strict access policies and network segmentation.

Traditional ZTNA was designed for web applications accessed through a browser, where identity is checked at the application layer before a session is established. FIX and TN3270 do not work this way; they rely on custom clients, fixed TCP connections, and session persistence that HTTP-centric access proxies can disrupt. To support these protocols, SASE platforms expose Layer 3 and Layer 4 ZTNA modes, where access control is enforced based on the identity of the device or user making the connection, tied to an agent running on the endpoint. The agent verifies identity and device posture before the network-level TCP connection is permitted to reach the target server. This means only authorised and healthy devices can initiate FIX sessions to a trading engine or TN3270 sessions to a mainframe, without any HTTP proxy in the path. The trade-off is that this approach provides less granular application-layer inspection than Layer 7 ZTNA, so it needs to be complemented by strong network segmentation and logging.

This is one of the most operationally significant questions for financial services SASE deployments. Protocols such as TN3270, IBM MQ, and FIX maintain TCP sessions that may run for hours or even days. If the SD-WAN fabric performs a failover to a secondary path, the behaviour depends on how the platform handles stateful session continuity. Some SD-WAN solutions perform hitless failover by maintaining a shared session state across tunnels, allowing the TCP connection to survive a path change transparently. Others perform a hard failover that resets the TCP session, forcing the application to reconnect. For trading systems and mainframe applications, a forced reconnect can cause significant disruption, and some applications have reconnect logic that is not designed for frequent re-establishment. When evaluating vendors, you should specifically ask for documented failover behaviour for stateful TCP sessions and request test evidence, not just marketing claims. The answer should include the failover time, whether sessions are preserved or reset, and how this changes under different failure scenarios such as link loss versus edge device failure.

QoS markings such as DSCP can be applied within your own network and within the SD-WAN overlay tunnels, but once traffic exits onto the public internet those markings are typically ignored or overwritten by ISPs. This is one of the fundamental limitations of internet-based transport compared to MPLS, where QoS is honoured end-to-end. SD-WAN addresses this in two ways. First, by using multiple underlay circuits and intelligently steering FIX traffic to the circuit with the best current performance metrics rather than relying on QoS. Second, by using packet replication and FEC to compensate for loss rather than trying to prevent it through queuing. For the most latency-sensitive FIX environments, some organisations use dedicated low-latency internet or private connectivity options as the primary underlay for trading traffic, with the SD-WAN overlay providing the intelligence and failover capabilities. This preserves the performance characteristics of a private circuit while gaining the flexibility and cost benefits of SASE management.

Third-party hosted payment switches are common in the acquiring and processing space, and they introduce a specific routing challenge: you need low-latency, reliable connectivity to an endpoint you do not control. The preferred approach is to use a SASE platform with a point of presence close to the third-party data centre, or to establish a private connect or cross-connect arrangement where available. The SD-WAN edge at your premises then steers ISO 8583 traffic to the nearest PoP using SLA-based routing, and the platform manages the last-mile path to the payment switch. Where PoP proximity is not possible, packet replication across dual internet paths can significantly reduce the effective packet loss rate seen by the application. You should also confirm with your payment switch provider whether they have specific network requirements or approved connectivity methods, as card scheme certification and PCI DSS compliance can impose constraints on how the connection is established and monitored.