How SavingsAI Works: The AI-Powered Tech Stack Behind the Site

The Problem: UK Savings Rates Are a Moving Target

The UK savings market is surprisingly opaque. Banks change their rates frequently — sometimes multiple times a week — and there is no single authoritative feed that aggregates all of them in real time. Major comparison sites update their data infrequently or rely on bank-supplied data that can lag the live rate by days. For a saver trying to catch the best rate before a fixed-term window closes, that lag costs real money.

SavingsAI was built to solve this problem at the individual level: an independent, daily-updated comparison of every major UK savings account — easy access, fixed term, ISA, and notice — without relying on bank-supplied data feeds, affiliate relationships that skew rankings, or manual research that cannot scale beyond a handful of products.

The result is a site that tracks 121 savings accounts across 17+ UK banks, updates every morning before UK markets open, and serves that data to users in both English and Traditional Chinese — powered entirely by automation and AI, with no paid staff maintaining a spreadsheet.

The Architecture: Five Layers Working Together

SavingsAI's backend is built around five distinct layers. Understanding each one explains why the data is reliable, why the site stays current without human curation, and why the whole system can run continuously at near-zero operating cost.

Layer 1 — Data Collection: n8n as the Daily Orchestrator

n8n is an open-source workflow automation platform — similar in concept to Zapier or Make, but with the flexibility to run complex multi-step pipelines with full control over data flow and no per-operation costs at scale. SavingsAI's entire backend pipeline is built as a single n8n workflow that runs on a daily schedule.

Each morning, the workflow wakes up and begins visiting the savings pages of every tracked UK bank. Rather than relying on bank APIs (which most UK retail banks do not publicly expose for savings rates), the workflow reads the published rate information directly from the bank's own website — the same source a human researcher would use. This means the data reflects what a customer would actually see today, not what was submitted to a data broker last week.

Why n8n Over Custom Code?

The decision to use n8n rather than a bespoke Python script was deliberate. n8n provides a visual workflow editor that makes the data flow auditable — each step, transformation, and branch is inspectable without reading code. It also handles scheduling, error retries, and execution logging natively, which means fewer moving parts to maintain. The workflow can be updated in minutes when a bank redesigns its website or changes the format it uses to display its rates.

The n8n instance runs on a lightweight cloud server. Execution typically completes in under three minutes for the full 17-bank sweep, well within the daily window before the UK finance news cycle begins.

Layer 2 — AI Verification: Three Models, One Ground Truth

Raw data collected from bank websites is not automatically trustworthy. Page structures change, banks introduce promotional rates in unusual formats, and automated collection can occasionally misparse a number. A single AI model verifying its own output is prone to confirmation bias — it tends to accept what it initially extracted. SavingsAI's solution is a three-model verification pipeline.

Claude (Anthropic)

Claude serves as the primary extraction and reasoning model. Given the raw text content of a bank's savings page, Claude is asked to identify the AER, gross rate, account type, minimum deposit, notice period (if any), and FSCS protection status for each product listed. Claude's strength is structured reasoning — it handles ambiguous rate presentations (e.g., tiered rates, introductory bonus rates) and can explain its interpretation in plain English, making it easy to audit.

Gemini (Google)

Gemini acts as the second-opinion cross-checker. It receives the same source content and returns its own independent extraction. Discrepancies between Claude's output and Gemini's output are flagged for closer inspection. Gemini is particularly strong on numerical precision and catches cases where Claude has misread a table layout or interpreted a promotional rate as the headline rate.

Perplexity

Perplexity provides the real-time web validation layer. Because Perplexity can access live web content, it serves as a final sanity check: "Is the rate we have just extracted consistent with what Perplexity currently finds for this bank's savings account?" This catches edge cases where the n8n collection step visited a cached or regionalised version of the bank's page rather than the live national rate.

