Banking and Financial Services Phone Systems: A Buyer's Guide

Financial services voice has one requirement that other industries do not have: the ability to prove afterwards what was said, to whom, by whom, and that nobody was able to alter it in between. Everything else about a bank's phone system — menus, queues, branch routing — is ordinary telephony. The recording and retention layer is where the procurement conversation actually lives.

Definition: A banking or financial services phone system is a voice platform for a regulated organisation, combining centralised recording and call detail record management, multi-branch central operation with local survivability, and access control and audit capability that a compliance officer can rely on.

Why financial voice has different rules

Three characteristics separate a financial branch from a normal office, and each one changes a design decision.

Every call may need to be reconstructable. In a heavily regulated business, "we think the call happened" is not sufficient. The recording has to be retrievable, tied to the right call, associated with the right people and stored with an audit trail. That pushes the recording system from "nice to have" to "the system you will be asked about".

There is usually a physical branch network. A bank with a branch network does not have a separate phone system worth speaking of per branch; it has a set of sites that need to behave like one bank to a customer and like separate sites to a regulator. The architecture question — how much is centralised, how much is local — is a central decision, not a per-branch one.

Availability is an operational requirement, not a comfort. A call centre that cannot take a call during a trading window is a business problem. A branch that cannot place an outbound call during a system outage is a regulatory incident. This is why the survivability question deserves more attention in financial services than in most other industries.

Recording: what to capture and how to manage it

The recording layer is where most financial telephony projects are won or lost, and it is worth separating out the components.

Newrock provides three distinct pieces that do different jobs:

• RMS, the recording management system — collects, stores, plays back and manages recording files, providing centralised management of recordings produced by OM-series IP-PBX systems and MX-series gateways. This is the system of record: one place to search, retrieve and manage.
• Recording Agent — runs on Windows, collects recordings produced by OM systems and stores them as MP3. This is the collection layer that moves files from the platform to storage.
• CDR Software — runs on Windows, collects call detail records from OM systems as .txt files to an external server and manages and retrieves them. This is the metadata trail — who called whom, when, for how long, on which line.

And the platform itself contributes. The OM20G ships with built-in analogue gateway module and recording storage, so recording works out of the box at the platform level. The SX100 session border controller supports call recording as well as voice quality monitoring, which is useful where calls cross a carrier network and the bank wants assurance about media quality as well as content.

Three design questions a compliance officer will ask, and the honest answers:

1. Where do the files live? They should live in one managed store — RMS — not scattered across individual platforms and PC desktops. That is both a control question and a retrieval question.
2. What format are they in? MP3 via Recording Agent is a pragmatic choice for storage and playback. If your retention policy or evidence process requires a specific format or an integrity guarantee, that requirement needs to be settled with the recording platform rather than assumed.
3. Who can retrieve them? Access control to the recording store is a separate matter from access control to the phone system, and it should be designed rather than inherited from whatever the PBX happens to allow.

What this article will not do is tell you what your retention period must be. Recording retention and consent obligations differ by jurisdiction and by the type of call, and they change. The correct statement is that they must be established against your local regulatory requirements and your own policy, and that the technical system should be configured to whatever those are. Anyone quoting a specific number at you is guessing.

Branch reliability and local survivability

For a bank, the question at each branch is binary: if the WAN fails right now, can the branch still place and receive calls?

The Newrock MA50-LS local survivability branch exchange is the component that answers it. It provides 2 to 8 FXO ports, registers 50 to 200 SIP users, keeps calls working locally when the head office or cloud server becomes unreachable, and switches back to the central server once the connection is restored. For a branch with a small PSTN presence and a handful of FXS extensions, that is enough to maintain service through a link failure and through a head office maintenance window.

Layered on top, the gateway layer has its own resilience story. The MX60E-G supports SIP registration failover, load balancing and PSTN failover, with optional 1+1 redundancy on the network port and power supply — so a gateway that loses its uplink or its power does not take the site's analogue estate with it. The OM1000-TE, which handles IMS/SIP and ISDN PRI (30B+D) protocol conversion with up to 120 concurrent calls, up to 40K busy-hour call capacity, 500 routing and number transformation rules, 512 SIP trunk accounts and dual network port and dual power supply redundancy, is the trunk-side equivalent for carrier-facing reliability.

