By Saurabh Shah, Co-founder, Spare
In my last piece, I wrote about compliance by design and the technical choices that make an Open Banking platform compliant at its core. That was about what we built. This piece is about something harder to talk about honestly: how we operate every single day.
Here is the truth most founders avoid saying out loud. The fastest way to ship software is to give everyone access and let them run. No approvals, no gates, no waiting.
We deliberately chose not to work that way. I want to be honest about what that choice costs us, why we still make it as an Open Banking provider, and why even startups outside of finance should consider taking the exact same trade-off.
The reality of the calculation
When you build Open Banking infrastructure across the GCC to handle bank connections, financial telemetry, and live payment initiation, the cost of a mistake goes far beyond a simple rolled-back deployment.
A single mistake can mean severe financial penalties, a revoked licence, or an enterprise client taking on your security failure as their own. When those are the stakes, moving fast and breaking things stops being a startup philosophy and becomes genuine negligence.
So we made a deliberate trade. We slow down in the specific areas where speed would expose us, and we move fast everywhere else.
The goal was never to remove friction entirely. It was about placing friction in the right spots so that company-ending mistakes cannot happen, while the rest of our work keeps moving.
That trade runs through four distinct layers.
The four-pillar operating framework
1. Identify the risks, set the targets, then write the policy
Policy is not just a document you produce for the sake of compliance. Done right, it is the set of guardrails that keeps your business safe. So do not copy someone else's for the sake of it. Identify what actually matters to you, set your targets, and only then write the policy. Use a template if you like, but the targets have to be your own and they have to make sense for your business.
Ours are set in-house against our own systems, stress-tested by our cyber and GRC teams, and proven in external audits. The output is not a shelf of documents; it is a set of thresholds an engineer can check their work against.
Because we operate across the region, we carry three regulatory regimes at once: CBB in Bahrain, SAMA in Saudi Arabia, and the Central Bank of the UAE. Rather than force our engineers to reason about three separate rulebooks, we take the strictest version of every requirement across all three and set that as our single internal baseline. Clear the internal threshold and you clear every jurisdiction at once, automatically.
2. Turn compliance into muscle memory
A policy that lives in a Notion doc nobody reads is worthless. We build compliance directly into how our engineers write code every day.
Every developer who joins Spare spends time learning our pipeline before they touch production. This is a real front-loaded cost. It takes a new engineer nearly a month to fully master our CI/CD controls, security testing gates, and codebase. We start them small on bug fixes, scaling them up as the pipeline becomes second nature.
The payoff is that compliance stops being a checklist people resent and becomes instinct. A developer here approaches compliance the same way they approach writing a unit test. When compliance lives inside developer tooling, like automated pre-commit hooks and PR templates, the friction moves off the delivery clock and onto the learning curve. That is not the same as free. We pay it once per engineer, and we pay it again every time we hire.
3. Replace human promises with machine guardrails
This is the layer engineers feel the most, and it is where traditional compliance breaks down.
Traditional compliance relies heavily on human vigilance through checklists, peer sign-offs, and promises that developers will follow policy. But humans get tired, miss details, and cut corners under deadline pressure. And human-scale controls do not survive company-scale growth. In 2024, the FCA fined Starling Bank £29 million after its anti-money-laundering and sanctions screening controls failed to keep pace as it grew from 43,000 customers to 3.6 million in a few years. Starling accepted the finding publicly. The lesson is uncomfortable but clear: manual vigilance breaks exactly when you scale fastest.
So we replaced human trust with machine-enforced technical controls:
Policy as Code: Rules live inside automated pipeline checks instead of static documents. If a change violates data localization rules, exposes sensitive API telemetry, or fails dependency scans, the pipeline fails instantly. The developer does not get asked to fix it later; the machine simply refuses to build it.
Zero Standing Access: We apply the same machine enforcement to system access. No engineer holds permanent access to production. When someone needs it, an automated portal issues short-lived credentials that expire on their own. Standing access never actually reaches zero. Service accounts, break-glass identities and admin roles are standing by design, and pretending otherwise is how you fail an audit you thought you had passed. What we do instead is keep the list of standing identities short, put a named owner against every one of them, and re-prove each entitlement on a quarterly cycle.
Break-Glass Auditing: In an emergency, a small group of designated engineering leaders can trigger a break-glass override to fix production immediately. Even then, the machine takes over. Every command executed during a break-glass session is automatically recorded, tagged, and routed for mandatory post-incident review.
4. Treat compliance as code
If the first three layers stood alone, we would drown in our own paperwork. Automation is our release valve.
We treat compliance as code across the board. Workflows, sign-offs, and infrastructure deployments route automatically. System assets continuously log telemetry into our security tools to catch unusual behavior in real time.
When an auditor or enterprise client asks who approved a specific API change six months ago, we do not spend weeks reconstructing history. We pull an immutable, automated audit trail in less than fifteen minutes.
The part I won't dress up
None of this is seamless, and I would be lying if I claimed otherwise.
The place it bites hardest is in documentation and cross-team review. A GRC or cybersecurity reviewer might not immediately grasp why an engineering team chose a specific database design or API architecture. That gap creates real friction.
Our solution is unglamorous, but it works: we ban long written argument threads. The moment a security review hits a second round of back-and-forth comments, the teams jump on a quick 10-minute call to talk it through live.
The effortless, frictionless compliance process touted in corporate marketing blogs does not exist. There is a real operational cost here, and we simply believe it is the right cost to pay.
Why non-regulated startups should steal this blueprint
It is easy to look at this and assume it only applies to fintechs handling bank APIs.
I used to think that way too, but that view feels outdated now. Even if you do not answer to a central bank, adopting a lightweight version of these guardrails gives you three massive advantages:
Enterprise sales move faster. The moment you try to sell upmarket, enterprise procurement will put your application through a grueling InfoSec review. Spending six months retrofitting access controls and drafting emergency policies will kill your deal in procurement. Proactive guardrails turn InfoSec into a sales accelerator instead of a bottleneck.
You control your blast radius. A regulatory fine is not the only thing that can kill a company. A fat-fingered database drop, an exposed public object storage bucket, or a leaked API key can wipe out customer trust overnight. Guardrails protect you from self-inflicted wounds.
Data privacy applies to everyone. Regional regulations like the UAE Data Protection Law and KSA PDPL mean that almost every software startup handles regulated data today. The line between regulated and unregulated tech has largely disappeared.
The lightweight version
None of those advantages require a central bank. And none of them require you to build what we built. The four pillars have a minimum viable form, and it is the same four pillars at a starter maturity. Here is what I would build if I were starting today with no auditor and no budget line, inside one quarter.
Targets, lightweight. Classify your data before you set a single target. Four tiers is plenty. Every store, every bucket, every table gets exactly one. Access rules, retention, encryption and vendor reviews all depend on this one decision, which means doing it later is not one task, it is redoing everything you built on top of the wrong answer. Alongside it, keep one register of every number you have promised: uptime, fix windows, retention periods, breach notification timelines. You have promised more of them than you think, scattered across contracts, policies and a security page on your website that nobody has reread since the day it went up.
Process, lightweight. Prioritise fixes by exploitability, not by severity label. Most of a critical list is not actually reachable in your environment. Fix what is being exploited in the wild and what is exposed to the internet on a system you cannot afford to lose. Separately, define your non-negotiables: two or three conditions that override all negotiation, and let everything else be argued on risk. Then, once a quarter, export who has access to what, system by system, and count the accounts nobody can explain. Not the ones you decide to remove. The ones for which no person in the room can name an owner. That number is your real access posture, and the first time you produce it, it will be higher than you expect.
Technology, lightweight. Make evidence a by-product, not a project. If proving something happened requires someone to go and assemble it afterwards, the control is not real yet. Approvals inside the tool, tickets linked to changes, logs retained by default. The test is whether you can answer "who approved this, and when" without asking a single colleague.
You will notice there is no lightweight version of the people pillar. That is deliberate. Muscle memory is the one thing you cannot buy or automate your way into early. It is built by doing the other three consistently until they stop feeling like overhead. Start the other three now, and the habit forms on its own.
The real payoff
For Spare, this discipline pays for itself where it matters most.
Today we hold a SOC 2 Type II report, our information security management system is certified to ISO/IEC 27001:2022, and we operate against the SAMA Cybersecurity Framework and the UAE Information Assurance Standard. When a financial institution runs a security audit on us, the evidence is already waiting for them.
Because we invested heavily in this operational foundation early, expanding our Open Banking platform into new regional markets becomes a repeatable process. We don't have to pause innovation to retrofit our security architecture every time we scale.
And the discipline does not stop at our own edge. Every merchant and financial institution that integrates with Spare inherits it along with the integration itself. The governance we've built is what lets them move fast too, without taking on the risk themselves.
We are not the fastest team at writing unverified code. We are the fastest team at shipping code that survives serious external scrutiny.
Build the guardrails first, and then go as fast as you can.