TINtech London Market 2026: Five Important Learnings

Our Sales Director Paul Cole spent a full day at TINtech London Market 2026 last week. Three hundred and fifty insurance executives packed into 155 Bishopsgate, and by the end of it, Paul had five things written down in his notebook that he reckoned actually mattered. I caught up with him the day after to talk through what he’d learned.

Stop building peer-to-peer integrations. You’re killing yourself.

“The integration conversation has properly matured,” Paul said, and he meant it as a compliment. “Everyone’s finally admitting that peer-to-peer integrations are a nightmare to maintain.”

He’d been sitting in the opening keynote panel, listening to Christian Kitchen from Marsh McLennan, Reno Daigle from CNA Hardy, and Ibrahim El Moghraby from QBE talk about connected market infrastructure. The theory was interesting enough. But what got Paul’s attention was when a CTO from one of the big MGAs stood up during the Q&A and basically admitted they’d stopped building bespoke integrations entirely.

“They’ve moved everything through a gateway,” Paul explained. “One integration point, multiple endpoints. Took them 18 months to get there, but they’ve cut their integration maintenance overhead by about 70%.”

I asked him what that actually looks like in practice.

“Think about how most people have been doing this for years,” he said. “You build an integration with one broker. It works. Great. Six months later, something changes on their end, or yours, and you’re firefighting. Now multiply that across 20, 30, 40 different partners. You’ve got an entire team just keeping the lights on. Nothing moves forward because everything’s breaking.”

The gateway approach flips that. You build one integration layer that sits between you and the market. When a broker’s system changes, you update the gateway once. When you need to add a new partner, you plug them into the existing infrastructure rather than building something bespoke.

“It’s not glamorous,” Paul admitted. “Nobody’s going to put it on a marketing slide. But it scales. And more importantly, it doesn’t create a maintenance overhead that eats your roadmap alive.”

Digital transformation has three questions that need answering. Most people skip all three.

“Right,” Paul said, “so most transformation projects are doomed before they start because they haven’t answered three fundamental questions.”

He’d been in a session where someone from AXA XL basically laid this out, and Paul said it was the most useful hour of the entire day because it explained why so many programmes he’d seen over the years had failed spectacularly.

“First question: Are we clear on strategy?”

Not the PowerPoint we showed the board, Paul clarified. Not the consultant’s 200-page document. The real strategy. What are we actually trying to achieve here and why does it matter?

“People kept talking about ‘digital transformation’ like it’s an end goal,” he said. “But transformation to what? If you can’t articulate what success actually looks like, how do you expect to build towards it? You’re just throwing money at technology and hoping something good happens.”

The second question: Is tech genuinely holding the business back?

“This one made people uncomfortable,” Paul said with a slight grin, “because a lot of the time, the answer is no. The tech isn’t the problem. The processes are broken. And people want new systems to magically fix their broken processes, which obviously doesn’t work.”

He’d seen this pattern repeatedly. An organisation decides they need a new policy admin system or a new rating engine. They spend millions implementing it. And then they’re confused when nothing actually improves because they’ve just automated the same inefficient processes they had before.

“You can’t fix process problems with technology solutions,” Paul said. “You have to fix the processes first.”

The third question, and the one Paul said was most underrated: Do our partners have the right culture?

“If you’re trying to be agile and innovative, and your tech provider thinks in 18-month waterfall cycles, you’re screwed,” he said bluntly. “The cultural mismatch doesn’t show up in the procurement process. It shows up six months in when you’ve spent half your budget and burned through everyone’s goodwill.”

Paul’s seen transformations fail purely because of this. Not because the technology was wrong. Not because the strategy was unclear. But because the insurance company and the technology provider fundamentally disagreed on how to work together.

“Someone from AXA XL said culture fit matters more than capabilities now,” Paul added. “Because if you’ve got the culture right, you can build the capabilities together. The other way round doesn’t work. You just end up fighting each other the whole way through.”

Are you actually fixing the right problem? Do you even understand your existing processes?

This was Paul’s third big takeaway, and he said it explained why so many transformation programmes deliver shiny new systems that somehow don’t actually make things better.

“Companies are transforming without understanding what they’re fixing,” he said. “They know they have pain points. Everyone knows they have pain points. But they haven’t mapped where the waste actually is.”

There’d been a breakout session on this that Paul described as “uncomfortably accurate.” The premise was simple: if you don’t understand your current state properly, you can’t design your future state effectively. You’re just guessing.

“So what happens is they kick off these massive programmes and end up digitising broken processes,” Paul explained. “They automate the chaos. Then they’re confused when the expensive new system doesn’t deliver the efficiency gains they expected.”