And at the top of the estate, the SX3000 enterprise SBC provides the border protections a regulated environment expects at the edge: signalling and media separation with TLS/SRTP encryption, connection to up to 5 SIP servers, IP table access control, NAT address hiding, blocking of untrusted calls, web brute-force protection with password complexity enforcement, Telnet and SSH enable/disable control, web and Telnet whitelists of up to 30 entries, and MTU 1500 byte signalling packet fragmentation.

Centralised operations for multi-branch banks

Centralised operation is where the operational cost of a voice estate is decided, and it is where multi-site estates usually struggle. The pattern of failure is consistent: each site has its own configuration, each site has its own administrator, and no one can tell from the centre which version of the configuration is actually running where.

Newrock's answer is UMS, which provides unified management and remote maintenance across OM-series IP-PBX systems and MX-series VoIP gateways. The important part is not the console itself but what it makes possible: a single fleet view, consistent configuration practice, and remote maintenance that does not require a site visit.

The remote access detail matters in a banking environment, where site networks are typically locked down. The OM20G supports remote access through New Rock Cloud, TR-069 and SNMP management, and the OM1000-TE includes a built-in cloud service client for penetrating NAT and firewalls. The SX100 provides a graphical web interface supporting remote upgrade and remote maintenance. These are the mechanisms that let a central team reach a branch site without asking the branch to open a hole in its firewall.

For recording and reporting at fleet level, RMS and CDR Software give the central team the two datasets a bank actually runs its operations on: what was said, and who called whom.

Which OM series platform fits

The capacity table is public, and for a bank the relevant question is usually trunk count and concurrency rather than user count — a branch network has many registrations and modest concurrency, while a contact centre has the opposite profile.

Two notes on reading this table for a bank. First, the trunk column is the one that matters for a branch network, because each branch typically consumes carrier channels and the number of channels is limited by trunk provisioning rather than by users. Second, the zero built-in FXS/FXO on the UC models and OM8000 is not a limitation for a bank with an all-SIP estate — it is a signal that these platforms expect external analogue gateways if legacy devices exist, which is usually a branch-with-legacy-equipment situation and therefore worth pairing with the MX series and the MA50-LS.

A due-diligence checklist for voice platforms

The questions to ask any vendor, including Newrock, before signing anything in a regulated environment:

• Where are recordings stored, and who can retrieve them? One centralised store with defined access control. Not per-platform folders.
• What is the audit trail? Recording Agent collects and stores as MP3; CDR Software collects call detail records as .txt to an external server. Both should support retention policies configured to match your own policy.
• What happens to a branch if the WAN fails? Require a documented answer per site, not a general capability statement.
• How is remote maintenance performed, and how is it authorised? Remote access through New Rock Cloud, TR-069 and SNMP for the OM series, a built-in cloud service client on the OM1000-TE, and a graphical web interface with remote upgrade and remote maintenance on the SX100. Ask what the access control on that path looks like.
• What protections exist at the network edge? The SX3000's TLS/SRTP separation, IP table access control, untrusted call blocking and whitelists are the relevant set.
• How is the estate licensed? Device-based licensing means adding a branch device does not mean adding per-person subscription cost. For a bank with a wide, mixed device estate, this is a materially different cost curve.
• What is the licensing and support commitment? Confirm contractual terms rather than relying on published capability.

Newrock perspective

Newrock's position on financial services voice is that the recording and management layer is the product, and the telephony is the platform it runs on. That is why RMS, Recording Agent and CDR Software are separate, retrievable components rather than a reporting tab inside the phone system — a compliance officer needs to search and retrieve, and a compliance officer does not want to log into a PBX to do it.

For branch reliability, the MA50-LS provides the local survivability, with 2 to 8 FXO ports, 50 to 200 SIP registrations, continued local service when the head office or cloud server is unreachable, and automatic switch-back on recovery. The MX60E-G's SIP registration failover, load balancing and PSTN failover with optional 1+1 network and power redundancy covers the gateway layer. The OM1000-TE's IMS/SIP and ISDN PRI (30B+D) conversion with 120 concurrent calls, up to 40K busy-hour call capacity, 500 routing and number transformation rules and dual network port and dual power supply redundancy covers the carrier-facing trunk layer.

