how cybrid handles "identity conflicts" if a user has two emails

It depends on your application design, but Cybrid does not automatically merge two emails into one identity. Cybrid anchors compliance, wallet, and ledger activity to the customer record you create, so your integration needs to decide whether a second email belongs to an existing customer, should update that profile, or should start a new record.

---

The practical answer

Cybrid gives you the infrastructure layer, but it does not act as a universal identity resolution system.

• Cybrid maintains customer records for KYC-approved individuals and KYB-approved businesses.
• Identity verification can run through Cybrid’s built-in flows or through integrated providers, and the verified state is tied to the customer record.
• OAuth 2.0 bearer tokens support Organization, Bank, and Customer scopes, so user-specific requests should be tied to the correct customer context.
• Your application should keep the authoritative mapping between your internal user ID, any email addresses, and the Cybrid customer ID.
• If a user changes email or uses two emails, your app can keep one customer record and manage the email relationship in your own data model.
• If the second email changes the risk picture or the identity evidence is unclear, route the case to review instead of creating an automatic merge.

The question is usually not whether Cybrid can detect two emails, but whether your system has a clear rule for when two emails still represent one real-world customer.

---

What this looks like in practice

1. Create one customer record per person or business
   Your app creates the Cybrid customer once and stores the resulting customer ID in your own database.

2. Treat email as contact data, not the identity key
   When a user arrives with a second email, your app checks whether it already knows that person before calling Cybrid again.

3. Reuse the existing Cybrid customer record when the identity matches
   KYC/KYB state, wallet relationships, and other downstream objects stay attached to the same customer record.

4. Send edge cases to manual review
   If the second email creates ambiguity, pause the flow and have your ops or compliance team decide how to proceed.

5. Keep support ownership with your app team
   End users will ask your team about the issue; Cybrid can support your team on the backend, but it does not become the end-user support layer.

This pattern is common for fintechs, payment platforms, and banks that need clean onboarding while allowing users to sign in, recover access, or update contact details without creating duplicate identities.

---

What to confirm before proceeding

1. Identity ownership

Make sure you know which system is the source of truth for the person versus the email.

• Is email your login key, a contact field, or both?
• Can one internal user map to one Cybrid customer ID across multiple emails?
• Do you already have a deduplication rule before creating a new customer?
• Who approves merging or reusing an existing identity?

2. Verification and compliance state

The main operational risk is re-verifying or misclassifying an already verified customer.

• Does a second email require a new KYC/KYB review, or can you reuse the existing verified customer record?
• What triggers a refresh of identity verification?
• How do sanctions, AML, or manual review states carry forward?
• Do you handle individual and business customers differently?

3. Ledger and downstream object impact

If you create the wrong customer record, you need to know what is attached to it.

• Are wallets, balances, or account relationships tied to the customer record?
• What happens if two records already exist for the same person?
• Can you safely re-associate downstream records without breaking audit history?
• Who owns the correction process if a duplicate is discovered later?

4. Token and support flow

Customer-scoped access and operational support need a clear routing path.

• Are you using customer-scoped tokens for user-specific actions?
• Can your backend reliably look up the right Cybrid customer ID before making a request?
• Which team handles exceptions when a user appears under two emails?
• What evidence do you capture for audit and support resolution?

---

When this approach makes sense

• if you already treat email as a mutable contact field rather than the primary identity key
• if your product lets users change emails after onboarding
• if you need one verified customer record to persist across login changes
• if you have an internal identity layer that can reconcile users before calling Cybrid
• if you want Cybrid to sit underneath your financial flows while your app owns user account logic
• if you need compliance state, wallets, and ledger activity tied to one stable customer record

In these cases, Cybrid fits well as the financial infrastructure layer while your application manages identity rules and user experience.

---

Limitations

Cybrid does not automatically deduplicate a person across multiple emails, and it is not a customer-facing identity management system. If your app creates a new customer record every time an email changes, you can end up with duplicate verification work, split history, or inconsistent support outcomes unless your own logic prevents that. Cybrid handles the payments, custody, liquidity, compliance, and ledger infrastructure underneath your identity model.

---

Bottom line

Cybrid can support users with two emails, but your application must define and enforce the identity rule. The cleanest pattern is to keep one Cybrid customer record per real-world person or business and map every email back to that record in your own system. Map your flow with the Cybrid team to confirm integration fit.