Self-hosted video conferencing for financial services

Why self-hosted video conferencing for financial services starts with records and contracts

For a regulated firm, the first question about a self-hosted video platform is not which product has the nicer interface but which calls must stay on infrastructure the firm controls and what evidence it must keep afterward. For advisory and client calls with authenticated attendees, Jitsi Meet fits best when a JWT or LDAP front door controls who joins, while BigBlueButton suits structured sessions that need polls, multi-user whiteboards and recordings. Board meetings and town halls usually sit closer to the BigBlueButton side, but the choice should follow the meeting format, not the brand.

The regulatory weight falls on three areas. For broker-dealers, SEC Rule 17a-4(b)(4) requires preservation of originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years, so any recording, chat log or transcript a call produces must have a defined retention path. Under DORA, which has applied since 17 January 2025 to a broad set of financial entities, every ICT services contract must state where services are provided and data processed, and the firm must hold a register of information on those arrangements and documented, tested exit strategies for services supporting critical or important functions. Non-bank institutions under FTC jurisdiction face the FTC Safeguards Rule, which requires multi-factor authentication for anyone accessing an information system unless the Qualified Individual approves an equivalent control in writing (16 CFR 314.4(c)(5)). Confirm with counsel and your regulator which of these rules apply to your entity type and jurisdiction before designing around them.

DeployOpen prepares the systems, configuration, logging and evidence that these reviews ask for, including authentication settings, retention schedules and exit documentation. It does not issue audit reports, attestations or certifications; independent auditors and the relevant regulators make those determinations. Before scoping, ask your implementation partner to map each control to the artifact it will produce, so compliance and infrastructure leads agree on the evidence before the first server is built.

Which financial regulations change the video conferencing build

This table maps each financial regulation or control framework to what it asks for and what that means for a self-hosted Jitsi or BigBlueButton build. Read each row as a design input to confirm with your compliance function, not as a finished compliance position. Retention and recording decisions in particular must be confirmed with counsel and the compliance function before rollout.

Requirement	What it asks for	Build consequence and evidence to keep
SEC Rule 17a-4(b)(4)	Broker-dealers preserve originals of communications received and copies sent relating to the business, including inter-office communications, for not less than three years	Decide whether meeting recordings, chat or transcripts count as business communications. If yes, route them to WORM-capable or retention-locked storage, index them by meeting and participant, and keep retention separate from the recording tool.
DORA Article 28(3)	Maintain a register of information covering all contractual arrangements for ICT services	Record the self-hosted video stack, the hosting provider, the implementation partner and any SaaS add-ons (such as a managed TURN or transcription service) as separate entries with their roles and criticality.
DORA Article 28(8)	Documented, tested exit strategies and transition plans for ICT services supporting critical or important functions	Document how meetings, recordings and configuration move to another host or platform. Test a restore of recordings and a rebuild of the Jitsi or BigBlueButton configuration from backups, and keep the test records.
DORA Article 30(2)	ICT contracts state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination	In the contract with the hosting provider and any support partner, confirm the data locations for media servers, TURN relays, recordings and logs, and the return and deletion terms. Ask for the wording before signing.
FTC Safeguards Rule, 16 CFR 314.4(c)(5)	Multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing	Applies where the institution is a non-bank financial institution under FTC jurisdiction. Require MFA on the identity provider behind LDAP, OpenID Connect or JWT issuance, and on admin consoles. Any exception needs a written approval on file.
SOX Section 404 IT general controls, SEC Release 33-8810	Program development, program changes, computer operations and access to programs and data are example IT general control areas	Where meeting infrastructure supports financial reporting or board materials, keep access reviews for admin and service accounts, change tickets for upgrades and .env or config changes, and job logs for backups and recording jobs.
PCI DSS v4.0.1	Applies where the entity stores, processes or transmits cardholder data, or could affect the cardholder data environment	Meetings that discuss or display card data, or that run on hosts in the cardholder data environment, may bring the video stack into scope. Confirm scope with your QSA or internal assessor before any card-related call, and keep the video hosts out of that scope unless it is proven otherwise.

