A rival could copy an interface. But getting a regulatory license in a new market and plugging into a local bank would still take them several years.
Peter Daunton, Chief Product Officer at Sokin, shares how he decides what his team should spend years building now that AI lets anyone clone a feature.
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.
Sokin bets ahead of the market
Peter Daunton worked at Currencycloud, which was acquired by Visa, a company so large that a one-basis-point improvement to its FX margins counted as one of its biggest wins of the year.
He now runs product at Sokin, a fast-growth fintech with a smaller install base to lean on, and where that incremental approach would fail.
Peter still chases speed, but he now focuses just as much attention on the assets a competitor cannot rebuild quickly, such as regulatory licenses and local bank integrations.
What you'll learn
Why Sokin builds stablecoin infrastructure itself but relies on a partner for checkout.
How keeping a shared platform team narrow lets 6 product areas move on their own.
Why Peter treats licenses and infrastructure as Sokin's strongest defense against competitors.
About Peter & Sokin
Why a fintech scale-up needs its own playbook
Michał Szehidewicz: You worked at Currencycloud and Visa before becoming Sokin's Chief Product Officer. What made you move?
Peter Daunton: I had always been close to the B2B treasury space.
At Currencycloud, we built payment infrastructure and served many fintechs operating in that space.
I felt the space was ripe for change, and I’d even pitched Currencycloud on building a separate B2B brand before I left.
Stablecoins and AI were also starting to shift the market at the same time, and such shifts tend to open the door for new players to challenge incumbents.
On a personal level, I enjoyed my time at Visa, but I thrive in scale-up environments, where I have broader ownership of the strategy and direction.
Sokin offered me that in a space I already understood, with ideas I wanted to try, and that combination was too much to turn down.
Visa operates in more than 200 countries, a scale most of us never get to see up close. How did that change the way you think about product decisions?
Visa had a different business model from the scale-ups I was used to.
A one-basis-point change to Visa's FX margins once counted as one of the biggest wins of the year.
At Visa's scale, even a tiny shift moves enormous revenue.
So, Visa stays conservative. They get the strategy right by making small, incremental changes. Those changes reach an enormous number of existing customers.
Sokin’s profile is different, and so, we take the opposite approach.
We form a strong view of where the market is going, build toward it, and try to get ahead of it before we’ve won the business.
A different scale means a different game.
Is Visa as innovative on the inside as it looks from the outside?
Visa's card network has to run at something like 99,999999% or 99,99999999% of uptime, which means it effectively never goes down.
Nobody will risk innovating on a system held to that standard, so the rule is to leave it alone.
So Visa splits the organization, with one group keeping the network running and anyone chasing something new sitting apart from them.
When Visa does want to innovate, it asks where the industry will be in 10, 15, or 20 years, and it accepts that getting there takes a long time.
Then, it carves out a part of the business to chase that.
On AI, Visa either buys a company or starts a separate team inside the business.
The new team is told not to work the way the core works, so the company doesn’t fall 10 years behind on a new initiative.
I thought that was a smart way to operate, and it is the lesson I took with me.
Sometimes you have to keep a big idea away from the core business, so the constraints the core carries do not slow the idea down.
At Sokin, the pressure to do that is lower because we already move fast.
Even so, there are cases where we have carved something out as its own initiative, put dedicated funding behind it, and let the bet run.
How Sokin decides what to build or buy
You’ve already made some pretty specific calls on build versus buy. How did your team decide to build stablecoin payments in-house while partnering with Adyen for checkout?
For me, it comes down to whether a problem in the industry already has a settled answer.
Stablecoins don't have one yet.
There’s still a lot to learn about how customers will use them and where they fit in the market.
So, we wanted to own that infrastructure ourselves and stay free to pivot as the market moves.
If you rely on a partner for something like that, you’re one of many customers they serve.
Checkout is a mature, established category with plenty of experienced providers, so building it ourselves would have taken years to catch up.
Partnering with Adyen has let us move fast there, and it's worked well enough that we're now seeing that product scale in volume.
Would you make the same build-versus-buy calls again, now that you've seen the results?
Yes.
Since partnering with Adyen, we’ve seen the product scale well in terms of volume, so it’s proven to be the right call.
Partnering isn’t a permanent decision. It only means we are not building a checkout ourselves yet.
At some point in the future the volume we get from the partnership may mean it makes sense to build and own that layer, in order to chase higher margins.
On stablecoins, clients often ask who we partner with.
Owning the infrastructure ourselves matters most to the businesses that build on top of our product.
They’re not managing someone else’s dependency. They come to us when they need something changed.
Acquiring Genpaid made Sokin’s stablecoin bet even more real. What was riskiest for your team about folding it in?
The acquisition let us reach the market faster than we could by building that capability from scratch ourselves.
The real challenge was staying true to our hybrid finance thesis.
We never wanted a separate crypto product sitting on the side.
We wanted stablecoins treated as another rail alongside euros, GBP, USD, and now USDT and USDC.
The new, stablecoin-based product had to go through the same approval processes, the same transaction monitoring systems, and report into the same accounting package as everything else we run.
With most acquisitions, you can bolt the product on and link out to it from a menu, keeping the two systems separate underneath.
We couldn’t do that here, because we needed on and off ramping between fiat and stablecoins to work well.
So, we integrated the new software until it felt like a single payment system to the customer, rather than two.
Which product decision at Sokin would you call your biggest mistake so far? I like asking this one because it’s more revealing than the wins.
I'm tempted to say we don't make mistakes, but only choices we learn from.
I try to build a product team that can experiment, since coming down hard on people for missing a target stops them from trying.
One bet in five pays off big.
To answer the question, though, I talked confidently earlier about choosing to partner rather than build for checkout.
Choosing a partner was not the first thing we did.
We tried to build payment acceptance ourselves first, and I massively underestimated how much trust matters in that market.
Our pitch was same-currency settlement.
Stripe forces a US merchant accepting euros to convert back into dollars, then convert again for any European payroll or tax.
We would give that merchant the settlement account as well as the acceptance, so the euros stay euros until they decide what to do.
I thought that would be enough, because it saves customers real money.
Customers told us the money saved on avoiding the currency exchange didn’t matter if the product fell over for four days and they lost every sale.
Losing four days of sales is a far bigger pot than anything we were saving them. And that risk wasn’t worth taking.
Payment acceptance is a crowded market, and trust turned out to be the hard part in it.
So, we moved to a partnership, and then we could tell customers we were running on established, secure technology.
Building what rivals cannot copy
Speed to market is now the biggest challenge product leaders face, and I think you would agree. Where do you see that pressure at Sokin?
Speed to market has always mattered to me.
Even a month’s head start on a competitor can matter, because customers who land with you tend to stay for a while.
AI has changed how fast software gets built, but it hasn't changed how I think about speed, because I was already chasing it before the tools got faster.
What has changed is where I put my attention.
I spend a lot more time now thinking about how to make something defensible, so a competitor can’t come along tomorrow and build the same thing.
A competitor can copy an interface, but getting a license in Singapore and integrating with a local bank there would still take several years.
That’s why I keep looking for the slow, hard things to implement.
Regulatory licensing and the infrastructure Sokin has already built took years to put in place.
Those slow things are what’s valuable, because they bring customers and investors to us, and AI can’t shortcut them.
You launched UK Checkout recently. What did you have to leave out to get it live?
It came down to a trade-off between reach and depth.
We had a roadmap to go deeper into checkout, with more native, Shopify-style experiences and additional alternative payment methods.
We chose not to pursue these features yet.
Instead, we opted for reach and launched in the UK, and Canada followed later this quarter.
Choosing reach over depth changed our strategy.
We started chasing the invoice-to-cash process through payment links, receivables, and invoicing.
Invoice-to-cash fits our mid-market treasury positioning better.
Team friction is an architecture problem
Sokin’s product is organized into six areas sharing one core platform team. How does that split work?
Our product taxonomy is split into six: receive, convert, send, control, earn, and spend.
Each has its own tribe that owns it end-to-end.
When the CTO and I see two product tribes fighting or leaning on each other a lot, we read that as a sign that we built the architecture wrong.
Each tribe gets full ownership of how it builds and what it builds toward an outcome we set.
We might tell the earn tribe to grow assets under management to a set figure by the end of the quarter.
How they get there is theirs to decide.
Underneath the tribes sits a core platform team, and we tell those people to keep it as thin as they can and to say no as much as they can.
If a tribe asks the core platform team for something, the first question back is, "Why can't you build that yourselves?"
When we choose to add something to our core platform, it is because we have looked at what the tribes will need over the next 12 months and found something that will reduce the burden across multiple tribes.
Our central ledger is one of those shared pieces.
We rebuilt it to be message-based, so tribes push events into it while the ledger team handles the cash.
Holding the ledger centrally also lets us manage safeguarding rules across markets from one place, instead of every tribe learning its own country’s requirements.
Could you walk me through how each tribe is built in terms of structure and talent?
Each tribe is made up of a pod of three or four engineers to one product manager, depending on the domain.
We tend to hire senior engineers, because fewer, more skilled people communicate better than a larger group of more junior ones.
Communication is hard even among people who know each other well.
Keeping pods small means they can get on a call together, understand each other, and avoid splitting into opposing camps on which direction to take.
People often disagree over decisions they could reverse later.
We call those two-way door decisions, and most of the disagreements land there.
One-way means you can’t come back from a decision, and two-way means you can. We try and encourage teams to not debate two-way door decisions too long and instead to quickly experiment with one path.
Is the team based in one location or spread across more markets?
It depends on whether the product is global or regional.
The Send tribe is regional by nature, because banking integrations and payment rails differ from market to market.
So, we put teams in Singapore, Dubai, Europe, the US, and Mexico, each near the markets they serve.
The Earn product works the other way, because every market uses the same thing.
Most of those teams sit in our engineering hub in Belgrade.
How AI reaches teams and customers
Only 65% of companies have a written policy for how teams use AI. What do you make of that?
It’s telling in both directions.
The 35% without a policy says as much as the 65% with one.
What I see happening at most companies is one of two extremes.
A restrictive AI policy that nobody reads pushes people onto their personal AI accounts, which is worse for data protection.
You think your data is protected, and it’s not protected at all, because personal accounts are where models get trained.
At the other extreme, leadership hands everyone an enterprise license and then asks why they are not 50% more efficient than they were yesterday.
Nobody becomes highly skilled overnight at a technology that is this hard to get to grips with.
At Sokin, we tried something different.
We built an AI infrastructure team to own the policy and the tooling, including pre-built, pre-vetted skills people could use.
We also found our early adopters, the people already excited and deep into the technology, and built a community around them.
Instead of AI adoption feeling like something leadership forces on people, it spreads from the bottom up.
For example, a couple of my product managers in the early adopter community are now helping compliance build an agent for regulatory reporting.
Marilyn, Thredd’s CTO, called the AI skeptics in her organization the guardians of the past. How do you reassure such individuals at Sokin?
I don’t dismiss them, because some skepticism is useful.
If you believed everything you read about AI on LinkedIn, you’d think we should all sit around prompting agents and doing little ourselves.
The reality is harder than that.
Getting an agent to produce consistent, high-quality work takes real frameworks and controls.
An agent is probabilistic rather than deterministic.
It might do something well four times and then something strange the fifth.
People also adopt new technology at different speeds.
Some jump in right away, and others wait until they see proof, which is the normal technology adoption curve.
You have to bring both groups along and be kind about it.
A lot of people worry about their jobs, so the message has to be that their work will change rather than disappear.
Product and engineering tend to need less encouragement, because those teams are already tech-first and excited about new technology.
Non-technical teams need more encouragement and more time to see where they fit.
How did the decision to let other businesses build on top of Sokin's payment infrastructure come about?
I always think about the access layer, which is how a user gets the ability to use my product.
Then I think about leverage, which is how I increase the number of customers who have that access.
Coming from Currencycloud, an infrastructure company, that lens felt natural to me, and Sokin had already started exploring similar ideas before I joined.
We built strong payment rails, and we were selling them to one business at a time.
Embedding them through an API meant one client could bring 1,000 businesses along.
Embedding our product into other businesses has turned out to be the fastest-growing part of the business.
We recently launched a third access layer, an MCP.
Finance teams can build their own workflows inside tools like Claude or ChatGPT.
If a workflow needs to execute a payment, create a beneficiary, or book a forward contract, the MCP does it.
The idea is simple. Go to where the user already is, and don’t expect them to come to you.
Looking 12 months ahead, what does success look like for your product team?
Up to now, our focus has been building strong payments infrastructure and the treasury capabilities around it, including invoice-to-cash, procure-to-pay, and hedging.
But all of that is still execution.
A customer works out what they need, comes to us, and books the payment or the forward contract themselves.
Success next year means broadening that into what we’re calling a decision layer.
Take hedging as an example.
Today, we execute a hedge once someone has already decided on it.
We want customers to hand us their cash flow and their treasury policy up front.
Then, we run the sensitivity analysis, find the gaps, and propose the hedging strategy.
An analyst reviews it and approves it.
Sokin books the contracts and reconciles everything afterward.
We are building AI agents that run that whole hedging sequence from the analysis to the reconciliation.
A person is there to check the output rather than work manually at every step.
12 months from now, I want the decision layer to move from an idea and a demo into working software that people are adopting.
The goal is for customers to do more through Sokin because Sokin is doing more for them.
3 moves worth making
Decide to build or buy by asking whether the problem is still unsettled
Sokin owns its stablecoin infrastructure because that market has not settled yet, and owning it lets the company change direction as customer needs shift.
Checkout is a mature, crowded category with established providers, and catching up would have cost Sokin years, so Sokin partnered with Adyen.
The test is whether your market already has a settled answer, because a settled one rewards a partner and an unsettled one rewards ownership.
Treat the assets a competitor needs years to build as your real advantage
Peter Daunton still chases speed, and AI has made his teams faster, but he now spends more of his attention on what a competitor cannot rebuild quickly.
A banking license in Singapore and a working integration with a local bank take a competitor two years, while a user interface can be matched in days.
That gap is where Sokin puts its long-term effort, because those years of licensing and infrastructure are what bring customers and investors in.
Test whether trust or price decides your market before you fight for it
Sokin first built payment acceptance in-house and pitched it on savings, because same-currency settlement meant a US merchant taking euros would not lose money converting back and forth.
Merchants told Peter Daunton that 4 days of downtime would cost them more than the savings were worth, so Sokin moved to a partnership with Adyen and could point to established, secure technology.
Sokin’s FX and payments business already carries the licensing record that earns that trust, so check where trust already sits in your business before you spend years building it somewhere new.
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.