How to screen new sign-ups without adding friction

To screen new sign-ups without adding friction, keep your form as it is and check the details people already give you, their name, email address, phone number, company or profile link, in the background once they have signed up. Most genuine users carry on without seeing another step. Only the accounts whose details do not hold together go to a person on your team, and only those few are asked for anything more. Sixtyfour does the research in that middle step: your backend sends it the details a person entered, and it returns findings on whether they belong to one real person, each with its source and, when you ask for one, a confidence score, while the user is already inside your product.

That research is one layer of screening. The other is the signals collected from the device and network as the form is filled in, which other tools handle. This guide covers what each detail can tell you, when to run the check, how to set the review rules, what a reviewer needs and how to ask for more without asking everyone. Our guides to investigating an email address and linking related accounts go deeper on single steps.

Every step you add at sign-up asks something of the people you want to keep. An ID upload needs a document to hand, a selfie needs a camera and decent light, and a code needs a phone that is nearby and switched on. Each is a point where someone with nothing to hide can stop, and the people who stop rarely tell you why.

One public figure gives a sense of how many genuine people a demanding identity check can lose. In 2019 the UK's National Audit Office reviewed Verify, the government's flagship identity verification platform, where people proved who they were to a commercial provider with evidence that included documents. The report gives the service's own success rate at the beginning of February 2019: 48 percent of the people who tried to sign up succeeded in a single attempt, against a 2015 projection of 90 percent. That figure did not count applicants who dropped out before choosing a provider, "for example because they do not have the required documentation to hand and decide not to proceed." It covers a whole identity check on one government service, so read it as a sense of scale.

Document and selfie checks still have their place. When an account will be paid, will meet people in person or will hold access that is costly to give to the wrong person, knowing that a real person matches a document is worth a step. The aim is to put that step in front of the few accounts that need it, when it matters, and to screen everyone else with what they have already told you.

Your sign-up form does not change. When someone submits it, your backend lets them in and sends the details they entered to Sixtyfour's API, and the research runs in the background. Your own account history and the device and network signals other tools collect are separate layers, which your rules weigh alongside its findings.

Four calls do most of the work:

• Verify Email checks whether the address can receive mail and returns OK, RISKY, INVALID or UNKNOWN. Its API reference says it responds in under a second for most addresses, so it is the check that fits before the welcome screen.
• Reverse Email returns the person behind an address: a name, a role, an employer and a professional profile.
• Reverse Phone returns the person behind a number, and adds the people linked to it in public records.
• People Intelligence takes everything the person gave, plus a plain-language research plan, researches sources across the web, and returns the fields you ask for in struct, with a short summary and the pages each finding came from. With confidence scoring on, each field also carries a 0 to 100 score, a justification and source URLs.

A People Intelligence run can take up to 10 minutes, so screening uses the async endpoints with a webhook_url: Sixtyfour posts the result to your server when the job completes, and the user never waits on it. A dispatch_id on the People Intelligence call makes a retried start safe, because a repeat returns the first job and charges nothing. Your rules read the result and mark the account clear or for review, and a person on your team decides every review.

Teams that would rather not write that code can build a workflow in Sixtyfour's web app that starts when their sign-up system posts a new user's details to it, runs the same checks as blocks, keeps the rows that match the review rules and posts them to the team's chat. For a review that needs more depth, an investigator can open the case in Atlas, which is enabled on request, and our Research API page covers building this research into your own product.

Each field on a sign-up form is a claim. Screening asks two things of the set: whether the details belong to one real person, and whether that person existed before today.

• The email address. Verify Email shows whether it can receive mail, and an INVALID result can be a typo, so asking the person to fix it is a step that helps them. Reverse Email shows whom the address leads to, and Sixtyfour runs both from the address alone. How long the address has been in use matters too, and our email guide covers how to date one from the traces it has left.
• The name. On its own a name proves little, because many people share one, and its value is in agreeing with everything else. Sixtyfour's scores reflect that: the docs note that with a very common name "even well-sourced fields score lower because the identity link is uncertain."
• The phone number. Reverse Phone shows whether the number leads to the person named, and who else is linked to it. What kind of line it is and which provider issued it are checks other tools make, or an analyst makes by hand.
• The company and role, where you ask for them. Give People Intelligence a field such as whether the employer exists and lists this person, and the answer comes back with the pages it rests on.
• A profile link. Ask People Intelligence whether the profile describes the same person as the rest of the form, and it returns its answer with its sources.
• Reporting about the person. Ask for it as a field and People Intelligence looks for news that names them in fraud or misconduct. Casco uses Sixtyfour to flag adverse media before a hiring call.

