A new marketplace’s first problem is not supply or demand. It is that two strangers must exchange value with no history between them and no shared institution to fall back on. Before the first transaction, trust comes entirely from design: which gates exist, which states cannot be walked back, and what a reputation is attached to. After that, reputation carries the weight, but only if it is anchored to something that costs money to fake.
What a marketplace gets wrong at zero transactions
Trust is treated as something to add after growth
The reasoning is that controls slow acquisition and there is nothing to protect yet. Instead, the earliest participants set the norms, and retrofitting verification means asking people who already transact to prove themselves. That conversation costs more than the friction would have.
A verified badge that verifies nothing in particular
A badge appears beside a profile with no stated meaning. Users infer it covers whatever they are worried about, which it does not. When something goes wrong, the gap between what the badge checked and what the user assumed becomes your problem, not theirs.
Reputation that is really advertising
Reviews left without a completed, paid transaction behind them are marketing copy with stars attached. They can be traded, requested from friends, or written by the same person twice. Once a rating system has visibly been gamed, participants stop reading it.
The whole friction budget is spent on the honest side
Every control has a price, paid overwhelmingly by people who were going to behave anyway. A long signup flow loses good participants at the moment they have least invested. The question is whether the harm prevented is worth the users it costs.
The rules are published in the help center
A well-meant transparency page explains what the system looks at and where the lines are. That page is a specification for passing the gate, and the people most motivated to read it carefully are the ones you built it for. Explaining that a control exists is fine. Explaining how it decides removes it.
Trust mechanisms, their price, and their weak point
Every mechanism here trades something. The third column is the one to argue about internally, because it is the cost you pay on every honest user, forever, in exchange for the harm named in the second.
| Mechanism | What it prevents | What it costs the honest user | Where it is weak |
|---|---|---|---|
| Identity verification at signup | Disposable accounts and quiet re-entry after removal | Friction at the worst moment, before any value has been shown | It establishes who somebody is, not how they will behave |
| Credential or licence checks in a category | Unqualified supply where the qualification is the product | Delay for legitimate professionals and a recurring renewal obligation | It moves the problem to your verification step rather than removing it |
| Funds held until a milestone is met | The oldest failure there is: one side performs and the other disappears | Working capital, and waiting for money already earned | Pressure moves to disputes about whether the milestone was met |
| Two-sided reviews revealed at the same time | Retaliatory ratings, and the silence that fear of them produces | Very little, if the window is short and the rule is explained plainly | Off-platform pressure to rate well, which is why the window matters |
| Reputation weighted to completed, paid transactions | Reviews bought, swapped, or written by people who never transacted | Slower reputation building for genuinely new participants | It can be built by transacting for real, which is the intent rather than a flaw |
| States that cannot be reversed | History being edited quietly once a dispute has started | Occasional real inconvenience when somebody makes an honest mistake | Support staff who can undo anything on request, which removes the control |
| Limits that expand with track record | A large loss concentrated in an account that has existed for a day | New participants cannot operate at full scale immediately | It can be worked around slowly, which is usually an acceptable trade |
| Dispute outcomes visible in aggregate | Repeat patterns no individual counterparty could ever see | Exposure of one bad month that may not represent them | Private settlements never enter the record, so count raised and resolved separately |
Sequencing the controls a new marketplace needs
Name the harm before naming the control
Write the specific bad outcome in a sentence: somebody pays and nothing arrives, somebody works and is not paid, somebody unqualified takes a job requiring a licence. Each sentence points at a different control. Starting from a list of controls produces a long signup flow that still misses the thing you feared.
Spend friction where the value is, not where the traffic is
Signing up should be cheap. The moment money moves, a commitment becomes binding, or somebody gains access to a home or a jobsite is where verification belongs. Progressive checks let people see the value of the platform before you ask them to prove anything.
Make the states that matter one-way
Identity confirmed, funds released, review window closed, dispute opened. If any of these can be reversed by the party who benefits, it is not a control, it is a suggestion. Enforce one-way transitions in the data model rather than the interface, because support tools get used.
Anchor reputation to something expensive to fake
Completed transactions with money attached, tenure, and dispute outcomes are costly to manufacture. Profile completeness, response speed, and self-declared credentials are cheap. Weight the display toward the expensive signals, and be careful about aggregating both into one number.
Design recourse, not only prevention
Every gate will be wrong in both directions. What determines whether users stay is what happens next: whether there is a way to appeal, whether a person looks at it, and how long that takes. Moderate prevention with excellent recourse earns more trust than aggressive prevention with none.
Say that a control exists; never say how it works
Publish the outcome and the principle. Accounts may be restricted where behavior is inconsistent with the terms is a fair statement. Describing the signals, the sequence, or the point at which something trips is not. Hold the same line in specifications and support macros.
What a trust layer sits on top of
- designing systems that know when to ask — Trust decisions are the clearest case for bands and human review, because both kinds of error are visible and expensive.
- custom software and AI development — Where pattern detection legitimately belongs in a platform, and the constraints that apply to it.
Is this a fit for your business?
A good fit when
- You are building a platform where two parties who do not know each other exchange money or access
- The first cohort of users is being recruited and the platform’s norms are still forming
- Something has gone wrong between two users and you are deciding what to change
- A category on your platform requires a licence, insurance, or certification
Probably not a fit when
- Both sides of every transaction are known to you and contracted directly
- You are shopping for a fraud detection vendor, which is a purchase rather than a design decision
- Volume is low enough that a person can review every new participant
What to have ready
- A written description of the worst plausible outcome for each side of a transaction
- The licensing requirements that apply to what is being sold
- A decision about who handles appeals, before the first one arrives
Questions we get asked
How much verification is too much at signup?
The test is whether you are asking for something before the person can see why it is worth giving. Asking for identity documents on the first screen loses people who had no reason yet to trust you either. Move what you can to the moment before value transfers, and keep the first step minimal.
Should users see a trust score for each other?
We would avoid a single composite number. A score invites both parties to optimize it, hides what it is made of, and implies a precision about a person that is not there. Show the underlying facts instead: transactions completed, account age, whether required credentials are current. Facts are harder to game.
What do we do about a good participant with no history at all?
Every marketplace has to solve this or it never starts. The usual answers are limits that expand with track record, holding funds longer on early transactions, a platform-backed guarantee on the first few, and where volume allows, a human review that vouches for them. All of them cost you something.
Do we have to tell somebody why their account was restricted?
Tell them the outcome, the category of concern, and how to appeal. Do not tell them which signal produced the decision or what would have avoided it. That distinction is not evasiveness; it is the only way a control survives contact with the people it exists to stop, and it is why appeals need a real person.
Related
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.