Skip to content
← All posts

Building Broker Telephony for Danske Bank

I built secure broker telephony systems for Danske Bank with direct secondary lines, logging, and high-security requirements. Implementations in London, Stockholm, and New York.

· 4 min read · Sylvester Damgaard
Building Broker Telephony for Danske Bank

I spent a period consulting for Danske Bank, building broker telephony systems for their trading and financial operations. The requirement was direct secondary phone lines for broker departments with high security, comprehensive call logging, and reliability that financial regulations demand.

The system

Trading floors need telephony that works differently from normal office phones. Brokers need dedicated direct lines that bypass the main PBX. Every call must be recorded and stored for compliance. Latency matters because conversations happen in real-time alongside trades. And the system needs to work identically across offices in different countries with different telecom providers.

The broker telephony is a backup system that ensures a crystal clear connection even if all other systems go down. All conversations are recorded for liability on trades. I converted their existing analog telephony to IP using multichannel ATA converters, achieving a total saving of more than 50% compared to conventional methods.

Implementations

The system was deployed across multiple Danske Bank offices:

  • London - the largest trading operation, highest volume of recorded calls

  • Stockholm - Nordic markets desk

  • New York - US operations

I traveled to each location for the implementation. The New York deployment happened to coincide with the 9th anniversary of September 11th, 2001. My wife joined me for that trip. Standing at Ground Zero on that date, in a city that had rebuilt itself, put the work in perspective. We were building infrastructure for a bank that operates globally. The systems needed to be resilient.

What I learned

Financial services telephony has zero tolerance for "it mostly works." Every dropped call, every gap in the recording log, every second of downtime is a compliance risk. This was my introduction to building systems where reliability isn't a goal but a hard requirement.

The multi-site deployment taught me how to build infrastructure that works consistently across different networks, different telecom providers, and different regulatory environments. The same system, the same logging, the same security model, deployed in three countries with three different sets of constraints.

This experience directly influenced how I think about infrastructure reliability today. The monitoring, the logging, the redundancy patterns I use in Kubernetes deployments trace back to lessons learned in bank trading floors.