# Commercial Identity Synthesis

## Source Type

identity-canon research synthesis connecting commercial theory, law, regulation,
and software practice to the canonical model.

## Domain

Cross-cutting commercial identity — binding, trust, persistence, and layer separation.

## Why This Source Matters

This note captures the research prompt: **identity and commerce are tightly coupled
in practice**. Conceptual or login-only identity can remain fluid when no commercial
value or enforceable promises attach. **Commercial binding** increases an identity's
relevance to other actors and creates foundations for trust, shared information, and
durable relationships.

## The Binding Gradient

| Stage | Commercial stake | Identity behavior | Canon pattern |
| --- | --- | --- | --- |
| Anonymous browse | None | Fluid, discardable | Persona, ephemeral Identifier |
| Free trial / lead | Low | Pseudonymous, reversible | Account + weak Commercial Record |
| Paying subscriber | Medium | Stable tenant + billing ID | Organization + Tenant + Commercial Record |
| KYC/AML customer | High | Verified, monitored, retained | Commercial Record + Evidence + BO linkage |
| Regulated markets (LEI) | Very high | Renewed legal identity, ownership public | Legal Entity + LEI Identifier + Lifecycle |
| Contractual enterprise | High | Agency, seals, signatures | Commercial Commitment + Representation |

**Insight:** fluidity is not a bug — it is rational when commercial externalities are
absent. Binding is what makes identity **economically and legally salient**.

## Layer Model (Commercial + Identity)

```text
Actor Layer          Natural Person, Organization, Legal Entity
Record Layer         Account (access), Commercial Record (billing/CRM/regulatory)
Reference Layer      Identifiers (LEI, DUNS, UEI, VAT, stripe_customer_id)
Relationship Layer   Commercial Relationship, Representation, Ownership, Trust
Commitment Layer     Commercial Commitment (contract, subscription, payment mandate)
Evidence Layer       KYC files, credit history, registry extracts, qualified credentials
Projection Layer     Auth Subject, Auth Principal (unchanged — not commercial roots)
```

Commerce does not replace identity layers; it **selectively hardens** them when
counterparties must rely, sue, invoice, or report.

## How Binding Creates Trust

From commercial theory and practice:

1. **Attribution**: counterparties know **who** bears liability (legal person, BO, agent).
2. **Commitment**: contracts, subscriptions, and payment authorizations create **costly exit**.
3. **Evidence**: KYC, LEI, registry credentials, and credit files provide **verifiable history**.
4. **Reputation**: PAYDEX, performance history, and repeat play increase **trust without re-verification**.
5. **Enforcement**: law of agency and contract makes promises **actionable** beyond platform ToS.

Trust Relationship in canon should often be **justified by** Commercial Relationship +
Commercial Commitment + Evidence, not declared ad hoc.

## Software Mirrors (Practical)

| System | Commercial artifact | Identity separation lesson |
| --- | --- | --- |
| Stripe | Customer | Billing ≠ login |
| Salesforce | Account / Contact | CRM ≠ User |
| Auth0/Stytch | Organization / Member | Subscriber ≠ billing record |
| KYC platforms | Customer profile + BO | Regulated counterparty ≠ session |
| GLEIF | LEI | Legal entity ID for markets |
| D&B | DUNS + PAYDEX | Credit identity + reputation |
| eIDAS/EUDI | Legal person wallet | Qualified org credentials |

## Canon Decisions From This Research

### Rejected

- **Customer Account** as canonical type (overloads layers).

### Added / strengthened

- **Commercial Record** — billing, CRM, regulatory counterparty records.
- **Commercial Relationship** — vendor/customer commercial link.
- **Commercial Commitment** — enforceable or costly promise binding parties (contract,
  subscription, payment mandate, regulatory onboarding acceptance).
- **Beneficial Ownership Relationship** — dedicated type from Natural Person to
  Organization/Legal Entity for KYC/CDD (not Ownership subtype).
- **Registry Identifier** and **Proxy Commercial Identifier** — Reference layer
  subtypes with authority class, ICD scheme, and renewal lifecycle.

### Unchanged roots

- **Actor** remains participation root.
- **Account** remains operational access record.
- Login, authz, and social layers unchanged; commerce **binds** them when stakes require.

## Fluid ↔ Bound Transitions

Model as lifecycle events, not silent merges:

- Lead → Account (CRM conversion): weak → medium evidence.
- Trial → paid subscription: attach Commercial Commitment + payment Credential.
- Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
- Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.

## Scenario Impact

- **S04 (vendor/customer tenants)**: add Commercial Record per customer tenant, Commercial
  Commitment for subscription/contract.
- **S14 (pseudonymous profile)**: incompatible with active Commercial Commitment unless
  explicitly scoped (e.g., marketplace escrow with privacy partition).
- **S15 (legal entity + tenants)**: LEI/registry Identifier + Commercial Record + renewals.

## Research Gaps

- Payment Credential vs. authentication Credential boundary in PCI contexts.
- Smart contracts and automated Commercial Commitment lifecycle.
- Synonymity strength bands for LEI ↔ DUNS ↔ company reg crosswalks.
- Reputation as first-class canon concept vs. Evidence Source aggregation.
- Standard `control_basis` enum for Beneficial Ownership across jurisdictions.

## Source Notes in This Stack

- `commercial-trust-binding-theory.md`
- `legal-person-agency-contract.md`
- `lei-gleif-legal-entity-identifier.md`
- `duns-commercial-credit-identity.md`
- `kyc-aml-commercial-identity-binding.md`
- `eidas-eudi-legal-person-wallet.md`
- `salesforce-crm-commercial-record.md`
- `beneficial-ownership-kyc-boi.md`
- `registry-identifier-subtypes.md`
- `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
- `../commercial-subscription/stripe-customer-billing.md`

## References

See individual source notes. Primary external anchors: GLEIF/ISO 17442, FinCEN CIP,
EU eIDAS, D&B DUNS, Salesforce Account model, Auth0/Stytch org tenancy, FATF digital identity.