Software companies embed Weavr's accounts and cards in their products, and now want AI agents to move their customers' money.
No agent can be held responsible for a payment, so Weavr needs a named company or person behind each one.
Alex Mifsud, Co-founder and CEO of Weavr, explains how to prove who that is before a dispute.
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.
Proving the customer approved the purchase
Connecting a product to a payments API so an agent can make a payment is about 5% of the work.
The other 95% is being able to prove the customer approved that payment once they open a dispute.
Alex Mifsud has built payments businesses since the early 2000s, and he now argues that software companies should plan for the dispute first and build the integration second.
What you'll learn
Software companies are using 3 patterns today to put AI agents into payment flows,
Agents can run repeating payments now, and full control over personal finances waits until around 2030,
The software running a payment knows more about the customer's intent than their bank ever will.
About Alex & Weavr
Software we once blocked now gets let in
Michał Szehidewicz: You have built 3 payments companies now, Entropay, then Ixaris, and now Weavr, which is a pretty unique vantage point.
What are you most proud of building?
The one thread through all 3 companies is the shift from making online payments possible to making software able to act financially on its own.
We are now at a point where agentic AI makes all of that real.
There are a couple of things I'm proud of.
One is my own little part in inventing virtual cards.
With the Entropay business, we launched the world's first virtual prepaid card in 2003, after spending a couple of years working on the concept.
At Ixaris, the big thing for me was getting global distribution.
We did deals with Amadeus and Sabre in travel, and that showed us how the game changes at global scale.
With Weavr, it's still a work in progress, but there's one piece worth naming.
We created a finance modeling language called FinML which lets us talk in a structured way about how different financial structures fit together and how they create the right setting for answering questions about regulation, security, and compliance.
The language was a good first step, and getting AI to use it to help us design better systems is where it goes next.
Getting the concept first is one thing I’m really proud of.
You have said openly that agentic AI without embedded finance can only suggest actions and can’t carry them out, and I think that sits at the heart of agentic payments.
When did that idea click for you?
The world has moved on since I said that.
There are now candidates for enabling agents with payments, including AP2 from Google, Visa's Trusted Agent Protocol, and Mastercard's Agent Pay, although the last 2 are card-centric.
In embedded finance, you always have software driving the financial service rather than the reverse.
You have software doing your accounts payable, and it needs to pay suppliers as part of that.
So you have software in the middle of the transaction.
If the software behaves badly, bad things happen, and you always have to make sure the customer’s consent is there.
We built our systems to keep AI bots out, and now we have to rebuild them to let the right ones in.
In Europe, strong customer authentication rules mean any payment service needs 2-factor authentication before a customer can authorize a payment.
The moment I saw the power of AI, I started to think about how the interaction would work between those regulatory requirements and agents.
For most of the life of electronic financial services, software trying to access a payment was called a bot, and we did everything to stop it.
Now, we want that software to make the payment.
Someone has to answer for a bad payment
Most people building AI agents treat finance as an integration problem, where you plug in Stripe and you're done. Does that miss the point? I can already guess your answer.
Wiring up an API takes almost nothing now, and it's the easy 5% of the problem.
As Spider-Man says, with great power comes great responsibility.
Carrying that responsibility is the hard bit.
Financial institutions apply strict security and compliance standards.
A bank ends up responsible for what happens, so it stays cautious about letting third-party software, let alone autonomous agents, do transactions on a customer's behalf.
The real question is who's responsible when things go wrong, and how you stop it from happening in the first place.
Answering that is a legal problem and a technical problem at the same time.
How do you prove you've done everything you need so the customer knows what's happening and agrees to it?
Legal solutions exist, and so does technology that informs the customer and captures consent in a way a fraudster can't get past.
Technologists should be putting their effort into that consent layer instead of the API integration.
Let's ground this in what's happening on your platform right now. How many of your current customers are already building AI agents that touch payment flows?
Most of them are.
Our customers are the embedders, meaning the software companies that integrate financial services into their own products.
I can't think of one that isn't adding AI today.
One employee benefits platform we work with has been public about how AI changes the customer proposition, and others are quieter but doing the same.
We see 3 patterns.
In the first pattern, the software gets the data in, runs the workflow, and sometimes collects consents inside the organization, while a person still authorizes the payment.
Most of what we see is that first pattern.The second pattern is where the AI agent already has the credentials to take money from an account to pay a supplier.
Agents with credentials are more ambitious and more value-adding.
Few companies use that pattern, because there are no established protocols for accounts in Europe once strong customer authentication applies.The third pattern is a layer on top of accounts and cards that lets third-party agents spend the customer’s money with their permission.
You would tie that to controls the customer sets like value limits and merchant category code limits.
A customer might set the limit at 100 euros, so if the agent gets the payment wrong, the worst thing that can happen is that the customer loses 100 euros and some will be ok with that as the price of being an early adopter.
A 100 euro cap lets business customers and consumers start experimenting with the whole population of AI agents now coming into the mainstream.
Visa, Mastercard, and Google are building protocols for exactly that, though mostly for cards right now.
Agentic AI startups come to us for the same reason, asking for the financial infrastructure to put those limits in place.
Consent needs limits, cryptography, and a timestamp
For a software business planning its own agent payments, what does it need in place before it can let an AI agent trigger a payment on behalf of a customer?
The core building block is a formal auditable delegation of authority.
You have to think backwards from the customer who spent a lot of money through an agentic AI process and then says they never wanted it.
Are you in a position to answer that?
The only way is to design for that situation, which means having explicit authority that can stand up in court.
Proving the customer approved the payment is partly cryptographic, showing they were in session when they approved it, that the approval carries a timestamp, and that nothing was added after the money moved.
If the customer approved only in general terms, a court will say they never understood what they were agreeing to, and the loss stays with you.
The tooling side isn’t the obstacle, because most of the technical tools already exist.
You have to understand how things go wrong, then collect the right data, hold the right evidence, and run the right processes to prevent them.
We built for that in December, when we released a delegation of authority framework, which sounds technical but is what lets the automation run.
The framework has to come from the financial side, because the financial institution is responsible for the customer's money.
Consent hands off from a customer who knows what will happen to their money to a software business that acts on it, and that protects the business from the liability too.
When customers come to you with an agentic payment flow, where do they get stuck? Is it the infrastructure layer, the compliance layer, or the engineering capacity to build it?
Let me start with the capacity.
We're in a time of plenty, and we use AI in software engineering ourselves.
Engineering capacity used to be the limiting factor, and that's no longer the case.
The limit has moved to whether you're building something that will work for customers and solve their problem.
Knowing what to build is the hard part now, because once you know, the build is easy.
Capacity isn’t the blocker for our business customers.
They get stuck on having to think beyond software.
Financial regulation differs by jurisdiction, and in some places the regulator is further ahead on what it expects.
In the UK, the regulator has something called Consumer Duty, which sets outcomes to achieve instead of rules to follow.
The basic idea is that you ensure there are no bad outcomes for the customer.
Once you unpack that, it becomes a problem about informing the customer, assessing whether the customer understood, and preventing harm that can be foreseen.
You have to design all of those obligations in.
Meeting them is why this is an era for multidisciplinary product managers.
You still need clever engineers to make the trade-offs, but the premium is on the people who understand the constraints and decide well.
People are calling that taste.
When AI can do a lot of the things we want, we need to know what we want.
I want to get more technical for a moment. What did you have to build from scratch in your stack to support agent-initiated transactions, and what surprised you about how hard it was?
The centerpiece of what we built is the delegation of authority stack we launched in December 2025.
We set out to solve one specific customer problem with it.
A customer wanted their own software to read the HRIS file, spot a new employee joining, and set that person up with a card, an account, and wallets.
They would do it without the employer in the session, which normally requires the employer's authority, and regulation doesn't allow that unless you capture specific consent.
So, delegation of authority was built to collect that consent, attach limits to it, and let the automation run.
We realized it could go much further than that.
Delegation of authority works like downloading a phone app, where the operating system asks whether the app can reach your camera, microphone, and files, and you can grant or withdraw each of those later.
We wanted to apply that to financial services, in a world where strong customer authentication regulation already exists.
So, we released it as a framework rather than a fixed set of consents, which lets us keep adding mandate types as the Visa, Mastercard, and Google protocols develop.
We're also conscious that we will have to re-engineer it over time as we meet more practical situations.
The main challenge is that we still want to do this in an embedded context.
We built protocols that tunnel through the customer's software, so we can be sure the person approving a payment is the same user we authenticated.
A software business embeds that consent step in its own product, and it has to show that step to the customer in a way that proves the business itself isn’t intercepting the approval.
We had to make the protocol proprietary for that reason, because it has to prove the approval is genuine and still sit inside the user experience without breaking it.
The same approach goes further once you apply it to agentic AI.
Only a company or a person can be sued
Compliance is the part I am always curious about.
How does it work in practice when the entity executing a financial decision is an algorithm rather than a person?
Embedded finance gave us a proving ground for this long before agents arrived.
Back then, the software sitting between a customer and their money was a SaaS product or an app, thin enough that the customer stayed in the session and got asked to confirm at every step.
Letting software we didn’t fully trust move the customer's money already took a lot of solving.
Solving it was step one.
We now cut through the software to find whoever is accountable behind it.
An AI can’t go to jail or sue anyone, so that liable party is always going to be a person or an organization.
Directors can be jailed even though the organization can’t, and the organization can sue, which no piece of software can do.
So the key decision every time is whether we can identify the person or the organization accountable for the payment.
If we as engineers can’t drill down to the company or the person who is accountable for a transaction, we can’t take part in it.
The presence of an AI doesn't change that rule.
If an AI agent makes the payment, we assess it as we would if an accountable company made it.
Once that principle is in place, compliance runs in a systematic way.
One question I find interesting sits outside that principle of traced accountability.
When an agent someone else built goes rogue, is the company that deployed it liable, or the company that built it?
You have watched a lot of founders build agent payments. What is the biggest mistake you see them make?
Founders treat the development of agent payments as an integration exercise.
The assumption is that if the agent can call the payments API, the hard part is done.
Compliance and consent is the harder and more overlooked part.
When things go wrong, you have to produce an auditable record that the consent existed.
Most designers still treat it as an afterthought, and we want to make it mainstream, because it's the real hard part.
Regulators and the society at large are fascinated by the power of AI and also terrified of it.
There is a great opportunity for founders who balance that power against that fear and build trust through thoughtful design.
Getting the technology to work just isn’t enough.
The payment flow must also make the customer feel safe and in control.
Agents now advise, but they’ll spend one day
Which types of financial decisions are AI agents closest to executing with confidence today, and which are still too risky to hand over?
Let me describe a future I think we'll get to at some point.
You could imagine an AI that looks at your credit card debt, your savings, and your monthly bills and their due dates, then pays them just in time.
The agent pays that debt before it gets too expensive, and you don't have to think about it.
You would tell it to give you good outcomes, set how much you can spend, and take care of your money.
We're not there yet.
You can build that agent as a demo, but in real life plenty goes wrong, because people change their mind, get excited, and spend too much in one month.
Handing your financial life over to an agent and hoping nothing goes wrong is too risky right now.
Today, we are at the stage of established workflows.
Take a business buying stationery for the office every month, where the routine still requires an order, a transaction, and a supplier payment.
Agentic AI suits that routine, because the purchase repeats on a pattern the agent can learn.
A business on 1,000 euros of stationery a quarter isn’t about to spend 20,000, and the pattern says so.
Forecasts point to 2030 for handing agents full power over personal finances, and I am not sure about that.
When do you think we will be ready?
The world doesn't move as one.
You always have early adopters, a late majority, and people who never change.
But one thing will decide how fast people hand their finances to an agent, and that is the cost of financial advice.
Wealthy people pay expensive advisors to work out the next best stock and get the most out of their money.
Within 24 months, an AI agent will give ordinary customers the same guidance that only rich clients can afford today.
Banks and fintechs will be the ones offering it, and the customer will still make the final decision.
Once people are confident with that software, and once society is ready, agents will move from advising to spending the customer's money on investments and bills.
If that runs a couple of years without a big mishap, it will become normal.
So 2030 is realistic for agents running personal finances, though not everybody will move.
3 moves worth making
Make the consent record impossible to fake
Write the consent record while the customer is authenticated, and attach the session and a timestamp to it.
Without a cryptographic signature the record proves nothing, because anyone could have written it after the dispute began.
A record phrased in general terms fails, because the customer can argue it never covered the payment that went wrong.
Put the spending limits in the permission the customer signs
Start with the purchases that repeat at a predictable size such as a quarterly stationery order.
The customer sets the ceiling on those purchases and the merchant categories, and those limits belong in the permission they sign rather than in your application code.
While the permission is new, a person should still release the payment.
Store the liable company or person with the consent record
An AI agent can't be prosecuted or sued, so a registered company or a named person has to carry the liability for every payment it makes.
The name sits inside that same consent record and travels with every payment request the agent submits, so your compliance checks run against a named party.
If a request arrives without one, the payment should fail rather than go through.
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.