Industries

Identity verification as an option on a profile

Some services owe their adult users a choice: the option to prove who they are, and a way to avoid accounts that have not. The check has to be easy to start and easy to refuse.

What services that offer a verified badge ask of identity checks

On a service where strangers meet, a badge that says "verified" does two jobs. For the user who earns it, it says that a real person stands behind the profile. For the user who looks at the profile, it says that someone has checked. Both jobs fail if the badge is easy to fake or if the check is so heavy that few people go through it. The badge is only worth something if the check behind it is a real check on a real person, and if a user can choose it without being pushed into it.

The second half of the idea is the filter. A user who does not want to hear from accounts that have not been verified should be able to turn them off. That turns verification from a mark on a profile into a setting of the service. The badge gives information, and the filter lets a user act on it. The UK Online Safety Act, discussed below, provides for both for services in the category it calls Category 1, within limits of place and part of the service that the frame block sets out.

  • Let an adult user start verification from the profile, on a phone.
  • Match a live face to the portrait on a document.
  • Spot generated and swapped faces in the verification selfie.
  • Recognise a removed user who returns under another name.
  • Pass the result on to the product without personal data.

The flow

  1. Choice. The user opens the verification option on the profile in your product. Nothing is sent until the user chooses it. This rule is yours. The Act's duty is about adult users in the United Kingdom and the user-to-user part of a Category 1 service, so who is offered the option, and in which part of the service, is a decision your product takes.
  2. Start. Your backend creates a session and opens the web widget. A user who starts on a desktop can finish on a phone with a QR code.
  3. Document. The user photographs a passport, national ID card, driver's licence or residence permit. The document is read and checked for fraud.
  4. Selfie and liveness. The selfie is matched to the document portrait and active liveness confirms a live person. Deepfake and face-swap detection runs inside the selfie and liveness steps.
  5. Returning faces. Repeat-user search looks for the same face among earlier verified users, and your own person lists and blocklists are checked in the same flow.
  6. Result. The webhook tells your system the session is complete, and it has an option that does not send personal data.
  7. Badge and filter. Your product shows the badge when the result meets your rule, and offers other users a filter that hides profiles without one. The platform does neither.
  8. Later. A returning user is compared with a stored reference face.

Where this differs from the dating and social page

The dating and social page is about the two things that go wrong at the edge of a service: the user who is not old enough, and the profile that is not who it says. It treats age and ban evasion as the main problems. This page is about a different pattern, in which the user decides. Verification is offered, not imposed, and its result is a badge and a filter that other users can use. The law quoted below describes that pattern for services in Category 1. The text of section 64 that was fetched carries no commencement annotation, so this page treats the duty it describes as one that applies once the section is commenced, and not as a duty already in force. The text adds a point that matters for the flow: the process the service offers need not rely on documents, and a service that wants an option without a document offers its own route beside this one.

Modules used

Regulatory frame

One United Kingdom text, three sections of the Online Safety Act 2023, as fetched on 27 October 2026. The duties in these sections are placed on providers of Category 1 services, so a service outside that category is outside these sections. The fetched record of section 64 says it was not in force at Royal Assent and shows no later commencement, so the statements on section 64 below describe an enacted duty that applies once it is commenced. The record of sections 65 and 15 shows them in force from 10 January 2024.

  • Section 64(1) requires a provider of a Category 1 service to offer all adult users of the service the option to verify their identity, if identity verification is not required for access to the service.
  • Section 64(6) and (7) limit the duties to the user-to-user part of a service and to the design, operation and use of the service in the United Kingdom, and define an adult user as an adult in the United Kingdom who is a user of the service or seeks to begin to use it.
  • Section 64(2) provides that the verification process may be of any kind, and in particular that it need not require documentation to be provided.
  • Section 64(3) requires the provider to include clear and accessible provisions in the terms of service explaining how the verification process works.
  • Section 65(2) requires OFCOM, in producing its guidance on the duty in section 64(1), to have particular regard to the desirability of ensuring that providers offer users a form of identity verification likely to be available to vulnerable adult users.
  • Section 15(9) requires the provider to include in the service features which adult users may use or apply if they wish to filter out non-verified users, and section 15(10) describes those features as ones that prevent non-verified users from interacting with the content which that user generates, uploads or shares, and reduce the likelihood of that user encountering content which non-verified users generate, upload or share.

This block describes the text, not our service. For information; not legal advice.

Sources

Next

Try the interactive tour, read about face verification or compare with the dating and social flow.

Questions, answered plainly

Does verification have to be compulsory for every user?

That is for your product to decide. The platform runs a session when your product opens the widget, so verification can be an option that a user chooses from the profile.

Can the verified badge be granted without sending the user's name and document to our system?

Yes. A webhook has an option that does not send personal data, and your product shows the badge when the result meets your rule.

Can a user who was removed come back and earn a badge under a new name?

Repeat-user search finds a returning face among earlier verified users, and your own person lists and blocklists can be checked in the same flow.

Can the check notice a generated or swapped face in the selfie?

Yes. Deepfake and face-swap detection runs inside the selfie and liveness steps.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us