How recording and retention rules shape the meeting design

A call is not automatically a business record, so the firm has to decide which meetings are recorded, where the files land, how long they are kept and how deletion is evidenced before the platform is configured. Recording is a policy decision first and a technical setting second. Advisory calls, board sessions and internal town halls carry different obligations, so each meeting type needs its own rule for recording on or off, storage location and retention period, with compliance, legal and records management signing off on the mapping.

For broker-dealers, SEC Rule 17a-4(b)(4) requires preservation of originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. The rule covers communications, not only meetings, so the retention period for each communication type, including any recording, chat transcript or meeting artifact, must be confirmed with counsel rather than assumed from the three-year floor. Insurers, asset managers and banks in other jurisdictions will map their own obligations, including DORA's expectations on ICT records, so the reader should confirm the applicable rules for each entity in the group.

On the technical side, the choice of platform sets the storage model. Jibri, the recording component for Jitsi, supports one recording per instance, so simultaneous recorded meetings need a planned pool of recording hosts. BigBlueButton recordings need about 500 GB of disk per server when recording is enabled, according to the BigBlueButton install documentation, so storage, archiving and disk growth must be sized before go-live. Ask the partner to show where recordings are written, how they are moved to archive storage, how legal holds are applied, and how deletion at end of retention is logged and evidenced.

Advisory calls versus town halls: which platform fits

Advisory and board calls are small, sensitive and usually tied to a named set of participants. The main requirements are that only authenticated staff and invited clients can enter, that the room is controlled by the host, and that guests cannot reach internal rooms by accident. Jitsi Meet fits this pattern well because its authentication model is set up per deployment and can rely on your existing identity provider. The Docker setup lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, configured through the .env file. For a firm with an identity provider that issues tokens, JWT is the option the Jitsi handbook recommends for new installations, and the older secure domain method is marked deprecated.

JWT from the firm's identity provider: Your SSO issues a signed token carrying the user's name, email and moderator status, and Jitsi admits the user only with a valid token.
Separate anonymous domain for guests: Clients who join without an account are placed on a guest domain, which keeps them away from the authenticated room namespace.
Lobbies: Hosts admit each guest manually, which suits calls where the advisor must confirm who is on the line before discussion starts.
LDAP as an alternative: If your directory is LDAP-based, the Docker configuration supports it, though you should confirm how group membership maps to moderator rights in your version.
Scope of server load: Advisory calls are small, so capacity planning centres on availability and failover rather than peak concurrency.

Before committing, confirm with your architects how token expiry, room naming and guest identity will be audited, because those records are often the evidence a supervisor or examiner asks for first.

Which open-source meeting platforms fit a regulated firm

Financial firms rarely need one meeting tool for every purpose. Advisory and board calls, large briefings and collaboration on shared files each place different demands on authentication, recording and hosting. The options below are sorted by the call type they fit best, along with the main risk to check before committing.

Jitsi Meet for advisory and board calls

Jitsi Meet is licensed under Apache-2.0 and is a practical fit for small, sensitive calls such as client advisory sessions and board discussions. Its Docker setup separates the web, prosody, jicofo, jvb and jibri components, so each can be reviewed on its own. Authentication can be set to JWT tokens, with a separate anonymous domain for guests, or to LDAP through the .env file. The main risk is recording: Jibri runs one recording per instance, so plan capacity and retention before promising recorded board minutes. Confirm the authentication and recording behavior of your release with the vendor.

BigBlueButton 4.0 for webinars and town halls

BigBlueButton 4.0.0 is licensed under LGPL-3.0 and was released on October 14, 2026. It suits webinars, investor briefings and staff town halls where presenters need slides, polling, Q&A and breakout rooms. Its install guide calls for a clean Ubuntu 24.04 server, since direct upgrades from 2.6, 2.7 or 3.0 are not supported, and it needs substantial hardware and open UDP media ports. The main risk is capacity planning for large audiences, which should be tested with a rehearsal before a live event. Confirm attendee limits and recording storage with the vendor.

