Once AI removes the limit on how fast fintech engineers can build, the hard part becomes choosing what's worth shipping.
Ross Harty, the VP of Product at 10x Banking, explains how his team chooses which features reach a customer now that writing code takes minutes.
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.
AI removed engineering's speed limit
Once AI can build most of what a bank asks for, engineering speed stops being the constraint on what ships.
The real bottleneck moves to deciding which features are worth building at all and making sure the data, adoption, and accountability behind them can support the decision.
Ross Harty explains how his product team chooses what to work on now that writing code takes minutes.
What you'll learn
Why layering artificial intelligence onto a broken process only speeds up the damage.
How to manage the tension between the pace of AI and adoption by non-technical users.
Why individual accountability rules should shape how fast banks let AI ship.
About Ross & 10x Banking
Every bank buys and deploys differently
Michał Szehidewicz: AI is reshaping how fintech software gets built, both for standalone products and for bank partnerships. What has changed most at 10x Banking since you joined three years ago?
Ross Harty: When I joined three years ago, 10x Banking had scaled quickly with major clients including Chase, Westpac, and Old Mutual in South Africa.
The company was heavily delivery focused, rather than product practice or scalability.
My early role was to help make 10x more product-led, with clearer strategy, better decisions, and the right team structure.
We had to adapt standard product practices to a business where every client is different and your traditional ways of validating decisions like large-scale A/B testing, isn't realistic.
Long, individually negotiated bank sales cycles force different trade-offs than a typical software company faces.
We've made real progress over three years, but the shift to a product mindset isn't finished, and agentic AI development is now reshaping the picture again.
I think we're further along on that than many product leaders I meet at industry events, but we've still got more to do.
What's the hardest part of getting new features live with legacy banking partners?
There are two challenges we run into most often.
The first is that our release cycle and a bank's project cycle can run at different speeds.
We use an agile approach and deploy changes quickly, while many banks still rely on project-based, waterfall processes.
Waterfall processes tighten further during a migration from an old core to a new one.
Our flexible roadmap and their fixed deadlines, budgets, and reporting requirements, can pose a challenge.
The second problem usually sits one layer behind a bank's most recent modernization.
Even after a bank modernizes its core, the systems around that core often still run in batches.
Payments integration is a good example.
Some payment schemes are still batch-based, running only Monday to Friday, and it can take up to 48 hours to know whether a transaction record has an issue.
Getting a real-time, event-based system to cooperate with a scheme like that throws up edge cases we've had to work through over the years.
Most modernization programs I come across run for years and stall somewhere in the middle. Has a bank you work with taken one all the way through to production?
Yes, we've seen it work, and one example is recent.
A couple of weeks before this conversation, we completed a full production migration for Move Bank in Australia with our partner Constantinople.
The Move Bank migration covered the full stack, from origination and product creation to the core, servicing, and operations.
Tens of thousands of accounts and millions of transactions came off a legacy system.
On the greenfield side, Chase in the UK and Old Mutual in South Africa show that large institutions can use modern technology to launch challenger products and grow quickly.
Together, Move Bank, Chase, and Old Mutual show that transformation can work at scale, whether a bank replaces its legacy system or runs a new platform alongside it.
Banks replace old core systems to keep customers
What do banks still get wrong when they modernize onto a platform like yours?
When we talk to a bank, one of the main points we make is that our platform isn't built around fixed products.
The platform is built from modules like interest and fees.
A bank can either recreate what it already offers or combine those modules into something new, as Old Mutual has.
Recreating the existing setup can still be a good reason to modernize.
A like-for-like rebuild can lower costs, improve scalability, and reduce risk.
But if that's the only goal, the bank misses a bigger opportunity.
The bank could use the same programme to rethink the customer experience.
Core modernization programs take years, and sooner or later the investment gets questioned if costs rise or timelines slip.
If the whole business case is based on saving money, that becomes much harder to defend if the program goes over budget.
A named customer outcome is what a team defends when budgets and timelines get challenged, and that outcome focus is what sets the likes of Revolut and Wise apart from day one.
I think about product strategy the way you'd think about sailing.
You know the direction you're heading, but you tack with the wind rather than traveling in a straight line, and as long as you keep making progress that way, you’re on the right track.
Why are banks pushing so hard into digital transformation right now?
Is this driven by challengers such as Revolut and Wise, or is it what customers have come to expect by default?
There are three drivers, and they've built on each other over time.
Market pressure, where customers got a taste of better digital experiences from challengers like Monzo, and what started as a narrow early-adopter expectation is now what almost every customer expects.
Infrastructure risk, since some bank cores are 30 or 40 years old, and the volume of systems stacked on top of them over the decades is starting to cause real breaks.
UK banks have had payment outages on payday more than once in the past two years, which put those failures on the agenda of board risk committees.
Cost pressure, built up over years of low interest rates, squeezing margins.
AI needs clean, live data to learn from, and a batch system updating weekly with messy records can't train anything useful.
So a bank now faces being unable to lower its risk profile, keep pace with competitors, cut its costs or truly leverage AI without moving to a true next generation platform, like 10x.
Weak data is also why so many of the chatbots banks have bolted on so far feel underwhelming.
Nobody collected the real-time customer data a chatbot needs to answer anything useful.
Even so, I think some banks will run visible AI projects while leaving the systems underneath untouched.
Announcing a chatbot is quicker than replacing a core, and it looks like progress to a board.
Skipping the core work rarely ends well, but it is the easier path, so I expect some banks to take it anyway.
Customers can't learn features that fast
Why do so few technology leaders talk about training the people who'll use AI-built software?
The problem reaches past banks to any non-technical business user of a B2B product; because adoption has always been the real hurdle.
We've all worked somewhere that replaced a tool with something supposedly better, only to make people learn a new system and enter the same data twice.
The cost of relearning a tool often decides whether internal software gets adopted at all.
There's a lot of focus now on how fast engineering can ship.
Product teams are under the same pressure to move quickly, while still making sure what gets built is useful.
What's missing is whether the person on the other end learns to use what was shipped and gets value from it.
Adoption is what shows up in business outcomes later.
In B2B especially, the product doesn't stop mattering the moment it ships.
Even if you ship 50 well-researched features, your customers' non-technical users have only so much attention to take it all in, so you've shifted the bottleneck onto them.
The airline industry has an idea called healthy friction, where a buyer who spends a large sum in one click ‘too easily’ starts to doubt the decision.
I think something similar applies here.
There’s an argument for spacing releases out rather than shipping every AI capability as fast as it can be built, as it gives people room to work out what they already have and get value from it.
Spacing matters even more in B2B, where non-technical users can only absorb so much, and messy adoption data makes it hard to tell whether a feature helped at all.
Now that AI builds so much of the software, is there still space for user research and MVPs?
Yes, if anything, those things get easier and faster with AI.
Faster building does not force you into worse decisions, as long as you keep testing what customers need.
When engineering can move that fast, the product org needs to move even faster to make sure what gets built is worth building.
And then on top of that, the bit that's still missing is what happens after you ship.
Does the person on the other end learn the new capability?
A good AI chat interface is still something users have to learn from scratch.
Keep shipping at that rate and the same interface carries fifteen features instead of three, six weeks after launch rather than six months.
Fifteen features in six weeks could be information overload rather than progress.
There's also a runtime question.
Once something is shipped, someone has to be accountable if it breaks.
Accountability matters most in a regulated industry, where the standard first question is how the system did what it did and what the customer impact was.
None of this argues against building faster.
But every new capability adds complexity, so oversight has to grow with it.
I don't think we talk enough about that trade-off.
We've been testing how to create products using natural-language prompts.
The approach is useful, but it raises questions about governance right away.
If an interest rate goes live wrong, was that the agent, a bad prompt, or a fat-finger error that set a rate at 40% instead of 4%?
Getting a decimal place wrong on an interest rate has real consequences, so a bank must know how it would catch that error before shipping AI-generated features.
Even a sensible upper limit on the field doesn't catch every version of that mistake, so the governance question has to be answered before the capability goes live, not after.
Natural-language product creation itself isn't the risk.
The surrounding controls, and who's accountable for them, have to grow as fast as the capability itself.
Two people approve what AI will build
My previous guest, Alex Mifsud of Weavr, argued that the missing piece in the conversation about AI in fintech is accountability, since software can't be held responsible the way a person can. So, who is accountable when an AI agent gets something wrong at a bank?
In the UK, there's a rule called the Senior Managers and Certification Regime, brought in after the financial crisis.
The regime holds specific named executives, as individuals, accountable for decisions made under their watch.
If something goes wrong, the person designated as accountable is liable individually, whether or not they built the system that caused the problem.
I don't work inside a bank these days, so these conversations don't reach me.
My sense is that boards and investors are pushing hard to be seen as making visible progress on AI.
Board pressure sits alongside a more personal question, since if an agent goes rogue, the executive who signed off answers for it.
The executive carrying that liability needs to feel confident that the controls are in place, while their board wants to see visible progress.
The real question is whether a bank's risk and control processes can keep pace with the new capabilities AI creates, not just with the speed of development.
I'm curious what you've put in place at 10x to make sure your own risk and control processes scale at the same pace as your AI capabilities?
There are two halves to what we've done.
On the bottom-up side, we set aside space, within clear guardrails, for people to experiment.
Some people in product and engineering are further ahead and more hands-on with these tools than much of senior leadership, and we don't want to stamp that out.
Everyone in product and engineering has access to Kiro, Amazon's AI assistant.
People are encouraged to experiment with different approaches and create reusable prompt skills.
We've also run a couple of hackathons to test new ideas.
We took the best ones and worked on turning them into production-ready tools.
When several people have developed similar skills, we look to combine them into a shared version that everyone in product and engineering can use.
On the top-down side, we’re running a transformation program with check-ins every couple of weeks against success metrics we've set ourselves.
Each check-in covers both the team-led change and top-down strategic transformation, with a focus on ultimately tying it back to the metrics we’ve set.
In some product teams, a product person and a tech lead write the plan first, the team signs off on it, and only then does an AI agent build it.
Other engineering teams, especially those touching the core of the platform, choose to move more slowly because our risk tolerance there is different.
We scale the top-down push where we've already found value and leave room for bottom-up experiments everywhere else.
The last piece, and the one we're still developing, is tying AI adoption and efficiency goals to learning, development, and performance management.
With those goals written down, team leads can then be accountable for measurable improvement in their area.
Product teams waste AI budget on messy data
Rolling tools out across product and engineering is a lot of internal change to manage.
Was there a moment that convinced you AI wasn't just a quick fix for operational problems?
When we started experimenting in earnest, a lot of what came up wasn't "we need more software," it was "we need better data."
AI doesn't fix an operational problem on its own.
Where you already have good practice, it makes you faster.
Where the practice is poor or the data is missing, it makes the mess bigger and faster.
I like the analogy of putting a much bigger engine into a car without touching the brakes, the suspension, or the steering.
All that buys you is a much faster accident.
So the real test is whether AI helps you achieve something you couldn't achieve otherwise, not whether you can find a reason to use it.
We're past the pure-experimentation stage now.
We've identified a handful of upgrades we trust, and we're rolling those out.
Fixing the underlying business process and the data behind it still matters just as much as adding the AI capability on top of it.
How do you decide whether an investment in AI is worth making?
The decision always comes back to outcomes, in any industry, but especially here, because the tooling and token costs add up fast.
Whatever you're doing, launching a feature, buying a tool, changing the team, or combining roles, it should support a broader business goal.
Otherwise, you end up reporting activity that no part of the business asked for.
The business goal doesn't always have to be revenue or profit.
But you do need to be clear about what you expect the investment to achieve.
A useful test for any AI tool is to compare its cost with something like putting extra budget into marketing your existing product – what’s actually going to deliver real return on investment?
I also think you have to accept there will be some level of stepping into the unknown here too - I made that mistake myself.
I assumed AI tools were useful for scrappy startups, but not for regulated businesses.
About a year ago, I realized full scale banks were already getting more value from these tools than we were, even with much stricter accountability requirements.
So don't be risk-averse or scared.
Change your processes and challenge your assumptions where you need to, but also understand the outcome you're trying to achieve before you do it.
I like asking this because reflection tends to reveal the most useful lessons. Looking back, what would you do differently with your first AI project?
I wouldn't change the project itself
I'd change what came before it.
I would have spent more time first on the unglamorous groundwork of closing the gaps in our reporting and our underlying data.
You don't need to fix everything before you start experimenting.
But in hindsight, doing some of that groundwork first would have helped us move faster later.
Instead, we started experimenting, then had to pause and fix those same issues before we could scale what we'd built.
If AI keeps improving, which seems likely, how will banks build software in five years?
Banks are always a bit behind the curve, and that's not necessarily a bad thing.
They handle people's money, so they're probably right to be among the slower adopters.
I think it'll start to look like what the best teams already do, with commercial people sitting much closer to the technical details because they understand what they're trying to drive.
Working that way differs from the classic handoff from commercial to product to engineering.
Teams are likely to get smaller and tighter, maybe two to four people, pairing someone watching the market with someone who can execute and deploy.
Sometimes that means writing the prompt itself, which then gets handed off or actioned in parallel.
Competition speeds up, because when a rival raises its savings rate, a bank can respond within minutes rather than days.
Process, risk, committees, and sign-off have always been something of a bottleneck, and rightly so, but faster building strains them further.
The harder question is how you let someone change pricing six times in a month while still tracking every change and its reason.
Five years might be too soon to remove the dependencies between teams, because organizational change always runs slower than people expect.
The more likely near-term shift is getting every bank onto a modern core banking system in the first place.
If the rest of the architecture is modernized, that one piece becomes the single blocker holding everything else up.
After that, I think the technology focus moves outward from the core banking and product layer to the surrounding operational processes, legal, finance, and similar back-office functions.
The goal is removing the blockers still sitting there.
To wrap things up, what's the one piece of advice you'd give other product leaders, regardless of company size?
Understand the outcome you're trying to achieve before you start, whether the work is a product change or a new tool.
Decide which tangible value you expect the work to change, then check back honestly and keep iterating.
Tie that to a long-term vision that names what you're building toward, what you're doing right now to move closer to it, and how that action moves you closer.
Then check whether it worked, and repeat the cycle.
If you do those two things, a real long-term vision and an honest habit of checking real-world results against it, you're unlikely to go too far wrong.
Checking results honestly is something product leaders, myself included, still struggle with.
3 moves worth making
Fix data gaps before you plan the AI roadmap
Figure out the data fields and reporting your first AI use case depends on, then mark the ones that are incomplete or updated too slowly.
Fix those before you commit to a delivery date, because a half-built rollout costs more to restart than to plan in the first place.
As part of the AI transformation at 10x, nearly as much time has been spent on this as the roll out of actual tools or code.
Measure adoption as much as new releases
Check how many people are actually using the last new feature or change before you ship the next one.
If usage is still climbing, or behind what you expect, spend time on things like guidance, training or customer awareness before worrying about the next shiny new feature.
Ross Harty's product team tries to focus just as much of their customer conversations around this as they do what the next thing looks like.
Set clear boundaries for AI
Write down clear limits for what an agent can and can’t do and which roles must approve any AI output that doesn’t fit those limits. This helps balance control without meaning every change needs a full review.
At 10x Banking, both a product person and a tech lead approve the spec and design before an AI agent acts.
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.