How do I set up a mortgage rate alert?

The simplest version is an n8n workflow that fetches the Freddie Mac PMMS CSV weekly and emails you when rates drop past your target threshold. Full personalization requires persisting borrower data and computing break-even before dispatching any notification.

How much does a mortgage rate need to drop before it's worth refinancing?

There is no universal answer. Divide your estimated closing costs by the monthly payment reduction at the new rate. That gives you break-even months. If you plan to stay in the home longer than that, the refinance makes sense. A 25 basis point drop could be enough for some borrowers and meaningless for others depending on loan balance and closing costs.

Are mortgage rate alert services free or do they sell my data to lenders?

Most free alert services from aggregators like Bankrate or NerdWallet generate revenue by selling or referring your contact information to lenders. If you are not paying for the product, the alerts are the lead-gen funnel, not the product itself.

What data sources should I monitor for the most accurate mortgage rates?

Freddie Mac's Primary Mortgage Market Survey is the most widely cited weekly benchmark and is available as a free CSV download. For daily movement, lender rate sheets are more granular but require scraping or a direct relationship with a pricing engine.

How do I build my own mortgage rate tracker without using a paid service?

Pull the Freddie Mac PMMS CSV on a weekly schedule using a free automation tool like n8n, store the values in a spreadsheet or database, and alert yourself when the rate crosses a threshold you set. The full stack with personalized break-even math requires Supabase, a scheduler, and an email or SMS dispatch service.

What TCPA rules apply to mortgage rate alert text messages?

Any automated SMS to a mobile number requires prior express written consent under TCPA. That consent must be clearly documented, stored, and honored if revoked. Email alerts have more flexibility but are still subject to CAN-SPAM requirements around opt-out and sender identification.

Mortgage Rate Alert Automation: A Builder's Guide

Mortgage rate alert automation is something almost every loan officer and borrower wishes existed but rarely builds correctly. The SaaS tools on the market are mostly lead-gen wrappers: they capture your email, show you a generic rate that may not match your loan profile, and sell your contact info to lenders. I wanted something different. I wanted a system that pulls a real rate source, filters out noise, computes a personalized break-even threshold for each borrower, and fires an alert only when acting actually makes sense. This post walks through how I built that, what the architecture looks like, and where the real friction points are.

Why Generic Rate Alert Services Fall Short

Before building anything, I looked at what was already out there. Bankrate, NerdWallet, and most lender sites offer some version of a rate alert. You enter an email address, pick a loan type, and they promise to notify you when rates move. The problems are consistent across all of them.

First, the rate they show is not your rate. The Freddie Mac Primary Mortgage Market Survey publishes a weekly average for a 30-year fixed loan across all conforming borrowers. That number gets quoted everywhere. But your actual rate depends on your credit score, loan-to-value ratio, loan amount, property type, and the lender's own margin. A borrower at 680 FICO with 10 percent down is looking at a rate that could be 50 to 75 basis points higher than the headline figure. Alerting them to a headline drop without adjusting for their profile is noise.

Second, these services alert on any movement. Mortgage rates move every business day. A 3 basis point drop from Tuesday to Wednesday means nothing to a borrower who needs to see 50 basis points of improvement to break even on refinance costs. Alerting on every tick trains people to ignore the alerts.

Third, they cannot compute break-even for a specific borrower. Break-even is simple math: divide total closing costs by the monthly payment reduction. If refinancing costs $6,000 and the new payment saves $200 per month, the borrower needs 30 months to break even. If they plan to sell or move in two years, the refinance makes no financial sense even at a lower rate. No generic alert tool does this calculation. They cannot, because they do not have the borrower's loan data.

The Architecture Behind Mortgage Rate Alert Automation

Here is the stack I used. None of it is exotic. The goal was something I could run cheaply and extend without rebuilding from scratch.

Data source: Freddie Mac's PMMS data, published weekly as a downloadable CSV at freddiemac.com/pmms. For more granular daily movement, I supplemented with a scrape of a lender rate sheet. The Freddie Mac data is free, structured, and reliable. It lags by about a week, which matters for urgency but not for trend detection.
Persistence: A Supabase Postgres table with one row per rate observation: date, loan type, rate, points, source. Historical rows let me compute a rolling average and flag when a current reading is a true departure from recent trend rather than random noise. I wrote about the Supabase table design I use for single-operator projects in this post on row-level security.
Scheduler: An n8n workflow that runs every Monday after the Freddie Mac update drops. It fetches the CSV, parses the latest row, writes it to Supabase, and then triggers the comparison logic.
Alert dispatch: Resend for email, Twilio for SMS. Email goes to everyone whose threshold was crossed. SMS only goes to borrowers who explicitly opted in with written consent. More on that below.

Noise Filtering: The Part Everyone Skips

Rates bounce. A single weekly reading 10 basis points below last week could be a genuine trend or it could reverse completely the following week. I did not want to send alerts that aged badly within days.

My filter uses a 4-week rolling average. I only fire an alert if the current rate is at least 25 basis points below the rolling average AND below the individual borrower's target threshold. Twenty-five basis points was a judgment call. It is small enough to catch meaningful moves early, large enough to ignore the usual week-to-week jitter in the PMMS data.

The query looks roughly like this:

