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.
For an installer, the important question is not only whether the Hub supports ARC reporting. It is whether the project can send the right event to the right ARC account, prove that the ARC received it, and make sure everyone knows what should happen next.
That is what turns ARC support from a product capability into a working alarm service.
Why would an alarm project use an ARC?
Consider a small shop after closing.
A rear door contact 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.
Where do ARC projects usually go wrong?
Most ARC commissioning problems appear where one part of the path hands over to the next. 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.
Return to the small shop. The installer triggers the rear door contact after the shop has been placed in its agreed test condition. RB Link shows the local alarm event, and the local system behaviour is correct. The ARC operator, however, cannot see the expected report.
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. Confirm that the intended door contact changed state and that the Hub formed the correct local event for the intended device or zone.
This establishes what actually happened on site before the team investigates reporting or receiving.
2. Is the Hub using the intended reporting configuration?
Roombanker Hubs can report to an ARC or receiver over a network. Current supported reporting options include SIA DC-09 and ADM-CID/Contact ID. 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, the installer enters the ARC-provided Main Address, Port Number and Account Number. In the shop example, these details should identify the same receiver and account that the ARC operator is watching during the test.
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?
This is the step that closes the loop.
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 → confirm the Hub-side event → let the ARC identify the account and event → ask the ARC to confirm what it received
If the ARC sees nothing, the two teams can now separate three questions: what happened at the site, how the Hub is configured, and what the ARC is seeing. Until the ARC confirms the final step, the project only knows that part of the path 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. The right choice depends on who must receive the event, which supported events require external handling, and what service the customer expects after receipt.
Before recommending ARC monitoring, establish:
• 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.
These decisions shape the integration before configuration starts.
What must be ready before configuration and testing?
The decisions have a natural order because each supplies an input for the next.
Events to report → Correct ARC account → Reporting settings → Test window → ARC confirmation
If an earlier input is unclear, a later test may show activity without proving that the intended project path works.
First, define the supported events that the ARC is expected to receive. This gives both teams a test scope. Without it, the installer cannot choose representative test events.
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 the reporting path using those project-specific inputs. Details from another site or account should not be reused as assumptions.
Finally, book a test window with a named person on both sides. The installer creates the agreed events; the ARC confirms the account and event received. Once receipt is proven, the customer and ARC can confirm 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 one of ten stores reports a problem months after handover. A service engineer should be able to identify which site and account are involved, which events were originally tested, and which ARC contact 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.
Consistency is therefore part of maintainability, not paperwork for its own sake.
What proves that the ARC path is commissioned?
The acceptance record should make the tested path reproducible without exposing credentials or operational secrets. It should identify:
• 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 owns the next action or escalation process.
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.
The ARC’s confirmation is the difference between knowing a capability exists and knowing the project path has been tested end to end.
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 assessment, 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. That gives the project enough information to move from ARC capability to a testable integration plan.