How to detect duplicate customers with Myaza Trust

To detect possible duplicate customers, turn on Face search in your onboarding workflow. Myaza compares each new selfie with people your organisation has already verified and with your face lists. You choose whether a match passes, fails or goes to a person for review.

This guide takes you from opening the workflow to testing the result in your app. You can also use it to improve a workflow you already run.

Screenshots use an example Sandbox workspace. Customer references, workflow IDs and prices shown are illustrative. Your workspace can show different prices, permissions and configured checks.

What you need before you start

• Access to the organisation you want to configure, with permission to read and manage workflows.

• A Full Verification workflow for individuals that captures a selfie. Face search is not offered on business or scoped biometric-authentication workflows.

• An existing, successfully verified test participant in your organisation, with appropriate permission to use their biometric data for your test. An empty customer book cannot demonstrate a duplicate.

• Your organisation's policy for handling repeated identities. A repeated face may be a returning customer or an accidental second account; it is not proof of fraud.

Start in Sandbox. A Sandbox workflow and key cannot be used as a Production workflow and key.

Workflow face search is included. A standalone search in Spot Checks has its own price. Identity, liveness and other checks in the workflow can still cost money. Check your organisation's estimate before running a verification. Opening the editor or its preview does not run a paid verification.

Set up duplicate detection, step by step

Step 1: Open the right workspace

Open the dashboard. Check the organisation and environment in the top-left workspace selector. Select the organisation you intend to protect and Sandbox.

Open Configuration → Workflows. You should see the list of that organisation's workflows, with each workflow's name and status.

Step 1: Workflows in the example organisation, with Sandbox selected

If you cannot see Workflows, ask your organisation owner for the required workflow permissions. Do not change another organisation's configuration to work around missing access.

Step 2: Open the workflow your customers use

Click the workflow's row. The editor opens with verification steps on the left, settings in the middle and a customer preview on the right.

Check the workflow name and ID at the top. This must be the workflow your app uses for onboarding. Editing another workflow will not protect that journey.

If you are starting from scratch, select Create workflow on the list first, choose an individual verification template, name the workflow and open its editor. Continue once you see the editor shown below.

Step 2: Individual verification workflow editor and its workflow ID

Step 3: Open Presence Intelligence

In Verification Steps, click Presence Intelligence. Keep the step enabled so your flow captures the face needed for comparison.

The middle panel should now be titled Presence Intelligence. It offers Setup, Rules and Returned data.

The Setup tab controls the liveness method. Liveness asks whether a real person is present; duplicate detection asks whether their face matches another account. These are different checks.

Step 3: Presence Intelligence selected, with the Setup tab visible

Step 4: Turn on Face search

Select Rules. Scroll down the middle settings panel to Face search, then turn on Enable face search if it is off.

Check the description beneath the switch. It should say that selfies are compared with people your organisation has verified and with your face lists, and that the face template is kept.

Step 4: Face search enabled in the Presence Intelligence Rules tab

If the section is missing, check the workflow's scope. Face search belongs to a full individual-verification workflow. Switching to a business or biometric-only scope does not provide the same setting.

Step 5: Choose what happens for each finding

Under When a face matches, configure each of these rows separately:

• Duplicated face: the face matches someone your organisation has already verified.

• Duplicated face with a different name: the face matches a verified person with a different name.

• Duplicated face on a different document: the match has a different document number or date of birth.

• Multiple faces detected: more than one face is present in the selfie; the largest face is the one checked.

For each row, choose Approve, Review or Decline according to your organisation's policy.

Approve lets that case pass. Review keeps the check's result and routes it to a person through decisioning. Decline makes that case fail with its corresponding reason code.

Step 5: Separate Approve, Review and Decline choices for each face-search finding

Do not use a strict decline rule merely because two faces match. Decide how you want to handle legitimate returning customers, name changes and mistaken second accounts.

Step 6: Check the Review rule

If you choose Review for any face-search case, look below the choices for the routing message.

You should see A decision rule sends these verifications to review. Select View rule to inspect it. If the panel offers to add the missing rule, add it and check the message again. Resolve a disabled-decisioning message before continuing.

Step 6: A duplicate-face Review choice and its decision-rule routing message

A Review choice alone is not sufficient when its decision rule is missing or disabled. Check the rule's position against your other rules too: rules run in order, and the first matching rule decides the outcome.

Step 7: Check that the draft is saved

Look at the status beside the workflow ID. Wait for Saved. If your organisation uses manual saving, save the draft before continuing.

Review the other checks already in the workflow and the price breakdown at the top. Face search being included does not make every other check free.

Step 7: Saved draft status and the configured duplicate-face Review action

Saved means your draft is stored. It does not mean customers are using that draft. A published workflow keeps serving its existing published version until you publish your changes.

