Prediction markets software: what operators need from it
The screen is the easy part to judge and the least important. What decides whether prediction markets software works for an operator is everything behind it: where the markets come from, what a price means, how an order is protected and how a result reaches your ledger.
In this article 10 sections
- What prediction markets software has to do
- A catalogue in one shape
- Prices that mean one thing
- Execution that refuses rather than slips
- Settlement and reconciliation
- Risk controls, and what you offer
- Compliance by country
- Wallet integration: one balance
- Embed or API: who draws the screen
- Questions to put to any provider
An operator looking at prediction markets software is usually shown a screen first: a market list, a ticket, a portfolio. That is the cheap part. The software that decides whether the category works inside a sportsbook or a casino sits behind the screen, and it has to keep running long after launch day: a catalogue that stays in one shape while venues change theirs, prices that mean what they say, orders a retry cannot double, and results that reach your ledger exactly once.
What prediction markets software has to do
Strip the interface away and the list is short to write and long to run. The software has to hold a catalogue, price it honestly, execute against it safely, settle it exactly once, enforce what you are allowed to offer, and move money only on your ledger. Each of those is a system that has to keep agreeing with the outside world, which is why building it in-house is a rebuild rather than a feature.
A catalogue in one shape
Venues disagree about what a market is. One publishes a question with two outcomes, another a ladder of thresholds under a single event, and either can change shape without warning. Good software hands you one event model instead: one question, an ordered set of priced outcomes and a canonical category rather than a venue tag, so your rendering code is written once and does not change when the liquidity behind it does.
It should also say whether a market is tradeable right now, not merely whether it exists. Parity's catalogue is ingested continuously and spans sports, politics, economics, finance, crypto, technology, weather, culture and more, each event with its price history and the resolution rules a customer can read before trading.
Prices that mean one thing
A number on a card and a number a customer can trade at are different numbers. The first is a reference; the second is what the market will fill for one side and one size at this moment. They diverge most in fast or near-certain markets, which is exactly when it matters. The software has to keep them apart, and bind the executable one into a quote: contract, side, stake, price, fee and quantity in one record, with an expiry.
On Parity the fee is stated separately on the quote rather than carried inside the price, so the number your customer sees is the market's own. What an integration needs from an API goes further into why the two kinds of price must never share a field.
Execution that refuses rather than slips
Between a customer pressing the button and the order reaching the market, the price can move. The order should be checked against its quote and rejected if the quoted price is gone, rather than filled at something worse. It should be idempotent on your own order id, so a retry after a timeout returns the original record instead of opening a second position.
Positions follow from that: an entry price that never changes beside a live mark that always does, and an exit before resolution at a market price, with the same protections as the entry.
Settlement and reconciliation
Markets resolve on their own timetable, under published rules attached to each contract. The outcome should come from that published resolution rather than from a result your team keys in, and arrive at your webhook as a settlement record: signed, retried and safe to apply twice without paying a customer twice.
Beside it, Parity offers two reconciliation endpoints, a point-in-time statement and an append-only feed, so your finance team can prove at any moment that your books and ours agree and explain any payout months later.
Risk controls, and what you offer
Two kinds of risk matter, and the software has to handle both. The first is event risk. Parity does not warehouse it, and your desk is not asked to price an election or a rate decision: a prediction market price is a matched price between participants, expressed as cents on a one-dollar contract, and revenue sits on the transaction and platform layer rather than on a hold percentage.
The second is offering risk: carrying a market your licence or your brand rules out. Offering rules on Parity are set by category, sport by sport, by region and down to an individual customer, and the same rule is enforced on the catalogue, the quote and the order, so a market you are not offered cannot be traded by posting its identifier directly. Controlling which markets your customers see covers the rules in detail. Your responsible-gaming controls stay on the one balance they were built around.
Compliance by country
No software settles whether you may offer a category in a given country. That turns on what your licence covers, which categories you carry and the role your provider plays, and it is a question for your counsel. Prediction market compliance by country frames it before that conversation.
What software can do is make the answer enforceable across several markets from one integration. Parity's surface speaks English, Spanish, Portuguese and Croatian, a region setting orders the board, and your server can record each customer's jurisdiction, which decides a jurisdiction-enforced offering. Where the final allocation of KYC, custody and regulatory responsibility falls is agreed per jurisdiction, before anything is built.
Wallet integration: one balance
A second wallet is the quickest way to lose a customer to a new vertical: a transfer step, a stranded balance afterwards, a second set of books, and every limit you built split in two.
Parity never holds your customer funds. Your wallet stays the single authoritative balance, and Parity returns the exact amounts to reserve, debit, release and credit, as decimal strings, for your ledger to apply. A customer with $100 who stakes $25 still has one balance of $100: $75 available and $25 reserved. Prediction markets on one wallet sets out the whole money path.
Embed or API: who draws the screen
The last decision is who renders the product. The same account supports both shapes, and the boundary between your side and Parity's does not move between them.
| Dimension | Embedded surface | API |
|---|---|---|
| Who draws it | Parity draws the market list, the ticket, the positions and the early exit, inside a frame on the origins you register. | Your team renders everything from data: catalogue, quotes, orders, positions and settlement records. |
| What you build | A session endpoint, the frame with a message listener on your page, and a settlement webhook. | Your interface over five calls: list the catalogue, take a quote, submit the order, read the position, receive settlement by webhook. |
| Your brand | Your mode, accent colour, corner radius and density, in four languages. | Everything the customer sees is yours, because you draw all of it. |
| Suits | Teams that want the category live without building a trading interface. | Teams that would rather render the product themselves. |
Either way, an integration is built against a sandbox that can be driven to outcomes that have not happened yet, so the settlement path is tested before launch rather than after. How white label prediction markets work covers what of the embedded surface carries your brand, and the prediction market API covers the other shape.
Questions to put to any provider
Is the price my customer sees the price they can trade at? What happens when the market moves between the quote and the fill? Who holds the customer's money? Is a category I switch off refused at the order, not only hidden from the list? And how does a settlement reach my ledger exactly once? Each has a short answer if the provider owns the layer and a long one if it does not.
What a B2B prediction market provider should own gives Parity's answers in full, and the developer documentation shows every endpoint behind them. If you run a platform for agents and their players, prediction markets for your players shows the same product as a tab in the client area you already run.
