Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Architecture
GitHub Logo

Real-time Rates for Financial Websites

See how Harper combines cached page content with current bank rates to deliver accurate offers in HTML with fewer serving systems to manage.
Real-time
Architecture
Real-time

Real-time Rates for Financial Websites

Harper
at Harper
November 3, 2026
Harper
at Harper
November 3, 2026
Harper
at Harper
November 3, 2026
November 3, 2026
Deliver current rates and terms as pages load, with fewer serving systems for your team to manage.
See how Harper combines cached page content with current bank rates to deliver accurate offers in HTML with fewer serving systems to manage.
Harper

A visitor compares savings or loan products on your bank’s website. They need a clear, accurate picture of the rate, the terms and when the offer applies. Your development team makes that experience possible. The goal is straightforward: when a rate change takes effect, the very next page load should show the new rate, with no more than seconds between the change and its appearance on the site. The experience needs to be fast, consistent, and accurate every time. Harper brings incoming rate updates, current offer data, and page rendering together, giving your development team a direct path from an approved change to the page your customer sees.

How Harper delivers current rates on every page

Harper brings together your website’s existing page content and current rate data before delivering the page. It caches the HTML shell from your origin and inserts the applicable rate, terms, and disclosures into the response. Your team can publish page content on its normal schedule while approved rate updates flow independently, keeping financial information current without rebuilding the whole page.

Your development team connects the approved rate feed and configures page-cache rules so a rate change reaches the next request without waiting for a scheduled site rebuild. The origin continues to handle the page layout and general product content. Your existing rate system continues to own approval and effective dates.

Including rates in the returned HTML also makes them available to permitted search and AI crawlers that do not execute the page’s JavaScript. Your team can start with crawler traffic, then extend the same delivery pattern to customer pages. Both receive the applicable offer in the page itself.

For experiences that also need to update pages already open, your team can add live browser subscriptions. Harper delivers the changed offer so the page can update its rate and terms without a refresh. This optional extension runs alongside rate storage and page assembly. Fabric manages regional deployment, replication, routing, and failover as the service grows.

Alternatively, separate services handle each step

A conventional setup connects a rate feed to a database, a cache, and a separate page assembly service. That service combines the origin’s cached HTML shell with the current offer. An optional messaging service delivers changes to open browser sessions, while the website and CDN manage cached pages. These services can meet the same requirements. The work is keeping their rate data, effective dates, and refresh rules aligned, especially as traffic grows or the service expands across regions.

Where coordination adds up when rates change

When a rate changes, updating the database is only part of the job. Newly requested pages must use the applicable offer, cached copies must be refreshed or bypassed, and open pages need the same update if live delivery is enabled. Separate services add connections for your team to build, monitor, and recover. Harper brings the data and serving logic together, reducing that coordination while keeping page caching and source updates under your control.

Why Harper matters

  • Current rates at page load. The renderer reads the current rate from the same process that stores it and injects it into the HTML, so visitors see the approved rate without waiting for a browser script.
  • Fewer systems to keep in step. Rate processing, storage, rendering, and live messaging run together, removing hops between them and reducing the cache coordination the web team maintains.
  • Consistent terms. Rates, effective times, conditions, and disclosures are written together, so a page does not pair a new rate with old terms.
  • Simpler regional growth. Fabric manages deployment, replication, routing, and failover as the service expands to more regions.
  • Optional live updates. Teams can add browser subscriptions later, without changing how pages render first.

Build around your rate and disclosure requirements

Define when an approved offer takes effect, which customers and products it applies to, and what information must accompany it. Build those decisions into your application so the rate, dates, and disclosures are delivered together. Set a freshness target for the full path from your rate system to the customer’s screen, including any CDN and serving regions. Agree on the message to show if the current offer cannot be confirmed, and have reconnecting pages retrieve the latest offer.

U.S. advertising rules make accuracy and disclosure part of this design. For deposit accounts, Regulation DD, § 1030.8(a) and (c)(2), prohibits misleading or inaccurate advertising and requires an advertised APY to include its offer period or an as-of date. The official interpretation of § 1030.8(c)(2) says that date must be recent relative to the medium’s publication frequency and circumstances.

For closed-end consumer loans, Regulation Z, § 1026.24(a), limits advertised credit terms to those the lender actually offers or will offer. These provisions do not set a universal website refresh deadline in seconds. Work with your compliance team to define the applicable offer, disclosure, and timing rules, then measure delivery against them. Real-time delivery helps your team put those decisions into practice.

Related resources

Start with one rate-sensitive product page

Start with one savings or loan product page and your existing approved rate source. Set the freshness target with your product and compliance teams, then measure how quickly changes reach newly loaded pages. If live updates are enabled, test open sessions too. Include your CDN and every serving region in the test. Track page speed, offer consistency, and the engineering effort required to operate the service. Bring your rate source and website setup to a Harper architecture workshop to map a pilot around your requirements.

‍