For central operation, UMS manages and remotely maintains the whole OM and MX fleet, and the remote access paths — New Rock Cloud, TR-069 and SNMP on the OM series, the cloud service client on the OM1000-TE, the SX100's web interface with remote upgrade and maintenance — are what make a distributed estate administrable without a site visit. At the edge, the SX3000 enterprise SBC provides the TLS/SRTP separation, access control, untrusted call blocking and whitelists.

The RMS recording management system, UMS unified management system and MA50-LS local survivability branch exchange pages are the ones to read.

FAQ

How long must we keep call recordings?

That is determined by your jurisdiction, the type of call and your own policy, and it changes — so establish it against your current regulatory requirements and legal advice rather than against a vendor answer or a general web figure. The technical requirement is that the recording system must be configurable to whatever period you settle on, and that access to expired recordings must be controlled. Newrock's RMS collects, stores, plays back and manages recordings, and CDR Software manages and retrieves call detail records, so both the storage and the metadata trail are in place to be configured.

Can recordings be tampered with?

Integrity guarantees are a specific design question and should be asked explicitly. What Newrock specifies is centralised collection and management through RMS, collection as MP3 by Recording Agent, and call detail records collected as .txt by CDR Software. If your policy requires cryptographic integrity verification, non-modifiable storage or a signed audit trail, raise that as a requirement and validate it against the actual system rather than assuming it.

How do we handle branches with no internet?

Give them local survivability. The MA50-LS provides 2 to 8 FXO ports, registers 50 to 200 SIP users, keeps calls working locally when the head office or cloud server is unreachable, and switches back to the central server once the connection is restored. For sites where the analogue population is larger, the MX60E-G adds failover and load balancing with optional 1+1 network and power redundancy.

What about carrier trunk reliability?

Use more than one carrier, and configure failover rather than relying on a single path. The SX100 supports trunk redundancy and load balancing with 1000 user registrations and 120 concurrent sessions; the MX60E-G supports PSTN failover; the OM1000-TE provides dual network port and dual power supply redundancy for trunk-side resilience.

Can a central team manage every branch?

Yes, that is what UMS is for — unified management and remote maintenance across OM-series IP-PBX systems and MX-series VoIP gateways. For sites behind restrictive firewalls, the OM20G's New Rock Cloud remote access with TR-069 and SNMP, the OM1000-TE's built-in cloud service client for NAT and firewall penetration, and the SX100's graphical web interface with remote upgrade and remote maintenance provide the access paths.

Is per-user licensing a problem for a bank?

OM-series platforms license by device rather than by person. For a branch network where the device count across the estate is different from the employee count — reception phones, back-office devices, meeting rooms, contact centre seats — that difference changes the cost curve over a multi-year term.

What about call centre and IVR requirements?

The OM20G includes call center features, 24/7 IVR, DID, direct access for VIP callers that bypasses the voice menu and auto-answer, along with built-in recording storage. For larger deployments, size on concurrency rather than users, and look at the SX100's 120 concurrent sessions and 70 media transcoding channels or the OM1000-UC's 200 concurrent calls.

How do we prove the estate is patched and configured consistently?

Centralised management and remote maintenance through UMS, with the OM series' New Rock Cloud, TR-069 and SNMP support and the SX100's remote upgrade capability, is how you make that answerable rather than a matter of trust. Backup discipline and configuration consistency are process, and they need an owner — but they need a single console to be practical at fleet scale.

Conclusion

A bank's phone system is a normal telephony estate with one unusual requirement: it has to be reconstructable afterwards. Start there, and the rest of the design falls into place. Put recording in one managed store — RMS, with Recording Agent collecting as MP3 and CDR Software collecting call detail records as .txt to an external server — and make the retention policy a configuration task against your own established requirements rather than a number someone quoted. Then answer the branch question per site, not generally: MA50-LS with 2 to 8 FXO ports and 50 to 200 SIP registrations for local survivability, MX60E-G registration failover and PSTN failover with 1+1 redundancy for the gateway layer, OM1000-TE IMS/SIP and ISDN PRI (30B+D) conversion with dual network port and dual power redundancy for the carrier side, and SX3000 TLS/SRTP separation with access control and untrusted call blocking at the edge. Run the whole estate from UMS, size on trunks and concurrency rather than users, and license by device. Then have your compliance officer read the design against your policy — if the design does not answer their questions on its own, no product feature list will.