Bank alarm panels installed over the past fifteen years span at least three technical generations: legacy dial-up-turned-IP panels reporting over SIA DC-09 or Ademco Contact ID, newer IoT-connected devices using MQTT, and manufacturer-specific protocols that fit neither. Replacing all of it to get one dashboard is rarely necessary — a platform that speaks each protocol natively can unify them without touching the panels themselves.
Who This Is For
- IT and security architects planning a unified dashboard across mixed-vendor hardware
- Engineering teams evaluating whether to build or buy a protocol translation layer
- Security operations teams monitoring alarms in one system and cameras in another
- Anyone told "you'll need to replace your panels" who wants to know if that's actually true
The Three Protocol Families You'll Actually Encounter
SIA DC-09 and Ademco Contact ID are the alarm industry's standard formats for intrusion and fire panels reporting events over IP — between them they cover the large majority of commercial alarm panels in service today. MQTT is a lightweight publish-subscribe protocol, originally built in 1999 for oil-and-gas telemetry, now common in newer IoT-connected security devices. Anything outside those two families is usually a manufacturer's proprietary protocol, which needs a purpose-built adapter — there's no shortcut for those.
Why a Receiver, Not a Replacement, Solves This
The architecture is conceptually simple even though each protocol's implementation isn't: a receiver layer speaks each panel's native protocol, normalises every event into one internal format, and a single dashboard and rules engine sits on top of that normalised stream. This isn't a new idea — multi-protocol alarm master stations in the telecom industry have done the equivalent for legacy network equipment for decades, supporting dozens of protocols side by side in one platform. The pattern transfers directly to bank branch security.
What This Costs You That Replacement Doesn't
- Protocol maintenance is ongoing, not one-time — firmware changes from a panel manufacturer can change how events are formatted
- Every protocol variant needs its own event-mapping validation before go-live, which adds real testing time per branch type
- If a panel is genuinely at end of life, or has no vendor support left at all, integrating it is a waste of engineering effort — replace it instead
Where Camera Integration Fits In
RTSP and ONVIF are the two standards that matter for live video. RTSP is the streaming protocol that actually delivers the live feed; ONVIF is the standardised discovery-and-control interface most IP cameras support, regardless of manufacturer. Integrating both sits alongside alarm protocol integration as a related but separate translation problem — getting video and alarm events into the same dashboard is a different engineering task from getting them onto the same screen.
Case in Point
Alartx integrates SIA DC-09, Ademco Contact ID, MQTT, and custom protocol adapters into one event stream for banks running alarm and fire hardware from more than one vendor across their branch network, alongside live camera feeds over RTSP and ONVIF. None of the underlying hardware had to be replaced to get there.
Frequently Asked Questions
What is SIA DC-09?
It's a two-way alarm communication protocol, developed by the Security Industry Association, for exchanging events over IP between intrusion or fire panels and a receiving platform. It's one of the most widely used standards in commercial alarm reporting today.
Can MQTT and SIA DC-09 devices really run on the same platform?
Yes, provided the platform normalises both into a common internal event format before anything downstream — the dashboard, notification engine, or audit log — touches the data. The protocols themselves never need to talk to each other directly.
How long does protocol integration typically take?
It varies by protocol maturity. A well-documented standard like SIA DC-09 integrates faster than an undocumented proprietary protocol, which can require reverse-engineering how a specific panel model actually behaves before an adapter can be built.
Is it ever better to just replace the panel?
Yes. Panel end-of-life, no remaining vendor support, or known security vulnerabilities in old firmware are all good reasons to replace rather than integrate.
