Identity Verification (KYC)

Identity verification (often called KYC, "know your customer") confirms that the person behind an account is who they say they are. On Babylon, buyers and sellers complete the check themselves through Stripe Identity, and your team reviews the result in the admin panel. This guide covers the provider setting, the rules that decide who has to verify, the review queue, and what each status means.

Before you start

• You need a role that can review identity checks. The Admin role can by default. Anyone without that permission will see a short explanation instead of the queue.
• Identity verification is switched on for new accounts by default. If it has been switched off for your account, do not set Bidder Eligibility to Full KYC Completed: no bidder would be able to satisfy it. Contact Hammerd support to switch verification back on.
• If you run your own Stripe account, Stripe Identity events must reach Babylon. See Stripe webhooks for how to configure that.
• You cannot approve or reject your own identity check. Another reviewer has to do it.

Choosing the KYC provider

The provider setting lives at Settings → Business Settings, on the Advanced tab, in the Provider Preferences section. The KYC Provider list offers Stripe, Onfido and Jumio.

Only Stripe (Stripe Identity) works end to end today. Choosing Onfido or Jumio does not switch your checks to those providers, and saving may fail because no credentials for them are configured. Leave this set to Stripe. If you need a different identity provider, contact Hammerd support.

The hint next to the field says verification is required for "sellers and high-value buyers". What actually triggers a check is controlled by the settings in the next section.

Deciding who has to verify

Two settings on Settings → Auction Settings, in the Anti-Sniping & Bidder Eligibility section, decide who must verify and when.

Bidder Eligibility

This controls what a bidder must complete before they can place a bid. Email verification is always required. The options are:

• Email Verified Only: the default. No identity check is needed to bid.
• Email Verified + Payment Method Added: the bidder must also have a saved payment method.
• Full KYC Completed: the bidder must have a verified identity before any bid is accepted. The same rule applies to taking part in live show chat.

There is currently no automatic value threshold that asks only "high-value" bidders to verify. If you want identity checks for bidders, use Full KYC Completed, which applies to every bid.

Seller Eligibility

This controls whether a seller must be verified before any of their listings can go live:

• Not required: the default.
• Identity verification required: a seller's listings cannot go live until their identity is verified.

A marketplace tier can also require seller verification on its own, through the Require seller identity verification switch on the tier. Whichever is stricter applies. See Marketplace tiers and authentication schemes.

Identity verification also feeds other checks. The Grant Verified Seller Badge action on a user requires the seller to be verified, and anti-money-laundering review of high-value sales relies on the parties' identity checks. See Fraud and AML monitoring.

What the buyer or seller does

When one of the rules above applies, the person is asked to verify from your storefront. They are taken through Stripe Identity to photograph an identity document, and the result comes back to Babylon automatically. There is nothing to create by hand in the admin panel: each attempt appears in the review queue on its own.

Reviewing identity checks

You can review from two places. Both use the same rules and record the same result.

The KYC Verifications queue

Open Post-Sale → KYC Verifications. The sidebar badge shows how many checks are waiting. The list shows every identity check attempt any user has submitted, oldest first, with these tabs:

• Pending: attempts still being processed or waiting for a decision.
• Retry needed: the provider could not complete the check (for example the document was unreadable) or the attempt was cancelled. The user has to submit again.
• Rejected: attempts a reviewer turned down.
• Verified: attempts that passed.
• All: everything.

Each row shows the User, when it was Submitted, the Provider, the status, which Attempt it is for that user, and its Age in queue. You can filter by status.

To decide on a check, use Verify or Reject on the row.

1. Click Verify or Reject. The confirmation window shows a briefing: the provider's result, what it read off the document, and any error the provider reported.
2. To approve, click Approve KYC. The account becomes verified.
3. To reject, enter a reason in Why are you rejecting this? (at least 10 characters) and click Reject KYC. The reason is recorded against the account so whoever handles the resubmission can see it, and the account moves to a failed state until the person submits again.

If a button is greyed out, hover over it to see why. For example, you cannot reject an account that is already verified, or approve one that has not submitted anything.

From a user's profile

Open Audience → Users. The sidebar badge and the Awaiting KYC review tab show accounts waiting on a decision. There are also KYC rejected and KYC verified tabs, and a KYC status filter.

In a user's row menu you will find Verify KYC and Reject KYC, which work exactly like the queue actions above.

On the user's page, reviewers also see:

• An Identity check evidence section with the Provider result, Provider session, Verified details the provider read from the document, any Provider error, and Rejected by if a reviewer rejected the account.
• An Identity checks tab listing every attempt. Use Inspect on a row to see what the provider returned.
• A Verification history tab listing every status change, when it happened and who or what caused it.

These sections are only shown to people who can review identity checks, because they contain personal details from identity documents.

What each status means

An account has one overall KYC status:

• Pending: waiting on the provider or a reviewer. New accounts start here.
• Processing: the provider is working on the submission.
• Verified: identity confirmed. This is the only status that satisfies the bidder and seller rules above.
• Failed: an attempt was turned down by the provider or a reviewer. The person can submit again.
• Required: verification is needed but nothing has been submitted.

Individual attempts in the queue use the provider's own statuses (Created, Processing, Requires Input, Canceled, Verified), which is why the queue and the user list can use slightly different words for the same situation.

Common questions

A new user shows as Pending but has not submitted anything

New accounts start as Pending, so they appear under Awaiting KYC review before they have done anything. Check the Identity check evidence section. If it says there is no verification attempt on record, approving would mark them verified on your word alone. Only do that if you have checked their identity another way, and record how.

Can I revoke a verification?

No. Reject is disabled for an account that is already verified. If you have concerns about a verified account, ban it from the user's row menu and contact Hammerd support.

Someone passed Stripe Identity but is still not verified

Check that Stripe Identity events are reaching Babylon. If you use your own Stripe account, see Stripe webhooks. The attempt should then appear in the queue for review.

Who can see identity documents?

Only people who can review identity checks. Other staff can see a user's overall KYC status but not the evidence. See Team members and roles.