Skip to main content
Being Idea Innovations
Building Banking and Insurance Websites with AEM: A Practical Guide
Back to Blog

Building Banking and Insurance Websites with AEM: A Practical Guide

1 October 20268 min readAdobe Experience Manager
Share:

A bank or insurance website is not a brochure. It publishes interest rates that must be correct to the decimal, product terms that legal has signed off, disclosures that differ by region, and application forms that handle sensitive personal data. It often runs several brands, several countries and several languages at once. And it changes constantly, because rates, offers and regulations change constantly.

That combination is exactly what Adobe Experience Manager (AEM) was built for. This guide explains which AEM features matter most for banking, insurance and other regulated industries, how to structure a build so it stays compliant, and where teams usually go wrong.

What makes regulated-industry websites hard

Most content management systems can publish a page. The difficulty in financial services is everything around the page:

  • Accuracy. A wrong APR or premium on a product page is not a typo; it can be a regulatory breach and a customer complaint.
  • Approval. Marketing writes the copy, but compliance and legal must approve it before it goes live, and you need a record that they did.
  • Consistency. The same disclaimer or rate appears on dozens of pages. Updating it in one place and missing another is a real risk.
  • Scale. Multiple brands, regions and languages, each with local rules, built from one platform.
  • Security and privacy. Forms collect income, health and identity data. Some content is only for logged-in customers, brokers or advisers.
  • Accessibility. Financial services are essential services, and accessibility regulations apply to them in many markets.

Each of these maps to a specific AEM capability.

The AEM features that matter most

Editable templates and policies: brand and compliance guardrails

In AEM, developers build a set of components (hero, rate table, product card, disclaimer, FAQ) and template authors decide which components are allowed on which kind of page. Policies control the details: which heading levels an author can use, which image sizes are available, which colour styles exist.

For a bank this is a compliance tool as much as a design tool. A product page template can require a disclosure component and lock it in place, so no author can publish a loan page without the legal text. Authors get freedom where it is safe and none where it is not.

Content Fragments: one source of truth for rates and terms

Content Fragments are structured content (think of a form with defined fields) that live independently of any page. Model a "Savings Product" fragment with fields for product name, interest rate, minimum balance, effective date and the legal footnote. Every page, comparison table and calculator then references that fragment.

When the rate changes, someone updates one fragment, it goes through approval once, and every page that shows the rate updates together. This removes the most common source of errors on financial websites: the same number typed into many places by hand.

The same fragments are available through AEM's GraphQL API, so your mobile banking app, internet banking dashboard and website can all show identical, approved product information.

Experience Fragments: reusable approved blocks

Experience Fragments are reusable groups of components, such as a regulatory footer, a "how to complain" panel or a fraud-warning banner. Build and approve them once, then place them across the site. When the wording changes, update the fragment and every placement follows.

Workflows: approval with an audit trail

AEM workflows route content through review steps before publication. A typical financial-services workflow looks like this:

  1. An author drafts or edits a page.
  2. The page goes to a marketing reviewer for brand and tone.
  3. It moves to compliance for regulatory review, who can approve, reject with comments, or send it back.
  4. Only after approval is it published, automatically or at a scheduled time.

Each step is recorded, and AEM keeps version history for pages, so you can show who approved what and when, and restore an earlier version if needed. For audits, that history is often as important as the content itself.

Launches and scheduled publishing: change on a date, not at midnight by hand

Rate changes and new products usually take effect on a specific date. AEM Launches let you prepare a future version of a set of pages, get it approved in advance, and promote it on the effective date. Scheduled on and off times handle simpler cases, such as a campaign banner that must disappear when an offer ends. Nobody has to log in at midnight to flip content live.

Multi Site Manager and language copies: many brands, one platform

Large financial groups run several brands and markets. AEM's Multi Site Manager (MSM) lets you build a "blueprint" site and roll it out as live copies for each brand or country. Shared content flows down automatically, while each market can break inheritance where local rules or products differ.

Language copies and AEM's translation integration send content to a translation service or agency and bring it back for review, so a regulatory update in English can be pushed to every language with a clear status for each.

AEM Forms: applications and claims

Loan applications, account opening, quote requests and insurance claims are the business-critical journeys on these sites. AEM Forms supports adaptive forms that change based on the applicant's answers, save-and-resume for long applications, pre-filling from customer data, and document generation. Because forms are built from the same components and authored in AEM, the business can change questions and wording without a development cycle, within the rules developers set.

Closed user groups: content for customers, brokers and advisers

