An Alarm Receiving Centre (ARC), also called a Central Monitoring Station in some markets, is the professional organisation that receives selected alarm reports from a protected site and handles them according to the service agreed for that account.
How does ARC monitoring work?
An ARC monitoring service receives alarm reports, identifies the account and follows its response instructions. In a contracted 24-hour service, operators work around the clock to review events, verify available information, notify the appropriate contacts and record what happened. The alarm type, service agreement and local response rules determine any dispatch.
What does alarm receiving centre software do?
Alarm receiving centre software presents incoming events against the correct customer account, with zone information and response instructions. It helps operators follow the handling process and retain an event history. Receiving a report and showing it to an operator are separate steps. During commissioning, check that your event appears under the intended account with the right instructions.
Can an ARC monitor fire alarms?
An ARC can receive fire alarm reports when the installed reporting equipment and contracted service support them. The operator handles the event using the agreed fire procedure and applicable local requirements. Specify your fire monitoring separately from intrusion monitoring, with equipment and a service that meet the applicable fire requirements.
If you add a Roombanker smoke detector to a shop, its alarm reports reach the ARC through the Hub. Agree the fire response procedure with the ARC before testing. Check that the event arrives under the right account and that the operator knows what to do next.
If the site needs a certified fire alarm system or certified fire monitoring, design and certify it separately under local fire rules; a smoke alarm reported through the Hub does not replace that.
You need both the reporting equipment and the agreed response to make the service work.
Does the ARC always call the police?
No. An operator follows the agreed response instructions and applicable local rules. That may involve calling a keyholder, reviewing available verification information or contacting an authorised responder. The service and event determine the order; a keyholder call is not a universal prerequisite. Intrusion, fire and medical alarms can have different procedures.
The daily workflow is receive → identify and verify → notify or escalate → record the outcome. A record should show the event time, location, contacts attempted and action taken, including cases where the first contact cannot be reached. If you test a rear-door contact at a closed shop, ask the ARC which action its instructions require when that first contact is unavailable.
Why would an alarm project use an ARC?
An ARC gives you an external team to receive selected events and follow the agreed response. Picture a small shop after closing.
If you trigger the rear door contact during a test, it creates an alarm event. The Hub receives it and, when ARC reporting has been configured for that project, sends the selected report through the network to the ARC receiver. The ARC identifies the customer account and event, then follows the action agreed for that account.
The working path is:
Device → Hub → reporting path → ARC receiver → what the ARC should do next
Each stage has a different job. The device and Hub create the site event. The reporting configuration connects that event to the intended receiver and account. The ARC adds the professional receiving and service layer.
This matters when selected events need to reach an external team rather than relying only on people responsible for the site to notice and handle them. The exact response—such as contacting a named person or following another escalation step—is defined by the customer and ARC for the service account.
How does the Hub reach the monitoring centre?
Roombanker integration routes include direct DC-09 reporting to a compatible ARC receiver and reporting through an IP receiver that converts for the ARC software. DC-09 is a SIA standard, not an ARC’s proprietary protocol.
R2 connects by Ethernet or Wi-Fi; R2 PRO also has 4G. These connections back each other up, and both models provide up to 8 hours of battery backup. Test loss and recovery of each configured path with the ARC. If you disconnect the main network path at a shop Hub during an agreed test, ask the ARC whether reports still arrive and what happens when that path returns.
Where do ARC projects usually go wrong?
Most ARC commissioning problems occur between the site event, the Hub’s reporting settings and the ARC account. A Hub may create the correct local event while the ARC sees nothing. A report may arrive, but the ARC operator may be watching another account or expecting a different test event. Both sides may be ready, but no shared test window has been arranged.
These are different problems. Treating all of them as a detector fault wastes time and can leave the real gap unresolved.
If you trigger the small shop’s rear door contact after placing it in the agreed test condition, RB Link may show the correct local alarm while the ARC operator sees no report. Start with the local event, then check the reporting settings and ARC account in turn.
The useful response is to check the path in three layers.
1. Did the site system generate the expected event?
Start at the protected point. Check that your intended door contact changed state and that the Hub formed the correct local event for that device or zone.
For example, if you open the rear stockroom door but see an event named for the front entrance, check the device and zone names before investigating the reporting path.
2. Is the Hub using the intended reporting configuration?
Roombanker Hubs can report to an ARC or receiver over a network. For IP reporting, SIA DC-09 is the transport layer carrying message formats such as ADM-CID (Contact ID) or SIA DC-03. The target ARC still needs to confirm which supported reporting option and receiving path will be used for the project.
For the current RB Link ARC setup, you enter the ARC-provided Main Address, Port Number and Account Number. For example, if you test the shop’s rear door contact, compare these details with the receiver and account the ARC operator is watching.
For more protocol context, see How SIA DC-09 Connects Alarm Systems to an ARC.
3. Did the ARC confirm the correct account and event?
Ask the ARC to identify the account and event it received from your test.
RB Link is used mainly for configuration. Its interface may show the local device or alarm event, but it does not display Hub-to-ARC reporting status. The ARC therefore needs to confirm what arrived at the receiving side and how it was identified.
A complete test follows one observable sequence:
Trigger the agreed event → check the Hub-side event → let the ARC identify the account and event → ask the ARC to confirm what it received
If you see the rear-door alarm in RB Link but the ARC sees nothing, compare the local event, Hub settings and receiving account with the operator. Keep the test open until the ARC identifies the correct account and event; the local event tells you only that the site stage worked.
Does every project need an ARC?
An ARC is relevant when an external professional organisation needs to receive selected events and handle them under an agreed service process.
If a project only requires selected users to view local or App-visible events and decide what to do themselves, user-managed visibility may be sufficient. Choose according to who needs the event, which supported events need external handling, and what your customer expects after receipt.
Before you recommend ARC monitoring, ask:
• who must receive selected events after the site system creates them;
• which supported event types belong in the ARC service;
• who may be contacted and when escalation applies; and
• whether those actions change between operating periods, such as opening hours and after closing.
For example, if you fit a rear-door contact at a shop where staff leave at closing, ask who will handle that alarm overnight. Use the answer to choose between user-managed alerts and an agreed ARC service.
What must be ready before configuration and testing?
Before you configure the Hub, agree the events, ARC account, receiver settings, test time and people taking part. Work in that order so each step has the information it needs.
Events to report → Correct ARC account → Reporting settings → Test window → ARC confirmation
If you trigger a shop’s door contact while the ARC operator is watching another account, both sides may see activity and still miss the intended report. Agree the account and event before starting.
First, list the supported events your ARC is expected to receive. You can then choose test events that cover that list.
Next, make sure both sides are looking at the same account and test event. The ARC provides the Account Number and receiver details, then confirms what it expects to see. Without that shared reference, both sides may see activity but still be talking about different results.
Then configure your reporting path using those site-specific details. Get the receiver and account details for this site rather than copying another site’s settings.
Finally, book a test window with a named person on both sides. You create the agreed events; the ARC identifies the account and event received. After the test, your customer and ARC can agree what should happen when a real event arrives.
This order prevents a common commissioning problem: testing the connection before both sides know which events, account and people are involved.
Why consistency matters across multiple sites
An installer or distributor may connect several shops to the same monitoring provider. Consistent site and account names, device or zone naming, reported events and test records make later support much easier.
Imagine that a rear-door contact in one of ten stores reports a problem months after installation. You should be able to find the site and account, see which events were originally tested, and contact the ARC person who confirmed the result. Without those shared references, the engineer may know that “an alarm was sent” but still need to reconstruct the original setup before useful diagnosis can begin.
Use the same naming and test-record format at each site so you can begin with the fault rather than reconstructing the setup.
What proves that the ARC path is commissioned?
Keep a test record that lets you repeat the same site-to-ARC test without exposing credentials or operational secrets. Include:
• the target ARC and account reference;
• the supported reporting option used;
• the receiver and account details used for the test;
• the supported event types included in the test;
• when the test took place and who confirmed receipt at the ARC; and
• who takes the next action or escalates the alarm.
ARC capable means the alarm system supports configuration for reporting selected events to a compatible receiving setup through a supported reporting option.
ARC commissioned for the project means the site generated the intended event, the Hub used the agreed reporting configuration, and the ARC confirmed receipt for the correct account and event.
For example, if you return to test a shop’s rear-door contact, use the record to find the agreed account and event, then ask the ARC to identify the report again. That lets you repeat the complete test rather than relying on a Hub’s feature list.
Move from the ARC decision to integration planning
Once the target ARC, events to report, account and receiver details, test contacts and expected action are known, the project can move into configuration and two-sided testing.
Use the ARC integration planning guide for the fuller configuration, testing and handover workflow.
For a Roombanker integration review, bring the target market, target ARC, the events you want to report, the ARC account details, the people who will take part in the test, and what the ARC should do after receipt. You can then plan the setup and the test with the ARC.