Nextcloud Talk when files share one identity

Nextcloud Server is licensed under AGPL-3.0. Choose Nextcloud Talk when calls must sit next to shared files, chat and user accounts under a single identity layer, so access to a meeting follows the same permissions as the documents discussed. This suits internal working groups more than large client-facing events. The main risk is that the meeting capacity and recording behavior of Talk depend on its backend configuration, so ask the vendor and your implementation partner to confirm the supported sizes and the authentication options in your environment before standardizing on it.

JaaS and meet.jit.si for regulated content

JaaS, the hosted Jitsi offering from 8x8, and the free public instance at meet.jit.si are excluded for regulated content. Neither runs in your infrastructure, so you cannot set the retention, access logging or data location that DORA Article 30(2) and SEC Rule 17a-4 expect for client communications. Use them only for public, non-sensitive events if at all. Before approving any hosted meeting service, confirm with your compliance team where media is relayed, who holds recordings, and how exit and data return are handled.

Deployment patterns that keep media and records inside the firm

Financial firms rarely need one server for every purpose. The patterns below separate media, identity, guest access and records so each can be placed, audited and evidenced on its own. Together they answer where media flows, who can join, and where the logs that auditors ask for end up.

Central Jitsi server with videobridges

Run the web server, Prosody, Jicofo and one or more Jitsi Videobridge media routers inside a private zone that you control. Serve the web app over HTTPS with a certificate issued for your own domain, because the Jitsi handbook says working audio and video depend on it and self-signed certificates cause problems, especially on mobile clients. Add videobridges as concurrency grows, since the default install is already set up for horizontal scaling. Check that the required ports (80/TCP, 443/TCP and 10000/UDP) are opened only where your firewall policy allows them.

BigBlueButton on a clean host

For advisory sessions that need slides, shared notes or recording, BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server and migrate content deliberately rather than upgrading in place. Size the host against the published minimums and confirm whether your recording volume justifies the disk allocation. Confirm the UDP range (16384 to 32768) and a TURN server for staff behind restrictive firewalls before go-live.

Separate guest and member domains

Keep client and external-party access on a different domain from staff access. Jitsi's handbook recommends JWT token authentication and a separate anonymous domain for guests, and it marks the older username and password room method as deprecated for new installations. Staff join through LDAP or JWT, and clients join only rooms they were invited to. Test that a guest link cannot reveal member-only rooms or shared secrets, and document the boundary as an access control for your review.

Archive tier and SIEM feed

Send web server, Prosody and bridge logs, along with authentication events and recording access records, to an archive tier and a SIEM. This supports the audit controls you need to show who joined, when and from where. Set retention for logs and recordings separately, since SEC Rule 17a-4(b)(4) sets a three-year floor for broker-dealer communications and your own policy may go further. Under DORA Article 30(2), the contract must state where services are provided and data processed, so name the hosting location in that contract and in your register of information.

How a regulated rollout moves from design to supervised use

This sequence takes a financial services meeting platform from agreed scope and compliance sign-off through identity, network, build, retention testing and pilot, ending in a handover the internal team can run and exit if needed.

