Vibecode Rescue: finservcorp.net
80% accuracy, 40% YTD, 20 years of backtesting from a firm that says it has six years of experience — and no risk disclosure, terms or privacy policy anywhere on the site. 40/100 — At Risk.
FinServCorp sells trading education — frameworks, mentorship, an algorithmic module, and a waitlist for something called TradeEasy. Two people are named on the site: a founder and head trader, and a technical director credited with the algorithmic work. The pitch is that their proprietary concepts put a student in the profitable minority.
It scored 40 out of 100. At Risk, by half a point, and the half point is doing a lot of work.
Observed on 2026-08-05 against a snapshot of the page, the shipped bundle, response headers, DNS and every legal route the site might have served. There is no checkout to walk through.
This is the only audit in the batch where the engineering is competent and the copy is the risk.
The numbers on the homepage don't survive being read together
From the hero and the stat strip:
80% Accuracy Rate · 40% YTD Returns · 6+ Years Experience
From the mission statement, two screens down:
…developing a consistent trading framework with an 80% accuracy rate over a 20-year period.
From "Why Choose FinServCorp?":
Our concepts have been successfully backtested over 20 years with an 80% accuracy rate across all market conditions including COVID, elections, and black swan events.
And from the founder's own bio:
Degree in Banking and Finance with 6+ years of trading experience.
Twenty years of results from six years of trading. There's a reading that reconciles it, and it's probably what was meant: the strategy was backtested against twenty years of historical data by people with six years of live experience. But the site never says it. It says "80% accuracy rate over a 20-year period" next to "6+ Years Experience" and lets the reader assemble a track record that nobody has claimed in so many words.
That distinction is the entire difference between a backtest and a record, and it's the first thing a diligence process asks about. A product selling trading frameworks to retail traders should be the most precise writer of that sentence on the internet, not the loosest.
The rest of the claim stack, all from the same page:
20% annually as minimum standard with 40% YTD performance.
Our students achieve consistent payouts that surpass other hedge funds monthly.
Our student success rate is north of 60% — far exceeding industry averages.
…a true trading edge that 99% of the market doesn't have access to.
We know that 90% of traders lose money. With us, we want those 90% to WIN.
Six quantified performance claims. Not one is sourced, dated, or attached to a methodology, an account statement or an audited record. The 90%-lose-money figure is the only one that's a widely-cited industry statistic — and it's the one being used to argue that this product is the exception.
There is no risk disclosure, and there are no legal pages
$ for p in privacy terms refund security; do
curl -o /dev/null -sw "%{http_code} /$p\n" https://www.finservcorp.net/$p
done
404 /privacy
404 /terms
404 /refund
404 /security
No privacy policy. No terms. No refund policy. And — on a site making six quantified claims about trading returns — no risk disclaimer anywhere. Nothing saying past performance doesn't indicate future results. Nothing saying this is education rather than personalised financial advice. Nothing saying you can lose money.
Compare that to another product in this same batch. RefineQuant, which sells an AI backtesting tool, publishes a Risk Disclaimer, an Acceptable Use policy, a Refunds policy, an ABN and the line "General information only — not financial advice. Backtests are simulated." Same category of product, same kind of claim, opposite posture. It isn't hard, and somebody comparable already did it.
One detail sharpens the point. The site does publish legal@finservcorp.net. There's an address for legal correspondence, and no legal document for it to be about.
Support runs through a personal Gmail, twenty-eight times
=== EMAIL ADDRESSES PUBLISHED ===
28 finserv0919@gmail.com
2 shaunyah@finservcorp.net
1 legal@finservcorp.net
The domain has Google MX records, so @finservcorp.net addresses do receive mail — the two published on the domain work. But the address the site actually pushes, twenty-eight times across the collected pages, is a free Gmail account with a numeric suffix.
For a business asking people to trust it with money decisions, the contact channel is part of the product. A personal Gmail can't be handed to a colleague, can't be audited, has no retention policy attached, and disappears with the person. And:
$ dig +short finservcorp.net TXT | grep spf
# nothing
No SPF record. The domain that hosts legal@ and the founder's address is spoofable by anyone, and DMARC sits at p=none, which reports and blocks nothing.
What it gets right
- It's fast and light. Lighthouse desktop: performance 97, best practices 96, SEO 92. Half a megabyte transferred, 0.9-second largest contentful paint, zero blocking time. Plenty of funded startups don't manage that.
- A path that doesn't exist returns a real 404, not a 200 with the app shell.
- A clean credential scan. Nothing exposed in the bundle across nine classes.
- The team is named, with faces and roles. Two people, stated qualifications, stated responsibilities. Most sites in this category hide behind a logo, and naming yourself is the one costly signal here.
-
The mail domain receives. The published
@finservcorp.netaddresses resolve, which is more than three of the five products in the previous batch managed.
The engineering underneath
All six security headers are missing — no HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy or Permissions-Policy. The server is LiteSpeed, unproxied.
Accessibility scores 76, the lowest measured in this batch, with failures on button-name, select-name, color-contrast and heading order. Buttons and a form control that carry no accessible name are a screen reader hitting an unlabelled control on a page asking for your contact details.
The score
Part B is 26.5 of 45 — the third-highest engineering score in this batch. Part A is 13.5 of 55, the second-lowest I've recorded in this series. The total lands one half-point above Broken purely because the site is well-built, and I want to be plain about what that means: the rubric is measuring the product, and the product is a website. The claims on it are Part A's business, and Part A is where it falls apart.
What I'd fix first
- Publish a risk disclaimer. Above the fold on a page claiming 40% YTD returns. This is the one that matters, and it's an hour of work.
- Separate backtest from track record in every sentence that currently blends them. "Backtested across 20 years of data" and "six years trading it live" are both defensible; the current phrasing is what turns them into a liability.
- Source the six numbers or cut them. Accuracy rate, YTD return, annual minimum, hedge-fund comparison, 60% student success rate, 99% market edge. Each needs a methodology note or it needs to go.
-
Write terms and a privacy policy. You already publish
legal@. - Move support to the domain, and publish an SPF record while you're in the DNS console.
Disclosure
Findings went to the operator before this published. These audits are free and public; the paid version is a Code Health Check, and the rescue work after it is Track 03 on my services page.
Payments scored Unknown rather than excluded: there is no public checkout, but the site serves a login, so a paid surface exists somewhere I can't reach from outside.