Insurers often need a broker or adviser portal; banks need content for logged-in customers. AEM supports closed user groups, which restrict pages to authenticated users in specific groups, and it integrates with your identity provider so people use their existing login.

Personalisation without breaking compliance

With Adobe Target or Adobe Experience Platform, AEM can show different content to different audiences, such as first-time buyers, existing customers or business clients. The important rule in a regulated setting: every variation is still built from approved content and fragments, so personalisation changes which approved message someone sees, never what the message legally says.

Banking websites: what a typical AEM build includes

  • Product pages for accounts, cards, loans and mortgages, driven by Content Fragments so rates and fees are always consistent.
  • Comparison tables that pull from the same fragments, so a product's rate on its own page and in a comparison can never disagree.
  • Calculators (loan repayments, savings growth, mortgage affordability) as front-end components, with rates fed from approved content rather than hard-coded.
  • Branch and ATM locator integrated with a location data source.
  • Rates and fees pages with effective dates and history.
  • Security and fraud centre content that can be updated quickly when a new scam is circulating.
  • Application journeys in AEM Forms, handing off to core banking or origination systems.
  • Headless content served to the mobile app and internet banking through GraphQL.

Insurance websites: what a typical AEM build includes

  • Product and policy pages for motor, home, life, health and business cover, with policy wording documents managed in AEM Assets.
  • Quote journeys that collect details step by step and hand off to rating engines.
  • Claims forms with document upload and status, built in AEM Forms.
  • Broker and adviser portals behind closed user groups, with product guides, commission information and marketing materials.
  • Agent and repairer locators.
  • Regional variations through MSM, because cover, wording and regulation differ by state or country.

Other industries with the same needs

The same patterns apply wherever content is high-stakes and governed:

IndustryWhat AEM helps with
Healthcare and pharmaMedically reviewed content workflows, region-specific product information, patient and clinician portals
Wealth and asset managementFund data from Content Fragments, adviser portals, country-specific disclaimers
Telecoms and utilitiesPlan and tariff pages driven by structured content, multi-brand sites, self-service journeys
Government and public sectorAccessibility, approval workflows, multilingual content, long-term maintainability
Retail and travelMulti-market sites, campaign scheduling, fast marketing pages on Edge Delivery Services

Security, hosting and performance

Most new builds run on AEM as a Cloud Service. Adobe runs the infrastructure, applies updates continuously, and serves pages through a CDN. Code only reaches production through Cloud Manager pipelines, which run code-quality and security checks before deployment. Adobe documents the security and compliance certifications for AEM as a Cloud Service on its Trust Center, and your security team will want to review them as part of vendor assessment.

For marketing pages where speed matters most, such as campaign landing pages or product overviews, Edge Delivery Services can deliver near-perfect Core Web Vitals scores. Many financial organisations combine the two: Edge Delivery Services for fast public pages, and classic AEM Sites with Forms for governed journeys and authenticated areas.

On accessibility, AEM's Core Components are built with accessibility in mind, which gives you a solid starting point. You still need to test your own components, colour contrast and content, ideally with real assistive technology, because accessibility depends on how the site is built and written, not only on the platform.

Common mistakes to avoid

  1. Hard-coding rates and disclaimers in page copy. Put them in Content Fragments from day one. Retrofitting this after launch is painful.
  2. Too many templates. A dozen well-designed templates with clear policies beat fifty one-off layouts that nobody can govern.
  3. Workflows that nobody follows. Design the approval process with compliance, not for them. If it is slower than email, people will route around it.
  4. Treating forms as an afterthought. Applications and claims are where revenue and risk live. Plan integrations, validation, save-and-resume and error handling early.
  5. Ignoring author experience. If authors find the editor confusing, they will make mistakes or depend on developers for every change. Good components and clear dialogs are a compliance control too.

How Being Idea can help

Our AEM developers work across the stack these sites need: AEM Sites and Core Components, Content Fragments and GraphQL for headless delivery, Java backend integrations with OSGi and Sling, Edge Delivery Services for fast public pages, and Adobe Journey Optimizer for personalised customer communication. Read more about the AEM roles a project like this needs and how authoring works for your content team, see how we provide AEM developers, or tell us about your platform.

Share:

Written by

Amit Verma

Founder / Senior Software Engineer

Amit leads engineering at Being Idea, with 15+ years building scalable software products for global markets and a hands-on role in every architecture decision.

More articles by Amit

Want to talk tech?

We ship software that scales. Let's work together.

No long-term contracts
Senior-led teams
US · AU · NZ timezone coverage
2-week paid trial sprint