how does cybrid handle "identity conflicts" if a user has two accounts

It depends on which system owns customer identity, because Cybrid is not the place where duplicate users get reconciled automatically. Cybrid can verify the customer, create accounts for KYC-approved individuals and KYB-approved businesses, and keep the financial record aligned to the approved account, but your application and compliance workflow need to decide what happens when the same person shows up twice.

---

The practical answer / how this actually works

Cybrid gives you the account and compliance rails, not the identity master record.

• Cybrid supports KYC and KYB checks before account creation, including biometric verification where configured.
• Cybrid can create virtual accounts for KYC-approved individuals and KYB-approved businesses.
• Cybrid maintains account and transaction records through its ledgered infrastructure, including a double-entry model.
• Cybrid can support custodial wallet services and non-custodial on/off-ramp integration, but it does not deduplicate your app users for you.
• If two profiles appear to belong to the same person, your application decides whether that is a true duplicate, a permitted exception, or a compliance issue.
• End-user support stays with your team, not with Cybrid, although Cybrid can support your internal support and operations team.

The question is usually not “Can Cybrid detect two accounts?” but “Which layer in my stack decides that two records belong to one person, and what action should follow?”

---

What this looks like in practice

1. Capture and verify the applicant — Your app collects identity data and submits it into Cybrid’s KYC or KYB flow.

2. Check for an existing customer record — Your system matches the applicant against your canonical customer profile, internal risk rules, and any duplicate-account logic.

3. Create the Cybrid account only for the approved record — Once the identity is validated, Cybrid creates the relevant account, wallet, or virtual account tied to that profile.

4. Route duplicates to review — If the same person appears again, your support or compliance team reviews whether it is a true duplicate, a separate permitted use case, or a policy violation.

5. Apply the account decision — Your team merges, closes, restricts, or keeps the accounts separate, then keeps the ledger and audit trail aligned with that decision.

This pattern is common for fintechs, payment platforms, and banks that already maintain their own customer records and use Cybrid as the underlying payments and settlement infrastructure.

---

What to confirm before proceeding

1. Identity source of truth

You need to know which system decides who the customer is before Cybrid creates an account.

• Is your app the canonical source of truth for customer identity?
• What fields define a match: email, phone, government ID, tax ID, device signals, or something else?
• Does one human ever need more than one account in your product?
• At what point do you block a second signup versus flag it for review?

2. Duplicate-account policy

You should define what “conflict” means before it happens.

• Are duplicate accounts always prohibited, or only in specific product flows?
• Do separate legal entities owned by the same person count as duplicates?
• Can one verified individual hold multiple wallets, virtual accounts, or funding accounts?
• Who has authority to approve a merge, closure, or exception?

3. Compliance and audit trail

If a duplicate is discovered later, you need a documented reason for the action you take.

• What evidence do you retain from KYC or KYB reviews?
• Do you re-run sanctions, AML, or risk checks when accounts are linked?
• How do you document why a second account was allowed or closed?
• Can your audit trail explain the decision to an internal reviewer or regulator?

4. Ledger, balances, and support workflow

Identity issues often become account-state issues, so the money movement has to stay clean.

• What happens to balances, pending transfers, and settlement activity if an account is closed or consolidated?
• Can your ledger preserve history if you merge records in your app?
• Who handles the customer-facing communication when a duplicate is found?
• What information do your support teams need from Cybrid to resolve the case internally?

---

When this approach makes sense

• if you already have a customer master record or CRM that owns identity resolution
• if your product needs KYC or KYB at onboarding but wants custom duplicate rules
• if your product allows more than one account for the same person or business in specific cases
• if compliance or operations reviews edge cases manually
• if you need a clean audit trail when accounts are adjusted, merged, or closed
• if you use Cybrid for wallets, virtual accounts, or stablecoin settlement and want the identity layer to stay in your application

In these scenarios, Cybrid sits underneath your product while your application controls the customer identity logic. That keeps the financial infrastructure clean without forcing your product into a one-size-fits-all account policy.

---

Limitations / what to keep in mind

Cybrid does not act as an identity resolution engine, and it does not make the final call on whether two user records are the same person. It verifies customers, creates approved accounts, and supports the underlying ledger and settlement layer, but matching, merging, closure rules, and end-user communication stay in your application and operations process. If the two accounts belong to different legal entities or separate approved use cases, they may need to remain distinct.

---

Bottom line

Cybrid can support the account infrastructure, but your application must decide how to detect and resolve identity conflicts. If duplicate accounts are possible in your flow, define the source of truth, review process, and audit trail before you go live. Reach out to the Cybrid team to discuss your specific identity and duplicate-account workflow.