Relay holds the bank accounts of 150,000 small companies that use the platform to pay their staff and suppliers. The company is now testing whether AI could auto-send some of those payments for the account owners.
Paul Klicnik has already found the limit of agentic payments and knows which of them a customer will hand to AI and which they want to see first.
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.
Payment automation can’t evolve without the customer’s trust
The safest payments to automate are the ones the owner has already set up as recurring.
A business owner can tell Relay to move 10% of every deposit into a tax account, and that transfer then runs without anyone approving it.
For payments the AI initiates itself, Relay tests those with customers, writes evaluation suites, sets confidence thresholds, and asks the owner to approve anything that cannot be undone.
Paul Klicnik, Relay's CTO, explains how a fintech team works out which bills it can pay without asking the owner first.
What you'll learn
What customers told Relay after a reminder bot called their vendors, and why that changed the product.
How a low confidence score stops a payment before anyone has to catch the mistake.
Why Paul Klicnik will not hand his own business finances to AI end-to-end, even while automating more of the platform.
About Paul & Relay
AI takes the busywork off Relay's engineers
Michał Szehidewicz: You co-founded Relay in 2018. How has engineering changed since then?
Paul Klicnik: It has changed because of AI, full stop.
Coding was the first obvious shift with AI-powered coding tools. I think back to Relay's early days, when I was still a hands-on keyboard. If we'd had these tools then, it's mind-boggling to think about how much more progress we could have made.
But it goes beyond writing code. AI changes how we think about development, the delivery lifecycle, internal workflows, and coordination between teams.
Nobody has completely figured this out yet. We're learning together, sharing what works, and trying to level each other up as we go.
Some of the CTOs I talk to deliberately keep a few AI skeptics around.
Marilyn McDonald, Thredd’s CTO, called them the “guardians of the past”. Do you see the same tension at Relay?
The biggest difference is usually experience.
Engineers early in their careers coming straight out of university have grown up AI-native. They tend to embrace these tools immediately.
For people who have been in the industry longer, it can take more time. They have established ways of working, and sometimes they're understandably concerned about what the new tools mean.
We introduced the tools step-by-step. First, everyone got Cursor, then Claude Code, and we ran internal sessions where people shared workflows and best practices.
Eventually, people have their aha moment. They automate something they never particularly wanted to spend time doing anyway, and suddenly, they can focus on a higher-level problem.
If someone told me I'd never have to write another React component again, I'd say "hell, yeah".
That's how I prefer to frame AI internally. It removes low-leverage work so people can spend more time solving actual business problems.
But the experienced engineers still matter.
Someone who has spent ten years working at different levels of the stack has learned where systems fail. A graduate asking for an LLM may not even know which question they need to ask yet.
For now, those experienced engineers provide important guardrails. Maybe that knowledge gap narrows as the tools improve, but we're still in the transition.
Customers write the transfer and payment rules Relay follows
Let's make this personal. Would you hand your own business finances to AI today?
Not end-to-end.
When we ask customers that question, the answers fall across a spectrum.
At one end are very tech-forward businesses who want APIs and MCP so they can automate everything, and who would be happy never logging into Relay again.
At the other end are customers who aren't anti-technology at all. They just want to build trust before they hand over more control.
Almost universally, people still want to be in the loop somewhere.
That doesn't mean an LLM can't generate a signal, make a recommendation, or help someone reach a decision faster. But fully autonomous financial management is different.
For now, “trust but verify” is the best model.
So what can you automate confidently today?
The easiest processes to automate are the ones where customers understand exactly how the decision was made.
Take auto-transfer rules.
A customer can tell Relay that whenever money comes into an account, 10% should go to taxes and 20% to payroll.
That's a deterministic system. The mental model is simple, so people trust it. We're not deciding what the customer should do. The customer has already told us exactly what should happen.
Recurring payments can work the same way.
If you receive the same invoice from a vendor every month and you completely trust that vendor, you might tell Relay to pay it automatically.
You don't need to automate your entire financial life to remove that one repetitive decision.
The interesting next step is to use the same principle for things customers currently have to anticipate on their own.
We're prototyping around sales tax, for example. A business owner may be focused entirely on surviving today and not thinking about an obligation thirty days from now.
If Relay can see what's coming, it can help start setting money aside in advance.
Inventory works similarly. If your sales history shows you will need $10,000 for stock in October ahead of the holiday season, Relay can tell you in January to start putting about 15k aside.
That's where automation becomes useful. The back office starts taking care of predictable work before it becomes a problem, without AI making a financial decision for you.
What Relay learned when its reminder bot fell flat
Before an automated decision becomes a product feature, how do you decide whether it will actually work for customers?
The first thing is not treating AI as something that needs to be shipped for its own sake.
When these tools first appeared, of course, we had conversations about how to integrate AI into the Relay platform.
But we made a conscious decision to reframe that.
AI isn't the product. It's a tool for solving a customer problem.
Once you do that, AI features become normal product problems.
Start with the customer outcome. Do discovery. Build a lightweight prototype or MVP. Put it in customers' hands and see what happens.
Then the important question is whether customers trust the result.
If they don't, maybe you need to show them more of the reasoning. Maybe they need better auditability. Or maybe you simply got the product wrong.
Once we've seen enough signals that something is useful, we build evals around it.
Then, once it's running, production data should feed back into those evals so the system keeps getting tested against what actually happens in the real world.
What's an example where that real-world test changed your mind?
Our reminder bot.
The problem looked straightforward.
A small business sends an invoice, the customer doesn't pay on time, and cash flow suffers. So we built an AI bot that could call the person who owed the invoice and ask about payment.
At a high level, customers liked the idea.
Then we put it in front of them.
People started saying, "I have a personal relationship with this vendor. I don't want a robot calling them."
Others worried because they couldn't be completely sure what the bot would say to their client.
Those are perfectly fair objections.
The feature ultimately underperformed because we misjudged where AI would deliver the most value and where it would be trusted to help our customers.
Our customers’ feedback helped us understand where the boundary for AI actually was.
I don't consider that a failure. We learned something much more useful than we would have learned by discussing the idea internally.
We learned where the customer's boundary actually was.
And the technical side taught us something too.
The bot once said something on a call we hadn't anticipated. It wasn't necessarily bad. It just went off script in a way that wasn't as helpful as we wanted.
That's exactly why evals matter.
Non-deterministic systems will occasionally do something you didn't anticipate. The evaluation layer is what lets you catch that, learn from it, and make the next version better.
It's where we spend the majority of our time.
Let the customer decide how much autonomy is enough
Moving money raises the stakes. Where does a person still have to stay in the loop?
It depends on the customer.
Some people genuinely tell us: “I never want to log into Relay again. Let me connect through MCP and automate everything from my own dashboard”.
Other people want verification before every meaningful payment.
Our job is to support both while keeping the customer in control.
For many businesses, the right experience is incredibly lightweight.
The system can prepare the payment and send a push notification that says: "Here's what we're about to pay. Press yes to approve it."
The business owner doesn't have to log in, review the bill from scratch, or manually issue the payment.
They only verify the final action.
That's still a huge amount of automation.
For critical, non-reversible decisions, verification matters today.
Maybe that changes as people build more trust in these systems.
What about transaction limits? How do you decide how much an automated system should be allowed to spend?
I don't think Relay should make one universal decision for everybody.
Imagine your account has a $10,000 daily transaction limit.
You might still decide you're only comfortable letting automated payments use $100 of that.
You should be able to set that yourself.
Then, as soon as an automated payment crosses your threshold, Relay puts you back in the loop.
That limit should be highly configurable because risk tolerance is personal.
As customers become more comfortable, they can expand it. The important thing is that they're the ones deciding how much control to delegate.
And if the model itself isn't confident?
That's another reason to break out of the automation.
If we're evaluating a payment and its confidence score isn't as high as it should be, we should alert the user rather than pretend the system knows.
When confidence drops, the automation should stop and hand the decision back to the customer.
Ideally, you reach a world where you never send out a payment that is wrong.
But when you're unsure, the right thing to do is ask.
The worst outcome isn't only losing money. Even if we could recover that money afterward, we've created a headache for the business owner and damaged their trust in Relay.
Preventing that is our responsibility as the platform.
Nobody yet lets a bill arrive and get paid untouched
How close is the wider market to fully agentic payments?
Most of the market seems to be in roughly the same place we are.
Companies are comfortable automating individual parts of the back office today.
What we don't see much of yet is a complete end-to-end flow where a bill arrives, gets validated, and gets paid without anyone being involved.
The interest is definitely there.I was at a conference recently and spoke to around ten Relay customers. Nine of them asked about API or MCP access.
But none of those nine were ready to put a completely agentic payment system into production.
They want to experiment first.
That tells you where we are. People want access to the technology so they can start building trust in it.
As an industry, we'll keep figuring out the guardrails, customers will become more comfortable, and eventually these systems won't feel unusual anymore.
A timeline around 2030 for agentic finance becoming normal sounds reasonable to me.
Humans and computers need to trust each other a little more first.
Does that same confidence in AI change how you think about Relay's engineering team?
Absolutely. I had a very personal reminder of it recently.
About ten years ago, I started building my own personal-finance application. I got maybe halfway through it and eventually abandoned the project.
Last weekend I picked it back up.
In about four hours, I rebuilt everything I'd already made and finished the other half.
I added features like semantic search and automated receipt management that would have been very difficult for me to build back then.
That was eye-opening.
The important part wasn't that AI wrote code quickly.
It was that the busywork disappeared, and I could move straight to the questions I actually cared about. Is my budget right? Where am I spending too much? What can I optimize?
That's the opportunity I see for Relay as well.
AI gives engineers more leverage. It speeds up testing, implementation, and delivery.
It doesn't mean we're hiring fewer people.
We've actually increased hiring, because people who know how to use these tools well can create dramatically more value.
We're looking for engineers who are comfortable building with AI and know how to leverage it.
I don't see this as a doom-and-gloom moment.
It's an empowering one.
3 moves worth making
Automate the payments a customer can predict
A recurring bill for a fixed amount is among the safest places to begin, because nothing about it has to be worked out.
The customer knows what will leave the account before it goes, so a product paying it for them asks for little trust.
That trust is what makes the same customer willing to try a payment AI picked on its own.
Ask customers about an automated feature before building it
Some people reject automation for reasons that have nothing to do with whether the code runs correctly.
Relay learned this from a bot that phoned people who owed its customers money.
The bot worked, and customers still switched it off, because they did not want a machine calling someone they deal with personally.
A prototype could have surfaced that objection in days.
The limit on automated payments belongs to the account holder
One business owner will let AI pay out thousands without being asked, while another will not go past a hundred.
A cap the platform sets for everyone leaves the first owner unable to automate much and pushes the second further than they want to go.
An owner who picks the cap can start at a hundred and raise it once the product has proved itself, with an approval step on any payment that cannot be reversed and a stop whenever the model is unsure.
Authors
Michał Szehidewicz
I'm a product delivery consultant with 12 years of experience across enterprise and scaleup businesses in financial services, SaaS, and software development. I help CTOs, CPOs, and CEOs unblock their software delivery, and I have worked in C-level management and B2B sales myself. Today, my focus is GTM engineering. I also host Fintech Recoded, an interview series with senior product and technology leaders at fintech companies. At tsh.io/fintech-recoded, you can read how these leaders make hard calls under real market constraints and uncertainty. Outside work, I'm a father of 2 with a newborn daughter and 1 unruly border collie. Everything else I love is in the mountains except 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.