Ravneet Shah shares how Allica scaled to 3,700+ production releases per year while operating in regulated banking, adopting AI at 92% across the organization, and building an engineering culture that demands both guardrails and continuous deployment.
She explains how Allica scaled deployment without losing control of risk, built AI trust in stages, and designed its platform so future products can plug in without a rebuild.
Fintech Recoded interviews demonstrate how experienced product and technology leaders make difficult decisions in an environment where resources are constantly constrained, market changes are sudden, and deadlines are non-negotiable.
Scaling engineering velocity demands a cultural foundation
Engineering velocity in regulated banking seems impossible when compliance overhead typically slows teams down.
Yet, Ravneet Shah built a culture of continuous deployment, tested AI in small deliberate steps, and architected Allica's platform so any future product can plug in.
What you'll learn
How Allica went from occasional releases to 3,700+ a year without losing control of risk.
Why trusting AI with financial decisions is a staged process.
How a single customer view shapes every product Allica adds, including ones not yet integrated.
About Ravneet & Allica Bank
From lead engineer to CTO
Michał Szehidewicz: You started at Allica as a lead engineer and are now CTO. What is the moment you are most proud of from that journey?
Ravneet Shah: I joined Allica in January 2020 as a lead engineer, with no previous experience with the bank's stack at the time.
I spent the first few months upskilling and delivered my first initiative after about 3 months, which was a significant release for a bank still setting up its systems.
Early on, I pushed to move away from a patchwork of legacy integrations toward technology we could own end to end.
That led to standing up new infrastructure with a microservices architecture, relying on a team of only 3 or 4 engineers initially who had no prior hands-on experience with the new stack.
We went live in under 6 to 7 months, building the microservices, the infrastructure, and the product at the same time.
Shortly after, the first core banking migration came in, and we had to go through the entire discovery and learning process for a new system.
We set up that core banking system from scratch and built all the integrations to support lending, then migrated data from a third-party bank in under 3 months.
Looking back, it still seems almost unachievable, but that focus gave Allica the boost it needed at the time.
The first big delivery is always the one you're most proud of, because every following migration comes with more confidence and more lessons learned.
Shipping at a scale without breaking things
3,700 releases in a year don't happen by accident. What did your team change to go from shipping occasionally to achieve that number in a year?
This wasn't exactly a 1-year journey.
Back in 2020, Allica released roughly once every 3 months, and each release was an occasional, risky event that depended on remembering every configuration change.
By 2021, engineers were shipping code daily, but no one owned deploying it to production.
We fixed that by giving engineers the tools to go from committing code to deploying it themselves.
We leaned heavily on Google's DORA metrics, measured at the squad level and built into team objectives, so every team felt accountable for the outcome.
Deploying infrequently makes every failure more visible, so we track deployment frequency, change failure rate, and cycle lead time together rather than in isolation.
None of this works without reliable automated testing and observability, which is what gives us the business confidence to deploy during the day instead of waiting for a 1 AM maintenance window.
We also moved from a Git flow branching model to trunk-based development, so any code merged to main is treated as a release candidate, removing the need for a dedicated release manager.
We automated database migrations, something Allica itself used to be nervous about, and trusted engineers with more of the deployment process instead of handing code to a separate team.
Feature flags let us turn a feature on or off in production without a full release, and observability was built in from day one rather than added later.
I want to push back a little here. What do engineers get wrong about working in a regulated environment?
Engineers coming from non-regulated environments are used to fewer constraints on endpoint access and production access.
The friction they notice most is around least-privilege and role-based access controls, and being limited to a set of approved tools rather than bringing their own.
Anything can go wrong in production, and the risk we watch most closely right now comes from frontier AI models specifically.
We keep strict controls in place so the team can operate safely while engineers adjust to a more constrained environment.
Have I understood correctly that you prefer to hire engineers without a regulated background?
My first instinct is to say I prefer engineers without a regulated background, but that's not quite right.
Allica actually hires deliberately from both regulated and non-regulated backgrounds.
Engineers from industries like e-commerce bring different UI and UX instincts compared to other industries.
That diversity of experience benefits the team.
AI adoption and where trust still has to be earned
How did your engineering team reach 92% daily AI use, and what does that actually look like day to day? The result is exceptional.
AI adoption inside engineering is actually 100%.
The 92% figure is the adoption rate across the whole organization.
Allica started with GitHub Copilot in early 2025, but adoption was mixed because the tool itself only supported code completion at the time.
Some engineers worried AI would erode the craft they were proud of, so early usage was encouraged from the bottom up rather than the top down.
The real shift came toward the end of last year, when more capable models such as Claude arrived and adoption accelerated.
AI is now used for bug triage, observability, and converting designs into codable UI applications.
An AI-first design library cuts application build time for standard components by 80 to 90%, though more complex components still take longer.
That actually connects to something a lot of people are wrestling with right now, especially when AI stops being just a coding assistant and starts touching real financial decisions.
How do you decide when an AI tool or agent is ready to be trusted in a live banking system, especially when it's involved in financial decisions?
Allica doesn't build its own AI models, so any third-party tool or model has to earn trust before it goes into production.
Every change bound for production follows a defined process, whether it's a traditional change, an AI tool, or an agent.
The release process for AI agents is still evolving, but it starts by onboarding a third-party tool or model and reviewing legal, information security, and model risk.
We run evals and tests to build confidence in what the agents produce.
Validation and verification checks, including guardrails, come before anything goes live.
Trust gets built in small, deliberate steps.
Your approach sounds measured and thoughtful, but not everyone is moving that way.
Do you think most banks are ready to let AI make decisions without a human checking the results?
That depends entirely on the risk behind the specific decision.
A few years ago, trusting AI with a personal financial decision felt far off, but consumer mindset shifts over time.
My parents took years to move from walking into a branch to using an app, and the same adjustment period will likely repeat with AI.
A human stays in the loop today, but that role might become less critical for banks and consumers as trust towards AI grows.
When AI starts touching money flows on behalf of customers, what keeps you up at night from an engineering perspective?
Access to data is the core concern, especially after hearing about AI agents deleting entire databases elsewhere.
Allica follows least-privilege access, role-based controls, and maintains backups and recovery as standard practice.
What worries me most is the unknown.
The risk from frontier AI models that hasn't surfaced yet.
Visa, Mastercard, and Stripe have been working on technology called agentic payments. What's your take on that?
Agent-to-agent payments are closer than people think, and the guardrails around them are being actively tested right now.
How people interact with banking will shift from clicking through an app to simply telling an agent to make a payment.
Longer term, an agent may operate the app on a customer's behalf rather than the customer navigating it directly.
That future is already starting.
Build versus buy and hiring
Allica recently added a big new piece to the puzzle by acquiring Kriya, a payments and embedded finance fintech.
How does integrating a payments product into a banking platform change the engineering challenges you face?
The architecture was never built around a single product.
It was built so any new product can plug into the core infrastructure.
The clearest example is commercial mortgages and asset finance, which originally launched on 2 separate systems with no way to see a shared customer across both.
That gap led to building a single customer view, so Allica knows every product a customer holds and can work with them accordingly.
In general, how do you decide what to build in-house versus what to outsource to a partner?
Allica made an early, deliberate decision never to build its own core-banking systems, and partnered with third parties for lending, commercial mortgages, and payments infrastructure instead.
Every customer-facing journey stays in-house, including a purpose-built loan processing hub covering the full journey from broker submission through servicing.
Building that hub in-house gives Allica the flexibility to tailor the journey to its own requirements, something no off-the-shelf system offers.
The same build-versus-buy logic applies to AI tooling.
Allica buys tools that benefit from a vendor's experience across many customers, and builds only where deep customization is needed
Allica recently closed a $155 million Series D, with international expansion on the horizon, so the bar gets higher.
Considering all of that, what do you think is harder to scale, the headcount or the knowledge?
Both are hard, but scaling headcount without also scaling culture is the easier half.
Finding people who share the same passion while also bringing fresh ideas is difficult.
Allica built its architectural foundations to be easily duplicated, which let the team scale consistent patterns rather than requiring every engineer to master every business domain.
Lending, payments, and transactional accounts each need their own domain knowledge, but the underlying architectural practices scale across all of them.
Are you still personally involved in hiring, or do you trust people to do that on your behalf?
I stay involved in hiring at the lead and principal level, but not for senior engineer or engin
I trust the team closest to those hires to make the call.
Skip-level interviews across different domains and levels help me stay close to what engineers are actually experiencing day to day.
I always like to end the interview with something forward-looking. What does success look like for your engineering team, and for you, in the next 12 months?
Allica is pushing to turn domain-specific engineers, whether backend, frontend, or a specific language, into T-shaped technologists who can reason about a problem regardless of their original specialty.
AI has removed much of the barrier to learning outside one's original domain, which is what makes that shift possible now.
I'd have to check the exact figure, but I think roughly half of engineering has already made the shift to T-shaped roles, out of a technology team of about 150 people, with the rest either exploring the shift or intentionally staying specialized.
What about the remaining 10%? Are they still in the process, or are they just too specific in their roles?
The engineers who stay specialized do so on purpose.
Their roles are specific enough that Allica wants them focused rather than generalized.
Is there any closing remark that you would like to share?
Being a CTO has been a significant journey since joining as a lead engineer, with a lot of learning and hard work along the way.
As an engineer, satisfaction used to come from what I personally shipped by the end of the day. That changed.
Success now comes from what the people I lead deliver.
It took time to accept that shift, but it's core to the move from engineer to CTO.
3 moves worth making
Give engineers ownership of the full deployment pipeline
Allica's shift to 3,700 releases a year didn't come from writing more code.
It came from making engineers responsible for deploying it too.
Track deployment frequency, change failure rate, and cycle lead time together at the team level.
Automated testing and observability have to exist before speed is safe.
Test AI internally for a full cycle before trusting it with customer-facing decisions
Allica started working on AI workflows internally in 2024 before deploying anything to external, customer-facing applications.
Every new AI tool goes through a structured review of legal, information security, and model risk before it touches production.
Move in small, deliberate steps.
Deploying an autonomous agent straight into a live application is a risk worth avoiding.
Architect your core platform so any future product can plug in
When Allica launched commercial mortgages and asset finance on 2 separate systems, no one could see a full customer across both.
That gap led to a single customer view, which now shapes how Allica adds every new product, including the still-unfinished Kriya integration.
The principle behind these decisions is simple.
Buy the infrastructure that doesn't differentiate the business, and build the customer-facing journeys that do.
Authors
Michał Szehidewicz
I have several years of experience in C-level management and B2B sales in various fields such as financial services, SaaS solutions and software development. I'm obsessed with business development, startups, new technologies, personal growth and the NBA.
Michael Sols
Content fixer: B2B Copywriter, Marketer, Strategist. Often questioning reality — to find facts that make business decisions good, of course. Connected with technology since training his family in the basics of Windows 98. Authored brand stories out and about the software market that were published by WIRED UK, Silicon Republic, The Sun, and Vanity Fair. Also, you deserve a raise.