Agree scope and meeting taxonomy
The client's compliance, legal and business owners define the meeting types, such as advisory calls with clients, board sessions, internal town halls and external webinars, along with who attends, whether guests join, and which meetings are recorded. DeployOpen maps each type to a platform choice, either Jitsi Meet or BigBlueButton, and to a retention and access rule. The output is a written scope and taxonomy signed off by compliance before any build work starts. Ask the compliance lead to confirm which recordings fall under broker-dealer or other record-keeping obligations, since that determines the retention schedule.
Design identity and authentication
The team selects how users and guests authenticate. Options include JWT tokens issued by the client's application, LDAP directory lookups, or the hybrid modes the Jitsi Docker setup supports, with the older username and password secure domain treated as deprecated for new installations. Multi-factor authentication is enforced at the identity provider that issues the tokens or directory credentials, and guests use a separate anonymous domain. The artifact is an authentication design record that names each user group, the trust relationship and the token lifetime policy. Confirm with the identity team how MFA is applied to every path into a meeting.
Design network and TURN paths
Network engineers map the ports, certificates and relay paths the platform needs, including TCP 443, UDP 10000 for Jitsi media or UDP 16384 to 32768 for BigBlueButton, and a TURN server for users behind restrictive firewalls. They confirm that HTTPS uses a certificate trusted by client devices, since self-signed certificates cause problems for audio and video. The output is a network diagram and firewall change list showing where media and TURN relays sit, which must match the data location commitments in the client's contracts. Confirm with the network team whether any media path leaves the approved jurisdiction.
Build and harden the platform
DeployOpen installs the chosen platform inside the client's own cloud account, data center or private network, using current supported operating systems and a clean server installation where the vendor requires it. The build covers service configuration, access control, logging, patching and hardening baselines, and the components each platform needs, such as the Prosody, Jicofo and videobridge services for Jitsi or the Greenlight front end for BigBlueButton. The output is a build record with versions pinned and a hardening checklist signed by the client's security team. Ask the vendor about the upgrade path before the build is finalized.
Configure and test recording and retention
Recording storage, encryption at rest, access controls and deletion rules are configured to match the retention schedule approved in the first step. DeployOpen then tests the full path, from creating a recording through storage, access by an authorized reviewer, and automated deletion at the end of the period. Test results are recorded against each rule in the schedule, including the three-year minimum that applies to certain broker-dealer communications under SEC Rule 17a-4(b)(4). The output is a retention test report that compliance signs off. Confirm with legal whether a legal hold process must also be supported.
Run a limited pilot
A small, named group of users runs the agreed meeting types against the platform, including one guest session and one recorded session, under documented conditions. DeployOpen monitors performance, authentication failures, audio and video quality and audit log completeness, and the group reports issues through a defined channel. Each issue is logged with a fix, owner and retest result. The output is a pilot report with pass or fail results against the acceptance criteria written in the scope step. Only move to wider use when the criteria are met and the compliance lead accepts the report.
Hand over with runbooks and exit plan
DeployOpen transfers operation to the client's internal team through runbooks for routine tasks, incident response, patching, certificate renewal, token key rotation and recording deletion. The exit plan covers data return, the transition path to another platform and the contractual records that show where services run and data is processed. Where DORA applies, the exit plan and register entry support the documented, tested exit strategy for ICT services that support important functions. The output is a handover pack and a completed exit plan. Ask the client's operations lead to run one runbook drill before handover is accepted.

Evidence auditors and supervisors ask for from a video platform

This table maps each piece of evidence a financial services auditor or supervisor may request to the platform component that produces it. Read it as a preparation list: the platform team must generate and retain each item, and the compliance team decides which items map to its own obligations. DeployOpen prepares this evidence for assessments, while independent auditors or certification bodies give any opinion on it.

Evidence item	What it shows	Producing component	Where it usually fails
Register entry and contract clauses	Where the video service sits, which provider runs it, and exit terms for DORA Article 28(3) and 30(2)	Ict services register and signed contracts with the hosting and support provider	Register omits sub-processors, or contracts do not state data locations and return on termination
Access control and MFA configuration	Who can create rooms, which login methods apply, and that MFA covers staff accounts under the FTC Safeguards Rule	Jitsi configuration in the .env file (authentication mode, JWT settings) and Greenlight OIDC settings	Guest domain is open to anyone, or a legacy username and password method remains enabled
Change logs for the platform	Dated record of upgrades, configuration edits and access changes tied to an approver	Server audit logs and version control of configuration files	Changes applied directly on servers with no ticket or approval trail
Recording retention settings and deletion logs	How long call recordings are kept, where they are archived, and proof of deletion at expiry	Archive storage policy, BigBlueButton recording storage settings and deletion job logs	Recordings of advisory calls are kept without a rule that matches the three-year broker-dealer retention period in SEC Rule 17a-4(b)(4)
TLS configuration and certificate records	Protocols, cipher settings and certificate validity for client and media connections	Web server TLS configuration, certificate inventory and renewal logs	Expired certificates, or self-signed certificates that break audio and video on mobile clients
Tested exit plan	Documented and rehearsed steps to move meetings, recordings and configuration to another platform, as DORA Article 28(8) expects	Exit runbook, backup restore test records and dated test reports	Plan exists on paper but has never been run, or recordings cannot be exported in usable formats

