A bank’s product page is a regulated document. The rate, the fees, the eligibility line and the small print must be approved by compliance before they go live, in Arabic and English, and the bank must be able to show later what a customer saw on a given day. On many Gulf bank and insurer sites, a rate change still means a ticket, screenshots emailed to compliance, and two languages updated at different times.
SitecoreAI (formerly XM Cloud) has the controls this needs: workflow on every version, scheduled availability, page variants and forms that post to your own systems. The compliance value depends on how you configure them, from the content model to the handoff into onboarding. Our financial services outlook has the wider picture.
Give every rate, term and disclaimer one home
The CBUAE’s Consumer Protection Regulation requires information in both Arabic and English, in plain language, with specific disclosure, including warnings, of a product’s main characteristics, risks, costs, fees and rates. A rate typed into the body copy of six pages means six approvals and six chances to miss one. This is the model we start from:
| Content | Where it lives | Who approves | How it changes |
|---|---|---|---|
| Product copy and benefits | Page and data source items, in versioned fields | Product owner and compliance | Workflow, in both languages |
| Interest or profit rates, fees, limits | One rate item per product, or the product system’s rates API | Treasury or product, then compliance | A new version with a start date, then a publish |
| Disclaimers | One item per disclaimer and market, referenced by pages | Compliance in that market | Workflow, published with its pages |
| Terms, charges and fact sheets | Documents linked from the page, one file per language | Legal and compliance | A new file per change, the old one archived |
| Offers for an audience | Page variants with their own content items | Marketing and compliance | The default page’s workflow |
| Calculators and forms | Front-end components reading the rate items | Product, IT and data protection | Release testing against every rate change |
One field setting matters more than any other. A Sitecore Shared field holds the same value for every version in every language, and workflow and publishing restrictions do not apply to it. Use Shared fields for product codes only. A rate, fee or line of legal text in a Shared field goes live in both languages at the next publish without passing through approval.
Rates also change on a date. Page builder can schedule when a version is available, from a start to an end date, and Sitecore says you must still publish the page or the site when each date starts, with only one version of an item on Experience Edge at a time. Put every rate change in a publishing calendar with a named owner, and check the live page afterwards, because the site may update with a delay.
Approval workflow and an audit record you can produce
Sitecore workflows are built from states, commands and actions. Items in a final state are publishable, commands move items between states, and a command can prompt the user for a comment. A command appears only to users with access to it, so the approve command can belong to compliance alone. When someone edits an approved item, Sitecore creates a new version and returns it to the initial state, so an approved rate is never changed in place. For regulated pages, add product, compliance and Arabic review before the final state.
Audit is where teams overestimate the platform. Sitecore’s common audit log records user activity in Cloud Portal, Personalize, CDP and Connect, keeps logs for one year and can forward them to a SIEM by webhook. That page does not list SitecoreAI, so confirm what your tenant records for content changes, and keep the regulated record yourself. SitecoreAI webhook event handlers fire on events such as item:versionAdded and publish:end, filtered by rules, so each publish can trigger a service that stores the rendered product page, its version and the time, for as long as your retention policy requires. The list has no workflow events, so build the record around publishing: what went live, which version, and when.
Disclaimers by market, and personalization within the rules
Banks that serve several markets, or conventional and Islamic customers, need different legal text for the same product family. Hold each disclaimer as its own item per market, with an approver in that market, and let product pages reference it. When a disclaimer changes, publish it with the pages that use it. Tie legal text to the market site the customer chose, and never let a personalization rule decide which legal text a customer sees.
Personalization works well for emphasis: which product leads, which benefits come first, which campaign banner shows. Page variants have hard limits, ten variants per page and five conditions per audience. One detail matters for compliance: an inline edit in a variant also changes the default page, so give each variant its own approved content items. Keep rates, fees and eligibility identical across variants unless compliance approved an offer for that audience, and get data protection sign-off for any rule built on customer data. Our guide to personalization on SitecoreAI covers the set-up.
Arabic and English, approved together
The CBUAE’s requirement for both languages makes Arabic part of the approval. Start with coverage: if a page has no version in a language, the live site shows it in the site’s default language, so an English-only rate page can appear on the Arabic site. Check language coverage for regulated pages before every release, and treat a missing Arabic version as a release blocker.
SitecoreAI can translate a page and its data sources with AI. With Keep workflow state cleared, the setting Sitecore recommends, the translation starts in the initial workflow state and goes through review. With it selected, the translation keeps the source state and may become publishable at once, so clear it for regulated content.
Then agree how Arabic pages write rates, amounts and dates, from digits to the per cent sign and the currency, and apply it in the front end, which also handles right-to-left layout. Our guide to Arabic-first Sitecore lists the checks.
Calculators and forms that hand off to onboarding
A finance or premium calculator is a promise in numbers. Build it as a front-end component that reads the rate, fees and limits from the same approved source as the product page, shows the approved disclaimer beside the result and states the rate’s effective date. Test it against every rate change, and log which rate version produced each quote.
Forms carry the customer into onboarding. SitecoreAI Forms post each submission to a webhook over HTTPS, with authentication options that include OAuth 2, and test submissions carry a test flag so they can be filtered out. Point the webhook at your onboarding platform or CRM, pass the product code, campaign parameters and language with the form data, and show the customer a clear message when the webhook returns a failure. Collect only what the first step needs: identity documents and account details belong in the onboarding platform after sign-in.
Where to start
- Inventory regulated content: every rate, fee, eligibility line, disclaimer and document on the site, by market and language, with its approver.
- Give each rate one home, and move rates and legal text out of Shared fields and body copy.
- Build the regulated workflow with compliance and Arabic review, and restrict the approve command to compliance.
- Set up the publish archive from webhook events, and test that you can produce any product page as it stood on a given date.
- Connect one form and one calculator to onboarding, and test the whole path in both languages on a phone.
Still on Sitecore XP? Build these controls into the move: Arcsen Ascend is our migration route to SitecoreAI. Choosing a partner? Our Sitecore partner RFP checklist lists the questions to ask.
Frequently asked questions
Can SitecoreAI make compliance approve a rate before it goes live?
Yes, through workflow: an item in a workflow becomes publishable only in a final state, and the approve command can be restricted to compliance. Keep rates out of Shared fields, which workflow does not cover.
Does SitecoreAI keep an audit trail of content changes?
Items keep numbered versions and workflow commands can prompt for comments. Sitecore’s common audit log documentation covers Cloud Portal, Personalize, CDP and Connect, so confirm what your tenant records, and use webhook events on publishing to archive what went live and when.
Should a bank personalize rates on its website?
Keep rates, fees and eligibility identical across variants unless compliance approved an offer for that audience. Personalize emphasis and order, with each variant’s content under the same workflow.
How should regulated pages handle Arabic?
Approve both languages together, check that every regulated page has an Arabic version before release, and keep AI translations in review by leaving Keep workflow state cleared.
Can SitecoreAI forms send applications to an onboarding system?
Yes. Forms post submissions to an authenticated webhook over HTTPS. Send what the first step needs, and collect identity documents in the onboarding platform.
Sources
- Central Bank of the UAE: Consumer Protection Regulation, Circular No. 8/2020
- Sitecore documentation: The template field template
- Sitecore documentation: Schedule publishing availability of a page
- Sitecore documentation: Defining workflows
- Sitecore documentation: Sitecore common audit log
- Sitecore documentation: Webhook event handler configuration fields
- Sitecore documentation: Create a page variant
- Sitecore documentation: Manage languages and locales
- Sitecore documentation: Translate a page with AI
- Sitecore documentation: Work with webhooks in Forms