Step 8: Publish the configuration

Select Publish for a new workflow or Publish changes for one that is already published.

In the review dialog, check the Target, Workflow ID, publication readiness and any warnings. Confirm that the target is Sandbox for your first test. Resolve blocking issues before proceeding.

Select the dialog's Publish version button when you are ready. The version number depends on your workflow. Do not cancel this dialog and assume the draft is live.

Step 8: Publication review showing the target environment, workflow ID and confirmation button

Your change applies to this workflow's newly published version. It does not change every workflow in the organisation, and sessions already started keep their original version.

Connect it to the journey in your app

If your app already uses this workflow

Check the workflow ID in your integration against the ID at the top of the editor. If they match and use the same organisation and environment, new verifications pick up the newly published version. A workflow configuration change does not require an application redeployment.

You still need to test that your backend receives and handles the outcome. A setting in Myaza cannot automatically stop a second account in your app unless your app uses the result.

If this is your first integration

Choose the method that matches your journey:

• Embedded capture: pass the published workflow ID to your supported Web, React Native or Flutter SDK. Your publishable key and workflow must belong to the same organisation and environment. Use a stable customer reference from your own app.

• Customer-bound session: create the session on your backend using the secret key, the published workflow and the intended customer's reference. Return the session's capture destination to that customer. Keep secret keys out of browser and mobile code.

• Hosted capture: use the published workflow's hosted-link controls for the supported capture journey. Check current link availability and reuse behaviour in the product documentation rather than reusing a claimed link for another applicant.

The workflow integration guide contains the SDK configuration. The session guide lists the exact request fields and response. Follow the method's current contract rather than mixing an SDK key with a server-only API.

Use the same customer reference for the same person in your application. A login journey should use biometric re-authentication, not repeatedly create new onboarding identities.

Test that duplicate detection works

Use authorised test participants and your test environment. Do not upload real customers' photos to an unrelated test workspace.

1. Complete the protected workflow for the first test customer. Confirm that the person is successfully verified in your organisation.

2. Start a new verification for a different test-account reference, using the same participant's live selfie.

3. Open the new verification result and check the recorded finding. Compare it with the action you selected for that case.

4. For Review, confirm the decision routes it for human review. For Decline, check the appropriate duplicate-face failure reason. For Approve, check that your policy permits that case to pass.

5. Confirm that your backend receives the correct verification/customer reference and applies your intended account action. Test failed delivery and duplicate notifications as well as a successful result.

6. Repeat with a different participant and check that your app handles that result correctly too.

For example, the decline reasons distinguish duplicated_face, duplicated_face_different_name, duplicated_face_different_document and multiple_faces. Read the reason instead of treating every failure as a duplicate account.

Do not expect a fixed similarity percentage. The 98.4% on the Solutions page is demonstration data, not a promised score for your test.

Get more from the control

Apply it to the right workflows. Repeat the configuration review for each onboarding workflow you actually use. Do not assume one change covers separate country, business or account journeys.

Use the separate case actions. Your policy can distinguish an ordinary repeated face from a repeated face attached to a different name or document. Keep those choices deliberate and reviewable.

Review rule order. Inspect the decision graph when you add other rules. An earlier matching rule can decide before a later one is reached. Test a customer who triggers more than one finding.

Use face lists deliberately. The Manage blocklist and allowlist link opens your organisation's face lists. Document why an entry belongs there and keep access limited to the right reviewers. Do not add people merely because a similarity score exists.

Keep liveness enabled. Face matching and liveness answer different questions. A match does not prove the current camera capture is a live person.

Deliver and handle results. Configure signed webhooks and verify the signature on your server. Deduplicate events and retrieve the authoritative current state before a sensitive account action. A notification being delivered is not proof that your application acted on it.

Troubleshooting

I cannot see Face search. Check for a full individual-verification workflow. Business and scoped biometric flows do not expose this setting.

No duplicate was found. Check that face search is on, the first test participant completed verification successfully and both records are in the organisation you intend to compare. Check the selfie quality. Another organisation's customer book is not your comparison population.

My change did not apply. Check for unpublished edits, the workflow ID in your integration and the environment of the key and workflow. Start a new session after publication; an existing session keeps its original version.

Review did not route. Inspect the message beneath the match choices, confirm decisioning is enabled and check rule order. Do not solve this by changing every case to Approve.

I cannot publish. Check your workflow permissions and the publication dialog's blocking messages. A suspended workflow cannot be published until the suspension is lifted.

My app still allowed another account. Check the backend result handler, customer reference and webhook delivery. The Myaza decision does not by itself change your application's account state.

Ready to configure it? Open Workflows. You can return to Solutions to compare this control with account protection and standalone face search.