What financial firms ask before hiring a video conferencing partner

What drives the cost of self-hosting video conferencing for a financial firm?

The cost is driven by server sizing, recording storage, identity integration and testing, and most of it is paid as a fixed-scope engagement plus infrastructure you own. Infrastructure costs follow peak concurrency: the Jitsi scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge, while the BigBlueButton 4.0 install docs call for at least 16 GB of RAM with swap, 8 CPU cores and 250 Mbit/s symmetrical bandwidth per server. Recording storage recurs and grows with retention: BigBlueButton's docs suggest 500 GB of disk for recordings, or 50 GB without recording. Ask any partner for a quote that separates one-time scope (design, integration, hardening, testing) from recurring items (hosting, bandwidth, storage, upgrades and support).

Can our team run self-hosted video conferencing without an implementation partner?

Yes, a skilled platform team can deploy Jitsi Meet or BigBlueButton, but the work is more than installation. The Jitsi self-hosting path involves a web server, Prosody, Jicofo and one or more Jitsi Videobridge media routers, plus ports and HTTPS certificates that must be correct before audio and video work. Financial firms also need authentication design (LDAP, JWT or hybrid modes), recording retention aligned with rules such as SEC Rule 17a-4(b)(4), which requires preserving relevant communications for not less than three years, and documented testing. Assess whether your team has capacity for that full set of tasks, then decide which parts to keep in-house and which to scope to a partner.

How long does a self-hosted video conferencing rollout take?

The schedule depends on the platform, the number of environments, the identity integration and how many approval gates your compliance and change processes require. No duration is fixed by the platform itself, so ask any partner for a written timeline tied to the agreed scope. BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a clean server build is recommended, which affects migration planning. Jitsi requires Debian 12 or newer or Ubuntu 24.04 or newer with OpenJDK 17. Schedule risk usually comes from identity owners, certificate issuance and firewall changes rather than from the software install.

What does the work need from our firm: identity owners, compliance sign-off and network changes?

Expect to supply four groups of people and decisions: identity owners who approve how users authenticate, a compliance lead who signs off retention and recording rules, network staff who open the required ports, and an approver for the change process. On the identity side, Jitsi supports internal XMPP accounts, JWT tokens, LDAP and Matrix verification, while the Jitsi handbook recommends JWT token authentication over the deprecated secure domain method. Network work includes TCP 80 and 443, UDP 10000 for Jitsi, and for BigBlueButton TCP 80 and 443 and UDP 16384 to 32768, plus a TURN server for users behind restrictive firewalls. Agree on owners for each item in the written scope before work starts.

Does DeployOpen certify that our video conferencing setup is compliant?

No. DeployOpen plans, implements, hardens and documents the platform and prepares the systems, controls and evidence that an assessment will need, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Relevant rules include the SEC's broker-dealer record-keeping rule, the EU Digital Operational Resilience Act (DORA), which has applied since 17 January 2025, and PCI DSS where cardholder data is in scope. DORA sets no certification scheme, so the evidence your supervisor or assessor expects should be confirmed with them directly before the scope is written.

How are upgrades and security patches handled after go-live?

Upgrades are handled through a documented process, either as a one-time task or under an ongoing support retainer, and the details should be written into the scope. DeployOpen supports ongoing support, upgrades and continuous testing as retainers. For BigBlueButton, the 3.0 branch continues to receive maintenance releases, such as 3.0.39 on October 2, 2026, and 4.0.0 was released on October 14, 2026, so ask how your partner will plan the move between branches. Jitsi Meet publishes stable builds tagged by build number, such as stable/jitsi-meet_11248 on September 14, 2026. Ask how upgrades are scheduled around live classes or board calls and how rollback is tested.

