How can AI speed up software development in regulated industries like fintech?

Fast and compliant are seen as opposite ends of the same rope. Pull on one, and the other gives way. Many fintech teams continue to build as if that trade-off is unavoidable. We spoke to tech leaders who don’t think like that.

Managers at Thredd, Digital Pay, and Brite Payments told us how they build software in regulated fintech environments.

Each of them has rebuilt their process so faster delivery doesn't come at the cost of compliance.

The old trade-off doesn't hold up anymore

For years, the assumption in regulated software was simple. Move fast, or stay compliant. Pick one.

McKinsey's most recent State of AI research found that software engineering teams using AI report cost reductions of 10 to 20%, and 88% of organizations now use AI in at least one business function.

Adoption is no longer the hard part.

The hard part is building the guardrails that let a regulated team use that speed without creating new risk every time they do.

That's the piece most fintechs get wrong about AI in fintech. They treat it as a productivity add-on bolted onto existing fintech software development practices, rather than rethinking what the process needs to look like once AI is part of it.

The three engineering leaders we spoke with reached the same conclusion from different starting points. Speed in a regulated environment comes from structure, not from cutting corners.

Compliance-as-code, not compliance-after-the-fact

Marilyn McDonald, CTO of Thredd, a payments infrastructure company supporting more than 100 fintechs worldwide, made the point in plain terms. The bottleneck was never compliance itself. It was when compliance got involved.

Thredd runs on what McDonald calls paved paths. These are pre-approved AI workflows within well-defined boundaries, closer in spirit to low code development than to writing every integration from scratch.

Once a flow such as code generation inside an approved environment is signed off, engineers don't need to request fresh approval every time they use it.

This is what compliance-as-code means in practice. It isn't a slogan, but a set of rules written into the workflow itself, so approval happens once, at the architecture level, instead of once per pull request.

The payoff shows up downstream. Engineers move through pre-approved territory at full speed, and compliance teams stop reviewing the same category of change over and over. Everyone gets their time back.

TSH saw the same payoff working with xpate, an e-commerce payments platform. Legacy payout processing took 3 to 10 days. With reliability and compliance requirements designed into the Serverless architecture from day one, rather than reviewed once something was already built, that payout time dropped to minutes.

When structure meets an emergency

Pre-approved workflows solve the everyday case. But regulated fintech also runs into moments with no notice at all, and that's where the same principle gets tested under pressure.

Ziad Hilabi, Head of Engineering and R&D at Digital Pay in Saudi Arabia, described this kind of moment. The Saudi Central Bank issued an urgent mandate on a Wednesday, requiring a change deployed across all POS terminals by the following Monday. No advance warning. Two and a half days to deliver.

His team made it, and the turnaround only worked because rapid application development was already how the team operated day to day, not something improvised for the occasion.

Hilabi is clear about why.

Improvisation under pressure would not have delivered such a result.

Compliance and testing checks are already part of Digital Pay's sprint structure, folded into the team's definition of done rather than treated as a separate gate at the end.

Automated regression testing, CI/CD pipelines with strict quality gates, and continuous documentation updates all run before anything is considered finished.

That structure is also why cross-training matters as much as it does at Digital Pay. If someone is unavailable during a two-day sprint, someone else on the team can step into their role, including into compliance and certification tasks, without waiting for a handoff.

• Compliance and QA checks are built into the sprint, not scheduled after it,

• Automated regression and penetration testing run on an ongoing basis, not as a final gate,

• Every engineer has working knowledge outside their core specialty, so no single absence stalls a release.

None of that is AI-specific. It's just disciplined agile software development, applied every sprint rather than only when a deadline is close.

When the rules are built into the process ahead of time, speed doesn't require skipping steps.

Ownership removes the bottleneck AI can't fix

Harald Walden, CTO of Brite Payments, comes at the same problem from the org-chart side rather than the pipeline side. His argument was that a lot of the delay teams blame on the process is a delay caused by who owns what.

He's seen the alternative model plenty of times. One group writes the code. A different group tests it. A third deploys it. A fourth runs it in production.

Brite's developers, by contrast, own their features end to end: architecture decisions, testing, deployment, and running the service once it's live.

There's no dedicated "architect" role sitting apart from the team. Senior developers tend to lead architectural calls in practice, but the decision belongs to the group that will be answering for it later.

That structure has a direct effect on how fast Brite can move. When one team owns a feature from design through production, there's no queue of handoffs waiting for the next department's availability.

Fewer handoffs also means fewer places where something can slip through undetected, which is what drives the downtime and rollback risk that erodes velocity in fintech software development, AI-assisted or not.

Full ownership doesn't remove risk, but relocates responsibility for catching it to the people closest to the code, before it ever reaches production.

The common ground

Three companies faced three different pressure points, AI-specific tooling, an unplanned regulatory deadline, and a growing team's org structure. The answer each leader reached for was the same in structure.

1. Pre-approve what can be pre-approved, so speed doesn't require a new conversation every time,

2. Build compliance into the definition of done, not into a review that happens afterward,

3. Give ownership to the people who'll be accountable for the outcome, and keep the chain of custody short.

None of these fintechs are moving fast by asking less of their engineers or their compliance teams. They're moving fast because the structure absorbs the friction earlier, so it doesn't pile up later, which is what sustainable fintech innovation looks like from the inside.

If you want the full picture, read the original conversations.

• The interview with Marilyn McDonald, CTO at Thredd,

• The interview with Ziad Hilabi, Head of Engineering and R&D at Digital Pay,

• The interview with Harald Walden, CTO, Brite Payments.