The architecture of trust: what "compliance by design" actually means in Open Banking
By Saurabh Shah, Co-founder, Spare
There's a phrase that gets thrown around constantly in fintech: compliance by design. The idea is simple. You build regulatory requirements directly into your product architecture from day one instead of layering them on later.
But getting this right is incredibly difficult. While many platforms use the phrase, there is a massive gap between marketing and actual execution.
The Tech-First Illusion
A few years ago, when my co-founder Dalal and I were testing early fintech ideas in Kuwait, we built a micro-investing prototype. We moved fast, wrote clean code, and stood up the technology quickly. We were quite proud of what we had built. Then the operational reality of building in a regulated space dawned on us.
We quickly learned something that shapes how we build today: developing the core software is the straightforward part. The real challenge lies in navigating localized compliance frameworks, data sovereignty, and operational security. We chose not to pursue that micro-investing idea for strategic business reasons, but the experience changed how we look at infrastructure. When we started building Spare's Open Banking platform, we knew compliance had to be an engineering constraint from day one.
Many teams try to chase speed-to-market by building the product first and patching compliance on top later. In financial data and payment infrastructure, that approach backfires. You end up building on top of deep technical debt that leaves you exposed to sudden regulatory changes and operational disruption.
The Open-Source Trap
When engineering teams need to scale quickly, it is easy to default to generic open-source libraries and developer tools because they let you deploy code immediately.
We recognized the hidden trade-offs of this approach early on. In a regulated Open Banking ecosystem, open-source components often carry a steep architectural cost. Many global developer tools are not built to satisfy the precise data residency rules, localized encryption standards, or explicit audit-trail mandates defined by GCC regulators. If you drop an unvetted open-source component into a core transaction flow, you risk failing a central bank audit because the tool routes metadata through international servers or lacks proper data isolation protocols.
Building enterprise-grade infrastructure means avoiding these shortcuts. We invested heavily in dedicated, highly compliant enterprise platforms from day one. It required significant upfront capital and rigorous engineering oversight, but it ensured our core foundation was solid. We still use open source where it makes sense, but only after rigorous vetting to ensure complete compliance with local frameworks. Part of this commitment also meant prioritizing on-prem cloud deployments, giving us absolute control over data residency and environment security instead of relying on generic public cloud setups.
The UX Tension
There is a common misconception that designing for compliance automatically creates a clunky user experience, or conversely, that compliance-by-design makes everything seamless.
The tension between the two is real. If you prioritize user speed blindly, you fail the audit. If you build strictly for the rules, the interface becomes unusable. Getting both right is incredibly difficult.
At Spare, when we engineered our consent flows, we didn't just design a convenient screen and hope it passed legal review. We started with the region's strict regulatory mandates as our baseline constraints and iterated on the user experience around those rules until the friction disappeared, without compromising the standard.
Navigating Regional Micro-Frameworks
The biggest pitfall a financial technology provider can fall into within the GCC is assuming that what works in one jurisdiction can be universally copy-pasted into another. There is no singular generic Middle East Open Banking template. Each central bank has tailored its framework to its market's unique risk profile.
If you look closely at the underlying payment APIs, the regional differences appear immediately.
In Bahrain, the Open Banking frameworks focus heavily on streamlined, direct account-to-account payment execution.
In the UAE, the central framework introduces advanced security parameters. To trigger a payment, the architecture must capture and pass comprehensive risk objects, including mandatory identifiers for merchants such as SIC code and trade license number, directly through the API payload.
Attempting to scale across the region by treating one country's framework as a template for another country doesn't just result in failed API requests. It places both the provider and their enterprise clients out of alignment with the UAE's explicit regulatory expectations.
The Cost of the Compliance Freeze
This isn't just an early-stage startup issue; it happens at the highest levels of enterprise procurement.
During my time at BCG, I worked with a large utility company migrating to a modern billing and CRM platform. The platform was excellent, the efficiencies were clear, and it was a multi-million GBP deal. Yet, the entire project froze because the software provider lacked SOC2 or ISO 27001 certifications.
To keep the deal moving forward, the company had to run a massive manual compliance review that cost hundreds of thousands of pounds and caused months of delays.
Technical excellence means very little if it cannot pass an audit. When large institutions procure technology, compliance is a binary gatekeeper. If your infrastructure lacks inherent institutional rigor, your enterprise customers end up paying the price in massive operational overhead, stalled procurement cycles, and delayed rollouts.
Infrastructure is an Inherited Responsibility
The GCC's Open Banking landscape is maturing quickly. Progressive frameworks from SAMA, the Central Bank of the UAE, and the CBB are setting clear standards for secure financial innovation.
In this environment, businesses cannot afford to rely on bolted-on architecture.
When a merchant or financial institution integrates with an Open Banking platform, they inherit the underlying regulatory profile of that vendor. Shortcuts taken by the provider become a liability for the client.
True compliance by design requires real engineering trade-offs, but it protects your enterprise clients, satisfies your regulators, and gives you a durable foundation to scale.