SELECT
  b.borrower_id,
  b.current_rate,
  b.target_threshold,
  b.loan_balance,
  b.estimated_closing_cost,
  r.rate AS current_market_rate,
  r.rate - AVG(r2.rate) OVER (
    ORDER BY r2.week_ending
    ROWS BETWEEN 3 PRECEDING AND CURRENT ROW
  ) AS rate_delta
FROM borrowers b
CROSS JOIN latest_rate r
JOIN rate_history r2 ON r2.loan_type = b.loan_type
WHERE
  r.rate < b.target_threshold
  AND (r.rate - rolling_avg) < -0.25;

That is simplified, but the logic is there. The join against borrower records is what makes this personalized rather than broadcast.

Break-Even Computation per Borrower

Every borrower record in my system has four fields relevant to break-even: current rate, current loan balance, estimated closing cost for a refinance, and months remaining on the loan. When a rate drop crosses the threshold, the system computes the following before sending anything:

New estimated payment at the current market rate for the remaining term.
Monthly savings: old payment minus new payment.
Break-even months: closing cost divided by monthly savings.
Remaining term in months: if break-even months exceeds remaining term, no alert fires.

This one check eliminates a significant share of false positives. A borrower with 4 years left on a loan who would need 36 months to break even should not get an excited text message about refinancing.

TCPA Constraints Shape Every Outbound Channel

This is where a lot of builders get into trouble. SMS and phone calls to borrowers are regulated under the Telephone Consumer Protection Act. The short version: you need prior express written consent before sending any automated text message or placing an autodialed call to a mobile number, even if the borrower is an existing client. Consent has to be clear, documented, and revocable on demand.

I wrote the full compliance architecture for my outbound mortgage calling system in a separate post: TCPA Compliant Mortgage Automation: Follow-Up That Won't Sue You. The summary relevant here is that my rate alert system gates SMS dispatch behind a consent flag stored per borrower. If the flag is not set, the system sends email only. Email is not subject to the same TCPA rules, though CAN-SPAM still applies.

One thing I do that generic alert services cannot: I log every alert sent, the rate data that triggered it, the break-even calculation, and the channel used. If a borrower ever questions why they received a message, I have a full audit trail. That is not optional infrastructure. It is the minimum viable compliance posture for anyone originating loans.

I also built an opt-out endpoint into every SMS. Twilio handles STOP replies natively, but I also mirror the opt-out into Supabase so the consent flag is updated in real time. A borrower who opts out of SMS at 9 PM on a Tuesday will not receive another text at 8 AM Wednesday when the scheduler runs. The check happens at dispatch time, not at schedule time.

What I'd Actually Do If You're Building This Now

If you are a loan officer who wants to set this up for your own pipeline, here is my honest recommendation: do not start with the full architecture above. Start with a much simpler version and add complexity only when the simple version proves out the concept.

Week one: set up an n8n free instance, pull the Freddie Mac PMMS CSV on a weekly schedule, and send yourself an email when the rate drops more than 25 basis points from last week. That is maybe two hours of work and zero dollars. It will tell you immediately whether you actually care enough about this to build further.

Week two: add a Google Sheet or Airtable with borrower records. Have the n8n workflow loop over the sheet and send personalized emails only to borrowers whose target threshold was crossed. Still no database, no custom code, no deployment. Resend's free tier handles 3,000 emails per month, which is more than enough for a single loan officer's active pipeline.

Week three is where the Supabase persistence, rolling average filter, and break-even math come in. By this point you have validated that the workflow runs reliably and that borrowers actually engage with the alerts. You are not building infra for a feature nobody uses.

The tradeoff I accepted in my own build: I spent more time on the consent and audit layer than on the rate logic itself. The rate math is maybe 20 percent of the code. Compliance infrastructure is 50 percent. That ratio surprised me, but it should not have. The risk in this system is not a wrong rate calculation. The risk is an unconsented outbound message to a borrower who did not ask for it. One complaint to the CFPB or a class action plaintiff's attorney changes the calculus fast.

If you want to see the other constraints I design around in the mortgage automation stack, the broader picture is in AI in Mortgage Lending: What It Can and Cannot Do.

The Actual Value This Creates for Borrowers

Borrowers are not going to monitor rate charts. They check once when they are actively shopping and then forget about it until someone calls them. A well-built alert system changes that dynamic without being annoying. The key word is personalized. An alert that says "rates dropped, you should call us" is spam. An alert that says "based on your current loan balance of $340,000 and estimated closing costs of $5,200, the rate drop this week would result in a monthly savings of $180 and a break-even period of 29 months" is useful.

That second message converts because it answers the actual question: does this rate drop matter to me specifically, right now? Generic alert services cannot send that message. They do not have the data. A loan officer who has already worked with the borrower does.

The conversion rate difference between a generic rate alert and a personalized break-even alert is not something I have a controlled study for. But in my own pipeline, the borrowers who received personalized alerts were meaningfully more likely to schedule a call than those who received a generic market update. The math makes the decision easier and reduces the friction of re-engaging.

If you are a borrower looking to get ahead of the next rate drop, the best first step is getting your loan in order so you can move quickly when the window opens. You can start that process at NewFed's borrower portal and I'll be on the other side of it.