Finance is a different sport. Latency matters because clicking through a fast-moving order book is nothing like scrolling a CRM. No third-party relay matters because client positions and model outputs should never transit a vendor's cloud. Multi-monitor matters because the actual workflow runs across four screens, not one. Remio is built for that reality — sub-5 ms on a wired LAN, end-to-end encrypted, every monitor streamed natively.
Sub-5 ms glass-to-glass on a wired LAN. Under 20 ms on a clean Wi-Fi same-network connection. The kind of figures that disappear into the noise floor of human reaction time — which is exactly the point.
Most remote desktop tools were tuned for people answering tickets and editing slide decks. The acceptable latency budget for that workflow is around 100 to 200 ms — fine for a UI where everything sits still until you act on it. A trading interface is the opposite: the screen is updating ten times a second, the click target is moving, and the cost of clicking the wrong row is real money. The latency budget is roughly one-tenth of a CRM session, and every millisecond past that budget compounds into missed fills and slipped prints.
When Remio reports sub-5 ms latency on a wired LAN, the figure is glass-to-glass: the time from a pixel changing on the host monitor to that pixel appearing on the client display. That includes capture, encode, send, decode, and render — every stage in the pipeline, end to end. Most vendors quote network round-trip alone, which can be a single-digit number even while the actual screen update lags by 80 ms behind it. Remio is built around the full budget because that is the budget the trader actually feels.
On a wired LAN between two devices on the same switch, glass-to-glass is typically under 5 ms. On a clean same-network Wi-Fi connection, under 20 ms. On a residential broadband connection from a home office to a desk workstation in the building, typically under 40 ms. Compare that to the 50 to 150 ms most traders quietly accept on a legacy remote tool — half of that latency is the difference between catching a print and watching it move. Even 50 ms of cumulative input lag costs accuracy on a fast book.
The Remio streaming pipeline is built around a single rule: every frame is the latest screen state, old frames have no value. There is no jitter buffer holding pixels back. There is no third-party relay adding a hop. The video path uses hardware encoders on the host and hardware decoders on the client — H.265 where the GPU supports it, H.264 elsewhere — wired into the platform-native presentation layer. The cumulative effect is a pipeline measured in milliseconds, not tens of milliseconds.
Remio sessions go direct peer-to-peer. Client positions, P&L, model outputs, draft research — none of it transits Remio infrastructure, because no session content does.
A typical remote desktop product routes every keystroke and every frame through a vendor-controlled cloud. The convenience is real; the cost is that the vendor sits in the middle of every session and is, by construction, in a position to see what crosses. Remio inverts that default. The signaling service introduces two devices to each other, hands them an encrypted channel, and steps out of the path. The actual stream — video, audio, keyboard, mouse, clipboard — flows directly between the client and the host. No vendor with logical access to your screen content.
The transport is end-to-end encrypted with authenticated session keys derived between the two devices through a modern key exchange. The keys exist on the client and the host, and nowhere else. Each session uses fresh keys that disappear when the session ends, so a future compromise of one device cannot retroactively decrypt past sessions. The signaling server, even if it were fully compromised, would have nothing to decrypt because it never held the keys to begin with.
Because no session content crosses Remio infrastructure, anything that ever appears on your screen during the session is, by construction, never on a Remio server. Client position blotters, P&L runs, factor model outputs, term-sheet drafts, capital-call letters, deal-team chats, Bloomberg windows — all of it stays between the two endpoints you control. That is not a contractual promise about what we do with the data; it is a structural property of the path the data takes.
On a small fraction of connections — generally where both endpoints sit behind strict network address translation that refuses direct UDP — Remio falls back to an encrypted relay. The relay forwards the same encrypted packets that would have travelled directly: same end-to-end keys, same ciphertext, one extra network hop. The relay operator (including us, when we operate it) cannot read what crosses. For trading desks running on managed corporate networks, direct connection is the norm; the relay path is the exception, not the default.
When the trading workstation runs four monitors, Remio streams every one of them. Layout, position, and resolution are preserved. Attach to a subset, reattach later from a different device with the layout intact.
The trading workstation is a four-to-six monitor rig because the work demands it: an execution surface on one screen, the order book on another, news and chat on a third, charts on a fourth, risk and positions on a fifth. The discipline of having all of that visible at once is the workflow — not a preference. A remote desktop tool that flattens that into a single tab is not remote-controlling the workstation; it is rebuilding a different, worse workflow.
When a Remio host runs on a multi-monitor trading workstation, every connected monitor is captured natively and streamed independently. The geometry — which screen is to the left of which, which is the primary, which sits above the others — is preserved end to end. Resolutions are preserved. Refresh rates are preserved. Drag a window between two physical screens on the host and it crosses the same boundary on the remote view. The workstation behaves like the workstation.
The remote client can attach to a single monitor (a phone screen showing just the order book), a subset (a laptop screen showing execution plus charts), or every monitor at once (a docked iPad rig at home with the full workstation layout). The choice is per-session and per-device; the host does not need to be reconfigured. A risk analyst pulling up the same workstation later from a hotel laptop sees the same monitor layout intact, because the host never lost it.
Trading days do not always end at the desk. When a trader disconnects from a Remio session and reconnects an hour later from a different device, the host workstation has not changed — every window is exactly where it was, every monitor is in the same position, every running app is still running. The remote client picks up the layout state from the host and re-projects it onto whatever screen real estate the new device offers. No “session restart,” no app relaunch, no losing the morning's pinned tabs.
The concrete shapes Remio takes on a finance team. Not a target market deck — actual roles and actual workflows we see today.
The actual desk box stays in the building, with the actual market-data feeds, the actual OMS session, and the actual locked-down corporate network around it. The trader works from the home office through Remio, on the same four-monitor layout they use in the building. Nothing about the workstation moves; only the screen and the input do.
A quant running a long Monte Carlo on the research workstation wants to peek at the convergence plot from a hotel room without copying the dataset off the corporate network. Remio gives the screen and nothing else — the data stays on the research box, the quant gets a thirty-second look at the chart.
A portfolio manager between meetings, pulling up the position blotter on an iPhone for a sixty-second look. Remio renders the existing dashboard as it is on the workstation — no separate “mobile dashboard,” no data copy to a phone-friendly app, no extra system of record to maintain.
A fund-ops analyst monitoring the end-of-day batch from anywhere with a network connection. The batch runs on the ops workstation, the analyst watches the run console through Remio, and intervenes if something stops mid-pipeline. The batch never leaves the ops environment.
A pager fires on a covenant breach at two in the morning. The risk analyst opens an iPad, attaches to the risk workstation, and triages the alert against the live risk dashboard without leaving the bedroom. The full workstation is one tap away; nothing was “synced down” to the iPad.
Office inaccessible? Power out on a floor? Storm closes the building? The desk workstations are still on, still on the network, still licensed for the OMS and the market data. Traders attach from home, from a hotel, from a co-working space, and the desk is open. Continuity is a configuration property, not a project.
Remio is software, not service. No content transits Remio's servers. The audit surface is narrow — workstation hardening, endpoint controls, network segmentation, identity. Remio adds one encrypted channel between two devices the user already controls.
Remio runs as a native host process on the workstation and a native client app on the device that connects to it. There is no vendor-hosted middleware in the session path. That distinction is the reason the audit surface stays narrow: the controls that matter are the ones you already operate on the workstation and on the endpoint device — Remio adds an encrypted-in-transit channel between them, and that is the new component in scope.
Practically, this means the compliance question for Remio is not “what does the vendor's cloud do with our data” — there is no vendor cloud in the path — but “does the architectural posture meet our requirement for a remote-access channel,” which the security whitepaper is written to answer.
The honest list. If any of these are blocking for your evaluation, the right time to surface them is now — not after a procurement cycle. The roadmap covers them; the security whitepaper has the current state in writing.
Remio today does not ship a centralised admin console where an IT team can define per-group session policies — allowed roles, allowed time windows, allowed device classes — and push them out across an organisation. Pairing is per-device, and policy is enforced at the workstation and endpoint level. A centralised admin surface is on the roadmap for the enterprise tier; if it is a hard requirement for an evaluation today, surface that and we can walk through what the gap currently looks like and what the workaround is.
There is no Okta, Azure AD, or Ping integration in the shipping product. Pairing happens between devices, not between identities, so the typical SSO flow does not have a natural attach point in the current pairing model. We are working on an identity layer for the enterprise tier that will sit alongside (not replace) the device-level pairing, with the obvious integrations. If SSO is a procurement gate for your team, that is a useful constraint to share early so we can be honest about timing.
Remio today does not ship audit logs into a SIEM through a managed connector. The signaling service has connection-level metadata (when a pairing happened, which devices were involved, broad geographic origin), and the workstation OS has its own session and login records. There is no Remio-managed pipeline that consolidates those into a Splunk or QRadar feed. SIEM-ready audit log shipping is on the roadmap for the enterprise tier.
Remio is built by a small team and the formal attestation programs — SOC 2 Type II, PCI-DSS, and the various sector-specific registrations — have not been completed yet. The architectural controls that those attestations typically check for (end-to-end encryption, no content at the vendor, narrow data surface, hardware-backed credential storage) are in the product today; the third-party validation of those controls is what is missing. Many evaluation teams find the architecture sufficient when paired with their own attestation program. If formal attestation is a hard procurement gate, that is the right thing to raise during evaluation.
The five questions that come up in every evaluation conversation. Plain answers — the same ones we give over email when a procurement team writes in.
Not yet. Remio is built by a small team; formal SOC 2 attestation has not been completed. The architectural controls — end-to-end encryption, no third-party relay of session content, no account collection — are described in the security whitepaper; many customers find them sufficient for evaluation when paired with their own SOC 2 program.
Yes. All connected monitors on the host are available to the remote client. The remote client can attach to a subset and reattach later from a different device, with the layout intact.
On a wired LAN, glass-to-glass latency is typically under 5 ms. On a clean same-network Wi-Fi connection, under 20 ms. On a residential broadband connection to an office workstation, typically under 40 ms. These figures meet or beat what most traders experience locally on the workstation itself.
No session data is held by Remio to begin with — sessions go direct peer-to-peer and are never recorded on Remio infrastructure. An acquisition or shutdown affects future signaling availability, not historical confidentiality.
The host and client need to reach the signaling service once per connection to find each other; once paired, the session is direct. No usage telemetry or session content is sent. A fully air-gapped deployment is on the roadmap, not in the shipping product.
Install the host on the trading workstation. Install the client on the device you want to reach it from. Sub-5 ms on a wired LAN, end-to-end encrypted, multi-monitor preserved, nothing at the vendor. Free during launch — talk to us about an evaluation for your desk.
No credit card. No account. Free during launch. macOS, Windows, iOS, iPadOS, Android.