In practice, the three-model pipeline agrees on the first pass for roughly 94% of rate checks. The remaining 6% typically resolve at the Perplexity validation step. Manual review flags are rare and usually indicate a bank has made a same-day rate change mid-sweep, which is then re-checked the following morning.

Layer 3 — Rate Change Detection: The 0.05% AER Threshold

Once the AI verification pipeline produces a clean, validated dataset, it is compared against the previous day's snapshot. SavingsAI does not treat every data point as equally significant. Minor discrepancies under 0.01% AER are treated as floating-point rounding differences in how different bank pages display the same rate. Changes of 0.05% AER or more are treated as genuine rate movements and trigger the notification pipeline.

The 0.05% threshold was chosen deliberately. At a £10,000 deposit, a 0.05% AER change represents £5 per year — meaningful to a saver making an active comparison decision, but small enough that smaller rounding differences do not generate unnecessary alerts. For ISA accounts where the FSCS-protected £20,000 allowance is fully deployed, the same 0.05% movement represents a £10 annual difference.

What Gets Stored

The validated daily dataset is written to a structured data store that serves as SavingsAI's operational database. Each record contains the bank name, product name, account type, AER, gross rate, minimum deposit, notice period, FSCS status, and the date last updated. The structure is intentionally flat and simple — one row per savings product — making it fast to read at query time and easy to audit when something looks wrong.

A secondary historical store maintains a rolling 30-day record of rate values for each product. This is the data source for rate history context and provides the snapshot baseline for the daily change detection comparison.

Layer 4 — Bilingual Delivery: English and Traditional Chinese in Parallel

SavingsAI serves two parallel versions of every page: English (/index.html, /blog/) and Traditional Chinese (/zh/index.html, /zh/blog/). The Chinese version targets the significant UK-based Hong Kong and wider Chinese-speaking diaspora community, for whom the UK savings market can feel particularly opaque when most financial content is only available in English.

The bilingual architecture operates at the content generation level, not via automated translation of English output. Blog articles, news summaries, and rate comparison labels are written independently in each language, ensuring that the Chinese content reads naturally rather than as a machine translation artifact. n8n triggers parallel content generation workflows for both languages simultaneously, with each language's output validated before publication.

The rate data itself is shared between both language versions — the underlying numbers are the same. What differs is the surrounding editorial content, the navigation labels, the blog articles, and the news summaries. A daily n8n sub-workflow handles the Chinese content pipeline in parallel with the English one, completing within the same morning window.

Layer 5 — User Alerts: Push Notifications Without Personal Data

One of the most common requests from savings comparison users is: "Tell me when rates change." Implementing this without collecting email addresses or phone numbers — which would trigger GDPR personal data controller obligations — required a different approach.

SavingsAI uses OneSignal's browser push notification service. Here is why this is genuinely privacy-preserving rather than merely privacy-adjacent: the browser's own native permission system handles consent. When a user clicks "Allow" on the browser's notification prompt, the browser — not SavingsAI — stores the subscription token. OneSignal receives a pseudonymous browser token; SavingsAI's servers receive nothing. There are no email addresses, names, or user profiles on SavingsAI's infrastructure at any point.

When the n8n rate change detection step identifies a movement of 0.05% AER or more, it calls the OneSignal REST API with a notification message — for example: "Marcus has moved its Easy Access savings rate to 4.75% AER — check if you need to switch." This fires within minutes of the rate change being detected in the morning sweep, before most UK savers have started their day.

The Full Data Flow: Bank Website to User Screen

Putting all five layers together, here is the complete journey a savings rate takes from a bank's website to a user's screen:

1. Step 1 — Data collection. The workflow begins each morning, visiting each bank's savings page in sequence and extracting raw rate data for every tracked product.
2. Step 2 — AI verification pipeline. Each extracted rate is passed independently to Claude, Gemini, and Perplexity for cross-checking. Consensus rates are accepted; conflicts are flagged for review.
3. Step 3 — Change detection. Today's validated rates are compared against the previous day's snapshot. Movements of 0.05% AER or more are logged as rate change events.
4. Step 4 — Data store updated. The live dataset is overwritten with today's validated rates, timestamped. The historical store receives a new daily record.
5. Step 5 — Rate data published to site. The validated dataset is written to a format the site can serve statically — no database query required at page load time.
6. Step 6 — Push notifications triggered (if applicable). If any rate changes were detected, the OneSignal API is called to dispatch browser push notifications to opted-in users.
7. Step 7 — RSS feed updated. The /feed.xml file is regenerated with the latest top rates and any new blog content published in the last 24 hours. This file is publicly accessible — anyone can subscribe via any RSS reader.
8. Step 8 — Social distribution. New content and rate summaries are cross-posted to Threads, Facebook, and Telegram via an AI-assisted pipeline powered by openclaw and a locally hosted Qwen3.5 35B model running on an NVIDIA DGX Spark.
9. Any time of day — User visits savingsai.co.uk. The browser loads the static HTML page and renders the full 121-account comparison table in milliseconds — no server-side processing, no API call at runtime.

Content Generation: AI-Assisted, Human-Reviewed

Beyond rate tracking, SavingsAI publishes regular blog articles and a daily UK finance news feed. These are also generated with AI assistance, but the workflow is different from the rate pipeline: AI drafts are reviewed and edited by the SavingsAI editorial team before publication, never published directly from the model output.

For the news feed, n8n aggregates headlines from several UK financial news sources, uses AI to summarise and contextualise each story for a savings-focused audience, and publishes the result to the news page. The editorial team reviews the output at publication and can pull any item that misrepresents the source material.

Social distribution is handled by a separate pipeline built on openclaw with a locally hosted Qwen3.5 35B model running on an NVIDIA DGX Spark. This setup generates contextual, platform-appropriate posts for Threads, Facebook, and Telegram — tailored in tone and format for each channel — without relying on third-party cloud AI for content that will be publicly published under the SavingsAI brand.

Blog articles — like this one — are written with AI assistance to handle research aggregation and initial drafting, then reviewed and substantially edited by team members with finance backgrounds before being published. The aim is the best of both: AI's ability to synthesise large amounts of information quickly, combined with human judgement on accuracy, tone, and the specific needs of a UK savings audience.

What This Architecture Gets Right — and Where It Has Limits

This kind of AI-orchestrated comparison system has genuine strengths that traditional manual research cannot match. The daily update cadence means rates are never more than 24 hours stale. The three-model verification catches errors that a single human researcher would likely miss in a routine daily check. The static frontend means the site is fast, secure, and cheap to run.

The architecture also has a deliberate scope boundary: SavingsAI tracks headline savings rates on publicly available savings accounts — it does not attempt to replicate the full product detail of a bank's terms and conditions, monitor temporary promotional rates that require a phone call to access, or track accounts that are only available to existing current account holders. These limitations are intentional; staying within scope is what keeps the data reliable.

The Technology Stack at a Glance

Why Transparency Matters for a Financial Comparison Site

There is a reasonable scepticism about AI-generated financial content — and that scepticism is warranted. A system that publishes financial data without explaining how it works is asking users to trust a black box with decisions that affect their savings. SavingsAI's approach is to make the methodology as transparent as possible: the data sources are publicly accessible bank websites, the AI models used are named and well-documented, the verification logic is described here, and the editorial team's background is published on the author page.

If you spot a rate that looks incorrect, the contact page goes directly to the editorial team. Rate corrections are prioritised and typically resolved within one business day — which in practice means the correction appears in the next morning's automated sweep, verified by all three models before going live.

Building a reliable financial data product with a small team and no institutional data budget requires automation to be thorough and AI to be verified. This stack is SavingsAI's current best answer to that challenge — and it continues to evolve as the AI tools available improve and as the UK savings market changes.