Council Post: Stop Treating UX And Compliance As Trade-Offs. They’re The Same Design Problem
Vishal Saxena, Chief Technology Officer of Octus.gettyHere's a tension every CTO building for regulated industries knows well: Great UX is supposed to reduce friction. In financial services and law- and compli...
Vishal Saxena, Chief Technology Officer of Octus.
getty
Here's a tension every CTO building for regulated industries knows well: Great UX is supposed to reduce friction. In financial services and law- and compliance-sensitive enterprise environments, friction is often intentional. It's what keeps sensitive data protected, audit trails intact and clients on the right side of their regulatory obligations.
For years, the industry response to this tension was to sequence it away. Build the experience first, harden it for security second, layer compliance on top third. Ship it and move on.
That model is broken. The organizations that haven't figured that out yet are paying for it in client trust, in renewal conversations and in the compounding cost of retrofitting compliance into products that weren't designed to carry it.
At Octus, we've learned this firsthand. Our client base includes some of the most compliance-sensitive organizations in global financial markets: buy-side firms, investment banks and law firms operating under GDPR, SOC 2, SEC requirements and increasingly stringent data governance mandates. Building for that environment taught us something that sounds simple but is genuinely hard to execute. Compliance is a design decision you make from day one. Here are four principles that have guided our thinking about this.
1. When Compliance Comes Into Conflict With Experience, The Highest Bar Wins
The clearest example of this at Octus came during the integration of FinDox into our broader client-facing platform. FinDox was built SOC 2 compliant from the ground up because it handles highly sensitive client documents. Our legacy platform, optimized for proprietary data, operated under different constraints.
Clients, however, didn't see two systems. They expected a unified experience across the entire workflow. That created a direct conflict: Maintain two separate experiences with different compliance postures, or elevate the entire platform to meet the higher standard.
We chose the latter. That decision triggered a significant investment in cybersecurity and compliance maturity across Octus. We migrated core capabilities, including our embedded and proprietary AI platform, CredtiAI by Octus, onto a SOC 2-compliant foundation so FinDox could integrate seamlessly. Over time, that standard propagated across the broader platform.
The lesson: Once your product serves compliance-sensitive workflows, the highest standard in your ecosystem becomes your baseline. Preserving different standards within the same user experience creates friction and erodes trust. Your clients will notice before you do.
2. Compliance Belongs In The System Design, Not The User Journey
Enterprise product teams that embed compliance logic in the interface expose the seams of their architecture to the people who should never have to see them. Warning dialogs, confirmation screens and access error messages are symptoms of a deeper architectural decision made too late.
At Octus, we made an early shift toward a component-driven architecture to address this directly. The goal was to isolate where compliance and security must be strictly enforced while allowing the user experience to remain clean and consistent.
A practical example is our centralized authentication and authorization layer, which we refer to internally as AuthZ. Rather than embedding permission logic across multiple applications, we built a single service that defines and enforces granular access controls once. Every client-facing product integrates with it. This ensures consistency, reduces risk and eliminates duplicative compliance logic that creates maintenance debt over time.
At the infrastructure level, using Terraform allowed us to embed guardrails directly into provisioning and deployment workflows, ensuring compliance by default. When compliance is built into the system design, users experience clarity and consistency. When it is part of the user journey, they experience friction.
3. Client Compliance Needs Vary. Your Product Controls Should Accommodate That
Clients evaluate compliance and product experience together. How your platform handles their regulatory requirements is part of the experience, and that understanding should shape how you build.
Some clients, however, needed visibility into user activity to meet their internal compliance and audit requirements. That feedback led us to build an opt-in model: Tenants can choose to receive audit data specific to their environment through controlled channels, while global usage data remains encrypted and isolated.
A similar pattern emerged with our mobile app. When we introduced FinDox capabilities on mobile devices, certain clients raised concerns related to their BYOD policies, specifically about data exposure on personal devices. The response was to prioritize tenant-level module controls, allowing clients to configure the experience in line with their own regulatory posture.
Compliance preferences vary across your client base. The product needs to provide flexible controls so clients can align the experience with their regulatory environment without that flexibility creating complexity for everyone else.
4. Design For The Auditor And The User At The Same Time
The external benchmark worth studying is AWS and its shared responsibility model. What AWS gets right goes beyond technical architecture. The platform is explicit about what it handles versus what the customer owns. Many of the most important controls are embedded at the infrastructure and service level, transparent to the end user while remaining fully auditable and controllable.
That separation matters. Strong enterprise platforms operationalize compliance in a way that becomes invisible to the workflow while remaining rigorous and traceable beneath the surface.
That is the standard worth building toward. Compliance designed into the system reinforces trust without interrupting the experience. A clunky permissions screen signals to your client that security and experience were designed by teams that never talked to each other. In regulated markets, that signal has consequences.
The organizations winning aren't making better trade-offs between experience and compliance. They've stopped treating them as separate problems and started designing as if trust itself is the product.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?