How Niekie is built, and what it refuses to publish

Niekie reads casinos' public bet feeds continuously, scores operators from sources they do not control, and withholds any figure it cannot state precisely. This is how that works, including the parts that do not work yet.

Affiliate publishing has had the same shape for twenty years. Write reviews, rank for them, send traffic, get paid. When search engines tightened their quality guidelines for money and health topics, a large part of that industry lost its visibility in weeks, because a static review is a claim about an operator on the day it was written and nothing more.

A page written in March cannot tell you that an operator changed its withdrawal limits in July. We built something that reads the operators instead.

Below is what actually runs. Where something is planned rather than built, it says so, because a technical write-up that overstates itself is the same failure as a review that overstates a casino.

What runs continuously

Bet-feed collection: several crypto casinos publish a live ticker of settled bets. We read those feeds around the clock and store every round.

Polling is per operator, at the rate each feed will bear: Roobet and Shuffle every 6 seconds, Winna every 15, Stake every 30. We have collected over 390,000 settled rounds this way, across roughly 6,000 games.

This is the only part of the system that is genuinely real time. Everything else runs on a daily schedule, and we would rather say that than call a nightly job real time.

Collection runs from two machines, which is not an architectural preference. Cloudflare will not serve Stake's feed to a datacenter IP, so Stake is collected from a residential connection while the other three run on a small cloud instance. The collector holds raw rounds locally and writes only aggregates upstream, so a bad collection run can be replayed rather than recollected.

What the daily jobs do

Licence registries, sanctions lists, enforcement actions, domain records and terms and conditions are each checked on their own schedule, mostly overnight. Term changes are picked up daily, not at the moment they happen.

Terms diffing: we store a snapshot of each operator's terms and compare it against the last one, so a changed wagering requirement or withdrawal cap shows as a diff rather than as a rumour.

Bonus arithmetic: a bonus advertised as "100% up to $1,000" is a marketing number. Our bonus tool takes the wagering multiplier, the game weighting and the maximum bet clause and returns the expected value, which is the number that decides whether an offer is worth taking.

The scoring, and why it is boring on purpose

The score is computed by an algorithm from recorded inputs. The same inputs always produce the same score. No human adjusts a number, and there is no field anywhere that lets one.

Every calculation is hashed. The inputs are serialised in a canonical form and run through SHA-256, so a published score carries a fingerprint of exactly what produced it. If we changed an input later, the hash would not match.

That matters more than it sounds, because the obvious question about any affiliate-funded rating is whether the money moves the number. A deterministic pipeline with a hash is how you answer that with something other than a promise.

What we refuse to publish

This is the part most write-ups leave out, and it is the part that took the most work.

Return figures we cannot state precisely. Slot returns are driven by rare large multipliers, so a mean over a few hundred rounds can sit far from the true rate by luck alone. We publish a game's observed return only when the 95% interval is within 10 points, and we show the interval next to the figure. Of 423 games with over 100 rounds, five currently qualify.

Return figures that are impossible. A precision test alone is not enough. Three games passed it and still produced rates no casino game could pay: 102.6%, 75.8% and 33.0%. The interval was tight because the heavy tail had not been drawn yet, not because the estimate had converged. Any point estimate outside 80% to 100% is withheld and counting continues.

If we published everything the way a live-RTP board does, 336 of 423 figures would be impossible. Four in five.

A studio-level RTP table. Pooling a studio's games mixes distributions with different multiplier scales, so variance grows faster than the sample: Hacksaw across 53,000 rounds gives 124% give or take 12 points. Instead the studio pages publish how often a studio's games return nothing, which is a proportion and settles quickly. The same 53,000 rounds give 89.9% to within a quarter of a point.

Anything from a feed we can prove is curated. A live ticker is a marketing surface. When a game's whole confidence interval sits above break-even, that is arithmetic proof the operator is not publishing every round, because no casino pays out more than it takes. Those rounds are labelled and excluded. Leaving one curated feed in moved a studio's figure by 13 points against an interval of one.

