Breaking Latency vs Throughput Limits

The financial services industry operates with a clear expectation: non-cash payments must be processed instantly and handled securely. Fast, reliable transactions are a core part of how banks and payment providers deliver customer service and maintain trust with their customers. 

Behind the scenes, this requires infrastructure to process very large volumes of transactions consistently and securely. Payment systems must handle continuous streams of requests without delays or failures, even during peak load. 

As a result, organizations operating in these environments aim to optimize two key metrics: Throughput - the number of transactions processed per unit of time, and latency - the time it takes for a single transaction to complete.  

Latency Limits Throughput 

In environments where financial institutions aim to scale their operations and handle growing transaction volumes, or anticipate increased demand, they require greater capacity to process transactions efficiently. 
When an application sends a large number of commands to a Payment Hardware Security Module (HSM), the system must support high throughput to process them efficiently. In a traditional request–response model, the application sends a command and waits for the response before issuing the next one.  

Send command → wait for response → send next command 

This waiting period reduces the rate at which commands can be sent. As a result, latency - the time between sending a request and receiving the response, directly limits the achievable throughput. 

Limiting Factors 

Several factors can limit performance within the traditional relationship between throughput and latency. 

• Distance between the application and the HSM 
  Communication between continents can be up to eight times slower compared to systems located closer together.
• Use of an existing TLS tunnel  
  Sending HSM commands over an already established TLS connection requires only a single round trip. In contrast, opening a new TLS connection for each HSM command may require around five round trips, resulting in roughly five times higher latency.
• Standard Load Balancer  
  Typically, the load balancer establishes a connection to the HSM only when the application connects to it, and all data is then transmitted over that single connection. To distribute the load across multiple HSMs, the application would need to establish a new connection for each command, which causes the load balancer to create a new TLS tunnel each time.
• Physical HSMs  
  Physical HSMs that operate just the standard amount of simultaneous connections. 
  What if commands could be sent without waiting for a response before issuing the next one? In such a model, the traditional dependency between latency and throughput would be broken, and latency wouldn’t be a limiting factor for the overall throughput.  
   

The Magic of Payment HSM Interface (PHI) 

The Payment HSM Interface (PHI) addresses these challenges by changing how applications interact with HSMs. 
Instead of waiting for each response, commands are streamed continuously over persistent, secure mTLS connections. This allows applications to send multiple commands in parallel without waiting for individual responses. 

The key effect is that throughput can scale dramatically without reducing per-command latency. Even if each command still takes 100 milliseconds, a system using PHI can process tens of thousands of commands per second, far beyond what traditional sequential or limited parallel connections allow. 

Comparison between Traditional and PHI Models 

Comparison between Traditional and PHI Models 

The PHI model effectively breaks the traditional link between latency and throughput, letting systems scale HSM transaction volumes without redesigning networks for ultra-low latency. 

Enabling High-Volume Payment Processing Without Latency Constraint  

By separating throughput from latency, PHI allows financial systems to handle massive volumes of transactions securely and reliably. Applications no longer need to open hundreds of connections or attempt to lower latency for each command. Instead, commands can be processed continuously, HSM capacity is better utilized, and systems can meet real-time payment requirements without compromising security or availability. 

In practice, PHI provides a practical, scalable interface for modern payment infrastructures. It addresses the dual pressures of high transaction volume and strict timing requirements.  

Utimaco’s Payment Solutions as a Service Solution  

PHI is offered through Payment HSM as a Service, part of Utimaco’s Trust as a Service portfolio of cloud-hosted, fully managed cybersecurity solutions. 

This service provides access to fully managed, PCI PIN-certified Payment HSMs hosted by Utimaco in secure, certified data centers. It eliminates the need for customers to invest in physical hardware, secure facilities, or management personnel, while also reducing the operational burden of compliance, audits, and ongoing support. 

The Payment HSM as a Service is complemented by eInvoice Signature as a Service and POS Key Generation as a Service solutions fulfilling cryptographic requirements for enhanced security. 

The Payment HSM as a Service is complemented by eInvoice Signature as a Service and POS Key Generation as a Service, providing solutions that meet cryptographic requirements for enhanced security.

Utimaco’s Payment HSM as a Service runs on our high-performance, market-leading Payment HSMs - Atalla AT1000 capable of processing up to 10,000 TPS, with the highest levels of security certification, including FIPS 140-3 Level 3 and PCI v3. 
 

Start your free trial
 

Übersicht

Peter Czempas

Product Marketing Manager, Utimaco