Embedded Insurance for a UK Bank: Insurance Software Development With SSO and Legacy Integration
Industry: Insurance / retail banking
Project type: Insurance software development services — white label insurance portal, single sign-on, legacy system integration
Context
A global insurer won a tender to provide travel insurance, and later home insurance, to customers of a large UK bank. The bank wanted insurance included in its paid monthly subscription for premium customers, so the subscription needed a strong insurance offer to justify its price. The insurer won on terms: the right set of travel products below the bank's price cap.
The insurer already ran white-label insurance portals for airlines, rail operators and car rental companies. The task was to deliver a version of that portal for the bank — a classic embedded insurance and bancassurance setup.
The Problem: Embedding Insurance Into a Bank Without Breaking Security
The customer flow had to be seamless. A customer opens the bank's app, taps the insurance section and lands in the insurer's portal without logging in again. There they can see their policies, buy travel cover, and add extras like ski cover or flight delay protection.
Behind that simple flow sat three hard problems:
- Data migration. The bank had a previous insurance provider. Customer data from that setup had to move to the insurer, so the new portal could price and serve each customer.
- Single sign-on across two unrelated systems. Bank and insurer systems were never connected. Access had to pass from one to the other with no chance of a session being stolen on redirect, and under banking security standards.
- Highly sensitive data. Bank data includes cards, addresses and spending. The bank would not give the insurer an interface to browse customer records.
The Solution
White Label Insurance Portal
The team took the insurer's standard portal and customized it for the bank. Design, customer journey and the insurance products stayed the insurer's. The page carried both logos with "provided by" branding. The bank could reject changes it disliked, but in practice it did not push back on the interface.
Secure Data Migration and Pseudonymized Customer Data
Customer data moved from the bank's side to the insurer through a shared database. Identifiers such as passport data, account IDs and email were hashed so that a leak would not expose them. Names were not needed at all: pricing and targeting work on an anonymous customer ID plus attributes such as age, household, account tier (for example, standard, silver or gold) and spending categories.
The insurer's and the bank's architects met and agreed on hashing and encryption standards that fit both sides' policies. Only a few people on the insurer's side, such as the IT architect and the lead backend developer, had access to match records. Getting through the bank's firewalls on the backend also took significant time.
Single Sign-On Integration
The portal opens only from inside the bank's app, either in an in-app window or in the customer's browser. The bank authenticates the customer and passes a time-limited session key to the insurer's portal. Both sides had to support one standard and one format, and hand over the session securely so nobody could intercept it in transit. Off-the-shelf login kits do not cover a custom bank-to-insurer setup like this, so it had to be built and tested to banking standards.
Pricing Engine Tuned for the Bank
The insurer's internal pricing engine calculates the premium by risk: age, family, trip type and other parameters the bank provides. It is parameter-driven, so it was adjusted rather than rewritten. The team benchmarked prices against competitors in the UK market and set them to stay under the bank's cap on policy price.
Add-On Microservices
On top of the core sales flow, the team added several services:
- Proactive flight delay claims. A customer registers their flight number and date. A real-time flight data API reports delays. If the delay passes the threshold, the payout is sent automatically, usually within a day.
- Hospital finder. Shows the nearest certified hospital where the insurer covers all costs.
- Medical phrase translator. A customer types symptoms and shows the translation to medical staff abroad.
Working Inside a Legacy Stack
The insurer required all development to follow its own internal frameworks and tooling, partly to protect its IP. Some core data systems dated back to the late 1980s and had not changed since — replacing them would be a huge investment, and in a heavily regulated industry the old, proven system is often the approved one. External developers had to adapt to this environment before they could deliver. This made legacy system integration a large part of the project, not a side task.
Results
- Launched in 9 months — a co-branded portal live inside the bank's app.
- No second login: customers move from the bank app to the insurance portal through single sign-on.
- Customer data migrated from the previous provider without exposing personal identifiers.
- Automatic flight delay payouts, usually within a day, with no claim application.form.
- A stronger bank subscription: travel insurance became part of the premium package and helped justify its monthly price.
Team, Timeline, Budget
- About 10 engineers at an external delivery partner: 3 QA, 3 backend, 3 frontend and a lead
- Offshore developers for the add-on microservices
- 4 people on the product side, including a product lead
- 9 months, Agile delivery in sprints
- Project cost: about €1.5 million
Challenges
- SSO and data migration. took the longest. The hardest part was not code but negotiation with the bank: which data to share, how to hash it and how to pass sessions.
- Firewalls and security reviews slowed backend integration.
- The internal stack forced external developers to learn the insurer's environment first.
- Each partner portal ran as a separate product with its own team — airlines, rail, car rental and now the bank. There was no shared update pipeline across portals, which kept the cost of onboarding each new partner high.
What Would Change If Built Today With AI
The redesign part was already fast and would not change much. The bigger gain is in legacy work. AI coding tools know older languages and frameworks, so writing code inside an old, unusual stack could go up to 10x faster, and a team would not need as many rare specialists in that stack.
It does not remove the need for engineers who know the system well. Someone still has to validate that the code works, especially where money moves. And in insurance, the limit is often not technology: regulation and the company's own willingness to change decide what can be used.
Where Insurance Software Development Like This Applies
This setup fits any embedded insurance or bancassurance partnership:
- insurers distributing through banks, airlines, rail and travel companies;
- banks and fintechs adding insurance to premium subscriptions;
- regulated enterprises that must build new customer features on top of decades-old core systems.
The common thread is connecting two secure systems that were never designed to talk, with a smooth customer flow on top. We do this kind of work in legacy software modernization and in custom software development projects.
Related Case Studies
About the Author
Vladislav Volovik — Data & Analytics Lead, Building Agentic
E-commerce data analyst at Sephora (LVMH Group) in Paris. Previously five years at Allianz Technology as a consultant, where he built BI solutions on SAP Analytics for IT cost optimization across the group. EDHEC Business School, MSc in Consulting & Digital Transformation. At Building Agentic he designs the data models and BI layer on every engagement — the part that decides whether reporting takes one click or one analyst.