Operator solvency. We publish no reserve, deposit or treasury figures, because a wallet balance only means something once you can show the wallet belongs to that operator. That requires opening accounts and recording the deposit addresses the casino itself hands over. The registry and its provenance rules are built. It is empty, and until it is populated we make no solvency claim.

What we got wrong

An architecture piece that lists only successes is marketing. Two failures worth publishing:

A regulatory fine against a slot software vendor was matched to a casino with a similar name, and that casino was published at 25 out of 100 as a result. Every input to that grade was about a different company. The matcher now requires whole-word containment and a minimum stem length, and a test suite built from the real incident guards it.

More recently, one operator's feed labelled Nolimit City and NetEnt games with a code we read as a studio name. 86% of what we called Evolution Gaming was that mislabelling. It was caught by comparing what different casinos say about the same game: where two independent feeds agree and one disagrees, the odd one out is the defect. 192 games were reattributed, and a check now runs against the live data rather than only against test fixtures.

Both were the same class of error: a correct calculation attached to the wrong company. It is invisible once published, which is why the checks matter more than the pipeline.

Security, stated plainly

The platform runs behind a managed edge with TLS in transit, and data is encrypted at rest by the database provider. Table access is governed by row-level policies rather than by application code alone, so a query cannot reach data the caller has no right to.

We are not going to claim a bespoke security programme. It is a standard managed stack configured carefully, and the meaningful risk for a site like this is not a firewall rule, it is publishing something false about a named company.

What is not built

Stated so nobody has to guess.

• Wallet attribution is designed and empty.
• Payout reliability is a scored pillar with almost no submissions behind it.
• Dispute filing does not exist. Operators can contest a figure by contacting us, and a disputed number is rechecked against the stored observations rather than removed.
• Automated risk detection for problem gambling does not exist. The responsible gambling page lists real helplines, and that is the honest extent of it today.

Who builds it

The scoring method was designed by Otto Bergström, founder, after 18 years auditing iGaming operators: which signals count, and what each is worth. Maj Jan Krošl, Chief Product Officer, built the pipeline, the collectors and the public surfaces.

The method is set in advance, applied identically to every operator, and published in full at how we score. The limits of what it can support are at our methodology.

We take affiliate commission from some operators. It never changes a score, and the reason that claim is checkable rather than a promise is the deterministic pipeline and the hash.

Frequently asked questions

How does Niekie collect casino data?

Continuously from casinos' public bet feeds, polling each operator every 6 to 30 seconds, which has produced over 390,000 settled rounds. Licence registries, sanctions lists, enforcement records, domain data and terms and conditions are checked on daily schedules. Only the bet feeds are real time.

Is the casino score decided by a person?

No. It is computed by an algorithm from recorded inputs, and the same inputs always produce the same score. Each calculation is hashed with SHA-256 over a canonical serialisation of its inputs, so a published score carries a fingerprint of what produced it and cannot be quietly changed afterwards.

Why does Niekie show "collecting" instead of an RTP figure?

Because the figure is not yet precise enough to mean anything. Slot returns are driven by rare large wins, so a few hundred rounds can sit far from the true rate. A figure is published only when its 95% interval is within 10 points and the estimate falls in a range a real casino game could pay. Of 423 games with over 100 rounds, five currently qualify.

What is a curated feed?

A casino's live bet ticker that shows more winning rounds than losing ones. When a game's entire confidence interval sits above break-even, that is proof the feed is not publishing every round, because no casino returns more than it takes. Those rounds are labelled and excluded from published figures.

Does affiliate commission affect the score?

No. Scoring is deterministic and the inputs are hashed, so the same evidence always produces the same number regardless of commercial relationship. Commission is disclosed wherever an affiliate link appears, and an operator that performs badly is marked down whether it pays us or not.