The strongest result is agreement: the address leads to the person named, the number leads to the same person, and the employer they gave lists them. The most useful flag is a contradiction, such as an address that leads to someone else or an employer with no trace of them. A missing record is a reason to look, and a contradiction is a reason to ask. Neither one, alone, is a reason to decline.

A second layer works from signals your app or website collects while the form is filled in: the device, the network, how the page was used and how many sign-ups arrive from one place. Your own systems and other tools collect those, and they catch automated and repeat sign-ups that research on a name will not. Our guide to the trust and safety tech stack sets out the tools for each layer.

Run it at sign-up, on every account, while the account can do little. Screening everyone matters because a prepared identity is built to look ordinary, so a check reserved for the accounts that seem odd misses the ones that were made with care.

Then run it again before the moments that carry risk:

• Before a first payout or withdrawal, when money first leaves your platform.
• Before a first call, meeting or job, when someone gives the account their time or lets it into their home. Rene Brandel, CEO and founder of Casco, describes the hiring version on our workforce risk page: "We see fake North Korean workers apply to Casco. Sixtyfour flags adverse media and resume inaccuracies before we ever get on a call."
• Before granting a permission that is costly to get wrong, such as access to a client's accounts, direct messaging, higher limits or the right to list expensive items.

The same research can run again at each point, because it starts from details you already hold. Staging it also keeps the cost in proportion. The People Intelligence tier sets research depth and cost: micro and low are built for high volume, medium adds more sources, and deeper tiers are available on request. A light pass can cover everyone at sign-up, and a deeper one can wait for the accounts that reach a riskier step.

Write the rules down before you switch screening on, and keep them short enough that a reviewer can say which one sent an account to them. A workable set:

• Clear the account when the details lead to one person, the fields that decide it reach the score you set, such as 65, and nothing on those questions is open.
• Send it to review when the email address or phone number leads to a different person, a deciding field scores below that line, a field you asked about comes back open, reporting names the person in fraud, or a detail matches an account you removed.
• Never decline on absence alone. A thin footprint sends an account to review at most, and our synthetic identity guide explains why so many real people have one.

The 65 in that example is where the second of five levels on the docs' confidence scale begins: Confirmed from 85, Established from 65 ("A careful person would rely on this"), Supported from 40, Speculative from 15, and Unreliable below that. The docs suggest choosing the line by use case and give 65 for outreach, so treat it as a floor. A field has no score when its value rests only on the input you sent, so a field that only repeats the form has not been checked.

Set the bar by what the account can do. At sign-up, when it can only look around, a review can wait a day. Before a payout you might raise the line to 85, where Confirmed begins, and hold the payout until someone has looked at any deciding field below it. Then measure: if most reviews end with the account cleared, a rule is sending too many, and if fraud reports keep arriving from accounts that cleared, it is sending too few.

A match with a removed account comes from your own records. To see whether a batch of new accounts is one operator, Lattice, in beta and enabled on request, turns rows of accounts into one graph and connects those that share an email address, phone number or profile URL. Its documentation says it "never merges people on name alone."

A reviewer should be able to decide from one screen, without searching for anything themselves. Put on it:

• What the person entered, beside what the research found for each detail.
• Each finding with the page it came from, its date where there is one, and its score and justification.
• What stayed open, in the research's own words.
• The rule that sent the account to review.

People Intelligence returns its sources as a map of each page to what was found there, and a short research summary in its notes field, so most of that screen comes straight from the result.

The decision has four outcomes, and the reviewer records which one and why. They can clear the account, ask for one thing that settles the open question, hold the risky action, such as payouts, while the rest of the account works, or decline with the reason and a route to appeal. Where the evidence is mixed, ask before deciding. A reviewer who clears an account should note what cleared it, because those notes show you which rule needs loosening.

Ask the few in review for the one thing that answers their open question, and nothing else. If the address leads to someone else, ask the person to confirm from an address you can tie to them. If a work history is unsupported, ask for a link to past work, a reference or a short call. If the question is whether a real person matches the identity they gave, that is the moment for a document and selfie check, run by the tools built for it.

Tell the person why you are asking, what happens next and by when, in plain words. Let them keep using whatever carries no risk while they answer.

Record the answer with the case, so you can see which open questions settle quickly and tune the rules.

The case is a composite. Norrowby, Nashby Lane Accounting, Nessmire Books and every person named here are invented. Domains use the .example names reserved for documentation, example.com stands for a large free mail provider, and the phone number comes from the fictitious 555-0100 to 555-0199 range reserved for entertainment and advertising.

Norrowby, at norrowby.example, is a marketplace where small businesses hire freelance bookkeepers and admin assistants, who are paid through the platform and are often given access to a client's accounts. Its sign-up form asks for a name, an email address, a phone number, a current or last employer and a professional profile link, and nothing else.