The event saw an example offered by Karthik Srinivas at MS Amlin, who was talking about building the data foundations needed for AI to work. He’d made the point that if your data’s a mess, AI just amplifies the mess faster.

“You can’t skip the boring foundational work,” Paul said. “You have to understand your current state properly before you design your future state. That means mapping what you’re actually doing today.”

Not what the process document says you should be doing. What really happens. Where’s the rework? Where are the handoffs that add no value? Where are people working around the system instead of using it?

“It’s process archaeology,” Paul said. “You dig through what’s actually happening and figure out where the waste is. Only then can you start asking whether you need to do things that way at all.”

But most organisations skip this step. They go straight to solution mode without doing the diagnosis.

“It’s like going to the doctor and demanding antibiotics before they’ve figured out what’s wrong with you,” Paul said. “Might work. Probably won’t.”

Don’t simply implement the same process. Look to best practice.

This followed naturally from the previous point, Paul said. Once you understand what you’re actually doing and where the waste is, you need to be willing to change how you work. Not just what you work on.

“When transforming, do not simply implement the same process,” Paul said, and this had come up in nearly every session he’d attended. “Too many projects treat the new system like a like-for-like replacement. They want everything to work exactly as it did before, just shinier and faster.”

But if your current process is inefficient, replicating it in new technology doesn’t fix anything. You’ve just spent millions automating something that shouldn’t be done that way in the first place.

“The question that kept coming up in Callum Alexander’s workshop on delegated authority was: should we be doing this at all?” Paul said. “And if so, what does best practice actually look like in 2026?”

The answer isn’t to blindly adopt someone else’s processes. But it’s also not to stubbornly insist on keeping your current ones just because that’s how you’ve always done it.

“You need to work with your technology provider to implement best practice in a way that suits your business,” Paul explained. “That requires a proper partnership. Not a vendor relationship where they just say ‘yes’ to everything you ask for.”

He’d heard multiple speakers make this point throughout the day. You need a provider who’ll push back when you’re trying to replicate something that doesn’t make sense. Who’ll show you what’s working for other clients. Who’ll tell you when you’re making it harder than it needs to be.

“Someone gave an example of an insurer who’d insisted on keeping a three-stage approval process in their new system because that’s what they’d always done,” Paul said. “Turned out two of those stages added zero value. They were just historical artefacts from when different people had different jobs. But nobody had questioned it in 15 years.”

The new system could have streamlined it to one approval. But because the insurer treated it as a like-for-like replacement, they automated a process that should have been redesigned completely.

“That’s the trap,” Paul said. “You spend all this money on transformation and end up with the same problems, just faster.”

It was a long day. But worth it.

By the time Paul got to the closing panel at 4pm, he’d been on his feet for most of eight hours. Three hundred and fifty people crammed into conference rooms at 155 Bishopsgate, listening to CTOs from QBE and AXA XL, the COO from Ki Insurance (Lloyd’s first fully algorithmic syndicate), and the Chief Digital & AI Officer from Mosaic talk about what capabilities organisations need for 2030.

“The implicit message was that five years goes faster than you think,” Paul said. “And competitive positions are being determined now, not in 2030.”

The attendee mix told you everything about why the event mattered. C-suite executives, heads of transformation, CIOs, CTOs, COOs. People who can actually authorise budgets and make decisions. Lloyd’s syndicates like Ascot and MS Amlin. Global carriers like QBE and Beazley. Major brokers including Marsh and Aon. MGAs like Carbon and Aventum.

“It’s one of the few events where you’re genuinely in a room with your peers,” Paul said. “People dealing with the same problems you are. That’s worth the ticket price on its own.”

I asked him if there was an overarching theme that connected his five takeaways.

“Yeah,” he said without hesitation. “Stop waiting for perfect conditions. Stop waiting for Blueprint Two. Stop waiting for the market to sort itself out. Start now with what you can control.”

The integration architecture conversation has matured because people have accepted that the old way doesn’t scale. The transformation questions matter because organisations are finally being honest about why programmes fail. The focus on understanding current processes properly comes from years of expensive mistakes. The push to adopt best practice rather than replicate broken processes is born from hard experience.

“All of it comes down to the same thing,” Paul said. “Do the unglamorous work. Ask the hard questions. Be willing to change how you work, not just what you work with. And choose partners who’ll tell you the truth rather than what you want to hear.”

He closed his notebook.

“That’s what I took away from TINtech. Not the AI hype. Not the Blueprint Two drama. Just five practical things that matter if you’re serious about making better technology decisions.”

And yes, pack comfortable shoes. It really was a long day – in the best possible way.