Which DORA contract terms should a video conferencing partner accept?

DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. Article 28(3) requires a register of information on contractual arrangements, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. A self-hosted model keeps media and recordings in your infrastructure, which simplifies data location questions, but the contract still needs these terms. Ask a partner to confirm in writing where its staff access systems, how it handles data return and how exit would be tested.

Which authentication setup works best for client and board calls?

The right setup depends on who joins: staff, clients, directors or external advisers. For staff, LDAP or a directory-backed JWT flow is typically the simplest route to a single identity source, while guests should use a separate anonymous domain with lobby or moderator controls. The Jitsi handbook marks the older secure domain method as deprecated for new installations, so JWT is the current recommendation. BigBlueButton API calls must carry a checksum computed with a shared secret, and that secret must never appear in a web page. Greenlight v3 supports OpenID Connect, and Keycloak can add SAML or other login methods. Confirm the identity flow with your identity team before the build begins.

Questions to put to an implementation partner

Start with the written scope, because every answer below should land in it. Ask the partner to state, before any work begins, which meetings are in scope (board, client advisory, town halls), which platform is proposed for each, what is delivered, and what evidence will exist at handover. Ask how they map recording and message retention to the evidence set your regulators expect. For broker-dealer communications, that means a retention rule that preserves copies for not less than three years under SEC Rule 17a-4(b)(4), and for DORA, entries in your register of information on ICT contractual arrangements. Ask them to show a sample of that mapping before they build anything, and to confirm which of those obligations they assess and which remain yours to confirm with your counsel.

Ask how JWT and LDAP are tested against your own identity provider, not against a lab directory. The Jitsi Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all set through the .env file. Ask which mode they recommend for board calls, how token expiry and room claims are checked, how a leaver loses access to a standing room, and what happens to guest access during a directory outage. Ask for test cases with named accounts from your environment, and for the result of a failed login path. Ask how recordings are stored, where they sit, who can play or delete them, how deletion is logged, and how it is reconciled with the retention schedule.

Ask how the exit plan is tested, not just written. DORA Article 28(8) expects documented, tested exit strategies and transition plans for ICT services supporting critical or important functions, and Article 30(2) expects the contract to state where services are provided and data processed and to cover data return. Ask for the hosting location as a named data center or cloud region in the contract, the notice period for changes, and a dated exit test with recordings and chat history restored elsewhere. On upgrades, ask how they will keep board calls running: which maintenance windows they propose, whether they test on a staging stack that mirrors your Jitsi or BigBlueButton version, and how a rollback is run. Confirm current release details with the vendor before planning.

How DeployOpen scopes and supports regulated video conferencing

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For financial services video conferencing, we start with a written scope that fixes the platform, the recording and retention rules, and the authentication design before any server is built.

How we scope

Written, fixed-scope agreement covering the platform choice between Jitsi Meet and BigBlueButton for each meeting type
Mapping of which calls are recorded, where recordings land and how long your retention rules require them to be kept
Confirmation of the authentication model, whether JWT tokens, LDAP or the hybrid option, and which guest and client access paths are allowed

How we build

Deployment inside your infrastructure with HTTPS certificates from your own domain and the firewall ports the chosen platform requires
Configuration of authentication, lobbies and guest domains, with testing of each access path before users are onboarded
Sizing of media servers for your expected peak concurrency, with load and failover tests documented as deliverables

How we hand over

Documentation of architecture, configuration, access controls, recording storage and retention settings as handover artifacts
Evidence packs for your compliance and audit teams, prepared for review by your independent assessors, not issued by DeployOpen
Runbooks for upgrades, backups, user administration and exit or transition planning for the video platform

How we support

Ongoing support, upgrades and continuous security testing available as retainers after handover
Scheduled upgrade windows agreed in advance so that advisory calls and board meetings are not disrupted
Periodic review of the written scope against changes in your recording, retention and third-party risk obligations