How Cygnetise Turned 20 Years Inside Banks Into Category-Defining Advantage

How Cygnetise Turned 20 Years Inside Banks Into Category-Defining Advantage

Most founders build products for industries they’ve never worked in. They interview customers, read reports, and study the market from the outside. Steve Pomfret had a different advantage: he’d spent twenty years inside the machine, watching it break in the same places over and over again.

But he wasn’t a banker. That distinction mattered more than anything else.

In a recent episode of Category Visionaries, Steve Pomfret, CEO and Founder of Cygnetise, a signatory management platform that’s raised $8 million in funding, explained how being the process guy instead of the banker gave him something bankers never had—understanding of what they’d actually adopt.

The Perspective That Bankers Don’t Have

Steve’s background sounds corporate on paper. Twenty years at large banks across New York, Florida, Moscow, Switzerland, Holland, France, and Italy. But the work wasn’t banking. It was something more valuable for a future founder.

“My background is I spent about 20 years working for large banks, but I’m not a banker. I haven’t been a banker. I worked in operational change and as more of a process guy. So I kind of help the banks resolve their inefficiencies and help to work with technology.”

This role gave Steve a unique vantage point. Bankers understood trading, corporate finance, and client relationships. Steve understood where processes bled efficiency and how technology could stop the bleeding.

The difference is perspective. When you work in front office trading, you accept operational processes as given. They’re just how things work. But when your job is fixing operational inefficiencies, you see patterns. The same problems appear at Deutsche Bank, at institutions in Switzerland, across markets and geographies.

You also see what gets adopted and what gets ignored. Which solutions actually change behavior and which ones end up as unused software licenses.

The Problem Visible Only From Inside

At Deutsche Bank, Steve witnessed a specific operational pain that bankers had normalized. One UK department needed to share their authorized signatory list with banking counterparts. The list detailed who could do what on behalf of the organization—critical information for financial transactions.

The process? Email PDF documents to a thousand counterparts. The frequency? Quarterly, because doing it more often was operationally impossible.

“I used to work at Deutsche bank and they did this once a quarter. So they would email like in one department that I worked in within the UK, they would have to email a thousand of the banking counterparts whenever they updated it. And you can’t do that on a daily basis by emailing PDF’s.”

This is the kind of problem you only understand from the inside. From the outside, you might think: surely banks have solved this with technology. They’re sophisticated institutions with massive IT budgets.

From the inside, you know: they’ve tried. “Banks and large corporates have tried to build their own databases to do that, and then they offer their counterparts to actually have access to view their internal databases.”

But those solutions created new problems. “Financial institutions do not want to go through firewalls and have access to other people’s counterparts internal databases or files.”

So everyone reverted to the manual process. Quarterly PDF emails to thousands of counterparts. Version control nightmares. Lag between changes and distribution. Error risk compounding with every manual step.

The Critical Filter: What Will They Actually Adopt

When Steve left banking and started learning about blockchain technology in early 2016, he didn’t immediately build Cygnetise. He analyzed problems.

“I literally was analyzing problems and which one would be the best suited for the use of the technology and which ones had, like, a better chance of making a business.”

This analysis phase is where twenty years of domain expertise became category-defining advantage. Steve wasn’t evaluating problems based on market size or technical elegance. He was evaluating them based on adoptability.

The critical filter? “Replacing a manual process and not replacing another technology.”

This insight only comes from watching enterprise technology adoption from the inside. Banks will adopt new technology to replace manual processes because manual processes have no switching costs, no vendor relationships, no technical debt to unwind.

But replacing existing technology? That’s a completely different adoption curve. You’re fighting installed vendor relationships, training investments, integration dependencies, and institutional inertia.

The signatory management problem passed Steve’s filter perfectly. Every bank had the problem. Everyone used manual processes. No incumbent technology vendor would fight back. The path to adoption was clear because Steve had seen what banks actually adopt versus what they buy and ignore.

The Confidence Gap That Experience Fills

Twenty years inside banks gave Steve something beyond market knowledge. It gave him confidence to take the leap.

“I’ve always admired other people running their own company, but whilst you’re actually working for a big corporation or a big bank is you kind of, there’s some kind of security. And I guess it was only after like, 20 years where I began to think maybe I should make the leap.”

Domain expertise doesn’t just help you find better problems to solve. It gives you credibility with early customers, investors, and employees. When Steve talked to banks about signatory management, he wasn’t guessing about their problems. He’d lived them.

That credibility accelerated every conversation. Prospects didn’t need to explain their workflows. Steve already understood them. Due diligence moved faster because Steve spoke the language fluently. Objections got addressed before they became blockers because Steve had seen every variation of “why we can’t change this process.”

The Methodology: Systematic Problem Analysis

Steve’s approach to finding Cygnetise reveals a methodology that other domain experts can replicate:

Step 1: Learn new technology capabilities. Steve spent early 2016 in classes and meetups understanding blockchain. “I realized that if I was going to continue doing what I was doing, I need to understand more about innovative technology.”

Step 2: Map technology capabilities to domain problems. Don’t start with a problem and force technology onto it. Start with technology capabilities and find problems they actually solve. “When I understood more about it, I realized it was in a great position to actually do something about it because I understood the problems that the banks faced, and now I actually understood more about the technology.”

Step 3: Filter for adoption reality. Evaluate which problems suit the technology AND which ones have realistic paths to adoption. Manual process replacement beats incumbent technology displacement.

Step 4: Validate with insider knowledge. Use domain expertise to stress-test whether solutions will actually get adopted or just get purchased and ignored.

This systematic approach explains why Steve took months between learning blockchain and starting Cygnetise. He wasn’t delaying. He was doing the analysis that twenty years of experience enabled.

When Domain Expertise Matters Most

Not every founder needs two decades in their target industry. But domain expertise creates disproportionate advantage when:

Adoption patterns are opaque from the outside. If you can’t tell what customers actually use versus what they buy, insider knowledge matters enormously.

Solutions require operational change, not just technology deployment. Understanding how organizations actually change behavior beats understanding what they say they want.

The market has tried and failed to solve the problem before. Knowing why previous attempts failed prevents repeating mistakes.

Credibility accelerates sales cycles. Enterprise sales to sophisticated buyers benefits from sellers who’ve lived the problem.

The problem is universal but invisible. Some inefficiencies are so normalized that people don’t recognize them as solvable problems until an insider points it out.

What Other Domain Experts Can Steal

If you’ve spent years inside an industry, here’s how to leverage that experience:

Map operational inefficiencies you’ve witnessed repeatedly across companies and geographies. Pattern recognition is your advantage.

Learn emerging technology capabilities systematically. Your domain knowledge is only valuable when combined with understanding what’s newly possible.

Filter opportunities through the adoption reality lens. What will organizations actually change versus what will they discuss and dismiss?

Use the manual process replacement filter. These have clearer paths to adoption than incumbent technology displacement.

Leverage insider credibility in early sales conversations. Speak the language. Understand the workflows. Address objections before they surface.

Steve didn’t need an MBA or startup accelerator. He needed twenty years of watching banks struggle with the same operational problems and the discipline to systematically analyze which ones blockchain could actually solve in ways banks would actually adopt.

That combination—deep domain expertise plus systematic technology analysis plus adoption reality filtering—created a category that banks didn’t know they needed until someone who’d lived inside them explained why it was possible now.