STH principles: secure messaging
The first important compliance milestone in the preparations for T+1 is approaching. According to ESMA's timeline, from 7 December 2026, the exchange of allocations and confirmations is expected to use electronic, standardised communication channels and international messaging standards. STH is ready to support the inter-institutional communication required for this transition.
Security, traceability and operational manageability were all key considerations in the design of STH. Below, we explain the architectural and business decisions through which STH supports market participants in their transition to T+1.
A shared connectivity model with STH
With STH, an institution connects to the service once and can use that connection to communicate with partners that have also joined the service. There is no need to maintain separate technical and operational solutions for each individual partner relationship.
In addition to connectivity, the service provides centralised logging, acknowledgements, monitoring, alerts, a predefined and standardised onboarding process, and professional support.
| Aspect | Partner-to-partner connections | STH connectivity model |
|---|---|---|
| Connectivity | Separate connection with each partner | A single connection to STH |
| Service provision | Required for every partner, potentially using different approaches | Not required; every partner connects to STH as a client |
| Operating rules | Defined separately for each partner, potentially using different approaches and interfaces | A shared connectivity model through a single user interface |
| Logging and statuses | Managed across multiple systems | Centrally traceable |
| Onboarding a new partner | Requires another individual implementation | The existing model can be reused |
| Support | Organised separately by participant | Centralised service-provider support |
| Cost structure | Implementation and operating costs incurred separately for each partner | Predictable service fee |
The value of STH therefore does not lie in introducing yet another data transfer technology.
It turns communication into a shared, supported service in which participants can apply the same connectivity and operating rules.
Data transfer is only the first step – the limitations of SFTP connections
During the preparations, SFTP may appear to many institutions as the quickest alternative to implement. It is a widely known and mature technology, and most financial institutions already have the expertise required to use it. However, implementing a modern SFTP connection aligned with DORA and the IT security expectations of the National Bank of Hungary (MNB) is not necessarily a simple task.
Such a connection also requires technical and organisational controls proportionate to the associated risks. These may include modern encryption algorithms, securely managed SSH key pairs and, where necessary, an additional authentication factor, IP-based access restrictions, key lifecycle management, logging and monitoring, as well as verification of file integrity using checksums. Implementing and continuously operating these controls may involve considerable IT administration and can also lead to workarounds on the user side.
As a data transfer technology, SFTP by itself ensures the secure transfer of files. Based on technical logs – provided the appropriate operational access and expertise are available – it is possible to determine whether a transfer was successful. However, it may not be possible to determine whether the receiving party processed the file, why it was rejected, or whether intervention is required. Detecting incoming messages, tracking processing statuses and errors, handling acknowledgements, and managing permissions within the organisation all require additional solutions. A bilateral SFTP connection between organisations does not provide these capabilities at the business-process level.
The missing functionality can, of course, be added through custom developments, scripts and supplementary applications. In that case, however, each partner connection must be designed, developed, tested and subsequently operated separately.
An SFTP-based solution can therefore easily lose its initial advantage of being quick and inexpensive to implement.
Modern APIs for data transfer – synchronous or asynchronous?
STH's messaging and retrieval interfaces are described by platform- and programming-language-independent OpenAPI specifications. These clearly define the endpoints, data structures, security requirements and possible responses.
When designing STH, we also evaluated webhook-based push APIs, Server-Sent Events (SSE), WebSockets and long polling as technology options commonly used in the market.
A webhook-based push API would require every participant to operate a continuously available and securely protected receiving endpoint. SSE and WebSocket, by contrast, use persistent connections initiated by the client: SSE is designed for one-way server-to-client event streams, while WebSocket supports bidirectional, real-time communication. These approaches are primarily advantageous when events occur frequently. For the discrete, asynchronous business messages handled by STH, however, reliable queuing, traceable delivery and the ability to acknowledge processing are more important than maintaining a continuous real-time connection. Persistent connections also require additional handling for reconnections, proxies, firewalls and scaling.
Based on these considerations, STH uses long polling. The client initiates an mTLS-authenticated HTTPS request, which returns immediately when a message arrives or when the configured timeout is reached. Messages that have not yet been retrieved remain in the STH server-side queue, allowing them to be retrieved later even if the recipient is temporarily unavailable. Message metadata and lifecycle statuses make interruptions, repeated retrieval attempts and controlled retransmissions traceable.
| Aspect | WebSocket | SSE | Long polling |
|---|---|---|---|
| Primary use case | Frequent, real-time interaction | Continuous event or data streams | Discrete, asynchronous messages |
| Compatibility with enterprise networks | May require additional proxy and firewall configuration | Persistent connections may be interrupted or buffered by intermediary devices | Easier to handle as standard HTTPS traffic |
| Sending and acknowledgements | Can be handled over a single channel, but requires a custom message protocol | A separate API is required for sending and acknowledgements | Can be handled through a unified REST API |
| Message queuing | Requires a separate server-side queue | Requires separate event storage and replay logic | Fits naturally with a central server-side queue |
| Temporary client unavailability | Requires reconnection and replay logic | Can reconnect automatically, but recovery of missed business events must be handled separately | The client can retrieve queued messages with its next request |
| Fit for the business use case | A more complex connection model than required | Less suitable due to its one-way nature and persistent connection | Well suited to queuing, repeated retrieval and traceable delivery |
STH as an operating model
In summary, designing STH was not simply about selecting a data transfer technology. The secure REST API, asynchronous message handling, server-side queuing, lifecycle statuses and centralised connectivity model together enable reliable and traceable communication between institutions.
These decisions are intended to ensure that participating institutions do not have to implement the same security, error-handling and operational solutions separately for every partner.
STH therefore not only supports preparations for the upcoming compliance milestone, but also provides a consistent long-term foundation for communication between securities market participants.
You can download the article in PDF format here.