On one Tuesday 214 freelancers sign up, and every one of them reaches the welcome screen at once. Behind it, Norrowby's backend calls Verify Email, starts Reverse Email and Reverse Phone, and starts a People Intelligence job with a research plan ("A new freelancer offering bookkeeping. Check that these details belong to one person and that the work history they gave holds.") and three fields: whether the email address and phone number belong to the person named, whether the employer and role they gave are supported, and any reporting that names them in fraud or misconduct. Confidence scoring is on, and each job reports back by webhook.

Norrowby's rules send an account to review when the address or number leads to someone else, when either of the first two fields scores below 65, or when the third finds anything. That evening 202 accounts are clear and 12 are in review. Nobody behind the 202 was asked for anything.

Most of the 12 take a reviewer a few minutes. Theo Nessmire's address, theo@nessmirebooks.example, leads Reverse Email to Ruth Nessmire, the owner of Nessmire Books, which looks like a contradiction until Sixtyfour's findings show the firm's own site listing Theo as a bookkeeper since 2022 and a local business directory naming them both. It is a family business with a shared domain. Ines Nolderby's address leads nowhere, and Sixtyfour finds her on the 2025 committee page of a university accounting society and on a professional profile from this year. Her employer field scores 58, because her employer's site lists no staff. Her footprint is thin and fits her story, so the reviewer clears her and notes that the research runs again before her first payout. In all, nine accounts are cleared from the findings alone. Two applicants who work for themselves, with no employer to find, are each asked for a link to past work, and both send one within the day and clear.

The twelfth is the case screening exists for. The applicant signs up as Maren Nellicott, with maren.nellicott.books@example.com, +1 312 555 0164, Nashby Lane Accounting as her last employer and a profile link. Verify Email returns OK. Reverse Email and Reverse Phone find no person behind the address or the number. People Intelligence returns three findings, each with its source. Nashby Lane Accounting exists, and its team page at nashbylane.example lists a bookkeeper called Maren Nellicott, with a work address on the firm's domain. A professional profile in her name, active since 2016, gives the same firm and no link to the address or number given at sign-up. And the profile linked at sign-up carries the same name and employer, with no activity before this month. The first field comes back as unclear, with a score of 18, Speculative, and the justification that nothing ties the address or number to the bookkeeper the firm lists. The research reports that link as open.

The reviewer reads it as one of two things: the real bookkeeper with new contact details, or someone using her name and work history. Norrowby asks this one applicant to complete the document and selfie check it already runs before payouts, and says why. Seven days later the check has not been started, and the account is closed with the reason and a route to appeal.

Of the 214 people who signed up that day, 211 saw no step beyond the form, two were asked for a link and one was asked for a document. Sixtyfour found the records and scored each field, and every decision, including the one that closed an account, was made by a person on Norrowby's team.

• A real identity used by someone else, with contact details that genuinely lead to the person being impersonated. When the details agree, the research has nothing to contradict, and the document check at the risky moment is the layer built for that question.
• An identity aged on purpose. Accounts opened years in advance and left to sit leave a footprint that looks earned, and our synthetic identity guide covers how they are built.
• A real person with bad intent. Research confirms who someone is and says nothing about what they plan to do, which shows in their behaviour on your platform.
• Automation at volume. Thousands of scripted sign-ups are for the device and network layer to stop before they reach research.
• A form that asks for very little. An email address alone gives the research less to compare than a name, an address, a number and a profile together.

Screening the details raises the cost of a fake account that holds together, so the fake accounts that still get through tend to be ones someone spent real time and money on.

Most of what sends an account to review has an ordinary explanation, and a fair review rules it out first.

• Thin footprints are common among real people, including the young, recent arrivals and people who keep off the internet on purpose. Absence is a reason to look.
• Names differ for ordinary reasons, such as marriage, a nickname or a transliteration, and an address on a shared family or business domain can lead to a relative or colleague, as Theo Nessmire's did.
• Phone numbers are recycled, so records attached to a number may belong to an earlier holder.
• Common names score lower because the link between the name and the person is weaker, and a low score on a common name says exactly that.
• An open field is open. It means the research could not settle the question, and the person you ask can often settle it in a minute.

Keep a reason to look apart from a reason to act. Decline an account only when the findings, with their sources, would satisfy a second reviewer who was not there.

Leave the sign-up form alone and research the details people already give you, in the background: whether the email address works and leads to the person named, whether the phone number leads to the same person, and whether the employer and profile they gave hold up. Send only the accounts whose details contradict each other or come back open to a person, decide nothing on absence alone, and ask those few for the one thing that settles their question. Sixtyfour does that research from the details your backend sends, returns each finding with its source and, when you ask, a confidence score, and leaves every decision with your team.