House Money × Parity
How House Money integrated Parity in 48 hours.
A casino whose platform did one thing, games, added sports, politics, culture and the economy in two days, and kept its own front end, its own brand and its own players.

Already in place
- Players
- A wallet
- KYC
- A brand
- The casino floor
- The customer relationship
01
The ask
A platform that did one thing, and the thing it was missing.
Before Parity, House Money’s platform did one thing: games. Sports, politics, culture and the economy were all happening somewhere else, and every opinion a House Money player had about them was being expressed on somebody else’s product.
Prediction markets were the obvious answer, and they are not a game you drop into a lobby. Markets need questions sourced and normalized, prices that hold when somebody hits them, positions that survive a refresh, and settlement that agrees with the operator’s ledger to the cent. So the question was never whether House Money’s players would trade. It was whether House Money would have to become a market operator to let them.
The product as it stood
House Money · before
- Slots
- Table games
- Live dealer
- Existing wallet
- Existing accounts
House Money · after
- Slots
- Table games
- Live dealer
- Existing wallet
- Existing accounts
Two rows arrived. Same wallet, same account, same brand, same licence.
02
Live in 48 hours
Almost all of the work in a prediction-market product happens before a player ever sees a price, and House Money did none of it.
Its work was the integration boundary: a server-to-server connection, a session for a player it had already authenticated, and somewhere in its own product for the experience to render. That is a different kind of project from building a wagering platform, and it is why House Money went live with Parity in 48 hours.
That speed is the point, not a footnote. An operator does not need a roadmap conversation or a multi-month plan to find out whether prediction markets belong on their platform. They need two days: short enough that finding out costs less than arguing about it.
Layers to build alone
The integration boundary
One connection. Parity runs the market side; House Money keeps the player, the wallet and the brand.
What the diagram counts is systems, not hours. It is the set of layers an operator would otherwise own and run itself, and the reason House Money’s side of the work fitted into two days is that its side of the work was the right-hand column.
03
What happened next
Three weeks after launch, in the numbers House Money measured.
Integration
48 hours
Start to live. The whole integration, embed to launch.
Engagement
35%
Of House Money’s users engaging with prediction markets weekly, within three weeks of launch.
Volume
Millions
Trading volume on the platform, at the precision House Money reports it.
Supplied by House Money about its own platform, measured three weeks after launch.
Better than a third of the platform now treats a category that did not exist there a month earlier as part of the weekly habit. It is not a trial cohort and it is not a promoted segment.
The figure House Money found most interesting is a shape rather than a percentage: the new category did not divide the existing audience between games and markets. It brought more people through the door.
Parity didn’t only add a new product, it widened our funnel. We’re seeing more unique users across the whole platform, not just on the prediction markets side.
04
How we did it
An embed, one endpoint, and a feed.
House Money dropped in the embed iframe, wired up one server endpoint to mint session tokens and confirm reserved funds, and pointed it at Parity’s market and pricing feed. No custom trading UI was needed. Pricing, market data and settlement all came from Parity, and House Money kept their own front end, their own brand and their own player relationships. The lift on their side looked less like a new build and more like a new tab.
Keep the key on the server.
House Money’s API key never reaches a browser. One server endpoint on their side exchanges that key for a short-lived embed session tied to their own user id, and confirms the funds reserved against the position. The browser holds the session rather than the key, and the player is authenticated once, by House Money, the way they always were.
POST /api/v1/embed-sessions
Put the markets where the player already is.
The embed iframe renders inside House Money’s product, under House Money’s navigation, in House Money’s palette. No second login, no second app, no custom trading UI to design or maintain, and nothing that reads to a player as being handed off to somebody else’s site.
Leave the wallet alone.
One balance. House Money’s ledger stays authoritative on every debit and every credit, and Parity holds no player balance and speaks to no player. Market data, pricing and settlement come from Parity’s feed. When a position resolves, the money moves on the operator’s books.
Parity · prediction marketsThe prediction-market experience renders inside House Money’s own product.
House Money didn’t need another wallet. It already had one. What it needed was the market layer underneath.
What arrived, in full
- Prediction markets
- 5-minute crypto markets
Same wallet, same account, same brand, same licence. A new wagering vertical without a new customer stack.
05
Integration timeline
Six stages, and all six of them inside two days.
Five of the six are configuration rather than construction. The only thing built from scratch was the server endpoint in stage two.
Stage 01 of 06
Provision
The operator gets its own record on Parity: a slug, a key, and a policy for which categories and venues it offers.
Stage 02 of 06
Connect
One server endpoint. The operator’s backend authenticates with its key, mints a session for a player it has already identified, and confirms reserved funds.
Stage 03 of 06
Embed
The iframe is placed inside the operator’s product at a registered origin, with the session handed to the frame rather than sitting in a URL.
Stage 04 of 06
Configure
Palette, locale, region and catalogue policy are set to match the product the experience is going into.
Stage 05 of 06
Verify
Quotes, orders, positions and settlement records are reconciled against the operator’s own ledger.
Stage 06 of 06
Launch
Prediction markets take their place beside the categories the operator already runs.
06
What we learned
Three things this project actually taught us.
01
The customer relationship stays with the operator.
We could have taken the player: own the account, own the balance, own the support conversation. That is the shorter path to a product we control end to end, and it asks a licensed operator to hand over the one asset they spent years building. They are right to refuse. Parity is never in front of a customer, and House Money never has to explain to a player who we are.
02
Prediction markets are a product layer, not another account.
The shape everyone reaches for first is a second wallet, with its own balance, its own deposits and its own reconciliation. It works, and it is the version most players quietly abandon, because funding a separate balance inside a product you have already funded is a strange thing to be asked to do. The market layer belongs under the wallet that exists, not beside it.
03
Executable pricing matters more than a displayed probability.
A midpoint between the best bid and the best offer is a number, not a price. What a buyer pays is their size, filled against a book that is moving, with the fee attached, and near the end of a short window a book can be one-sided enough that the two disagree badly. So a quote here is not a probability with a cost discovered afterwards: side, size, fee and quantity are bound into one record, and that record is the thing that executes.
07
Where the line sits
The operator keeps the customer. Parity runs the market.
The split is the same on every integration, and everything else on this page is a consequence of where the line falls, including how quickly the integration went.
House Money keeps
Players
Every account and login belongs to the operator. Parity never authenticates a player.
Wallet
The balance a player sees is House Money’s, held on House Money’s own ledger.
KYC
Identity, eligibility and jurisdiction stay with the licensed operator.
Brand
The experience carries House Money’s name, navigation and styling throughout.
Ledger
House Money’s ledger stays authoritative on every debit and every credit.
Support
The player talks to House Money. Parity is never in front of a customer.
Parity runs
Markets
The event catalogue, normalized into one question with priced outcomes.
Pricing
Reference prices across the catalogue, kept distinct from an executable one.
Quotes
An executable price with side, size, fee and quantity bound into a single record.
Execution
The order path behind the experience. Safe to retry, and never opening a second order.
Positions
Open positions marked against the live price, with an exit available before resolution.
Settlement
Resolution, settlement records, and the reconciliation an operator checks them against.
Streaming
Price updates over one stream per page, filtered to what the operator offers.
Fast Markets
Short-window crypto markets, priced and resolved on the same infrastructure.
08
What’s next
Where the work goes from here.
01
More inventory.
The catalogue grows as venues are added and categories are normalized, and an operator on Parity gets the additions without doing anything.
02
Fast Markets.
A five-minute crypto window behaves nothing like a market that resolves in November, and it asks more of the pricing path than anything else we run.
03
The mix.
Three weeks in, we know a casino audience opens prediction markets and keeps opening them. Which categories carry that weekly habit, and whether the short windows pull a different player than the long ones, are answers House Money can now read off its own platform rather than guess at.
Run the same integration
Parity runs the catalogue, the pricing, the execution and the settlement. You keep the player, the wallet and the brand.
